[Freeswitch-dev] On high CPU usage and NONBLOCK-ed sockets

Steven Ayre steveayre at gmail.com
Mon Sep 6 11:52:18 PDT 2010 

Careful you don't spend more time adjusting the interval than you save. ;)

Steve on iPhone

On 6 Sep 2010, at 18:05, Oleg Khovayko <khovayko at gmail.com> wrote:

> Another idea to conserve CPU and sys-time usage - to use adaptive 
> timeouts in the timewait intervals.
> General idea: requests to our system aren't random, but correlated. For 
> example, night time
> there are too few requests, and so on.
> 
> Simple code for demonstrate algorithm following.
> There is min_interval is ~4ms, max_interval is ~524ms:
> 
> 
> uint32_t interval = 1 << 25; // ~4ms
> 
> while(usleep(interval >> 13)) { // Max 2^19us, or 524ms
>    // wake up here
>    if(need_to_do_something) {
>      do_something();
>      interval = 1 << 25; // Reset interval
>    } else {
>       // Nothing to do -- *2 interval
>       interval |= interval << 1;
>    }
> }
> 
> 
> 
> Anthony Minessale wrote:
>> Can you produce some example code that we can test on other architectures?
>> What exactly were you doing in mod_skinny? if you copied
>> mod_event_socket it may be true your blocking approach is better but
>> mod_event_socket has some high performance reasons to not block.
>> 
>> We use the centos kernel and trying to make it work better on debian
>> with a newer kernel could disrupt our stable user base.
>> 
>> consider making a mod_debug or mod_testperf we can mess with on many boxes.
>> 
>> 
>> 
>> On Fri, Sep 3, 2010 at 3:52 PM, Mathieu Parent<math.parent at gmail.com>  wrote:
>> 
>>> On Fri, Sep 3, 2010 at 8:22 PM, Anthony Minessale
>>> <anthony.minessale at gmail.com>  wrote:
>>> 
>>>> What do you mean by high cpu exactly?
>>>> 
>>> when going blocking-mode, the user CPU gets lower and the kernel CPU is similar.
>>> 
>>> 
>>>>  what are you using to measure it?
>>>> 
>>> top, vmstat
>>> 
>>> without mod_skinny
>>> mathieu at netthieu:~/apps/freeswitch/freeswitch.git$ vmstat 5 5
>>> procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
>>>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
>>>  7  0     48 175552 161664 787636    0    0     8    10  184  361  6  8 86  1
>>>  1  0     48 171948 161672 791372    0    0     0     5 4141 9191 14 12 74  0
>>>  0  0     48 171700 161684 791496    0    0     0    11 4125 9081 13  9 78  0
>>>  0  0     48 175048 161688 787860    0    0     0     3 4344 9177  7 10 84  0
>>>  6  0     48 175048 161692 787860    0    0     0     1 4225 9035  9 11 80  0
>>> 
>>> with mod_skinny NONBLOCKED
>>> mathieu at netthieu:~/apps/freeswitch/freeswitch.git$ vmstat 5 5
>>> procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
>>>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
>>>  1  0     48 172668 162104 789052    0    0     8    10  190  374  6  8 86  1
>>>  1  0     48 173528 162108 788652    0    0     0     2 4792 10346 15 13 72  0
>>>  1  0     48 173528 162124 788664    0    0     0    17 4678 10326  9 12 78  0
>>>  0  0     48 173528 162124 788628    0    0     0     1 4788 10343 10 14 77  0
>>>  9  0     48 166956 162136 792764    0    0     0    10 4592 10535 16 13 71  0
>>> 
>>> with mod_skinny BLOCKED
>>> mathieu at netthieu:~/apps/freeswitch/freeswitch.git$ vmstat 5 5
>>> procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
>>>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
>>>  0  0     48 175288 161648 787832    0    0     8    10  182  358  6  8 86  1
>>>  1  0     48 175280 161648 787824    0    0     0     0 4236 9054  7  9 83  0
>>>  7  0     48 175404 161648 787804    0    0     0     3 4173 8927  7 10 83  0
>>>  0  0     48 175280 161652 787576    0    0     0     5 4288 9182  9 10 81  0
>>>  6  0     48 175404 161656 787580    0    0     0     4 4209 9001  8 10 82  0
>>> 
>>> So it seems that both %user and %system are lower. I have not done
>>> complete tests but mod_skinny is more responsive in BLOCKING-mode
>>> 
>>> 
>>>> what OS are you on?
>>>> 
>>> Linux netthieu 2.6.32-5-686 #1 SMP Thu Aug 12 13:38:27 UTC 2010 i686 GNU/Linux
>>> 
>>> this is Debian testing using FS built from recent git using debian packaging.
>>> 
>>> 
>>> 
>>>> in my findings not more efficient, not at all reliable.
>>>> 
>>> Googling some, I found (from
>>> http://www.ibm.com/developerworks/linux/library/l-async/)
>>> 
>>> "Synchronous non-blocking I/O: A less efficient variant of synchronous
>>> blocking". This is what we are doing?
>>> 
>>> The good solutions IMO are:
>>> - Synchronous blocking I/O: simple and efficient
>>> - Asynchronous blocking I/O: not so good. use of "select" is not recommended
>>> - Asynchronous non-blocking I/O (AIO) which is a completely different
>>> API (portable?) which should fit well with FS's event model but with a
>>> lot of work
>>> 
>>> Maybe we can make it configurable at build-time (as it is in
>>> mod_skinny) to allow performance testing? Perhaps the results will be
>>> very different from one platform to another.
>>> 
>>> Mathieu
>>> 
>>> _______________________________________________
>>> FreeSWITCH-dev mailing list
>>> FreeSWITCH-dev at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>>> http://www.freeswitch.org
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> _______________________________________________
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org

More information about the FreeSWITCH-dev mailing list