Como descubro o que está congelando minha máquina?

Question

Estou executando o Arch nesta máquina:

3.40GHz i7 hexacore (4930K)

16GB DDR3 1600MHz RAM

2xSamsung 840 EVO SSDs in Raid0 (using BTRFS raid)

Quando executo o VMware no meu Arch com algumas VMs (2 ou 3), dando a eles cerca de 2-4 núcleos cada e 2 GB de RAM cada, meu sistema começa a ter congelamentos aleatórios. A cada dois minutos, o sistema irá congelar por 10 a 30 segundos, e então começará a se mover novamente, apenas para congelar 30 segundos depois até que eu desligue as VMs. Quando o sistema congela, o mouse ainda se move bem, mas os aplicativos param de responder no host - o vmware não responde, o firefox (que também está aberto no host) não responde, etc.

Quando o congelamento acontece, se eu tiver o monitor de processo em execução, ele mostra vários núcleos maximizados pelo vmware, mas, ao mesmo tempo, há outros núcleos não utilizados. Eu também tenho RAM mais do que suficiente - as VMs usam um total de 6 GB, e o host tem 10 GB sobrando. Eu tenho 0 swap de espaço, então não há como trocar está diminuindo nada.

Existem relatos de que, como o btrfs causa a fragmentação de arquivos no nível do sistema de arquivos, as máquinas virtuais podem ficar lentas. Até onde posso dizer, a fragmentação é apenas um problema nos discos rígidos tradicionais - os SSDs não têm cabeças de leitura que procuram, por isso não se importam se um arquivo é altamente fragmentado.

Isso nunca costumava acontecer quando eu estava rodando Debian 7, então tenho certeza que não é um problema de hardware.

Que ferramentas posso executar para descobrir por que meu sistema continua congelando? Eu tentei top / htop e iotop (nada está escrevendo ou lendo excessivamente quando o sistema congela). Não parece haver qualquer tipo de monitor de atividade para o btrfs dizer se está tendo problemas em manter a escrita / leitura de qualquer coisa. Há mais alguma coisa que eu possa tentar?

    

Answer 1

Da página de dicas do btrfs:

Files with a lot of random writes can become heavily fragmented (10000+ extents) causing trashing on HDDs and excessive multi-second spikes of CPU load on systems with an SSD or large amount a RAM.

• On servers and workstations this affects databases and virtual machine images.

  • The nodatacow mount option may be of use here, with associated gotchas.

  ...

• Symptoms include btrfs-transacti and btrfs-endio-wri taking up a lot of CPU time (in spikes, possibly triggered by syncs). You can use filefrag to locate heavily fragmented files (may not work correctly with compression).

Eu tive problemas semelhantes aos descritos com o Virtualbox. A opção nodatacow para o btrfs não ajudou de maneira perceptível no meu sistema. Eu tentei a opção de desfragmentação automática (mencionada como uma possível solução para bancos de dados de aplicativos em ambientes de área de trabalho) também, também sem resultados que tornariam o comportamento aceitável.

No final, eu reduzi minha partração btrfs e o Volume Lógico em que ela vive, eu criei um novo LV e o formatei como ext4, e coloquei as imagens do disco VM que eu tenho (VirtualBox) naquela "partição". / p>     

Answer 2

Poderia ser uma questão de páginas de abraço transparente, em que um segmento de kernel khugepaged , literalmente, minerava sua memória RAM para desfragmentá-la ou fazer mais do que 4k.

O kernel poderia ter decidido habilitar as páginas de entrada dadas a quantidade razoavelmente grande de RAM do sistema.

Verifique o conteúdo desses dois sintetizadores do kernel:

/sys/kernel/mm/transparent_hugepage/enabled
/sys/kernel/mm/transparent_hugepage/defrag

Se o conteúdo deles for always , você poderá alterar em never e ver se os picos / congelamentos de cpu desaparecem.

    

Answer 3

O problema foi completamente resolvido por não usar o LUKS na partição. Então eu formatei a partição diretamente com o BTRFS e não com o LUKS primeiro.

Também montado com os seguintes parâmetros:

/dev/sda2 /           btrfs       rw,noatime,space_cache,compress=lzo,ssd,discard,autodefrag,commit=0,thread_pool=8 0 0

Relacionado a Desempenho geral de gravação abismal de dm-crypt (LUKS)