Я заметил, что когда я делаю тяжелые приложения для записи, вся система замедляется. Чтобы проверить это дальше, я выполнил это, чтобы выполнить (относительно) работу с низким процессором и высоким диском:
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.
Установите точку монтирования в «noatime». В большинстве случаев использования, как правило, тратится время на обновление активности. Особенно в случае непрерывной перекачки одиночных строк в файл, вы вынуждаете несколько обновлений файловой системе для каждого доступа.
Проверьте лифт. Стандартный лифт по умолчанию для большинства дистрибутивов настроен для плунжеров произвольного доступа. SSD не нуждается в дополнительной логике, поэтому установка лифта в noop может повысить производительность, позволяя аппаратным средствам управлять записью.
Сжатие с обратной записью. Это немного более эзотерично, но вы можете проверить метод кэширования, используемый с 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 МБ.