Como calcular ulimit -n (descritores de arquivos) para um servidor de squid dedicado

Question

Eu tenho um servidor de squid de produção que estava tendo alguns problemas com conteúdo e reportando que ele estava sem descritores de arquivo. Consegui aumentá-lo de 1024 (padrão) para 4096 e pareceu resolver meus erros no log. Eu ainda estava vendo o código de resposta 0 e 0 bytes recebidos para algumas chamadas que não foram armazenadas em cache e isso me leva a acreditar que, em um volume de pico (tempestade de inicialização), minha contagem de descritores de arquivos ainda é muito baixa.

Já li alguns posts e a configuração pode ser alta para algo como 24k, 40k ou até 70k. Sendo esta uma caixa de squid dedicada, não estou preocupado com outros processos / usuários competindo por descritores de arquivos em todo o sistema, mas eu gostaria de saber qual é a melhor prática para fazer um cálculo aproximado de quantos descritores de arquivo eu devo configurar para ulimit -n.

Na minha configuração, eu tenho um máximo de 3000 conexões TCP do lado do cliente, um máximo de 3000 conexões TCP do lado do servidor, e alguns arquivos de log que são configurados por padrão na configuração do squid (cache.log, squid. registro). É tão simples como dizer que devo definir o meu ulimit -n para 3000 + 3000 + 2 + (algum montante de despesas gerais)? Por falta de documentação sobre o assunto, eu provavelmente configurarei para 24k apenas para nunca ter que lidar com isso, mas eu prefiro ter uma fórmula de melhor prática a seguir - assim como com o apache2 você pode calcular a memória necessária para quantos pedidos você quer ser capaz de lidar simultaneamente.

Editar: Esqueci de mencionar que não estou gravando esses arquivos em cache no disco, eles ficam na memória. São algumas centenas de arquivos (no total de < 5 MB no total) que são a única página carregada por esse meio, por isso omiti os descritores de arquivos de leitura / gravação em disco.

    

Answer 1

No pior cenário, cada requisição ao servidor squid requer três descritores de arquivos;

1. Um descritor para a conexão do lado do cliente
2. Outro para a conexão do lado do servidor, caso ela não seja armazenada em cache.
3. Terceiro, para o arquivo ler o hit ou o cache da falha.

Em seguida, há overheads, incluindo arquivos de log, qualquer comunicação entre processos, por exemplo, ajudantes e conexões inativas. Então, como uma estimativa aproximada, você precisa de três descritores de arquivo para cada conexão TCP de entrada e, em seguida, incluir em qualquer sobrecarga para isso.

    

Answer 2

Em uma busca para encontrar mais informações sobre "melhores práticas", a Nasoo já estava decidida sobre como calcular o número de arquivos abertos que você deve configurar. Descobri que existem intricados com a forma como os navegadores lidam com o download de arquivos em paralelo, de modo que 3000 clientes realmente falam em cerca de 25 a 30 soquetes cada para fazer o download de toda a página da web e conteúdo dinâmico. Parte disso depende de como os navegadores são baixados em paralelo, e também de como as APIs de javascript lidam com o download de conteúdo dinâmico.

Portanto, embora eu não possa determinar com precisão um número adequado sem toneladas de testes adicionais, eu também tropeço em um manual que afirma que 256 identificadores de arquivo podem ser configurados para cada 4 MB de RAM. Então, isso deve ser mais do que suficiente, e até metade dos 8GB de RAM que tenho para essa caixa seria um exagero.

link

EDIT: Eu também comecei a fazer um pouco de log de uso do descritor de arquivo para um arquivo RRD uma vez por minuto via cronjob. É um script muito básico que registra tudo e você pode gerar gráficos muito úteis sem um servidor de monitoramento ou qualquer coisa. Se alguém estiver interessado, me avise e eu vou tirar proveito disso.