Come faccio a capire cosa sta congelando la mia macchina?


10

Sto eseguendo Arch su questa macchina:

3.40GHz i7 hexacore (4930K)

16 GB di RAM DDR3 1600 MHz

2x SSD Samsung 840 EVO in Raid0 (usando il raid BTRFS)

Quando eseguo VMware sul mio Arch con alcune macchine virtuali (2 o 3), dando loro circa 2-4 core ciascuno e 2 GB di RAM ciascuno, il mio sistema inizia ad avere blocchi casuali. Ogni paio di minuti, il sistema si bloccherà da 10 a 30 secondi, quindi ricomincerà a muoversi, per poi bloccarsi solo 30 secondi dopo fino a quando non spengo le macchine virtuali. Quando il sistema si blocca, il mouse continua a muoversi bene, ma le applicazioni smettono di rispondere sull'host - vmware non risponde, firefox (che è anche aperto sull'host) non risponde, ecc.

Quando si verifica il blocco, se ho monitor di processo in esecuzione, mostra diversi core massimizzati da vmware, ma allo stesso tempo, ci sono altri core inutilizzati. Ho anche RAM più che sufficiente: le macchine virtuali utilizzano un totale di 6 GB e l'host ha lasciato 10 GB. Ho 0 spazio di scambio, quindi non c'è modo che lo scambio rallenti qualcosa.

Ci sono rapporti secondo cui poiché btrfs causa la frammentazione dei file a livello di file system, le macchine virtuali potrebbero rallentare. Per quanto posso dire, tuttavia, la frammentazione è solo un problema sui dischi rigidi tradizionali: gli SSD non hanno testine di lettura che cercano, quindi non si preoccupano se un file è altamente frammentato.

Questo non è mai successo quando stavo eseguendo Debian 7, quindi sono abbastanza sicuro che non sia un problema hardware.

Quali strumenti posso eseguire per capire perché il mio sistema continua a bloccarsi? Ho provato top / htop e iotop (nulla si scrive o legge eccessivamente quando il sistema si blocca). Non sembra esserci alcun tipo di monitor di attività per btrfs per dire se sta avendo problemi a stare al passo con la scrittura / lettura di qualcosa. C'è qualcos'altro che posso provare?


Potrebbe essere correlato all'utilizzo associato a LUKS: unix.stackexchange.com/questions/203677/…
brauliobo

Risposte:


15

Dalla pagina gotchas di btrfs :

I file con molte scritture casuali possono diventare fortemente frammentati (oltre 10000 estensioni) causando il cestinamento su HDD e picchi eccessivi di più secondi di carico della CPU su sistemi con un SSD o una grande quantità di RAM.

  • Su server e workstation ciò influisce sui database e sulle immagini delle macchine virtuali.

    • L'opzione mount nodatacow può essere utile qui, con i gotcha associati.

    ...

  • I sintomi includono btrfs-transacti e btrfs-endio-wri che richiedono molto tempo CPU (in picchi, probabilmente innescati da sincronizzazioni). È possibile utilizzare filefrag per individuare file fortemente frammentati (potrebbe non funzionare correttamente con la compressione).

Ho avuto problemi simili a quelli che descrivi con Virtualbox. L' nodatacowopzione per btrfs non ha aiutato in modo evidente sul mio sistema. Ho provato anche l'opzione di deframmentazione automatica (menzionata come possibile soluzione per database di applicazioni in ambienti desktop), anche senza risultati che renderebbero accettabile il comportamento.

Alla fine ho ridotto la mia porzione btrfs e il volume logico in cui vive, ho creato un nuovo LV e formattato come ext4, quindi ho inserito le immagini del disco VM che ho (VirtualBox) su quella "partizione".


Sicuramente sembra il mio problema. In realtà stavo cercando un modo per verificare quanto fosse frammentato un file, ma mi sono arreso quando ho letto la frammentazione non influenza gli SSD come fanno gli HDD. Apparentemente il posto che ho letto non era del tutto esatto - influenza ancora gli SSD - è molto interessante. Proverò filefrag e forse ridimensionerò la mia partizione btrfs e sposterò le mie VM in una partizione ext4 come hai fatto tu, e riporterò indietro. Grazie
Tal

0

Potrebbe essere un problema di hugepages trasparente, in cui un thread del kernel khugepaged , sta letteralmente estraendo RAM per deframmentarla o creando hugepage da 4K.

Il kernel avrebbe potuto decidere di abilitare gli hugepage data la quantità abbastanza grande di RAM di sistema.

Controlla il contenuto di questi due parametri sintonizzabili del kernel:

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

Se il loro contenuto è always, è possibile cambiare nevere vedere se i picchi / blocchi della cpu scompaiono.


il problema è in ritardo di scrittura e non è correlato all'utilizzo della CPU
brauliobo

0

Il problema è stato completamente risolto non utilizzando LUKS sulla partizione. Quindi ho formattato la partizione direttamente con BTRFS e non prima con LUKS.

Montato anche con i seguenti parametri:

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

Relativo alle prestazioni di scrittura Abysmal general dm-crypt (LUKS)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.