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
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
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
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
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,
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo