Eu estava esperando que alguém pudesse me dar alguns conselhos, por favor. Estou executando um servidor CentOS 6 e, nos últimos dias, meu uso de disco passou de 60 GB para 135 GB (98% cheio). Acredito que o problema pode estar relacionado ao diretório de sessão do PHP (/var/lib/php/session), pois parece ser enorme (não posso ls ou rm), deve haver literalmente milhões de arquivos neste diretório.
Como posso remover este diretório? rm não está funcionando aqui e também tentei substituir um diretório vazio pelo rsync, mas isso também leva uma eternidade.
Se isso está causando o problema - por que o PHP não está removendo esses arquivos automaticamente?
É provável que haja algum registro em algum lugar que possa me apontar na direção de uma exploração, DDOS ou falha?
Obrigado
sudo find /var/lib/php/session -type f -deletefuncionará melhor do quesudo rm /var/lib/php/session/*porque a expansão*dificilmente é possível para grandes listas de arquivos.Parece que seu aplicativo está criando sessões, mas nunca as destruindo. Isso pode ser uma programação ruim e uma mistura de configurações de ambiente ruins.
Se você quiser remover esses arquivos de sessão, precisará usar o sudo, pois eles provavelmente não pertencem ao seu usuário.
Eu não removeria todo o diretório da sessão.
Outra coisa é ajustar o tempo limite da sessão do PHP para um intervalo menor.
A configuração padrão do Ubuntu é que o PHP não expira sessões, mas há um cron job que exclui arquivos antigos. Uma discussão completa sobre isso levaria algum tempo (IMHO, é uma péssima ideia), no entanto, não sei se a Redhat está adotando uma abordagem semelhante.
Você não forneceu nenhum detalhe de sua configuração de sessão. Essa situação pode surgir devido aos valores de qualquer um de session.gc_probability, session.gc_divisor ou session.gc_maxlifetime. Definir os padrões de 1, 100 e 1440 deve garantir um sistema razoavelmente homeostático depois de limpar os arquivos conforme descrito nas outras respostas.
Você não disse quantas sessões simultâneas você vê em seu sistema, seu tamanho médio, nem o sistema de arquivos em que estão armazenadas. Se você espera mais de 300 sessões (dependendo do sistema de arquivos), considere o uso de uma árvore de diretórios em vez de um único diretório para armazenar os arquivos; prefixe o session.save_path com 1 ou 2 (assumindo que este não é um servidor NFS que suporta um cluster de servidores, caso em que você deve mudar para uma arquitetura diferente).
Matt menciona que pode ser a configuração do selinux. Se isso permitir que os arquivos sejam criados, mas nunca excluídos. Embora isso seja possível, sugere que a configuração do sistema está seriamente bagunçada. Se for esse o caso (verifique seu log de auditoria), provavelmente você deve fazer uma instalação limpa e restaurar seu aplicativo sobre ele.
É muito improvável que tenha algo a ver com programação ruim.