Comment savoir ce qui gèle ma machine?

J'utilise Arch sur cette machine:

3.40GHz i7 hexacore (4930K)

16 Go de RAM DDR3 1600 MHz

2x SSD Samsung 840 EVO dans Raid0 (en utilisant le raid BTRFS)

Lorsque j'exécute VMware sur mon Arch avec quelques machines virtuelles (2 ou 3), en leur donnant environ 2 à 4 cœurs chacune et 2 Go de RAM chacune, mon système commence à avoir des blocages aléatoires. Toutes les deux minutes, le système se fige pendant 10 à 30 secondes, puis recommence à se déplacer, pour se figer 30 secondes plus tard jusqu'à ce que j'arrête les machines virtuelles. Lorsque le système se bloque, la souris se déplace toujours bien, mais les applications cessent de répondre sur l'hôte - vmware ne répond pas, firefox (qui est également ouvert sur l'hôte) ne répond pas, etc.

Lorsque le gel se produit, si mon moniteur de processus est en cours d'exécution, il montre plusieurs cœurs maximisés par vmware, mais en même temps, il y a d'autres cœurs inutilisés. J'ai également plus qu'assez de RAM - les machines virtuelles utilisent un total de 6 Go et l'hôte a 10 Go. J'ai 0 espace de swap, donc il n'y a aucun moyen que le swap ralentisse quoi que ce soit.

Il existe des rapports selon lesquels btrfs provoque la fragmentation des fichiers au niveau du système de fichiers, les machines virtuelles peuvent s'exécuter lentement. Pour autant que je sache, la fragmentation n'est un problème que sur les disques durs traditionnels - les SSD n'ont pas de têtes de lecture qui recherchent, donc ils ne se soucient pas si un fichier est très fragmenté.

Cela ne se produisait jamais lorsque j'utilisais Debian 7, donc je suis sûr que ce n'est pas un problème matériel.

Quels outils puis-je utiliser pour comprendre pourquoi mon système continue de geler? J'ai essayé top / htop et iotop (rien n'écrit ou ne lit excessivement lorsque le système se fige). Il ne semble pas y avoir de moniteur d'activité pour btrfs pour savoir s'il a des problèmes pour suivre l'écriture / la lecture de quoi que ce soit. Puis-je essayer autre chose?

Depuis la page gotchas de btrfs :

Les fichiers avec beaucoup d'écritures aléatoires peuvent devenir très fragmentés (plus de 10000 extensions), provoquant la corbeille sur les disques durs et des pics excessifs de plusieurs secondes de charge CPU sur les systèmes avec un SSD ou une grande quantité de RAM.

• Sur les serveurs et les postes de travail, cela affecte les bases de données et les images de machines virtuelles.

  • L'option de montage nodatacow peut être utile ici, avec les gotchas associés.

  ...

• Les symptômes incluent btrfs-transacti et btrfs-endio-wri qui prennent beaucoup de temps CPU (en pointes, éventuellement déclenchées par des synchronisations). Vous pouvez utiliser filefrag pour localiser des fichiers fortement fragmentés (peut ne pas fonctionner correctement avec la compression).

J'ai eu des problèmes similaires à ceux que vous décrivez avec Virtualbox. L' nodatacowoption pour btrfs n'a pas aidé de manière notable sur mon système. J'ai également essayé l'option de défragmentation automatique (mentionnée comme une solution possible pour les bases de données d'application dans les environnements de bureau), également sans résultats qui rendraient le comportement acceptable.

À la fin, j'ai réduit ma partition btrfs et le volume logique dans lequel elle vit, j'ai créé un nouveau LV et l'ai formaté en ext4, puis j'ai mis les images de disque VM que j'ai (VirtualBox) sur cette "partition".

Il pourrait s'agir d'un problème de pages géantes transparentes, où un thread du noyau khugepaged , exploite littéralement votre RAM pour le défragmenter ou crée des pages géantes à partir de 4k.

Le noyau aurait pu décider d'activer d'énormes pages compte tenu de votre assez grande quantité de RAM système.

Vérifiez le contenu de ces deux paramètres ajustables du noyau:

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

Si leur contenu est always, vous pouvez changer neveret voir si les pointes / gels du processeur disparaissent.

Le problème a été complètement résolu en n'utilisant pas LUKS sur la partition. J'ai donc formaté la partition directement avec BTRFS et non avec LUKS en premier.

Également monté avec les paramètres suivants:

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

Associé aux performances d'écriture générales dys-crypt (LUKS) d' Abysmal