Тяжелая активность записи на производительность системы SSD nukes

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

john -incremental > file_on_SSD 

Это выводит десятки тысяч строк в секунду на файл на моем системном диске.

Когда это делается, мышь отстает, TTY перестают реагировать, приложения «исчезают», и вообще весь компьютер становится непригодным. Когда я смогу в конечном счете Control + C john , система вернется в полную силу через несколько секунд.

Это экстремальный пример, но у меня есть аналогичные проблемы с немного меньшей интенсивностью записи, например, копирование больших файлов из быстрых источников или перекодирование.

Мой основной диск ОС – довольно быстрый SSD ( OCZ Agility 60GB ) с EXT4. Если я напишу вывод john на механический диск с EXT4, я не испытываю таких же замедлений, хотя скорость намного медленнее (SSD составляет ~ 42 000 слов в секунду, механический – 8 000 w / s). Пропускная способность может быть актуальной. Механический диск также не имеет ничего общего с системой. Это всего лишь данные.

И я использую ядро ​​2.6.35-2, но я заметил эту проблему, так как я получил этот SSD, когда я, вероятно, использовал .31 или что-то примерно с того времени.

Итак, что вызывает замедление? Выпуск EXT4? Ядерный вопрос? Вопрос SSD? Все вышеперечисленное? Что-то другое?

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

Это была известная проблема на некоторое время. Использование SSD-настроенной FS, такой как Btrfs, может помочь, но это может и не так.

В конечном счете, это ошибка в системах управления планировщиком / памятью IO. Недавно были некоторые исправления, направленные на решение этой проблемы. См. Исправлено: проблема оперативной реакции Linux на рабочем столе?

Эти патчи могут в конечном итоге пробиться в ядро ​​mainline, но на данный момент вам, вероятно, придется скомпилировать ваше собственное ядро, если вы хотите исправить эту проблему.

Есть несколько вещей, которые вы можете проверить, чтобы попытаться улучшить производительность SSD в Linux.

  1. Установите точку монтирования в «noatime». В большинстве случаев использования, как правило, тратится время на обновление активности. Особенно в случае непрерывной перекачки одиночных строк в файл, вы вынуждаете несколько обновлений файловой системе для каждого доступа.

  2. Проверьте лифт. Стандартный лифт по умолчанию для большинства дистрибутивов настроен для плунжеров произвольного доступа. SSD не нуждается в дополнительной логике, поэтому установка лифта в noop может повысить производительность, позволяя аппаратным средствам управлять записью.

  3. Сжатие с обратной записью. Это немного более эзотерично, но вы можете проверить метод кэширования, используемый с hdparm для устройства. Кэширование с обратной записью может оказать положительное влияние на производительность SSD по сравнению с записью.

Возможно, ваше кэширование файлов неправильно настроено для вашей рабочей нагрузки. К сожалению, ядро ​​Linux достаточно глупо, чтобы не обрабатывать это автоматически, а значения по умолчанию довольно плохие, если у вас много ОЗУ и достаточно медленных блочных устройств. Подробнее см. https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/ .

Я предлагаю попробовать изменить /etc/sysctl.conf либо

 vm.dirty_background_ratio = 3 vm.dirty_ratio = 6 

чтобы значительно снизить давление в RAM, вызванное кэшированием записи, чтобы ядро ​​могло лучше справляться с другими задачами. Это будет способствовать улучшению латентности для более низкой пропускной способности.

Другая возможность – увеличить кеширование, но если ваш процесс постоянно записывает новые данные, вы будете сильно задерживаться, если кеш когда-либо будет заполнен. Если вы хотите попробовать, вы можете сделать что-то вроде

 vm.dirty_background_ratio = 5 vm.dirty_ratio = 80 

Обратите внимание, что настройки *_ratio относятся к проценту доступной ОЗУ. Если вам нужен лучший контроль, используйте настройки *_bytes . Я лично использую следующую конфигурацию для своей рабочей станции:

 vm.dirty_background_bytes = 50000000 vm.dirty_bytes = 200000000 

Это ограничивает фоновый буфер записи до 50 МБ и создает синхронную запись, если в кеш 200 МБ.