Melhor configuração do sysctl.conf para alta carga - servidor de streaming de conteúdo extremamente ocupado

Question

Qual é a melhor configuração do sysctl.conf para um servidor de streaming de conteúdo extremamente ocupado e de alta carga? O servidor busca o conteúdo de servidores remotos como amazon, s3, etc., em seguida, usa o php para transmitir dinamicamente o conteúdo para o usuário sem salvá-lo no disco rígido. php usa CURL para buscar o arquivo, então usa flush () para fazer stream simultaneamente, então não há muito trabalho no disco rígido ... apenas rede e largura de banda.

O servidor é xeon quad core, com NIC full duplex de 1 Gbit, 8 gb de RAM e 500 GB x 2 em RAID. O uso de memória do servidor e o carregamento da CPU são muito baixos.

Nós estamos executando o debian lenny e o lighttpd2 nele (sim, eu sei que não foi lançado ainda :-)) com o php 5.3.6 e o php fastcgi com o spawn-fcgi ligados em 4 soquetes unix diferentes com 20 filhos cada. O máximo de solicitações fcgi é 20, com o módulo mod_balancer na configuração lighttpd2 para balancear as solicitações fastcgi entre esses 4 soquetes na configuração SQF (fila pequena primeiro).

Nossos servidores usam muita largura de banda, ou seja, a conexão de rede está ocupada o tempo todo. Logo após 100 a 200 conexões paralelas, o servidor começa a desacelerar e, eventualmente, não responde, começa a fornecer erros de tempo limite de conexão. Quando nós tivemos cpanel, nós nunca tivemos erros de timeout, então não pode ser um problema de script. Deve ser um problema de configuração de rede.

configuração lighttpd2: processos de trabalho = 8, manter solicitações ativas é 32, manter ativo tempo limite ocioso é 10 segundos e conexões máximas é 8192.

Nosso conteúdo atual do sysctl.conf é:

net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_tw_recycle = 1

# Increase maximum amount of memory allocated to shm

kernel.shmmax = 1073741824

# This will increase the amount of memory available for socket input/output queues
net.ipv4.tcp_rmem = 4096 25165824 25165824
net.core.rmem_max = 25165824
net.core.rmem_default = 25165824
net.ipv4.tcp_wmem = 4096 65536 25165824
net.core.wmem_max = 25165824
net.core.wmem_default = 65536
net.core.optmem_max = 25165824

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

# you shouldn't be using conntrack on a heavily loaded server anyway, but these are
# suitably high for our uses, insuring that if conntrack gets turned on, the box doesn't die
# net.ipv4.netfilter.ip_conntrack_max = 1048576
#  net.nf_conntrack_max = 1048576

# For Large File Hosting Servers
net.core.wmem_max = 1048576
net.ipv4.tcp_wmem = 4096 87380 524288

    

Answer 1

O ajuste de desempenho e a identificação de gargalos como esse são um problema difícil de resolver e frequentemente exigem muitas informações para serem diagnosticadas. A chave para o processo é percorrer o processo que ele usa e ver se você pode descobrir qual recurso está sendo exaurido. Quando você disse que o servidor não está respondendo por php, mas html ainda serve, que é um ponto de dados interessante. O que é diferente entre como eles são servidos? Pode ser um buffer de rede sutil, ou pode ser mais básico do que isso. Você pode ter simplesmente esgotado o limite do processo filho de 20 filhos fcgi, e todos eles estão ocupados servindo dados, enquanto novas solicitações estão sendo congestionadas na fila de escuta (e expirando eventualmente) esperando que um processo fcgi php apareça.

O truque real ao tentar obter visibilidade na caixa é entrar na caixa quando estão ocorrendo problemas e começar a coletar informações.

Para descobrir quantos processos php estão em execução, você poderá executar algo assim:

ps auxgmww | grep php

E se você quiser contá-las em vez de contá-las você mesmo, você pode fazer algo assim:

ps auxgmww | grep php | wc -l

De volta à sua pergunta original sobre o ajuste de desempenho, antes de alterar o syctl.conf, você pode querer ver o que seu servidor está dizendo quando o problema está ocorrendo, você pode descobrir isso fazendo o seguinte:

sysctl -a > sysctl.txt

E, em seguida, veja o seu arquivo de texto - é um monte de dados, mas antes de ajustar qualquer valor, veja se a saída sysctl relata qualquer coisa sobre o que está sendo usado naquele ajuste e o que ele está consumindo. Um exemplo são os arquivos abertos, que você pode ver uma amostra de saída aqui:

fs.file-nr = 3456   0   102295

Isso nos diz que estamos usando descritores de arquivos 3456, mas nosso limite é 102295, por isso não estamos nem perto do limite. Se o primeiro número estivesse no intervalo de 100.000, isso diria que você está ficando sem descritores de arquivos e é isso que você precisa ajustar.