Após 30 minutos de uptime usando o Ubuntu 14.04 com um SSD híbrido ext4 , vejo muitos processos bloqueio de IO usando iotop.
A causa raiz dessa lentidão foi rastreada até a chamada do sistema Unix sync .
A execução de sync do terminal repetidamente pode levar da ordem de 1 a 2 segundos, mas SOMENTE após 30 minutos de atividade.
Para provar isso, criei um script que gera tempo de atividade em segundos em relação ao tempo necessário para executar a sincronização, e o executa a cada segundo:
while true;
do
cat /proc/uptime | awk '{printf "%f ",$1}'; /usr/bin/time -f '%e' sync;
sleep 1;
done;
Corri o script acima, esperei cerca de uma hora (o sistema ficou inativo) e plotei os resultados no gnuplot (y = tempo em segundos para executar a sincronização, x = tempo de atividade em segundos):
Opontonotempoemqueográficoapareceéporvoltade1780(1780/60=aproximadamente30minutos).
Nadadevesergravadonodisconestemomento,excetooscript,portanto,nãodevehaverquasenadanocachedapáginaapósaprimeirasincronização.Cadasincronizaçãosubseqüentegravaráexatamenteoqueestásendogravadonoscript,queseráaproximadamente100bytesoumais.
Quandoeuverificocat/proc/meminfodalinhasuja(dadosnocachedepáginasqueprecisamsersalvosnodisco?)ealinhadewrite-back(HDbufferdedisco?)estáemzero.Meupensamentoeraquechamarsyncliberaessescachesdedisco,maseleaindacongelamesmoquandonãohánadanessescaches,então,elefazoutracoisa?
Esseproblemapersisteapósasreinicializações;porexemplo-seeuesperar30minutosparaadesaceleração,entãoreinicie,alentidãoaindaestarálá.Seeudesligar,reinicieoproblemaaté30minutosdepois.
Outracuriosidadeéquequandoexamineiográficoacimaeaumenteiozoomemumaáreaondealentidãoestáocorrendo,percebiisso:
Os picos e depressões se repetem - isso ocorre em intervalos de 10 segundos, do vale ao vale.
Eu também testei o hdparm ( hdparm -t /dev/sda e hdparm -T /dev/sda ) antes da lentidão:
/dev/sda:
Timing cached reads: 23778 MB in 2.00 seconds = 11900.64 MB/sec
/dev/sda:
Timing buffered disk reads: 318 MB in 3.01 seconds = 105.63 MB/sec
e durante a desaceleração:
/dev/sda:
Timing cached reads: 2 MB in 2.24 seconds = 915.50 kB/sec
/dev/sda:
Timing buffered disk reads: 300 MB in 3.01 seconds = 99.54 MB/sec
Mostrando que as leituras de disco reais não estão sendo afetadas, mas as leituras em cache são, isso poderia significar que isso tem a ver com o barramento do sistema e não com o HD, afinal?
Aqui estão as soluções que tentei:
-
Altere as configurações do spindown do HD (talvez o HD estivesse entrando no modo de economia de energia?):
hdparm /dev/sda -S252 #(set it to 5 hours before spindown)
-
Altere o tipo de journalling do sistema de arquivos para writeback em vez de ordenado para que possamos obter melhorias de desempenho - isso não resolve o problema, pois não explica o tempo de atividade livre de lentidão de 30 minutos quando tentei fazer isso. nenhuma mudança.
-
CRON desativado, como parece ocorrer após 30 minutos.
-
O uso da CPU é bom e está completamente ocioso, portanto nenhum processo pode ser responsabilizado. No entanto, tentei desligar todos os serviços, incluindo o gerenciador de sessões (lightdm), isso não faz nada, pois acredito que o problema seja de nível inferior.
-
A análise de qualquer novo processo que chegue em 30 minutos indica que não houve alterações - eu diferenciei a saída do PS antes e depois e não há diferença.
Isso só começou a ocorrer há cerca de duas semanas, nada foi instalado e nenhuma atualização foi feita nesse período. Eu estou pensando que este problema é muito mais baixo, então eu realmente apreciaria alguma ajuda aqui, já que eu estou sem noção, até me apontar na direção certa seria útil.
O cache de gravação está ativado no disco em questão. Também tentei desativar as barreiras de gravação. Dados SMART no HD indicam que não há problemas com o HD em si, mas tenho minhas suspeitas de que é o HD fazendo algo misterioso, pois ele persiste após as reinicializações.