Как выяснить, что замораживает мою машину?

Я запускаю Arch на этой машине:

3,40 ГГц i7 hexacore (4930K)

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

2xSamsung 840 EVO SSD в Raid0 (с использованием рейда BTRFS)

Когда я запускаю VMware на моем Arch с несколькими виртуальными машинами (2 или 3), давая им по 2-4 ядра и по 2 ГБ ОЗУ каждая, моя система начинает зависать случайным образом. Каждые пару минут система будет зависать от 10 до 30 секунд, а затем снова начнет двигаться, только через 30 секунд зависнет, пока я не выключу виртуальные машины. Когда система зависает, мышь все еще работает нормально, но приложения перестают отвечать на хосте - vmware не отвечает, firefox (который также открыт на хосте) не отвечает и т. Д.

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

Есть сообщения, что поскольку btrfs вызывает фрагментацию файлов на уровне файловой системы, виртуальные машины могут работать медленно. Однако, насколько я могу судить, фрагментация является проблемой только на традиционных жестких дисках - твердотельные накопители не имеют считывающих головок, которые ищут, поэтому им все равно, сильно ли фрагментирован файл.

Такого никогда не было, когда я работал с Debian 7, поэтому я почти уверен, что это не проблема с оборудованием.

Какие инструменты можно использовать, чтобы выяснить, почему моя система продолжает зависать? Я пробовал top / htop и iotop (когда система зависает, ничего не пишется и не читает слишком много). Похоже, что btrfs не может использовать какой-либо монитор активности, чтобы определить, есть ли у него проблемы с записью / чтением. Есть что-нибудь еще, что я могу попробовать?

Со страницы Btrfs получил :

Файлы с большим количеством случайных записей могут сильно фрагментироваться (более 10000 экстентов), вызывая перегрузку на жестких дисках и чрезмерные мультисекундные скачки загрузки процессора в системах с твердотельным накопителем или большим объемом оперативной памяти.

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

  • Здесь может быть полезна опция монтирования nodatacow со связанными ошибками.

  ...

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

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

В конце я сжал свой раздел btrfs и логический том, в котором он находится, я создал новый LV и отформатировал его как ext4, а затем поместил образы виртуальных дисков, которые у меня есть (VirtualBox), в этот «раздел».

Это может быть прозрачная проблема с огромными страницами, когда поток ядра khugepaged буквально анализирует вашу оперативную память для ее дефрагментации или создает огромные страницы из 4k.

Ядро, возможно, решило включить огромные страницы, учитывая ваш довольно большой объем системной памяти.

Проверьте содержимое этих двух настроек ядра:

/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

Связанный с производительностью записи Abysmal general dm-crypt (LUKS)