Results 1 to 7 of 7

Thread: HUGE CPU use

  1. #1

    Default HUGE CPU use

    We're battling with a very odd problem. We're brining on about one hundred new rtmp streams, encoding from digital rapids. This is what we see so far.

    We are seeing multiple issues but i shall highlight a few.

    When pushing about 30 2mbps streams to a wowza on Ubuntu/Centos we see massive CPU loading when using a 'live' type, but not 'default'. We removed the http segmenters stuff from the Application.xml to eliminate that.

    We dont see the issue from FMLE, only digital rapids and exaggerated when using b-frames. We see the problem much worse from the 64 bit version of DR Stream.

    I am thinking its to do with video/audio sync problems and have added the <sortPackets> lines to the Application.xml - doesn't help. We have tuned and fiddled and tried most things, different versions of Java etc

    ****It doesn't happen on another machine running windows 7****

    Dodgy hardware? But why invoked when going from type 'default' to type 'live'

    Please help its driving us mad.

  2. #2

    Default

    Update, we changed the machine, 24 core, 16GB ram, HP box.

    When we push to the server when type is 'default' we dont see much CPU use. However moving to type 'live' increases loading by about 1000%

    Whats up?

  3. #3
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    I don't understand what you are comparing. You have 100 incoming live streams? You are switching from "default" to "live" for that application?

    Incoming live streams are limited by CPU and memory, whereas outgoing (play) streams are usually limited by bandwidth. 100 incoming live streams is a lot. You can get more on some hardware, I have heard of up to 200, but not much more usually.

    Richard

  4. #4

    Default

    Quote Originally Posted by rrlanham View Post
    I don't understand what you are comparing. You have 100 incoming live streams? You are switching from "default" to "live" for that application?

    Incoming live streams are limited by CPU and memory, whereas outgoing (play) streams are usually limited by bandwidth. 100 incoming live streams is a lot. You can get more on some hardware, I have heard of up to 200, but not much more usually.

    Richard
    Yes, actually the issue seems not to be to do with the number on incoming streams but the total bitrate of incoming streams. What we suspect to be the case is that when we are reaching the upper limits of the switch ports 80 mbps, we see increase CPU use when the application type is set to live. Moving the the type to deafult, reduces the CPU usage considerably.

    The only thing I can think of is that the difference between live and default is some notion of latency. In the case of live streaming this would be required but not for on-demand. If the network ports were to be a little stressed and the network packets were a little disorganised the wowza server would have to be waiting and rebuilding, disjointed live streams therefore making the CPU use go up.

    To confirm this we are putting both encoder and server on the same gig switch and re-testing.

    Can you please let me know what other differences there are between type live and default which might potentially give raise to large CPU use?

    Thanks,

    Joe

  5. #5

    Default

    Quote Originally Posted by brayster99 View Post
    To confirm this we are putting both encoder and server on the same gig switch and re-testing.
    Done and this makes no difference. What is going on? Default install of latest wowza. Push 20 streams of 3 mbps each. Followed the performance tuning advice. With the application type set to deafault we see very little CPU use. When changing nothing but the application type to live, a 24 core runs at about 75% utilisation across all of its cores. We have tried with different hardware AND os's.

    please help.

  6. #6

    Default

    Hi,

    Can you please zip up your conf & logs folders and send to support@wowza.com. Please include a reference to this forum post.

    Regards,

    Roger.

  7. #7

    Default

    Found it! It was a bug in the Digital rapids stream 3.7 implementation of their CBR+filler AVC codec. Heavens knows what it was doing but it seriously killed the wowza server. DR are aware of the problem and will be fixing.

    Thanks for your help.

    Quote Originally Posted by roger_l View Post
    Hi,

    Can you please zip up your conf & logs folders and send to support@wowza.com. Please include a reference to this forum post.

    Regards,

    Roger.

Similar Threads

  1. more CPU cores get weaker performance than less CPU cores
    By lidabnu@126.com in forum Performance and Tuning
    Replies: 13
    Last Post: 01-06-2016, 12:53 AM
  2. Huge latency on mobile devices for live stream
    By ynot2k in forum Live Streaming and Encoders
    Replies: 6
    Last Post: 09-05-2014, 11:27 PM
  3. High Cpu usage AMD Opteron Dual CPU Server.
    By djcenk in forum Performance Tuning Discussion
    Replies: 1
    Last Post: 11-26-2013, 08:11 AM
  4. CPU Dual Core CPU 8GB RAM
    By peuapeu in forum General Forum
    Replies: 4
    Last Post: 10-03-2013, 03:17 AM
  5. Huge delay on iOS stream compared to Flash
    By krissy in forum Wowza Media Server 3 for Amazon EC2 Discussion
    Replies: 1
    Last Post: 07-18-2012, 11:56 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •