Jak dowiedzieć się, co zamraża moją maszynę?

Korzystam z Arch na tym komputerze:

Hexacore 3,40 GHz i7 (4930 K)

16 GB pamięci RAM DDR3 1600 MHz

Dyski SSD 2xSamsung 840 EVO w RAID0 (przy użyciu RAID BTRFS)

Kiedy uruchamiam VMware na moim Archu z kilkoma maszynami wirtualnymi (2 lub 3), dając im około 2-4 rdzeni i 2 GB pamięci RAM, mój system zaczyna się losowo zawieszać. Co kilka minut system zawiesza się na czas od 10 do 30 sekund, a następnie zaczyna się ponownie poruszać, tylko po 30 sekundach, aż do momentu wyłączenia maszyn wirtualnych. Gdy system zawiesza się, mysz nadal się porusza, ale aplikacje przestają odpowiadać na hoście - vmware nie odpowiada, firefox (który jest również otwarty na hoście) nie odpowiada itp.

Kiedy następuje zawieszenie, jeśli mam uruchomiony monitor procesu, pokazuje kilka rdzeni zmaksymalizowanych przez vmware, ale jednocześnie istnieją inne nieużywane rdzenie. Mam też więcej niż wystarczającą ilość pamięci RAM - maszyny wirtualne zużywają łącznie 6 GB, a hostowi pozostało 10 GB. Mam 0 przestrzeni wymiany, więc zamiana niczego nie spowalnia.

Istnieją raporty, że ponieważ btrfs powoduje fragmentację plików na poziomie systemu plików, maszyny wirtualne mogą działać wolno. Z tego co wiem, fragmentacja jest jedynie problemem na tradycyjnych dyskach twardych - dyski SSD nie mają głowic odczytu, które szukają, więc nie obchodzi ich, czy plik jest bardzo pofragmentowany.

To się nigdy nie zdarzało, kiedy korzystałem z Debiana 7, więc jestem prawie pewien, że nie jest to problem sprzętowy.

Jakie narzędzia mogę uruchomić, aby dowiedzieć się, dlaczego mój system zawiesza się? Próbowałem top / htop i iotop (nic nie pisze lub nie czyta nadmiernie, gdy system się zawiesza). Wydaje się, że nie istnieje żaden monitor aktywności dla btrfs, który mówi, czy ma problemy z nadrobieniem pisania / czytania czegokolwiek. Czy jest coś jeszcze, co mogę spróbować?

Ze strony btrfs gotchas :

Pliki z dużą liczbą losowych zapisów mogą zostać mocno pofragmentowane (ponad 10000 zakresów), powodując śmieci na dyskach twardych i nadmierne wielosekundowe skoki obciążenia procesora w systemach z dyskiem SSD lub dużą ilością pamięci RAM.

• Na serwerach i stacjach roboczych wpływa to na bazy danych i obrazy maszyn wirtualnych.

  • Przydaje się tutaj opcja montażu nodatacow z powiązanymi gotchas.

  ...

• Objawy obejmują btrfs-transacti i btrfs-endio-wri zajmujące dużo czasu procesora (w skokach, prawdopodobnie wywołanych przez synchronizacje). Możesz użyć filefrag do zlokalizowania mocno pofragmentowanych plików (może nie działać poprawnie z kompresją).

Miałem podobne problemy, jak opisujesz w Virtualbox. nodatacowRozwiązaniem dla btrfs nie pomoże w zauważalny sposób na moim systemie. Próbowałem również opcji automatycznej defragmentacji (wspomnianej jako możliwe rozwiązanie dla baz danych aplikacji w środowiskach stacjonarnych), również bez rezultatów, które sprawiłyby, że zachowanie było akceptowalne.

Na koniec zmniejszyłem swoją partycję btrfs i wolumin logiczny, w którym on żyje, utworzyłem nowy LV i sformatowałem go jako ext4, a następnie umieściłem obrazy dysków VM (VirtualBox) na tej „partycji”.

Może to być problem z przezroczystymi stronami, w którym wątek jądra khugepaged dosłownie wydobywa pamięć RAM, aby ją zdefragmentować lub tworzyć fragmenty z 4k.

Jądro mogło zdecydować o włączeniu funkcji ukrywania, biorąc pod uwagę dość dużą ilość pamięci RAM systemu.

Sprawdź zawartość tych dwóch tunerów jądra:

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

Jeśli ich zawartość jest always, możesz się zmienić neveri sprawdzić, czy skoki / zawieszenia procesora znikają.

Problem został całkowicie rozwiązany przez nieużywanie LUKS na partycji. Tak więc sformatowałem partycję bezpośrednio za pomocą BTRFS, a nie najpierw za pomocą LUKS.

Montowany również z następującymi parametrami:

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

Związane z wydajnością zapisu Abysmal general dm-crypt (LUKS)