Se o problema for grandes uploads de clientes, você pode atenuar isso um pouco configurando a opção LimitRequestBody (consulte link - o litespeed afirma ser compatível com o Apache, portanto, ele também deve funcionar lá, caso contrário, você precisará verificar seus documentos). No entanto, isso limitará as solicitações únicas. Um grande número de uploads ao mesmo tempo ainda pode preencher o armazenamento temporário.
Qual é o tamanho do volume que contém /tmp e é especificamente para /tmp ou compartilhado com outras áreas? Seria útil adicionar a saída de df -h à sua pergunta. Se você não tiver um sistema de arquivos separado para /tmp , algo em outro lugar pode estar preenchendo o volume.
Sugiro adicionar algum monitoramento ao servidor. Eu uso collectd para manter um olho nas coisas e uma versão ligeiramente alterada de este script para produzir belas imagens a partir dos dados gravados - existem algumas outras opções populares que também fariam o mesmo trabalho. Você pode pedir para monitorar o espaço do sistema de arquivos usado + free (usando este módulo ) e então você verá se seus erros correspondem a um período em que /tmp foi preenchido.
Um sistema de arquivos pode estar "cheio" quando há muito espaço se ele ficar sem inodes. Se esse for o caso, você poderá recriar o sistema de arquivos com um número maior deles. Isso geralmente é um problema quando você tem muitos arquivos pequenos, já que os padrões ao criar um sistema de arquivos são normalmente bons (um exemplo de onde o número de inodes precisa de ajustes é o servidor de email onde cada email é armazenado como um arquivo separado). / p>
Como uma solução de monitoramento rápida e suja, você pode ter uma tarefa do cron que é acionada a cada minuto e é executada:
date >> /home/tmpfsspace
df -P /tmp >> /home/tmpfsspace
df -i /tmp >> /home/tmpfsspace
tail -n 7200 /home/tmpfsspace > /home/tmpfsspace
Isso deixará você com um arquivo listando o espaço e inodes livres no sistema de arquivos / tmp a cada minuto do dia nas últimas 24 horas, que você pode usar para ver se o espaço de inodes é o problema na próxima obtenha o erro. O arquivo terá cerca de 425Kbytes de comprimento. Isso está longe de ser eficiente, portanto, não deve ser usado como uma solução permanente, e perderá os problemas causados por /tmp simplesmente sendo muito pequenos para que possam preencher completamente um minuto (a resolução do cheque). Você poderia tornar o script mais sofisticado e executar date; du -shc /tmp/* > /home/tmpusewhennearfull se o espaço ou inodes disponíveis em / tmp estiverem abaixo de um determinado ponto (50%, por exemplo) e você tiver a chance de ver o que está consumindo o espaço se algo estiver temporariamente .
Observação: suponho que este seja um servidor ou VM dedicado ao seu uso. Se você estiver em um servidor compartilhado, terá opções muito mais limitadas para instalar o software de monitoramento e assim por diante. / em>