Um servidor virtual de 48 GB de RAM mantendo cerca de 25 mil conexões TCP (dispositivos em campo fazendo login para configurar um túnel SSH) ficou sem RAM e começou a trocar, ficando lento etc. Atualizamos e reinicializamos. Mesmo depois que as 25k conexões foram restauradas e a tempestade inicial de DDOS foi resolvida, o servidor agora mostrava uma enorme quantidade de uso do softirq. Como encontro a causa?
Aqui você pode ver os eventos:
É impressionante que não costumava haver muito softirq. Agora, existem 8 threads do kernel fazendo cerca de 60% da CPU ( ksoftirqdthreads).
Olhando para os gráficos de Munin, vejo que as interrupções de PCI-MSI 49153-edge virtio0-input.0aumentaram muito (cuidado com a escala log y):
A quantidade de tráfego de rede com a qual a máquina tem que lidar realmente não mudou.
Eu escrevi um script python rápido que mostra as interrupções por segundo, a cada segundo, /proc/interruptsde PCI-MSI 49153-edge virtio0-input.0, e geralmente é cerca de 50 a 100 por segundo, mas de vez em quando, há uma rajada de 5000 a 10000.
Porque no processo de atualização, o painel de controle do hoster da VM anunciou que precisava migrar a VM para outro servidor. Eu teorizei que esse servidor tem um controlador Ethernet diferente, controlador de interrupção emulado de maneira diferente ou qualquer outra coisa, mas eles até migraram a VM de volta e não há diferença.
Outra diferença é que a VM passou de vmlinuz-4.15.0-45-genericpara /boot/vmlinuz-4.15.0-72-generic. Com todos os patches de CPU da Intel ultimamente, posso imaginar algo escondido lá.
A grande questão é: como chegar à causa raiz ou obter mais informações de onde vêm essas interrupções? A reinicialização do servidor para o kernel antigo é possível, mas não desejável.
Acontece que alguém instalou no topo, que tem um serviço systemd que coleta informações de contabilidade de processo. Removê-lo corrigiu.