Як визначити, що морозить мою машину?

Я запускаю Arch на цій машині:

3.7GHz i7 hexacore (4930K)

16 ГБ оперативної пам'яті DDR3 1600 МГц

2xSamsung 840 EVO SSD в Raid0 (використовуючи рейд BTRFS)

Коли я запускаю VMware на моїй арці з декількома VM (2 або 3), даючи їм приблизно 2-4 ядра кожна і 2 ГБ оперативної пам’яті кожна, у мене в системі починаються випадкові заморозки. Кожні пару хвилин система замерзає десь від 10 до 30 секунд, а потім почне рухатися знову, лише щоб замерзнути 30 секунд пізніше, поки я не вимкнуть віртуальні машини. Коли система замерзає, миша все одно рухається нормально, але програми перестають реагувати на хості - vmware не відповідає, firefox (який також відкритий на хості) не реагує тощо.

Коли заморожування трапляється, якщо у мене працює монітор процесу, він показує кілька ядер, що вмикаються vmware, але в той же час є й інші невикористані ядра. У мене також є більш ніж достатньо оперативної пам’яті - VM використовують всього 6 Гб, а у хоста залишилось 10 Гб. У мене є 0 місця для обміну, тому немає ніякого способу.

Існують повідомлення, що оскільки btrfs викликає фрагментацію файлів на рівні файлової системи, віртуальні машини можуть працювати повільно. Наскільки я можу сказати, однак, фрагментація є лише проблемою на традиційних жорстких дисках - на SSD-дисках немає читання головок, які шукають, тому їх не хвилює, чи файл сильно фрагментований.

Це ніколи не бувало, коли я запускав Debian 7, тому я впевнений, що це не проблема обладнання.

За допомогою яких інструментів я можу зрозуміти, чому моя система постійно замерзає? Я спробував топ / htop та iotop (нічого не пишуть і не читають надмірно, коли система замерзає). Здається, не існує жодного монітора активності для btrfs, який би визначав, чи не виникає проблем із тим, щоб щось писати / читати. Чи можна ще щось спробувати?

На сторінці gotchas btrfs :

Файли з великою кількістю випадкових записів можуть бути сильно фрагментованими (10000+ розширеннями), що спричинить руйнування на жорстких дисках і надмірні багатосекундні стрибки завантаження процесора на системах з SSD або великою кількістю оперативної пам'яті.

• На серверах та робочих станціях це впливає на бази даних та зображення віртуальних машин.

  • Тут може бути застосований варіант кріплення nodatacow, пов'язаний з ним.

  ...

• Симптоми включають btrfs-transacti та btrfs-endio-wri, що займають багато процесорного часу (у шипах, можливо, викликаних синхронізаціями). Ви можете використовувати filefrag для пошуку сильно фрагментованих файлів (можливо, не працює належним чином при стисненні).

У мене були подібні проблеми, як ви описуєте з Virtualbox. nodatacowВаріант для Btrfs не допомогло в помітному чином на моїй системі. Я також спробував параметр автоматичної дефрагментації (згаданий як можливе рішення для баз даних додатків у робочих середовищах), також без результатів, які б зробили поведінку прийнятною.

Врешті-решт я скоротив мій розділ btrfs та логічний том, в якому він живе, я створив новий LV і відформатував його як ext4, а потім поставив зображення диска VM, які у мене є (VirtualBox), на цей "розділ".

Це може бути прозора проблема величезних сторінок, де нитка ядра, що khugepaged , буквально видобуває оперативну пам’ять, щоб її дефрагментувати або робити величезні сторінки з 4-х.

Ядро могло вирішити включити величезні сторінки, враховуючи ваш досить великий об'єм оперативної пам'яті.

Перевірте вміст цих двох змінних ядер:

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

Якщо їхній вміст є always, ви можете внести зміни neverта побачити, чи зникнуть шипи / заморозки процесора.

Питання було повністю вирішено, не використовуючи LUKS на розділі. Тож я відформатував розділ безпосередньо BTRFS, а не спочатку LUKS.

Також монтується з такими параметрами:

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

Пов’язаний із загальною ефективністю запису dbs-crypt (АБСМ)