Работа с каталогами в современных операционных системах медленнее, когда она многопоточная?

Question

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

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

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

У меня был опыт работы под Windows и Linux. Я тестировал чистый поиск файлов с использованием инструментов операционной системы, а также написал собственные маленькие тесты.

Я что-то упустил?
Может кто-нибудь объяснить мне секреты этой темы?
Спасибо!

Answer 1

решение: используйте NCQ для повышения производительности. Для этого настройте контроллер жесткого диска SATA на использование AHCI.

дополнительная информация ниже:

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

• 1 ядро: довольно быстро
• Включено 4 ядра: намного медленнее! это было довольно удивительно, а также сбило меня с толку.

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

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

в мире SCSI это был общий стандарт уже довольно давно. и в мире SATA он был адаптирован некоторое время назад. чтобы разблокировать эту функцию, необходимо настроить контроллер жесткого диска для работы в режиме AHCI - это обязательное условие для использования NCQ!

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

• совместимая / устаревшая IDE
• AHCI

Я реализовал свой собственный эталонный тест для сравнения одной и той же системы, работающей со следующими конфигурациями:

• 4 ядра включены, устаревшая IDE: довольно медленно
• Включено 4 ядра, AHCI / NCQ: намного быстрее. отдельные тесты выполняются в 6 раз быстрее!

-

заключение

для полного использования возможностей систем с одновременным доступом к жесткому диску:

1. переключитесь на AHCI (чтобы вы могли использовать NCQ )
2. не используйте универсальные драйверы AHCI, поставляемые с ОС. вместо этого используйте специфичные для поставщика оптимизированные драйверы . Пример: Windows 7 поставляется с некоторыми общими драйверами AHCI, которые поддерживают большинство распространенных контроллеров HDD. однако при использовании набора микросхем Intel обязательно установите Intel «менеджер хранилища матрицы» или Intel «технология быстрого хранения» (например, Intel RST 11.7). оптимизированные драйверы показали дополнительное повышение производительности жесткого диска.

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

-

примечание: существует миф, который гласит: NCQ относится только к "серверным" средам (с сотнями процессов, работающих параллельно) . мои результаты тестов указывают в другом направлении: это также актуально для "настольных" сред. при тяжелом одновременном доступе к жесткому диску .

дополнительные примечания:

1. некоторые старые чипсеты / контроллеры жестких дисков SATA не поддерживают режим AHCI. но это не охватывается здесь.
2. некоторым «старым» ОС требуются специальные действия при установке в режиме AHCI или при переходе уже системы из режима IDE в AHCI. но это не охвачено здесь.

Answer 2

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

Если перефразировать, то процессор может быть параллельным, а диск - нет.

Answer 3

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

Answer 4

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

Фактически, более новые ядра Linux изначально поддерживают AHCI. Windows XP требует установки драйвера, зависящего от поставщика, даже если AHCI присутствует на адаптере шины хоста. Windows Vista изначально поддерживает как AHCI, так и NCQ. FreeBSD полностью поддерживает AHCI и NCQ начиная с версии 8.0.

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

Answer 5

Я думаю, что ваше предположение об оптимизации ОС для одновременного доступа к диску просто неверно. Я предполагаю, что это делает такой переупорядочение, когда вы используете Scatter / сборку ввода / вывода из одного потока, но для этого нет никакого практического способа оптимизировать параллельные запросы. Любая такая схема привнесет ненужную задержку в однопоточном чтении. (ОС придется немного подождать на случай, если поступит параллельный запрос.) В любом случае, короткий ответ заключается в том, что ваши параллельные запросы заставляют головки чтения перепрыгивать повсюду. ОС не может оптимизировать это.

Answer 6

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

На грубом уровне возможность ускорения возникает, когда вы не используете максимальную пропускную способность контроллера ввода-вывода и его кешей или когда вы перекрываете ввод-вывод с интенсивной работой ЦП и они заблокированы, ожидая друг друга.

Сравниваете ли вы чтение нескольких маленьких файлов, разбросанных по системе, или просто считывание нескольких больших файлов последовательно? Вы увидите различные характеристики производительности здесь.

Профилировали ли вы с хорошим системным профилировщиком, таким как (бесплатно) инструментарий производительности Windows , чтобы увидеть, что происходит в ваших тестах? Это практически обязательно.

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

-Rick