qualify problem

kovzol
Joined: Fri 10 of Aug, 2007

Re: qualify problem

Posted:Mon 13 of Oct, 2008 (19:50 UTC)
It seems that the queue for TCP and UDP packets grew up more than the Linux kernel default. I had statistics in /proc/net/sockstat and it became clear that the queue with at most 1000 entries is too short. Now I am using 4000 which seems to solve the problem mostly.
kovzol
Joined: Fri 10 of Aug, 2007

qualify problem

Posted:Sun 12 of Oct, 2008 (20:53 UTC)
I have a problem with a 1000 user Asterisk system (max. 80 channels, 350 registered peers, hardware is Intel Core2 6420@2.13 GHz, 2 GB RAM, Broadcom NetXtreme BCM5721 Gigabit Ethernet PCI). I use qualify=yes for all peers to force not losing any peers behind NAT. Unfortunately, if the server starts to work on some other task (e.g. copy a file to a different directory, running munin statistics or similar), then about 20 peers become UNREACHABLE. Then, when asterisk continues on working using full resources, the UNREACHABLE peers become reachable.

I started to renice asterisk which helped a bit (I'm using -8 now), but it didn't give a full solution. Getting rid of munin and other parallel processes, the result is even better, but not perfect. There are no other services on my system which can be stopped to give asterisk all resources.

I don't think the solution is to disable qualify=yes for the most of the peers. What do you think? I thought this hardware should be good enough to handle such a small amount of peers. I am using asterisk-1.4.17.