Makinemi neyin dondurduğunu nasıl anlayabilirim?

Bu makinede Arch kullanıyorum:

3.40GHz i7 hexacore (4930K)

16 GB DDR3 1600 MHz RAM

Raid0'da 2xSamsung 840 EVO SSD'ler (BTRFS baskını kullanarak)

Arch'ımda VMware'i birkaç VM (2 veya 3) ile çalıştırdığımda, her birine yaklaşık 2-4 çekirdek ve her biri 2GB RAM vererek, sistemim rasgele donmaya başlar. Her birkaç dakikada bir, sistem 10 ila 30 saniye arasında herhangi bir yerde donacak ve sonra tekrar hareket etmeye başlayacağım, sadece 30 saniye sonra VM'leri kapatana kadar donacak. Sistem donarsa, fare yine de iyi hareket eder, ancak uygulamalar ana bilgisayarda yanıt vermeyi durdurur - vmware yanıt vermez, firefox (ana bilgisayarda da açık olan) yanıt vermez, vb.

Donma gerçekleştiğinde, işlem monitörünüz çalışıyorsa, vmware tarafından en fazla sayıda çekirdek gösterilir, ancak aynı zamanda kullanılmayan diğer çekirdekler de vardır. Ayrıca yeterli RAM'im var - VM'ler toplam 6GB kullanıyor ve ana bilgisayarda 10GB kaldı. 0 takas alanım var, bu yüzden takas yapmanın herhangi bir şeyi yavaşlatmasının bir yolu yok.

Btrfs dosya sistemi düzeyinde dosyaların parçalanmasına neden olduğu için sanal makinelerin yavaş çalışabileceği raporları vardır. Bununla birlikte, parçalanma sadece geleneksel sabit disklerde bir sorundur - SSD'lerin arayan kafaları yoktur, bu nedenle bir dosyanın çok parçalı olup olmadığını umursamazlar.

Bu, Debian 7'yi çalıştırırken hiç olmadı, bu yüzden bir donanım sorunu olmadığından eminim.

Sistemimin neden donmaya devam ettiğini anlamak için hangi araçları çalıştırabilirim? Üst / htop ve iotop'u denedim (sistem donunca hiçbir şey yazma veya aşırı okuma). Btrfs için herhangi bir şey yazarken / okurken sorun yaşayıp yaşamadığını söyleyecek herhangi bir etkinlik izleyicisi yoktur. Deneyebileceğim başka bir şey var mı?

Btrfs gotchas sayfasından :

Çok sayıda rastgele yazımı olan dosyalar, HDD'lerde çöpe ve SSD veya büyük miktarda RAM bulunan sistemlerde çok fazla CPU yükünün aşırı yükselmesine neden olarak ağır şekilde parçalanabilir (10000+ uzantı).

• Sunucular ve iş istasyonlarında bu, veritabanlarını ve sanal makine görüntülerini etkiler.

  • Nodatacow montaj seçeneği burada, ilişkili gotcha'larla kullanılabilir.

  ...

• Semptomlar arasında çok fazla CPU süresi alan btrfs-transacti ve btrfs-endio-wri (sivri uçlarda, muhtemelen senkronizasyonlarla tetiklenir) bulunur. Ağır parçalanmış dosyaları bulmak için filefrag kullanabilirsiniz (sıkıştırma ile düzgün çalışmayabilir).

Virtualbox ile anlattığınız gibi benzer sorunlar yaşadım. nodatacowBtrfs için seçenek sistemimde farkedilir şekilde yardımcı olmadı. Ayrıca, davranışı kabul edilebilir hale getirecek sonuçlar olmadan, otomatik birleştirme seçeneğini (masaüstü ortamlarındaki uygulama veritabanları için olası bir çözüm olarak belirtilmiştir) denedim.

Sonunda btrfs bölümümü ve içinde yaşadığı Mantıksal Hacmi küçülttüm, yeni bir LV oluşturdum ve onu ext4 olarak biçimlendirdim ve sonra (VirtualBox) sahip olduğum VM disk görüntülerini o "bölüme" koydum.

Bir çekirdek iş parçacığı khugepaged , şeffaf bir büyük sayfalar sorunu olabilir , kelimenin tam anlamıyla onu birleştirmek için RAM madenciliği veya 4k olanlardan büyük sayfalar yapmak olabilir.

Çekirdek, oldukça fazla miktarda sistem RAM'iniz göz önüne alındığında büyük sayfaları etkinleştirmeye karar verebilirdi.

Bu iki çekirdek ayarının içeriğini kontrol edin:

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

İçeriği ise always, değişebilir neverve cpu ani / donmalarının kaybolup kaybolmadığını görebilirsiniz.

Sorun, bölüm üzerinde LUKS kullanılmamasıyla tamamen çözüldü. Bu yüzden bölümü önce LUKS ile değil, doğrudan BTRFS ile biçimlendirdim.

Ayrıca aşağıdaki parametrelerle monte edilir:

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

İlgili Dipsiz genel dm-crypt (LUKS) yazma performansına