We kregen de laatste tijd van klanten vaak vragen over de betekenis van de melding ‘STALE’ in de N2 monitoring interface. In het kort betekent deze melding dat, op een gegeven tijdstip, de UDP-pakketjes die de n2txd-agent naar ons monitoring-systeem stuurt niet zijn aangekomen. Als dit een enkele keer bij een VPS voorkomt maar hij niet minutenlang in die staat blijft hangen is er op zich geen reden tot ongerustheid, maar liever zien we ze natuurlijk helemaal niet.

Ons vermoeden voor het vaker voorkomen van deze meldingen was dat het iets te maken had met de netwerk-interface van de monitoring machine. We hebben deze onlangs dan ook vervangen door nieuwere hardware met een A-merk netwerkkaart. Helaas bleken we hiermee op een dood spoor te zitten, de meldingen bleven bij vlagen verschijnen.

Uiteindelijk bleek de oorzaak te liggen in een veel subtieler schaalprobleem. Het programma dat verantwoordelijk is voor het ontvangen en verwerken van de UDP-pakketjes was tot nog toe een single-threaded daemon die in de in een ‘infinite loop’ iedere keer op een UDP-pakketje wachtte, dit pakketje verwerkte, eventueel wat opruimwerk verrichte en dan weer op een pakketje wachtte. Dit ontwerp had voor de eerste paar duizend hosts geen enkel probleem en het programma gebruikt, ook nu, nooit echt veel CPU.

De stap ‘opruimwerk’ bleek echter een onvoorspelbare factor. Deze duurde soms net lang genoeg dat een hoger aantal UDP-pakketjes zich opstapelde in de kernel. Als deze wachtrij te lang werd, dan begon de kernel doodleuk met het weggooien van volgende pakketjes.

De software is nu aangepast naar een multi-threaded ontwerp, waarbij een losse achtergrond-thread alleen de verantwoordelijkheid heeft voor het uit de kernel-wachtrij trekken van de UDP pakketjes. Hierdoor kunnen deze zich niet meer opstapelen en zijn de STALE-meldingen als het goed is verleden tijd.