Nedávno se mi v error logu nginxu objevila řada následujících chyb:

2013/09/14 21:05:01 [alert] 26115#0: phantom event 0001 for closed and removed socket 21
2013/09/29 08:52:59 [alert] 49045#0: phantom event 0004 for closed and removed socket 17
2013/09/30 16:51:37 [alert] 49045#0: phantom event 0001 for closed and removed socket 46
2013/10/09 11:01:15 [alert] 92940#0: phantom event 0004 for closed and removed socket 28

Samozřejmě jsem nejprve Googloval a v prvních pár dotazech našel odpověď. Mám ale ve zvyku nejprve pochopit, co vlastně tomu serveru cpu do konfigurace a proč to vyřešit právě takto a ne jinak. Zkoumal jsem tedy dál a snad i pochopil, v čem je vlastně jádro problému.

Proč vlastně tento problém vzniká?

• Nginx je asynchronní server. Veškeré operace zpracovává během iterací tzv. event loop-u (také nazývaného IO loop).
• Solaris nginxu předává eventy (připojení klientů) tzv. poll-em pomocí zařízení /dev/poll.
• Chyba vzniká nekonzistencí při práci nginxu s /dev/poll, který vrací eventy hromadně v jedné iteraci.
• Výchozí limit eventů předaných kernelem nginxu je pro /dev/poll nastaven na 32.
• Nginx při práci s jednotlivými eventy otevírá jejich sockety postupně. Když chce zpracovat další, musí současný socket zavřít. Pokud tedy kernel předá nginxu až 32 eventů (spojení s klienty), při větším vytížení serveru se může stát, že event již není aktivní (klient se odpojil).
• Dá se to vyřešit tím, že nginx donutíme přijímat od kernelu vždy jen jeden event během iterace. V confu to nastavíme parametrem devpoll_events.
• Na výkonu nginxu by se to mělo projevit jen neznatelně.

events {
    devpoll_events 1;
}

Jaký je skutečný důvod vzniku problému?

Ačkoliv tímto nastavením zařídíme, aby si už nginx nestěžoval do logu, příslovečný pes je zakopaný někde jinde. Kernel má totiž limity pro maximální počet navázaných a příchozích spojení, které jsou v základu poměrně malé. Pokud server obdrží nový požadavek na spojení, který se nevejde do bufferu, starší spojení se zahodí.

Parametry tcp_conn_req_max_q a tcp_conn_req_max_q0

Parametry tcp_conn_req_max_q a tcp_conn_req_max_q0 určují maximální počet požadavků, které mohou být přijmuty na jednu IP adresu a jeden port. tcp_conn_req_max_q je maximální počet příchozích spojení, které mohou být akceptovány (accepted) na IP a port. tcp_conn_req_max_q0 je maximální počet „polovičně otevřených“ (half-open) TCP spojení, které mohou existovat na portu. Parametry jsou odděleny kvůli efektivnímu blokování SYN segment denial of service útoků.

Jak zjistit, zda byly limity překročeny?

netstat -s|grep ListenDrop

• Pokud je tcpListenDrop nenulový, je potřeba navýšit tcp_conn_req_max_q.
• Pokud je tcpListenDropQ0 nenulový, je potřeba navýšit tcp_conn_req_max_q0.

Ale počkat! Není to zase tak úplně jednoduché. Navýšením tcp_conn_req_max_q na příliš vysoké hodnoty můžeme otevřít cestu pro SYN segment denial of service útoky. Solaris to má ale díky oddělení parametrů dobře vymyšleno. Navyšujte tcp_conn_req_max_q v násobcích 256. Použijte tcp_conn_req_max_q0 pro zvýšení počtu „polovičně otevřených“ TCP spojení. Pokud nginx nebo jiný server nemůže zpracovávat spojení dostatečně rychle, zvýšení tcp_conn_req_max_q0 může zabránit tomu, že se klienti nebudou schopni připojit. Spojení klientů zůstávají v „polovičně otevřeném“ stavu, dokud je nginx nezpracuje.

Jak limity nastavit?

ndd -set /dev/tcp tcp_conn_req_max_q 4096
ndd -set /dev/tcp tcp_conn_req_max_q0 8192

