trabalhadores do unicórnio morrendo

Question

Ontem à noite, por volta da meia-noite, nosso aplicativo caiu e estou tentando determinar o porquê. Atualmente, temos um servidor front-end nginx e dois servidores (app) de trabalhador de unicórnio no EC2.

Praticamente nossos trabalhadores de unicórnio continuaram o tempo livre e, portanto, foram reiniciados pelo mestre.

Pelo que vejo, não temos crontabs nem nada para ser executado neste momento, por isso estou um pouco perplexo.

Eu consegui o aplicativo nesta manhã quando acordei (após 6 horas de inatividade) matando os processos de unicórnio e reexecutando o binário de unicórnio. (unicorn_rails -c unicorn.rb etc)

Alguma ideia de onde procurar? O fato de que ambos os servidores de aplicativos foram desativados me faz pensar que poderia ser o banco de dados (RDS)?

O registro foi preenchido com o seguinte (por 6 horas ... etc);

E, [2013-02-28T00:07:40.367981 #11097] ERROR -- : worker=2 PID:26941 timeout (31s > 30s), killing
E, [2013-02-28T00:07:40.468495 #11097] ERROR -- : reaped #<Process::Status: pid 26941 SIGKILL (signal 9)> worker=2
I, [2013-02-28T00:07:40.756724 #28319]  INFO -- : worker=2 ready
E, [2013-02-28T00:07:44.519818 #11097] ERROR -- : worker=1 PID:11292 timeout (31s > 30s), killing
E, [2013-02-28T00:07:44.626362 #11097] ERROR -- : worker=0 PID:26933 timeout (31s > 30s), killing
E, [2013-02-28T00:07:44.726936 #11097] ERROR -- : reaped #<Process::Status: pid 11292 SIGKILL (signal 9)> worker=1
E, [2013-02-28T00:07:44.727254 #11097] ERROR -- : worker=0 PID:26933 timeout (31s > 30s), killing
E, [2013-02-28T00:07:44.932858 #11097] ERROR -- : reaped #<Process::Status: pid 26933 SIGKILL (signal 9)> worker=0
I, [2013-02-28T00:07:45.661356 #28329]  INFO -- : worker=1 ready
I, [2013-02-28T00:07:45.828289 #28334]  INFO -- : worker=0 ready
E, [2013-02-28T00:08:11.113970 #11097] ERROR -- : worker=2 PID:28319 timeout (31s > 30s), killing
E, [2013-02-28T00:08:11.214770 #11097] ERROR -- : reaped #<Process::Status: pid 28319 SIGKILL (signal 9)> worker=2
I, [2013-02-28T00:08:11.518723 #28368]  INFO -- : worker=2 ready
E, [2013-02-28T00:08:16.270463 #11097] ERROR -- : worker=1 PID:28329 timeout (31s > 30s), killing
E, [2013-02-28T00:08:16.371067 #11097] ERROR -- : worker=0 PID:28334 timeout (31s > 30s), killing
E, [2013-02-28T00:08:16.471684 #11097] ERROR -- : reaped #<Process::Status: pid 28329 SIGKILL (signal 9)> worker=1
E, [2013-02-28T00:08:16.471983 #11097] ERROR -- : reaped #<Process::Status: pid 28334 SIGKILL (signal 9)> worker=0
I, [2013-02-28T00:08:17.038915 #28376]  INFO -- : worker=0 ready
I, [2013-02-28T00:08:17.128931 #28379]  INFO -- : worker=1 ready
E, [2013-02-28T00:08:42.628665 #11097] ERROR -- : worker=2 PID:28368 timeout (31s > 30s), killing
E, [2013-02-28T00:08:42.729290 #11097] ERROR -- : reaped #<Process::Status: pid 28368 SIGKILL (signal 9)> worker=2
I, [2013-02-28T00:08:43.015140 #28390]  INFO -- : worker=2 ready
E, [2013-02-28T00:08:48.778221 #11097] ERROR -- : worker=0 PID:28376 timeout (31s > 30s), killing
E, [2013-02-28T00:08:48.878530 #11097] ERROR -- : worker=1 PID:28379 timeout (31s > 30s), killing

    

Answer 1

Consegui resolver esses caras. Investigações posteriores mostraram grandes quantidades de tráfego de rede (e uso da CPU!) Entre os horários de 12h - 4h. Acontece que as configurações do webmaster foram definidas como "altas" entre esses tempos, fazendo com que o bingbot enlouqueça e martele o unicórnio. (pobre unicórnio).

Mais informações; link