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

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

O servidor é quad core xeon, 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 a carga da CPU são bem baixos.

Estamos executando o debian lenny e o lighttpd2 nele (sim, eu sei que ainda não foi lançado :-)) com o php 5.3.6 e o ​​php fastcgi com spawn-fcgi bind em 4 soquetes unix diferentes com 20 filhos cada. As solicitações máximas de fcgi são 20, com o módulo mod_balancer na configuração lighttpd2 para equilibrar as solicitações fastcgi entre esses 4 soquetes na configuração SQF (primeira fila curta).

Nossos servidores usam muita largura de banda, ou seja, a conexão de rede está sempre ocupada. Logo após 100 a 200 conexões paralelas, o servidor começa a ficar lento e, eventualmente, deixa de responder, começa a gerar erros de tempo limite de conexão. Quando tivemos o cpanel, nunca tivemos erros de tempo limite, por isso 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 pedidos ativos é 32, manter tempo limite inativo ativo é 10 segundos e o número máximo de conexões é 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

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 diagnosticar. A chave do processo é passar pelo processo usado e ver se você pode encontrar qual recurso está sendo esgotado. Quando você disse que o servidor não responde ao php, mas o html ainda serve, esse é um ponto de dados interessante. O que é diferente entre como essas são servidas? Pode ser uma saturação sutil de buffer de rede ou pode ser mais básico que isso. Você pode simplesmente ter esgotado o limite do processo filho de 20 filhos de fcgi e todos estão ocupados servindo dados, enquanto novas solicitações estão sendo atoladas na fila de escuta (e atingindo o tempo limite), aguardando o processo de fcgi php.

O verdadeiro truque ao tentar obter visibilidade na caixa é entrar na caixa quando ocorrerem problemas e começar a coletar informações.

Para descobrir quantos processos php estão sendo executados, você deve ser capaz de executar algo como isto:

ps auxgmww | grep php

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

ps auxgmww | grep php | wc -l

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

sysctl -a > sysctl.txt

E então visualize seu arquivo de texto - são muitos dados, mas antes de ajustar qualquer valor, verifique se a saída sysctl relata algo sobre o que está usando atualmente para esse ajuste e o que pode estar consumindo. Um exemplo são os arquivos abertos, que você pode ver uma saída de amostra aqui:

fs.file-nr = 3456   0   102295

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