Хотя я просмотрел здесь некоторые вопросы, я думаю, что каждая ситуация индивидуальна и, возможно, требует совершенно другого решения.
Что у меня сейчас:
На этом томе в основном хранится около 10 миллионов файлов (максимум 20 МБ в будущем) размером от 100 до 2 МБ. Это более точное распределение диапазонов размеров файлов (в K) и чисел в диапазоне:
4 6162
8 32
32 55
64 11577
128 7700
256 7610
512 555
1024 5876
2048 1841
4096 12251
8192 4981
16384 8255
32768 20068
65536 35464
131072 591115
262144 3411530
524288 4818746
1048576 413779
2097152 20333
4194304 72
8388608 43
16777216 21
Файлы в основном хранятся на уровне 7 тома, например:
/volume/data/customer/year/month/day/variant/file
В этих папках обычно ~ 1-2К файлов, иногда меньше, иногда до 5-10К (редкие случаи).
Ввод / вывод не такой тяжелый, но я испытываю зависания, когда нажимаю на него немного сильнее. Например:
Запуск следующего cron один раз в час приводит к зависанию всего сервера на несколько секунд и может даже нарушить работу службы (запись новых данных), поскольку генерируются тайм-ауты ввода-вывода:
find /volume/data/customer/ -type f -iname "*.ext" -mmin +60 -delete
find /volume/data/customer -type d -empty -delete
Я также наблюдаю низкую скорость записи (несколько МБ / с) при записи файлов в указанных выше диапазонах. При записи файлов большего размера все идет нормально, пока кеш записи не заполнится (очевидно), а затем скорость упадет и сервер начнет зависать волнами.
Теперь я ищу решение для оптимизации производительности моего хранилища, поскольку я уверен, что я не оптимален по умолчанию, и многие вещи можно улучшить. Хотя это не так полезно для меня, я бы не стал отказываться от LVM, если он не дает значительного прироста, потому что, хотя это возможно, я бы не переустанавливал весь сервер, отбрасывая LVM.
Много читал о XFS, ReiserFS и Ext4, но я весьма озадачен. Другие мои серверы с гораздо меньшим объемом RAID1 2 ТБ, но с такой же настройкой и значительно большей рабочей нагрузкой, работают безупречно.
Любые идеи?
Как мне отлаживать / экспериментировать?
Спасибо.
Согласитесь с Shodanshok, что крайний срок, вероятно, хорошая идея. Далеко не уверен, что вам следует использовать здесь XFS.
find / volume / data / customer / -type f -iname "* .ext" -mmin +60 -delete
Раньше XFS плохо справлялась с удалением файлов - мне сказали, что большинство ошибок в этой области были устранены, но не проводилось никаких жестких тестов, чтобы подтвердить это.
все идет нормально, пока кеш записи не заполнится (очевидно), а затем скорость упадет и сервер начнет зависать волнами
Висит? звучит так, как будто вы должны отрегулировать соотношение грязных страниц (уменьшить фоновое raio, увеличить коэффициент блокировки), вы также должны изменить dirty_expire_centisecs (вверх или вниз - посмотрите, что делает его быстрее!) и уменьшить dirty_writeback_centisecs, если общая нагрузка и использование процессора приемлемы .
Если операторы find обрабатывают основную часть данных, то хорошей идеей будет настройка vfs_cache_pressure. Опять же, единственный способ узнать правильное значение - это метод проб и ошибок, но с очень большим разветвлением и, по-видимому, небольшим количеством чтения файлов данных, а затем уменьшение этого значения должно улучшить эффективность кеширования.
Обратите внимание, что снимки LVM убивают пропускную способность ввода-вывода.
---- вышесказанное применимо независимо от выбранной файловой системы ----
При выборе файловой системы самое важное соображение - насколько она должна быть надежной. Если это все временные файлы, и вы не против потерять их все даже в случае сбоя / не требуется быстрое время восстановления после сбоя, то вам вообще не следует использовать журналируемую файловую систему. Но вы мало что рассказали нам о данных.
Отмечая большое количество разветвлений .... функция dir_index ext3 / 4 была явно добавлена, чтобы обеспечить более быстрое и эффективное разрешение, когда каталог содержит большое количество файлов / высокий оборот файлов. Я не знаю, насколько эффективна XFS в этом сценарии.
ReiserFS больше не очень хорошо поддерживается.
Есть еще несколько вещей, на которые вы, возможно, захотите взглянуть (включая ИБП, bcache, специальные журнальные устройства), но тогда у меня не будет оправдания подключить книгу по теме.
Во-первых, XFS - правильный выбор для такого сценария: с XFS практически невозможно выйти из inodes.
Чтобы повысить эффективность удаления, попробуйте следующее:
deadline Планировщик ввода / вывода (по умолчанию) cfqlogbsize=256k,allocsize=64k как варианты крепления (в дополнение к nodiratime,noatime)Чтобы снизить влияние удалений на другие действия системы, попробуйте запустить find сценарий с использованием ionice -c 2 -n 7
Сообщите о своих результатах!