У нас есть централизованный файловый кеш, который кластер веб-серверов использует для хранения «тяжелых» страниц. Каждый веб-сервер использует Samba для монтирования этой общей области.
У нас на сервере много iowait, и мне было интересно, какие шаги мы могли бы предпринять, чтобы сделать централизованный кеш более эффективным? Мы уже используем memcache в качестве кэша первой строки для некоторых объектов и можем просто увеличить объем памяти для этого, но мне интересно узнать, какие методы мы могли бы использовать для ускорения кеширования на основе файлов. На всех серверах установлена последняя версия Ubuntu.
Сервер использует файловую систему ext3 с LVM. Может быть, другие файловые системы будут более производительными для такого рода деятельности? Мы использовали Samba в течение многих лет просто потому, что всем она комфортна, и у нас были проблемы с обслуживанием NFS (например, отказ от размонтирования). Может, есть технологии получше ...
Проверьте планировщик io (в документации ядра он называется лифтом io), назначенный этому тому.
$ cat /sys/block/sda/queue/scheduler
noop anticipatory [deadline] cfq
Для большинства дистрибутивов RedHat и Fedora по умолчанию используется планировщик CFQ. IMHO это не лучший вариант для серверного процесса iobound. Я рекомендую планировщик сроков
$ echo "deadline" > /sys/block/sda/queue/scheduler
чтобы изменить это или добавить
elevator=deadline
к вашим аргументам загрузки, чтобы сделать это постоянным.
Высокое время iowait также может быть вызвано агрессивным опережением чтения, которое может быть ненужным для вашей рабочей нагрузки. По умолчанию для систем RedHat и Fedora установлено 128 КБ.
$ cat /sys/block/sda/queue/read_ahead_kb
128
Поэкспериментируйте с отображением более низких значений в этот файл и посмотрите, уменьшит ли это время iowait.
Также проверьте базовый диск или массив. В случае его ухудшения или перестройки время iowait резко возрастет, поскольку базовая дисковая подсистема крадет пропускную способность io при восстановлении себя.
Высокий процент IOWait на сервере означает, что вам нужен более быстрый диск / больше памяти для дискового кеша.
Взгляните на свою статистику iostat -x 5 - вы насыщаете диск? В зависимости от семантики вашего приложения, возможно, вам подойдет больше памяти на файловом сервере.
Если между хранением и извлечением страниц сервером существует большая задержка, вам нужен более быстрый диск.
Проверьте вывод free, чтобы узнать, сколько памяти у вас есть и для чего она используется.
Поскольку доступ к Samba осуществляется по сети, я считаю, что ваша сеть является узким местом в первую очередь. Оптимизированы ли ссылки для типов и размеров файлов / пакетов, проходящих по сети?
Можете ли вы отслеживать ссылки, чтобы узнать, насколько они используются?
Если сеть не кажется узким местом, вы можете ознакомиться с некоторыми советами в это руководство чтобы немного оптимизировать конфигурацию Samba.
редактировать
Вы упомянули LVM, что это за диски? Обычные имеющиеся в продаже диски IDE со скоростью вращения 7200 об / мин? Если это действительно ожидание ввода-вывода, то да, вам понадобится более быстрый диск. Это может быть так же просто, как диск SATA 10k, или даже высокопроизводительный рейд.
Другой вариант - использовать решение с обратным прокси-кешем, такое как Squid или varnish, вместо того, чтобы проходить через разные уровни, чтобы получить одни и те же данные. Просто то, что следует рассматривать как такое решение, будет оптимизировано для обслуживания веб-страниц (в отличие от более общего решения для обслуживания файлов).