mod_fcgid: lê erros de tempo limite de dados

Question

Eu mudei para um servidor não gerenciado que usa o fcgid (antes de usar o mod_php), e nos logs de erros eu vejo toneladas de tais erros:

[Mon Apr 23 21:17:12 2012] [warn] [client 66.249.68.233] mod_fcgid: read data timeout in 31 seconds [Mon Apr 23 21:17:12 2012] [error] [client 66.249.68.233] Premature end of script headers: index.php

[Mon Apr 23 17:59:51 2012] [warn] [client 74.117.180.58] mod_fcgid: read data timeout in 31 seconds [Mon Apr 23 17:59:51 2012] [warn] [client 74.117.180.58] (110)Connection timed out: mod_fcgid: ap_pass_brigade failed in handle_request_ipc function

Parece haver mais destes quando a carga é maior (2-3) durante os backups, e eu até consegui replicar isso durante uma carga de 3 quando tar / mysqldump estava rodando durante um backup (o usuário vê um 500 mensagem de erro após 30 segundos). O servidor poderia estar sobrecarregado? Esta questão parece estar relacionada O PHP + Fcgid trava se o download for interrompido mas não o mesmo.

Este é um servidor de primeira classe, e estou surpreso que isso seja demais. Aqui estão algumas especificações: 6-7 sites do Drupal com o Webmin

• Intel® Core ™ i7-2600 Quadcore incl. Tecnologia Hyper-Threading
• RAM 16 GB de RAM DDR3
• Discos rígidos2 x 3 TB SATA 6 Gb / s HDD 7200 rpm (Software-RAID 1)
• NIC1 Gbit OnBoard conectado a 100 Mbit

Answer 1

Esses erros significam que os scripts estavam rodando por mais de 31 segundos e, portanto, foram encerrados, como diz o fcgid.conf. O tempo limite padrão é de 40 segundos.

Você pode facilmente verificar esse comportamento escrevendo um test.php:

<?php sleep(32); ?>

Isso deve dar um erro 500 e colocar esse erro nos seus registros.

Você tem duas possibilidades para resolver isso:

1. Re-crie seu index.php (ou o aplicativo por trás) e resolva possíveis problemas de loop (onde o script é executado para sempre e é finalizado após 31 segundos).

2. Defina os tempos limite mais altos. Isso tem que ser feito para cada vhost (não se esqueça de SSL!), Pois essa configuração é alterada toda vez que outro vhost for carregado e permanecerá até que o processo gerado seja interrompido.
   A maneira mais fácil seria editar /etc/apache2/mods-available/fcgid.conf . É isso que estamos usando:

   IdleTimeout 3600 em ProcessLifeTime 7200 em IPCConnectTimeout 8 em IPCCommTimeout 600 em BusyTimeout 300

Edit: Ah, o segundo erro está relacionado a strings de consulta excessivamente longas em URLs. Para permitir sequências de consulta mais longas, edite também fcgid.conf e insira

MaxRequestLen 15728640

Não se esqueça de reiniciar o apache para eliminar todos os processos em execução, para que eles obtenham as novas configurações.

    

Answer 2

O mysqldump, por padrão, irá gravar o banco de dados enquanto ele é executado, para que os dados não sejam alterados durante o backup, o que pode causar danos. O Drupal grava no banco de dados em todas as requisições, então os pedidos irão travar enquanto o mysqldump está rodando, e eventualmente o tempo limite.

Se você estiver usando InnoDB (ou pode converter para ele), então você pode usar Percona XtraBackup fazer backups quentes. Além disso, não canalize mysqldump para tar ou gzip; despeje o arquivo .sql e execute o tar / gzip nele depois que o mysqldump terminar (e liberar o bloqueio).

Também esteja ciente de que em certas versões do fcgid, há um bug que faz com que ele apenas aplica configurações em blocos do VirtualHost, e aplica-as no bloco de última leitura globalmente .