Выявление узкого места на статическом файловом сервере при скорости 1000 запросов в секунду

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

Я буду краток и прост: у меня есть файловый сервер (2x Dual Core Xeon 2.0, 8 ГБ ОЗУ, 132 жестких диска SCSI), на котором размещается несколько тысяч небольших файлов изображений, 4–10 КБ, и получающих до 1000+ запросов в секунду.

Я пробовал на нем Apache, Nginx и Lighttpd и обнаружил, что Lighttpd лучше всего подходит для этой работы.

Когда веб-сервер выключен, простой тест HD показывает, что он может читать со скоростью около 170 мегабайт в секунду. Однако, когда веб-сервер включен и обслуживает около 30 мегабайт в секунду, этот же самый тест HD показывает, что HD может читать со скоростью всего 5 мегабайт в секунду, вместо 140 (170 минус 30) мегабайт в секунду, как пустышка. я ожидал.

Теперь даже при 1000 запросов в секунду ЦП работает нормально (нагрузка ниже 1), и есть много свободной памяти, что наводит меня на мысль, что узким местом на самом деле является HD.

Итак, мой вопрос: почему? Почему HD, который якобы может читать со скоростью 170 мегабайт в секунду, создает узкие места только со скоростью 30 мегабайт в секунду при обслуживании через веб-сервер?

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

Это правильно? Если да, то как я могу это решить? RAID? Еще HD? SSD?

Заранее спасибо!

Ваша проблема действительно, скорее всего, заключается в поиске накладных расходов. Есть два основных решения:

Добавление достаточного количества оперативной памяти для размещения в памяти вашего рабочего набора - идеальный подход, и в наши дни это довольно дешево. Даже если вам кажется, что у вас достаточно ОЗУ, проблема заключается в том, что кэш-памяти недостаточно, который обычно не отображается как «использованный».
В противном случае SSD выполняет поиск намного быстрее, чем обычный жесткий диск, и может помочь, если ваш рабочий набор слишком велик для размещения в ОЗУ (т. Е. Слишком велик для ограничения ОЗУ вашей материнской платы или будет дешевле, чем такой же объем обычной ОЗУ. ).

RAID10, RAID1 или RAID0 (опасность: потеря одного диска приведет к уничтожению массива) может помочь разделить доступ для чтения между несколькими жесткими дисками, улучшая среднее время доступа, но это только улучшение Nx (где N - количество используемых дисков) , поэтому добавление ОЗУ следует считать предпочтительным.

Это действительно похоже на то, что вы перегружаете возможности ввода-вывода вашего диска. Диск со скоростью вращения 15 000 об / мин может выполнять около 170 операций ввода-вывода с произвольным вводом-выводом в секунду. При использовании в массиве RAID0, RAID1 или RAID10 это число операций ввода-вывода складывается в зависимости от количества дисков в массиве (R5 и R6 создают еще одно узкое место, поэтому истинная пропускная способность может быть снижена по сравнению с теоретической). Если у вас 96 дисков, ваш теоретический максимум составляет около 16K операций ввода-вывода в секунду.

В сторону: сравните это даже с твердотельными накопителями среднего уровня в наши дни, которые могут обрабатывать 30 КБ операций ввода-вывода в секунду на одном устройстве.

Этот HD, вероятно, достаточно старый, чтобы иметь размер сектора 512 байт, хотя файловая система, вероятно, имеет размер блока 4 Кбайт. Таким образом, вы получите некоторую последовательность ввода-вывода для всех этих файлов размером 4–10 КБ. Даже в этом случае 1000 одновременных запросов в секунду звучат так, как будто это действительно приведет к насыщению одного диска. Тот факт, что ваш бенчмаркинг в загруженное время показывает скудные 5 МБ / с, говорит мне, что вы перегружаете диск.

Если ваш набор данных достаточно мал, один SSD (или пара в зеркале R1) будет достаточно быстрым, чтобы не отставать, не увеличивая объем оперативной памяти для кеширования. Если этот «132 SCSI HD» на самом деле является «132 ГБ SCSI HD», то вы находитесь в «довольно доступном» ценовом диапазоне SSD.