Eu escrevi um sistema de cache horrivelmente rápido e sujo para um site de busca de vídeo que armazena e armazena em cache os resultados da pesquisa dentro de um diretório "/ cache /" oculto.
Tudo estava correndo bem nos primeiros meses, até que comecei a perceber resultados de pesquisa muito populares sem exibir nenhum vídeo.
Eu olhei para a pasta cache, e com certeza, foi cheio de cerca de 30.000 arquivos em cache, muitos deles agora sendo criados sem conteúdo dentro deles ... mesmo para termos de pesquisa muito populares.
Eu deletei cerca de 10.000 arquivos de cache (que tinham mais de 1 mês ou vazios em termos de resultados) e agora tudo parece estar funcionando sem problemas novamente.
Obviamente, terei que escrever um sistema de cache MySQL adequado em um futuro próximo, mas será que esse grande número de arquivos dentro de um diretório pode estar causando o Soluço no CentOS?
Talvez puxar um arquivo em cache e descompactá-lo seja simplesmente demais?
Eu tenho um mecanismo que me avisa sempre que um download não ocorre sem problemas. O servidor bing não está me bloqueando, na verdade estou sendo servido resultados, eu simplesmente não conseguem armazená-los em cache (na ocasião) quando o número de arquivos na pasta cache fica "muito grande".
Todas as idéias / comentários são bem-vindos!
A resposta real tem a ver com a API de má qualidade do Bing - veja este tópico no fórum oficial da API bing 2.0: link
Basicamente, ocultam aleatoriamente os resultados de consultas de pesquisa aleatórias - forçando você a atingir os servidores duas vezes mais do que o necessário para obter as informações deles. Como muitas vezes uma resposta "sem resultados" realmente tem resultados, você precisa verificar novamente.
Obrigado a todos por sua contribuição!
Depende do tipo de sistema de arquivos que você está usando. Acredito que ext2 e ext3, por exemplo, estão limitados a 32000 subpastas (você pode ter muitos ou mais arquivos, mas o desempenho sofrerá ...); ext4 duas vezes isso, e alguns outros permitem mais ou um número ilimitado. Veja esta pergunta na falha do servidor para uma discussão e uma resposta cobrindo vários tipos de sistema de arquivos Linux.
Eu vi o contrário no FC7 e no Ubuntu, onde os diretórios lidam com mais de 100 mil arquivos sem problemas. Em vez disso, há um problema quando o número de subdiretórios é de 32 K ou mais - mas não apenas arquivos.
Como você disse que essa solução era "terrivelmente rápida e suja", talvez o problema não esteja no CentOS, mas no seu código? Ou até mesmo na língua que você está usando? É possível que seu código esteja tentando manter todos esses arquivos abertos de uma só vez, para que fique sem identificadores de arquivos ou algum recurso desse tipo?
Tags filesystems centos