Como depurar problemas com sockets de domínio unix?

Question

Ubuntu Server 10.04.2

$ uname -a
Linux my.local 2.6.32-30-generic-pae #59-Ubuntu SMP 
Tue Mar 1 23:01:33 UTC 2011 i686 GNU/Linux

Parece que minha fila de soquete de domínio está sobrecarregada, mas não posso provar isso.

Eu tenho essa pilha nginx->[spawn-fcgi->multiwatch->]custom-fcgi-service

O Nginx está se comunicando com custom-fcgi-service por meio do soquete de domínio unix.

Hoje temos um pequeno aumento no tráfego e, de repente, meu nginx error.log está cheio de enguias:

2011/04/07 15:31:51 [error] 28187#0: *469350 connect() to unix:/tmp/my.socket 
failed (11: Resource temporarily unavailable) while connecting to upstream, 
client: [IP witheld], server: my.local, request: "GET /myurl HTTP/1.0", 
upstream: "fastcgi://unix:/tmp/my.socket:", host: "example.com"

Algumas solicitações são aprovadas, mas muitas retornam o erro 5xx.

Se eu reiniciar custom-fcgi-service , o erro desaparece, mas logo reaparece. Depois de inspecionar custom-fcgi-service status, estou razoavelmente seguro de que funciona bem (embora possa ser muito lento para essa quantidade de tráfego, mas isso é uma mera hipótese).

Eu tentei fazer isso:

echo 65535 > /proc/sys/net/unix/max_dgram_qlen

Mas isso não ajudou muito. (Não tenho certeza se o tempo para erro ficou mais longo, pode ser, mas não o suficiente para consertá-lo.)

Se eu aumentar o número de garfos de trabalho de custom-fcgi-service , o erro não será exibido por mais tempo, mas até agora não consegui aumentar o número de funcionários com alta capacidade de corrigi-lo para sempre. A CPU, a memória e o carregamento de E / S nessa máquina estão dentro dos limites, então, novamente, acho que custom-fcgi-service está apenas sendo lento em algumas chamadas de rede subsequentes.

A pergunta é: como depurar esse problema? E se for realmente o tamanho da fila de sockets, como fazer um sensor que nos avise que precisamos de bifurcar mais custom-fcgi-service workers?

    

Answer 1

Parece que você tem problemas com a conexão, não com o envio. Tente aumentar o backlog do receptor de kernel:

echo "2000" > /proc/sys/net/core/netdev_max_backlog

ou

sysctl –w sys.net.core.netdev_max_backlog=2000

Você verificou os registros do sistema (por exemplo, dmesg)?

    

Answer 2

tente alterar o arquivo de configuração do spawn, o backlog: 4096.