Увеличение производительности в Ubuntu

Я конечно зачастил публиковать статьи других авторов (да и всё по правилам делаю, обратные ссылки в конце оставляю, авторство не присваиваю), но тут действительно интересная статья. Называется она "Фикс падения производительности при копировании/закачке файлов в Ubuntu". Лично воспользовался ей - есть результаты. Рекомендую!

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

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

Проблема

При высокоскоростной закачке торрентов, многопоточном копировании с диска на диск, на флешки, загрузка процессора зашкаливает в 100%, быстро растет LA.

При этом на файловых операциях с небольшим числом потоков всё работает хорошо.

Немного теории

Есть такие штуки в операционной системе, называются планировщики ввода-вывода (IO schedulers), которыe являются прослойкой между блочными устройствами и драйверами низкого уровня. Задача планировщика — оптимальным образом обеспечить доступ процесса к запрашиваемому дисковому устройству. В случае жесткого диска — это означает минимизацию перемещений считывающей головки.
Деятельность планировщиков сводится к следующим аспектам:

• Увеличение производительности за счет переупорядочения и слияния запросов
• Предотвращение зависаний и перетирания считываемых данных записью
• Честное распределение времени доступа к ресурсам разным процессам

Планировщиков есть много и, как выяснилось, именно с ними была связана проблема, решаемая этим постом.
Рассмотрим вкратце наиболее распространенные.

Noop

Простейший планировщик, работающий по принципу FIFO. Переупорядочения нет, слиянию могут подлежать только запросы, находящиеся рядом в очереди. Хорошо подходит для устройств со случайным доступом, вроде Flash памяти.

Deadline

Планировщик, который ставит больший приоритет запросам на чтение, нежели запросам на запись. Запросы переупорядочиваются, но при этом время обработки запроса не должно превышать заданные пределы(по умолчанию, 0.5 с для чтения, 5 с для записи)

Для реализации используются 4 очереди: 2 очереди sorted-by-start-sector(для чтения и для записи) и 2 очереди FIFO(тоже для чтения и для записи). Обычно, запросы берутся из сортированных очередей, но если поджимает deadline(таймаут) первого запроса из очереди FIFO, то обработка запросов продолжается по сортированным очередям с этого элемента.

Лучше всего подходит для организации баз данных.

CFQ — Completely Fair Queuing

Цель этого планировщика — честное распределения времени доступа к ресурсу всех инициаторов запросов. CFQ может быть настроен для уравнивания процессов, групп процессов, пользователей.

По реализации, CFQ подразумевает по одной FIFO-очереди на инициатора запросов и переключается между очередями по алгоритму Round-robin.

Не знаю, кому нужна такая честность, но переупорядочения запросов для минимизации перемещения считывающей головки жесткого диска в этом планировщике нет.

Anticipatory

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

Планировщик Anticipatory базируется на Deadline. Подходит для десктопов, т.к. сохраняется отзывчивость подсистемы ввода вывода. Не подходит для RAID, TCQ. Плохо подходит в ситуациях, когда синхронные запросы посылаются разными процессами.

Решение

Планировщик по умолчанию в Ubuntu 10.10 — CFQ, но как показывает практика именно этот планировщик и вызывает высокую нагрузку на CPU при многопоточном копировании. Изменяем планировщик на другой, например, на Deadline и вуаля — больше нету загрузки CPU под 100%.

Для SSD дисков и Flash памяти вообще, как отмечено выше, рекомендуется использовать Noop.

Немного практики

Узнать активный планировщик

Чтобы посмотреть все доступные планировщики в системе и узнать, какой из них активен выполняем:

Здесь {DEVICE-NAME} — имя блочного устройства, например sda.
Например, если диск sda, то нужно выполнить:

На выходе получаем строку вроде этой:

В квадратных скобках указан текущий планировщик.

Смена планировщика на лету

Чтобы поменять планировщик в реальном времени без перезагрузки выполняем:

Здесь {SCHEDULER-NAME} — один из присутствующих в системе планировщиков, у меня это: noop anticipatory deadline cfq. Например, чтобы поставить планировщик deadline, выполяем

Фиксация настройки планировщика

Далее, нам нужно заставить Ubuntu использовать выбранный нами планировщик и после перезагрузки. Для этого добавляем строку

в конфиг GRUB 2.

UPD: После внесения изменений нужно обновить конфигурацию grub:

Если у вас grub, а не grub2, то добавляем строку

в /boot/grub/grub.conf.

Помощь в выборе планировщика

На хабре уже писали про автоматизированный выбор планировщика. Конечно, простой проверки скорости чтения недостаточно для оптимального выбора, но кое-какое представление дать может.

Полезные ссылки

Ссылки, использованные при написании поста:
Презентация на тему I/O Schedulers в Linux
A comparison of I/O Schedulers
Планировщики ввода/вывода в Linux (linux kernel io schedule optimization tune)
Книга о Grub 2

P.S.

UPD:
Данная статья рассказала лишь об одном, по сути самом простом, способе решения проблемы, связанной, c т.н. багом 12309. Есть еще советы по решению данной проблемы:
— не менять планировщик CFQ, но отконфигурировать
— поставить zen ядро
— настроить аггресивность Swap
— купить жесткий диск с аппаратным планировщиком и много оперативки(чтоб в Swap не уходить)

Источник: habrahabr.ru.