Dobrý den,
mám server s Asteriskem, který momentálně testuji. Nemohu vytvořit více, než 1023 hovorů, při generování zátěže dojdu k tomuto počtu hovorů, bez transkódování, s cca 30-40% využitím procesoru a NIC je vytížena 88 Mbps z 1000 Mbps. Prostoru na blokovém zařízení je dostatek, a operační paměť je více než z 80% volná. Generátor je připojený do Gbps přepínače, server taktéž. Každému hovoru, který je více, než 1023. se nevytvoří další socket a Asterisk se pak pochlubí touto hláškou:
[Mar 22 15:36:10] WARNING[1020]: chan_sip.c:3587 __sip_xmit: sip_xmit of 0x7f746 d358340 (len 480) to 172.16.100.153:5060 returned -1: No buffer space available
[Mar 22 15:36:10] WARNING[1020]: acl.c:495 ast_ouraddrfor: Cannot connect
Pro skupinu asterisk je nastaveno vyšší limit file deskriptorů v /etc/security/limits.conf (píši zpaměti, ale nějak tak to je):
asterisk hard nofile 65535
asterisk soft nofile 65535
A taktéž v init skriptu Asterisku je toto navýšeno (volá se tam ulimit -n $parametr).
Volných prostředků je dostatek, poradili byste mi, jak navýšit počet otevřených UDP socketů, abych mohl propojit mezi sebou více uživatelů? S transkódováním u zdrojových kodeků je změna u využití RAM minimální, u procesoru je výraznější, ale i tak je mým limitem 1023 hovorů. Potřeboval bych ten server dostat z hlediska zatížení opravdu "na kolena".
Můžeš poslat aktuální výstup příkazu ulimit -aH?
Výstup po bootu je tento:
root@debian:~# ulimit -aH
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
V init scriptu asterisku se mi nereflektuje do "open files" ulimit -n 65536, musím ho tedy zadávat ručně, ale nevidím, že by to mělo nějaký efekt.
Zatim jsem se s timto problemem nepotykal, ale podle toho co jsem četl tak limits.conf je kongigurak pro pam_limit.
Prikaz "ulimit -aH" ti pak ukazuje harlimity na urovni kernelu (nastavitelny v /proc filesystemu).
Tzn. cokoliv nastavujes nema smysl, protoze kernel ma limity viz vyse a pres ne nejede vlak :-) (open file = 1024).
Nemam odkouzeseno ale zkus mrknout na tuto hodnotu v /proc:
cat /proc/sys/fs/file-max
Predpokladam, ze tam budes mit prave vyse uvedenych "1024". Mela by to byt hodnota,
podle ktere kernel nastavuje svuj hard limit.
Takze "echo 2048 > /proc/sys/fs/file-max" by mela zmenit hardlimit na 2048. A pak bys mel mit moznost nastavit limit pro usera az do 2048 atd.
Dej vedet jestli to vali :-).
Zkusím to a ozvu se - teď musím vyřešit problém s generátorem, občas odmítá generovat hovory ;-).
Hodnota, která tam byla a stále je:
root@debian:~# cat /proc/sys/fs/file-max
817845
Jediné, co se blíží k hodnotě 1022 je open files (ulimit -n). A ani když nastavím "open files" na více, než 1024, tak se nic nezmění, generátor si generuje více, ale na 1022 to končí na straně asterisku.
Tak tim padem asi neni problem na urovni kernelu. Podle toho co jsem cetl, tak ulimit nastavi dany limit ji v kontextu daneho skriptu. Jak jsi nastavil limit v asterisku?
Asterisk je momentálně bez jakéhokoli limitu a spoléhá se na omezení systémem (podle toho, jak chápu konfigurační soubory, tak limit na celkový počet hovorů není záležitostí asterisku). Vypadá to, že asi více hovorů neutáhne.
asi jsi uz cetl ale jen pro jistotu: http://www.voip-info.org/wiki/view/Asterisk+dimensioning
mam na ustredne jen 5 uzivatelu, tak se mi v tom ted moc nechce rypat :-(
Četl jsem, dva 4 jádrové procesory E5300 (4 roky staré Core 2) zvládnou 1500 hovorů. Já jsem na 1022 hovorech u nového Core i7 na 4 jádrech s HT na virtuálním stroji (přiděleny pouze 4 jádra).
Zkoušel jsem navýšit počet RTP portů, ale taktéž bez výsledku. Kroky podle toho článku "asterisk dimensioning" jsem provedl již v prvním kroce, a nic. 1023 je finální počet kanálů, jestli nenajdu něco jiného, tak je to asi konečná.