Mezipaměť sousedů v jádře Linuxu není tak jednoduchá.
Existují nepatrné rozdíly mezi tím, zda záznam z vyrovnávací paměti sousedů skutečně úplně vypadne, nebo je pouze označen jako zastaralý/neplatný. V určitém okamžiku mezi base_reachable_time /2 a 3* base_reachable_time /2, záznam bude stále v keši, ale bude označen stavem STALE. Měli byste být schopni zobrazit stav pomocí "ip -s soused show".
Když jsem ve stavu STALE, jako je uvedeno výše, když pingnu na 10.64.42.121, paket okamžitě odešle na b8:20:00:00:00:00. O sekundu později obvykle odešle požadavek ARP pro toho, kdo má 10.64.42.121, aby aktualizoval svou mezipaměť zpět do stavu REACHABLE. ALE, aby to bylo ještě více matoucí, jádro někdy změní hodnoty časového limitu na základě pozitivní zpětné vazby od protokolů vyšší úrovně. To znamená, že když pingnu na 10.64.42.121 a ono odpoví, pak se jádro nemusí obtěžovat odesláním požadavku ARP, protože předpokládá, že pong znamenal, že jeho záznam v mezipaměti ARP je platný. Pokud je záznam ve stavu STALE, bude také aktualizován nevyžádanými odpověďmi ARP, které náhodou vidí.
Nyní je ve většině případů vše, o co se musíte starat, že je záznam ve stavu STALE. Proč potřebujete, aby byl záznam zcela odstraněn z mezipaměti? Jádro vynakládá velké úsilí na to, aby paměť nemlátilo tím, že pouze změnilo stav položek mezipaměti namísto toho, aby je neustále odstraňovalo a přidávalo do mezipaměti.
Pokud opravdu opravdu trváte na tom, že bude nejen označena jako STALE, ale bude skutečně odstraněna z hashmapy používané v sousedské keši, musíte si dát pozor na pár věcí. Za prvé, pokud záznam nebyl použit a je zastaralý po dobu gc_stale_time sekund, měla by být způsobilá k odstranění. Pokud gc_stale_time prošel a označil záznam jako v pořádku k odstranění, bude odstraněn při spuštění garbage collector (obvykle po gc_interval sekund).
Nyní je problém v tom, že položka souseda nebude odstraněna, pokud je na ni odkazováno . Hlavní věc, se kterou budete mít problémy, je reference ze směrovací tabulky ipv4. Je tu spousta komplikovaných věcí pro sběr odpadu, ale důležité je poznamenat, že sběrač odpadu pro mezipaměť trasy vyprší platnost položek pouze každých 5 minut (/proc/sys/net/ipv4/route/gc_timeout sekund) na mnoha jádrech. To znamená, že sousedský záznam bude muset být označen jako zastaralý (možná 30 sekund, v závislosti na base_reachable_time ), pak bude muset uplynout 5 minut, než mezipaměť trasy přestane odkazovat na záznam (pokud budete mít štěstí), následuje nějaká kombinace gc_stale_time a gc_interval projde, než bude skutečně vyčištěn (takže celkově uplyne něco mezi 5-10 minutami).
Shrnutí:můžete zkusit snížit /proc/sys/net/ipv4/route/gc_timeout na kratší hodnotu, ale je tam hodně proměnných a je těžké je všechny ovládat. Aby věci fungovaly dobře, bylo vynaloženo velké úsilí tím, že se položky z mezipaměti neodstraňují příliš brzy (ale místo toho je pouze označíte jako STALE nebo dokonce FAILED).
gc_stale_time
je správný parametr, který lze vyladit, aby se vyloučily položky STALE z tabulky ARP. Ale je toho víc:
ARP garbage collection se spouští v pravidelných intervalech neigh_periodic_work
funkce. Interval lze upravit pomocí proměnné /proc/sys gc_interval
.
Poté zkontroluje, zda existuje alespoň gc_thresh1
záznamy v tabulce ARP. Tím se vyhnete spotřebě dalších cyklů CPU, pokud je tabulka příliš malá na to, aby viděla nějakou skutečnou výhodu, pokud jde o paměť.
Ve vašem případě mám podezření na gc_thresh1
je proměnná, kterou budete chtít vyladit. jeho snížení přinutí GC běžet častěji. To však může mít negativní dopad na výkon v závislosti na intervalu běhu.
Poznámka:gc_thresh3
je tvrdý práh. Tabulka nikdy neuchová více položek, než je tato hodnota. Vylaďte to opatrně.