Perda de desempenho após 30 minutos

Question

Este me confundiu. Eu tenho Ubuntu 14.04, 3 dias atrás (2014-2010) começou a abrandar.

Eu o reproduzi abrindo o gedit e depois fechando o gedit, quando o problema está ativo, ele atinge aproximadamente 2 segundos para fechar um arquivo vazio, enquanto que sem o problema, isso é sempre instantâneo - afeta todo o resto de maneira semelhante. / p>

top não relata nenhuma atividade incomum quando o congelamento ocorre, htop o mesmo, iotop o mesmo também.

O problema só surge após 30 minutos de funcionamento, posso garantir que aos 29 minutos de tempo não consegui reproduzi-lo, aos 31 minutos de tempo de funcionamento consegui reproduzi-lo consistentemente (usando o método acima, nenhum aplicativo iniciado além de terminal e htop ) e conseguiu repetir isso 4 ou 5 vezes (desligando, inicializando e esperando meia hora - o que foi agradável).

O problema persiste mesmo após as reinicializações, mas pode ser redefinido desligando e ligando de volta, que parte do Ubuntu mantém o estado após as reinicializações, mas não as paralisações?

Registros relevantes para este período são syslog, auth.log e Xorg.0.log (examinando o conteúdo de / var / log para a hora modificada no intervalo especificado)

syslog:

Oct 22 17:21:36 raiden NetworkManager[1102]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Oct 22 17:39:01 raiden CRON[3284]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Oct 22 18:09:01 raiden CRON[3370]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))

authlog:

Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session closed for user root
Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session closed for user root
Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session closed for user root

Xorg.0.log: (provavelmente eu acabei de reativar o computador)

[  3466.727] (II) intel(0): switch to mode [email protected] on LVDS1 using pipe 0, position (0, 900), rotation normal, reflection none
[  3466.880] (II) intel(0): switch to mode [email protected] on VGA1 using pipe 1, position (0, 0), rotation normal, reflection none

Nenhum deles indica algo ruim e as etapas subseqüentes para reproduzir o problema não indicam alterações nos registros, portanto, provavelmente eram apenas registros inocentes.

Eu presumo que há 3 possíveis fontes deste problema:

Instalação de software: eu instalei algo desonesto

eu fiz:

• história | grep apt-get '- não instala nesse período de tempo
• Analisou o histórico do gerenciador de pacotes sinápticos - nada nesse período de tempo
• Histórico do centro de software - a última atualização ocorreu várias semanas antes (houve um problema de dependência, por isso não atualizei há algum tempo)
• Eu instalei o Skype para Ubuntu por volta desse período de tempo, mas não há nenhuma indicação de que ele tenha sido causado pelo Skype (removido de qualquer maneira)

O trabalho do Cron está errado

Cronogramas verificados no crontab, /etc/cron.d /etc/cron.daily e de hora em hora, nada indicando que é algo lá; somente um cron job do PHP ocorre a cada 30 minutos, mas se fosse o cron, ele faria isso em certos pontos o relógio não 30 minutos após o arranque.

A análise de novos processos que foram iniciados entre o estado de não desaceleração e o estado de desaceleração sugere que nenhum novo processo foi iniciado (primeiro teste, isso mostrou um encadeamento kworker, mas é provável que isso seja apenas uma coincidência). Eu presumo que isso deva significar que é um processo existente que desencadeou ou algo diferente.

Malware

Devido a sua indefinição e a misteriosa ausência de 30 minutos do problema (30 minutos parece uma quantidade de tempo escolhida pelo ser humano) comecei a pensar que poderia ser algum tipo de malware, por mais improvável que fosse (não fiz uma atualização por um tempo e ter algumas portas abertas). Então rodei o rkhunter (localizador de rootkit) mas nada desagradável foi encontrado.

Outras coisas que eu tentei:

• Desmarque certos componentes do compiz - sem alteração
• Reiniciando compiz - sem alteração
• Desmarque todos os componentes do Compiz - sem alterações (exceto para mim, wrestling para obter o computador utilizável novamente)
• Tocando vários instrumentos musicais enquanto aguarda o tempo de atividade para chegar a 30 minutos e, em seguida, assistir aos resultados de top e htop para quaisquer alterações suspeitas - nada de estranho

Alguém já teve algo parecido com isso ou pode me apontar na direção certa se você clicar no botão de votação repetidamente na sua resposta (vou me certificar de que é um número ímpar)

    

Answer 1

Isso foi causado por dados SMART ativados para a unidade em questão.

Desativar dados SMART resolveu isso:

sudo smartctl --smart=off /dev/sda

Presumivelmente, ele continuou executando algum tipo de auto-teste interno 30 minutos após o disco girar e entrar em loop; como isso aconteceu na camada de hardware, o resto do computador não sabia disso, por isso não vi nenhum processo em particular responsável pelo bloqueio de I / O e nenhum processo sobrecarregando recursos.

    

Answer 2

Existem algumas maneiras de configurar o cron para executar um trabalho 30 minutos após a inicialização. Jenkins faz isso fazendo hash na função e usando H/30 * * * * por exemplo. Também poderia ser um thread dormindo por 30 minutos e gerando um processo killer de cpu silencioso.

Algumas ideias:

Você tentou htop como root? Alguns processos podem estar invisíveis, eu vi isso no Debian especialmente.

Você tentou fazer logout / login novamente quando o problema ocorreu? Pode ser o gerenciador de janelas ou um problema de sessão.

Se logout / login não funcionar, você pode tentar reiniciar o gerenciador de sessões. Eu acho que é lightdm por padrão, então sudo service lightdm restart deveria fazer isso.