Eu tenho uma instância do AWS Lightsail (instância de 1 GB de RAM) executando um site relativamente novo (ou seja, praticamente sem tráfego). Está rodando nginx e PHP-FPM 7.3 (tentei com 7.2 também) e MariaDB. Tudo isso está sob o CentOS 7.
Tudo funcionou bem no nível gratuito da AWS. Executei uma instância T2.micro EC2 e uma instância T2.micro RDS. Lightsail tem sido um pouco... mais sensível. Para fazer o Lightsail funcionar, troquei o PHP-FPM paraondemand
ondemand - nenhum filho é criado na inicialização. As crianças serão bifurcadas quando novas solicitações forem conectadas.
Eu tive que fazer isso, ou o MariaDB travaria aleatoriamente. Isso não parece afetar o problema abaixo.
O painel de administração do Wordpress parou de funcionar corretamente e todos disseram para CONCATENATE_SCRIPTSdesligar. Isso funciona... principalmente. O editor de postagens e modelos está com problemas. Ninguém foi capaz de me dar uma pista do porquê. Olhando ao redor, eu encontrei algo eu mesmo.
As páginas que não funcionam não estão carregando completamente. Com CONCATENATE_SCRIPTSa ativação, os arquivos CSS são carregados em uma página gigante. Como isso não é renderizado completamente, os arquivos CSS e JS são ignorados pelo navegador. CONCATENATE_SCRIPTScontorna isso simplesmente dividindo-os em arquivos componentes, que são menores e carregam facilmente. Mas a página de edição não pode ser dividida e depurar o problema subjacente tem sido enlouquecedor. Eu recebo uma resposta de 200 e alguns dados
Mas o desenho da página está incompleto. Eu diria que talvez 80-90% do HTML esteja lá, mas corte. Na seção começando aqui (bloco JS)
wp.apiFetch.use( wp.apiFetch.createPreloadingMiddleware( {"\/":{"body":{"name":"S
ele apenas termina abruptamente, e no mesmo ponto todas as vezes. É como se o PHP-FPM ou o nginx tivessem parado, mas sem nenhum log de erro (e a maioria dos outros problemas por aí sobre esse tipo de configuração são para páginas que não desenham). Ainda mais estranho é que não está fazendo isso em páginas menores, apenas muito longas. Não há tempo de roubo tope a instância não parece estar sob nenhuma carga séria, então não sei por que faria isso. Recarreguei todos os arquivos novos e até configurei um site WP separado para testar isso e todos o fazem.
Por comentários, ativei o log de depuração do nginx e encontrei
2019/08/07 02:33:08 [crit] 1461#0: *47 open() "/var/lib/nginx/tmp/fastcgi/3/00/0000000003" failed (13: Permission denied) while reading upstream, client: x.x.x.x, server: example.com, request: "GET /wp-admin/post-new.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000",
Isso não faz sentido porque ele faria isso em APENAS um punhado de arquivos grandes. Nenhuma unidade está cheia ou perto disso. Eu li esta pergunta, mas tanto o nginx quanto o PHP-FPM estão sendo executados no apache. A exclusão dos arquivos tmp também não resolveu. Os diretórios são de propriedade de apache:root, mas alterá-los para apache:apachenão tem efeito. O SELinux também não parece ser o culpado. Também não estou usando proxy_cache.
