Kennisbank

De afgelopen maanden speelden er issues op het VPS-platform, waardoor je VPS op willekeurige momenten verminderde prestaties kon ervaren. We bieden je onze welgemeende excuses aan voor het eventuele ongemak dat je hierdoor hebt ervaren. Nu deze issues achter de rug zijn, informeren we je via deze Post Mortem graag zo volledig mogelijk over de achtergrond en oplossing.

De verminderde performance bleek het resultaat van een bottleneck in de afhandeling van IRQ's (Interrupt ReQuests: onderbrekingen om de aandacht van de CPU te vragen) van de netwerkinterface van de hypervisor die jouw VPS host. De oorzaak van deze bottleneck is weggenomen en hierbij is tevens de netwerkcapaciteit van de hypervisors op het VPS platform verbeterd.

Om de recente issues toe te kunnen lichten, moeten we een kleine sprong terug in de tijd maken: In januari 2023 migreren we alle VPS'en in onze availability zone RTM0 vanuit Delft naar een nieuw datacenter in Alblasserdam. Geruime tijd na deze migratie ontvangen wij meldingen over issues met de performance van het platform in Alblasserdam. Interne tests wijzen erop dat dit komt door een probleem met de drivers van de netwerkinterfaces van onze hypervisors. We configureren daarom een nieuwe netwerkdriver en rollen die uit op het gehele platform. Om deze driver in productie te nemen, was het nodig om VPS'en tussen hypervisors te migreren zodat hypervisors zonder downtime van jouw VPS gereboot kunnen worden. Het migratieproces zelf zorgt hierbij voor een performance-impact op de VPS'en. Dit blijkt het gevolg te zijn van een verhoogde CPU-belasting voor het afhandelen van IRQs. Op ons PerformanceVPS-platform is een aantal CPU-cores gereserveerd voor het afhandelen van IRQ's. Om de hogere belasting te compenseren, verspreiden we de afhandeling van IRQ's tijdelijk over alle CPU-cores van de hypervisors.

Na het implementeren van de nieuwe driver ervaren we op dat moment geen issues meer in Alblasserdam en besluiten daarom deze driver ook uit te rollen in onze availability zone AMS0 in Amsterdam. Ondanks onze voorbereidingen zorgt dit medio december 2023 voor vergelijkbare issues als tijdens het implementeren van de driver in Alblasserdam. Uit onderzoek door onze engineers blijkt dat de nieuwe driver het onderliggende issue niet geheel verholpen heeft: de redundante netwerkinterfaces van de hypervisor ervaren korte momenten waarop er geen connectiviteit is. De verbinding 'flapt', wat inhoudt dat deze down gaat en onmiddellijk weer up komt. Wij vermoeden dat de hoeveelheid verkeer die de hypervisor afhandelde hiervoor zorgt: voor IO (Input/Output) gereserveerde CPU-cores op de hypervisor worden dusdanig belast dat netwerkpakketjes niet tijdig worden beantwoord door de hypervisor en een timeout optreedt. We verhogen de timeout-instellingen voor netwerkverkeer. De hypervisor krijgt zo meer tijd om op pakketjes te reageren en de verbinding 'flapt' hierna niet langer. We concluderen dat we de oorzaak van het performance-issue in de CPU-hoek moeten zoeken: de CPU lijkt tijdelijk te pauzeren, waardoor er een impact is op de performance van Ceph-IO en de reactietijd op netwerk-pakketjes. Eveneens gebeurt dit enkel bij VPS'en (die AMD-CPU's en Ceph-opslag gebruiken) en niet bij VPS'en (die Intel-CPU's en ZFS-opslag gebruiken). Daarnaast reserveren we op VPS-hypervisors geen CPU-cores voor IRQ-afhandeling, wel op VPS-hypervisors.

We escaleren het issue intern en richten een taskforce op met engineers met verschillende expertises om zo snel mogelijk de onderliggende oorzaak te achterhalen en een oplossing te vinden. Deze aanpak leidt snel tot resultaat, en medio februari kunnen wij de issues in een testomgeving reproduceren door een grote hoeveelheid IO vanaf een test-hypervisor naar een andere test-hypervisor te sturen. We zien dat vanaf circa 50Gbit/s aan netwerkverkeer de maximale throughput van de hypervisor daalt tot 1Gbit/s. Het is echter niet uitgesloten dat dit in onze productieomgeving bij lagere pieken al gebeurt. Analyse van de stacktraces van de hypervisor tonen vervolgens dat het IOMMU-pad in de driver hiervoor verantwoordelijk is. Een nieuwe driver biedt geen soelaas, maar we zijn duidelijk op het juiste spoor.

We traceren uitvoerig de werking van de kernel-workers (processen die kernel-taken uitvoeren) en constateren dat meerdere CPU-cores wachten op het vrijkomen van een CPU-lock. De CPU blijkt te veel tijd te besteden aan het opnieuw toewijzen (remappen) van IRQs. Dit proces wordt gebruikt om virtuele machines rechtstreeks gebruik te kunnen laten maken van PCI-apparaten. De CPU besteed echter nauwelijks teveel tijd aan het remappen als we het netwerkverkeer over alle cores van de hypervisor spreiden,
zoals bij het eerdere spreiden van IRQs over alle CPU-cores in Alblasserdam.

Om het issue structureel te verhelpen, passen we de IOMMU-instellingen in de kernel aan. Hierna verbetert de maximale throughput van netwerkverkeer aanzienlijk. De stabiliteit verbetert eveneens en de maximale throughput daalt niet langer bij piekbelasting. Om de netwerkverbinding op dergelijke hoge snelheden nog stabieler te laten functioneren, verlagen we het aantal kanalen dat de netwerkdriver gebruikt om IRQs te verdelen over CPU-cores. De performance blijft hierna stabiel bij tests met extreme snelheden die aanzienlijk hoger liggen dan het normale gebruik van een hypervisor. Deze stabiliteit bevestigt dan ook dat de bottleneck nu verholpen is.