Administrace komentářů

Hmm... Vy jste se nám ještě nepochlubil verzí jádra

Pokud se týče conntrack tabulky, napadá mě, že by situaci mohla zhoršovat nějaká horda zombies, která tu tabulku postupně zahltí, jak se snaží všude možně rozesílat spamy, skenovat porty nebo tak něco - ale zas mi to nepřipadá moc pravděpodobné, jednak Vaše čísla z výpisu "conntrack" takovému hlcení nenasvědčují, druhak pokud jsem měl někde tenhle typ problému, tak se zombík většinou po resetu rozjel během pár minut, pak vystropoval nějaké úzké hrdlo a už jel pořád stejně rychle (na stropě). Náběh dlouhý 10 dní je blbost. A kdyby, tak bych nečekal, že to shodí zrovna firewall... Dočetl jsem se, že se dají ladit pouze dva parametry conntrack tabulky: jednak velikost hash tabulky, jednak objem paměti, který na ni lze obětovat. Je fakt, že protní rozskok skrz hash tabulku vede na uzly, ve kterých se pak prochází spojový seznam. Nemám představu, zda je reálné, abyste v této oblasti měl problém či nikoli - kdyžtak zkuste experimentovat. Je možné, že defaulty kernelu nebo Vaší distribuce jsou zbytečně asketické

No a pak jsem našel pár dalších zmínek, co taky může způsobovat vysokou zátěž ksoftirqd. Docela často se objevovala zmínka o softwarovém bridgingu a jeho STP, kde byla by default nastavena příliš vysoká frekvence HELO zpráv. Případně snad bridging v kombinaci s dynticks. V jednom případě okolo 2.6.22 byl nějaký problém s jakýmsi časovačem v TCP stacku - to se ale pochopitelně týkalo jenom TCP provozu zakončeného v user space procesu na daném stroji, nikoli prostého forwardingu procházejících paketů...

Pokud se týče nástrojů, které mohou poskytnout nějakou představu "co to tam sakra běží", existuje několik více či méně irelevantních, např.:

• /proc/timer_stats - statistiky tikání několika různých timerů
• latencytop - nic moc, zaměřuje se víceméně na vybrané blokující syscally (a čas strávený v zablokovaných voláních), což vlastně není náš případ.
• powertop - údajně často leccos odhalí (ukazuje nejčastější "důvody probuzení")
• oprofile - konkrétně "opreport -d", tj. detailní výpis by mohl obsahovat podrobnosti až na úroveň funkcí, snad i v rámci ksoftirqd. Tenhle nástroj je asi nejmocnější, ale taky relativně náročnější na použití než ostatní (je potřeba si zkompilovat jádro s podporou oprofile, a pro samostatné debugování taky trochu rozumět Cčku a kernelovým zdrojákům)

V podstatě bych to viděl na dotaz do LKML s přiloženým detailním výpisem oprofile, ale nutnou podmínkou je, že to napřed reprodukujete na nějakém rozumně novém jádře... Staré vykopávky nikdo ladit nebude, protože ten problém byl možná dávno vyřešen.