Re: [SR-Users] async workers causing unexplained high load average

2014-10-31 Thread Daniel-Constantin Mierla
Hello, back in the discussion after being traveling. Interesting, because it shows like being the normal recvfrom() done on the internal socket, expecting to be no load there. I have seen the backtrace you sent in previous email and it is in the same recv function from the system. The process is

Re: [SR-Users] async workers causing unexplained high load average

2014-10-24 Thread Alex Balashov
I also find this in 'dmesg' about the async workers periodically: INFO: task kamailio:4480 blocked for more than 120 seconds. Not tainted 2.6.32-431.29.2.el6.x86_64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kamailio D 0001 0 4480 44

Re: [SR-Users] async workers causing unexplained high load average

2014-10-24 Thread Alex Balashov
But most of the time, I do get this from both processes: (gdb) where #0 0x7fb699e07673 in __recvfrom_nocancel () from /lib64/libc.so.6 #1 0x0042c10c in async_task_run (idx=2) at async_task.c:201 #2 0x0042b449 in async_task_child_init (rank=0) at async_task.c:144 #3 0x0

Re: [SR-Users] async workers causing unexplained high load average

2014-10-24 Thread Alex Balashov
Hi Daniel, On 10/24/2014 09:03 AM, Daniel-Constantin Mierla wrote: Can you attach with gdb to one of the async processes and see with the backtrace command what is the process doing at that time? Sometimes I can do this: (gdb) where #0 0x7f4c17007673 in __recvfrom_nocancel () from /lib6

Re: [SR-Users] async workers

2014-10-24 Thread Alex Balashov
Vitaliy, The argument against more workers holds that the specific interprocess communication used by them causes one to reach the point of diminishing returns rather quickly, due to contention and locking. In many applications, one can create dozens of hundreds of workers in such a situation,

Re: [SR-Users] async workers

2014-10-24 Thread Vitaliy Aleksandrov
Hi, What is the practical limit to the number of async worker processes? With SIP child processes, it seems to be about the number of available CPUs in /proc/cpuinfo. After that--at least, per my testing--one begins to hit the point of diminishing returns, presumably due to SHM IPC and synchro

Re: [SR-Users] async workers

2014-10-24 Thread Alex Balashov
Thanks, Daniel. So, does this mean that the module "reserves" a "workers" number of common async_workers for its exclusive use? Or do those async_workers just receive whatever they are sent from any number of modules? In that case, what exactly is the role of the "workers" parameter? To limit th

Re: [SR-Users] async workers

2014-10-24 Thread Frank Carmickle
On Oct 24, 2014, at 9:15 AM, Daniel-Constantin Mierla wrote: > > On 23/10/14 04:03, Alex Balashov wrote: >> Also, what is the point of core async_workers setting versus the >> 'workers' modparam to async? Are they supposed to equal each other? >> Does one override the other? > > async_workers

Re: [SR-Users] async workers

2014-10-24 Thread Daniel-Constantin Mierla
On 23/10/14 04:03, Alex Balashov wrote: > Also, what is the point of core async_workers setting versus the > 'workers' modparam to async? Are they supposed to equal each other? > Does one override the other? async_workers from core are common for all modules, being a decision not to have each mod

Re: [SR-Users] async workers

2014-10-24 Thread Alex Balashov
On 10/24/2014 09:07 AM, Daniel-Constantin Mierla wrote: Hello, On 23/10/14 03:36, Alex Balashov wrote: Hi, What is the practical limit to the number of async worker processes? With SIP child processes, it seems to be about the number of available CPUs in /proc/cpuinfo. After that--at least, p

Re: [SR-Users] async workers

2014-10-24 Thread Daniel-Constantin Mierla
Hello, On 23/10/14 03:36, Alex Balashov wrote: > Hi, > > What is the practical limit to the number of async worker processes? > > With SIP child processes, it seems to be about the number of available > CPUs in /proc/cpuinfo. After that--at least, per my testing--one > begins to hit the point of d

Re: [SR-Users] async workers causing unexplained high load average

2014-10-24 Thread Daniel-Constantin Mierla
Can you attach with gdb to one of the async processes and see with the backtrace command what is the process doing at that time? Cheers, Daniel On 24/10/14 05:30, Alex Balashov wrote: > I just tested the same thing on a Rackspace VPS (Xen I think) and am > seeing the same climbing load average wi

Re: [SR-Users] async workers causing unexplained high load average

2014-10-23 Thread Alex Balashov
I just tested the same thing on a Rackspace VPS (Xen I think) and am seeing the same climbing load average with 2 async workers. It seems to top out at 1.05. On 10/23/2014 02:13 PM, Alex Balashov wrote: Another thing I have found is that having a certain amount of async workers running, even

Re: [SR-Users] async workers

2014-10-22 Thread Alex Balashov
Also, what is the point of core async_workers setting versus the 'workers' modparam to async? Are they supposed to equal each other? Does one override the other? On 10/22/2014 09:36 PM, Alex Balashov wrote: Hi, What is the practical limit to the number of async worker processes? With SIP ch