Ontem realizei uma atualização de lançamento que incluiu a atualização do PHP 7.4 para 8.2.
A princípio pensei que o problema poderia ser da versão do PHP (pois era php8.2-fpmo serviço que ficava morrendo), então voltei para php7.4-fpm, mas isso não resolveu o problema.
php7.4-fpm.service: A process of this unit has been killed by the OOM killer.
php7.4-fpm.service: Failed with result 'oom-kill'.
php7.4-fpm.service: Consumed 12min 18.367s CPU time.
Tenho soquetes do site organizados por pools
Todos têm esta configuração:
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
O serviço cai em cerca de 1 hora. Então decidi introduzir uma max_requestslimitação
pm.max_requests = 1000
E então ficou muito mais estável, mas acabou caindo em torno de 12 horas. Então agora temo que apenas ajustar isso e continuar reduzindo esse número só fará com que o servidor caia mais tarde, mas caia em algum momento, o que não é o ideal. A parte estranha aqui é que antes da atualização (Ubuntu 20.04 LTS) ele estava 100% estável, nunca caindo, e depois da atualização para o Ubuntu 22.04 LTS, as coisas começaram a enlouquecer.
Depois de revisitar muitas outras questões em Server Fault e Super User em relação ao OOM, estou ficando sem ideias para testar mais opções, então gostaria de saber se alguém poderia sugerir outras novas possibilidades para eu testar
Houve um vazamento de memória devido a um plugin do Wordpress (WP-Rocket)
Consegui identificar isso graças a esta resposta em outra pergunta:
https://stackoverflow.com/a/20590805/4442122
Isso apontou o local exato onde o vazamento estava sendo produzido. Depois de descer, encontrei a causa. Não foi nada simples, especialmente porque havia um sistema enorme por trás (WP) para que o problema pudesse vir de qualquer lugar (especialmente porque tudo carrega do index.php inicial no WP).