Me deparei com este post ao fazer algumas pesquisas sobre as sessões. Embora a resposta aceita seja muito boa (e a chamada do fusor foi removida do script do GC por algum tempo), acho que vale a pena observar algumas outras considerações caso alguém se depare com um problema semelhante.
No cenário descrito, o OP estava usando o ext4. Os diretórios no ext4 armazenam dados de arquivo em um formato de banco de dados htree - o que significa que há um impacto insignificante na retenção de muitos arquivos em um único diretório em comparação com a distribuição deles em vários diretórios. Isso não é verdade em todos os sistemas de arquivos. O manipulador padrão no PHP permite que você use vários subdiretórios para arquivos de sessão (mas observe que você deve verificar se o processo de controle está recursando nesses diretórios - a tarefa cron acima não funciona).
Grande parte do custo da operação (depois de remover a chamada para o fusor) surge de olhar para arquivos que ainda não estão obsoletos. Usando (por exemplo) um único nível de subdiretórios, e 16 cron jobs procurando em cada subdiretório (0 /, 1 /, ... d /, e /, f /) irão suavizar os problemas de carga que surgem.
Usar um manipulador de sessão personalizado com um substrato mais rápido ajudará - mas há muito por onde escolher (memcache, redis, soquete de manipulador mysql ...) deixando de lado o intervalo de qualidade dos publicados na Internet, que você escolhe depende nos requisitos exatos com relação à sua aplicação, infraestrutura e habilidades, para não esquecer que freqüentemente existem diferenças no manuseio da semântica (notavelmente bloqueio) comparado com o manipulador padrão.
