Wie finde ich heraus, was meine Maschine einfriert?

Ich verwende Arch auf diesem Computer:

3,40 GHz i7 Hexacore (4930 K)

16 GB DDR3 1600 MHz RAM

2xSamsung 840 EVO SSDs in Raid0 (mit BTRFS Raid)

Wenn ich VMware auf meinem Arch mit einigen VMs (2 oder 3) ausführe, die jeweils etwa 2 bis 4 Kerne und jeweils 2 GB RAM enthalten, kommt es auf meinem System zu zufälligen Einfrierungen. Alle paar Minuten friert das System für 10 bis 30 Sekunden ein und beginnt dann erneut, sich zu bewegen, um 30 Sekunden später einzufrieren, bis ich die VMs heruntergefahren habe. Wenn das System einfriert, bewegt sich die Maus immer noch einwandfrei, aber Anwendungen reagieren nicht mehr auf dem Host - VMware reagiert nicht, Firefox (das auch auf dem Host geöffnet ist) reagiert nicht usw.

Wenn das Einfrieren auftritt und der Prozessmonitor ausgeführt wird, werden mehrere von VMware ausgelastete Kerne angezeigt, gleichzeitig sind jedoch auch andere nicht verwendete Kerne vorhanden. Ich habe auch mehr als genug RAM - die VMs verwenden insgesamt 6 GB und der Host hat noch 10 GB übrig. Ich habe 0 Swap Space, also kann Swapping auf keinen Fall etwas verlangsamen.

Es gibt Berichte, dass virtuelle Maschinen möglicherweise langsam ausgeführt werden, da btrfs eine Fragmentierung von Dateien auf Dateisystemebene verursacht. Soweit ich jedoch feststellen kann, ist die Fragmentierung nur auf herkömmlichen Festplatten ein Problem. SSDs haben keine Leseköpfe, die suchen, daher ist es ihnen egal, ob eine Datei stark fragmentiert ist.

Dies war nie der Fall, als ich Debian 7 ausführte, daher bin ich mir ziemlich sicher, dass es sich nicht um ein Hardwareproblem handelt.

Welche Tools kann ich ausführen, um herauszufinden, warum mein System immer wieder einfriert? Ich habe top / htop und iotop ausprobiert (nichts schreibt oder liest übermäßig, wenn das System einfriert). Es scheint keine Aktivitätsüberwachung für btrfs zu geben, um festzustellen, ob es Probleme gibt, mit dem Schreiben / Lesen Schritt zu halten. Kann ich noch etwas ausprobieren?

Von der Seite mit den btrfs- Fallstricken :

Dateien mit vielen zufälligen Schreibvorgängen können stark fragmentiert werden (über 10000 Speicherbereiche), was bei Festplatten und Systemen mit einer SSD oder einer großen RAM-Größe zu einem Papierkorb auf Festplatten und einer übermäßigen CPU-Auslastung von mehreren Sekunden führt.

• Auf Servern und Workstations betrifft dies Datenbanken und Images von virtuellen Maschinen.

  • Die Option nodatacow mount kann hier mit zugehörigen Fallstricken von Nutzen sein.

  ...

• Zu den Symptomen gehören btrfs-transacti und btrfs-endio-wri, die viel CPU-Zeit in Anspruch nehmen (in Spitzen, möglicherweise ausgelöst durch Synchronisierungen). Sie können filefrag verwenden, um stark fragmentierte Dateien zu finden (funktioniert möglicherweise nicht richtig mit Komprimierung).

Ich hatte ähnliche Probleme wie Sie mit Virtualbox beschreiben. Die nodatacowOption für btrfs hat auf meinem System nicht merklich geholfen. Ich habe auch die Option zur automatischen Defragmentierung (die als mögliche Lösung für Anwendungsdatenbanken in Desktop-Umgebungen erwähnt wird) ausprobiert, auch ohne Ergebnisse, die das Verhalten akzeptabel machen würden.

Am Ende habe ich meine btrfs-Partition und das logische Volume, in dem sie lebt, verkleinert, eine neue LV erstellt und als ext4 formatiert und dann die VM-Disc-Images, die ich habe (VirtualBox), auf diese "Partition" gelegt.

Es könnte sich um ein transparentes Problem mit riesigen Seiten handeln, bei dem ein khugepaged- Kernel-Thread buchstäblich RAM abbaut , um es zu defragmentieren, oder riesige Seiten aus 4k-Seiten erstellt.

Der Kernel hätte sich angesichts der relativ großen Menge an System-RAM für die Aktivierung großer Seiten entscheiden können.

Überprüfen Sie den Inhalt dieser beiden Kernel-Tunables:

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

Wenn ihr Inhalt ist always, können Sie sich ändern neverund sehen, ob CPU-Spitzen / Einfrierungen verschwinden.

Das Problem wurde vollständig gelöst, indem LUKS nicht auf der Partition verwendet wurde. Also habe ich die Partition direkt mit BTRFS und nicht zuerst mit LUKS formatiert.

Auch mit folgenden Parametern montiert:

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

Bezogen auf die Schreibleistung von Abysmal General DM-Crypt (LUKS)