Pozor! Po nastavení limitu je potřeba restartovat nginx nebo jiné aplikace, kterých se to týká! Také tato nastavení se vyresetují restartem systému. Jak je nastavit permanentně si řekneme ale až v příštím článku 🙂

Zdroje

• Phantom event for closed and removed socket
• Solaris TCP/IP parameters: tcp_conn_req_max_q and tcp_conn_req_max_q0

Rozchodit Sphinx daemon ve SmartOS zóně chce trochu snahy navíc. Hned po instalaci nefunguje.

Sphinx by měl být v zóně vytvořené z image base64 (alespoň od verze 13.1.0) již předinstalovaný. Ověřit si to můžeme pomocí pkgin:

# pkgin se sphinxsearch
sphinxsearch-2.0.8 = Sphinx Full-Text Search Engine

Následně jej aktivujeme pomocí svcadm:

svcadm enable sphinx

V tuto chvíli Vám ale fungovat nebude:

# svcs -a|grep sphinx
maintenance    15:25:22 svc:/pkgsrc/sphinx:default

Zobrazíme si tedy log SVC:

# tail /var/svc/log/pkgsrc-sphinx\:default.log
[ Aug 28 15:18:00 Enabled. ]
[ Aug 28 15:18:00 Could not interpret "user" property value "pbulk", error 2. ]

Vypadá to, že v systému nemáme uživatele pbulk. Ale zakládat jej nebudeme, pro sphinx už totiž uživatel připraven je:

# cat /etc/passwd|grep sphinx
sphinx:x:1001:1001:sphinxsearch sphinx user:/nonexistent:/usr/bin/false

Nastavíme tedy SVC, aby daného uživatele použilo:

# svccfg -s pkgsrc/sphinx setprop method_context/user=astring: sphinx
# svccfg -s pkgsrc/sphinx setprop method_context/group=astring: sphinx
# svcadm refresh sphinx
# svcadm clear sphinx

Sphinx ale stále neběží, máme tu ještě jeden problém:

# tail /var/svc/log/pkgsrc-sphinx\:default.log
[ Aug 28 15:24:08 Leaving maintenance because clear requested. ]
[ Aug 28 15:24:08 Enabled. ]
[ Aug 28 15:24:08 Executing start method ("/opt/local/bin/searchd -c /opt/local/etc/sphinx.conf"). ]
[ Aug 28 15:24:08 svc.startd could not set context for method:  ]
[ Aug 28 15:24:08 chdir: No such file or directory ("/nonexistent") ]
[ Aug 28 15:24:08 Method "start" exited with status 96. ]

Vypadá to, že složka, ve které má uživatel sphinx svůj home, neexistuje. Změníme ji na existující:

# usermod -d /var/spool/sphinx sphinx

Nyní už by nám měl Sphinx vpořádku naběhnout. Pokud tedy máme správně nastaven conf a vygenerované indexy.

# svcadm clear sphinx
# svcs -a|grep sphinx
online         15:25:22 svc:/pkgsrc/sphinx:default

Docela jsem si zvykl na htop a ačkoliv ve SmartOS zónách funguje, v globální zóně tomu tak není. Pro svůj chod htop potřebuje linuxový /proc filesystém, který v globální zóně není. S trochou snahy jej ale můžeme dodat.

Pokud jste ještě do globální zóny nenainstalovali pkgin, je právě čas. Návod najdete na wiki smartosu. Samotný htop pak snadno nainstalujeme pomocí příkazu:

pkgin in htop

Nyní vytvoříme shell shkript, který nám namountuje lxproc a umístíme jej do souboru /opt/custom/method/fs-lxproc.

#!/sbin/sh

. /lib/svc/share/smf_include.sh

if smf_is_globalzone; then
    mkdir /system/lxproc
    mount -F lxproc lxproc /system/lxproc
fi

exit $SMF_EXIT_OK

Adresář /op/custom a jeho podadresáře ještě pravděpodobně vytvořeny nemáte, založte je tedy. Budeme pokračovat vytvořením XML definice pro SMF, aby se náš mount skript spouštěl automaticky. Skript uložíme do souboru /opt/custom/smf/lxproc-fs.xml. Do tohoto adresáře lze uložit i jiné definice SMF služeb, SmartOS je při bootu načte a spustí.

Nakonec XML definici načteme do SMF.

svccfg import /opt/custom/smf/lxproc-fs.xml