оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)
PreScriptum: раз уж написалось -- даю копию в sysadmins@l.a.o,
просьба отвечать (при необходимости) в ту рассылку, где прочитали.
On Sun, Dec 23, 2007 at 03:01:09PM +0500, Timur S. Sattarov wrote:
> > Мысль была банальная -- грамотная разводка I/O способна
> > помочь ощутимо сильнее крутых рейдов и быстрых дисков самих
> > по себе. Примеры тому наблюдаю с незавидной регулярностью.
> А где можно почитать про грамотную разводку I/O ?
В т.ч. в Multi-Disk HOWTO.
> может есть примеры из собственного прошлого ?
Разумеется.
> почему спрашиваю - сейчас стоит задача оптимизировать это самое
> I/O некоторое время назад в соседней ветке я описывал проблему
> с медленными дисками на сервере.
См. ниже.
On Sun, Dec 23, 2007 at 03:43:46PM +0300, Alexey Pechnikov wrote:
> Оптимизация - это настройка СУБД, оптимизация медленных
> запросов.
Ой зависит. Для рассылочного сервера (с СУБД!) это не даст вааще
ничего ;-)
> На примере постгреса - ставим логирование всех запросов,
> которые выполняются дольше 400 мс (я выбрал такое значение,
> диски SATA) и избавляемся от них. Для того же постгреса
> рекомендуют разделять базы и журналы, но после выполнения
> вышеописанной оптимизации это может и не требоваться. Ну и логи
> отключите (реверс-прокси, веб-сервер...) - можно логировать
> что-то очень нужное, но сохранять все запросы слишком дорогое
> удовольствие.
Это решение "от софта" -- его танцевать полезно, но не всегда
возможно (например, эти самые логи могут быть нужны). Тогда надо
понимать сильные и слабые стороны используемых ФС и RAID -- и всё
равно при необходимости плясать ещё и от железа.
В случае базы и веб-сервера может иметь смысл для начала
отбросить логи на отдельный диск или массив (физически отдельные
шпиндели). В зависимости от используемой шины -- возможно, на
отдельный канал или контроллер (для IDE-дисков, где остались --
правило как для SATA: "один шлейф, один девайс").
С файловыми системами тоже не всё просто: из тех, на которых
нормально происходит двустороннее движение, знаю только XFS.
Это на которой элементарно можно потерять данные при внезапном
сбое. А вот ext3, на которой нет такой security feature, при
активном r/w способна заткнуться с взлётом LA в небеса и падением
пропускной в моём случае на два порядка (от ~50Mb/s до ~500Kb/s,
это ещё ниже, чем просто разрывающиеся диски).
Для файловых систем, на которых ничто не закладывается на время
доступа к данным (спулеры могут и почто-ньюсочиталки) -- показано
применять опцию монтирования noatime, которая сокращает
количество операций записи на ФС (той же ext3 неплохо помогает).
Про dir_index уже рассказали, на ядрах 2.4 этого не было и с ext3
на толстых каталогах было просто печально. Поэтому там жили xfs
с reiserfs.
Журналируемым файловым системам, по крайней мере xfs, по
доверенным слухам здорово помогает вынос журнала на отдельный
шпиндель -- мне тут mithraen@altlinux рассказывал, да всё никак
руки не дойдут попробовать.
> Некорректно сформированные запросы должен блокировать
> реверс-прокси, чтобы они не грузили веб-сервер.
Или mod_security. Хотя для веба там, где некритично -- может
куда больше помочь инструктирование гугля ходить со средней
частотой (при помощи google webmaster tools), вот кто бы ещё
яндексам рассказал про существующие расширения robots.txt насчёт
частоты... (inktomi, msn, northernlight проще рубить на файрволе
-- всё равно у нас они никому по существу не упали, а тот же msn
был замечен в игнорировании robots.txt)
> P.S. Настройка системы для "черного ящика" (чужого ПО) весьма
> неблагодарное занятие... По-хорошему, надо настраивать и ПО и
> систему совместно.
Разумеется. Но есть и относительно общие места.
On Sun, Dec 23, 2007 at 06:35:24PM +0500, Timur S. Sattarov wrote:
> Спасибо за ответ, уточню - есть система, прищедшая по
> наследству, основная задача которой - почта, количество
> пользователей - порядка 20 тысяч, сколько из них активных не
> знаю, может 6-7 тыс.
Есть знакомые провайдеры -- в sysadmins@lists.altlinux...
> свои проблемы со скоростью винтов (20-30 мегабайт в секунду,
> даже с кэшем) я уже выкладывал в соседней ветке.
Дисков-то много и в каком уровне RAID? (сорри, ветку искать лень,
а эту мож ещё почитаю на неделе по скорингу)
> из-за не совсем грамотной настройки - письма не сразу
> отвергаются при ошибках во время SMTP сессии (не тот юзер,
> переполнен ящик), а сначала получаются а потом отлупливаются
> обратно. Load Average поднимается до 1000-1500
Насколько помню, на kernel.org проверяли, что на 1024 оно
обнуляется, на собственном опыте... ;)
> проц в большинстве своем занят iowait.
Да-да, типичная i/o bound задача.
> после установки валидации пользователей - ситуация улучшилась,
> но бэкап периодически грузит машину, если в это время есть
> приличное количество писем на отправку - то висит куча
> процессов ожидающих ответа от дисковой системы. Я прекрасно
> понимаю что надо реорганизовывать дисковую подсистему и даже
> уже наметил что-то в качестве решения. И тут поднимается вопрос
> о грамотной разводке I/O, поэтому очень хотелось бы послушать,
> что именно делают другие специалисты для того чтобы *грамотно*
> организовать дисковую подсистему.
Спул в одну сторону (на что-то вроде RAID10 или несколько RAID1
-- у RAID5/6 всё грустно при записи), mailbox'ы или то, куда
почта доставляется -- в другую, логи -- в третью, бэкап -- в
четвёртую.
Здесь речь о физических шпинделях (предположительно зеркалах),
а не о разделах. Таким образом, на данные получается от 6HDD,
при этом спул может иметь смысл положить на SAS или быстрые SATA
вроде WD Raptor, а доставочные -- а, maildir -- на просто 7200
вроде WD Raid Edition или Hitachi.
Логи можно класть и не на зеркало; бэкап -- если не хватает
посадочных мест, то можно попробовать тоже (и вынимать, когда
не пишется, на другую машинку с более надёжным местом).
Систему можно поставить на тот же диск (или диски), где логи
и бэкап. Если вжиматься в 6HDD и всовывать их в один ящик,
то это похоже на такой вариант (воспринимать не буквально):
[ sda, sdb: средняя скорость, повышенная надёжность]
sda1 sdb1 своп (RAID1, pri=100)
sda2 sdb2 система (RAID1, ext3, noatime)
sda3 логи (ext3, noatime)
sdb3 бэкап (ext3, noatime)
[ sdc, sdd: высокая скорость, умеренная ёмкость]
sdc1 своп (pri=75)
sdd1 своп (pri=75)
sdc2 sdd2 спул (RAID1, xfs, noatime?)
[ sde, sdf: средняя скорость, повышенная надёжность]
sde1 своп (pri=50)
sdf1 своп (pri=50)
sde2 sdf2 maildirs (RAID1, ext3/xfs, !noatime)
Насколько понимаю, на maildir noatime лучше не ставить.
Меньше чем на 4HDD я бы строить не стал.
Про приоритеты свопов (больше=выше) -- см. swapon(2).
Может оказаться хорошо поставить жёсткие квоты на 90--95%
каждой файловой системы -- в этих пределах наступает затык
по производительности всех известных мне ФС.
Если дисков на самом деле понадобится больше -- стоит озадачиться
материнкой, на которой разведено I/O в плане дисковых
контроллеров и слотов, в которые его можно воткнуть, и сети:
зачастую в недорогих даже серверных платах всё валят на одну
шину, которой быстро плохеет.
Например, ftp.linux.kiev.ua сейчас работает на Foxconn
NFPIK8AA-8EKRS (nForce Pro 2200), где основная шина попросту
продублирована и картинка по части I/O выглядит так:
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
80:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
80:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
80:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
80:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
80:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
80:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
80:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
Т.е. набортные 8 каналов SATA разбросаны по двум шинам.
Соответственно болтающиеся на них 8HDD друг другу особо
не мешают (кажется, они разбрасывались вперехлёст, но
точно уже не помню).
> Попутно пара вопросов - в текущей системе стоит reiserfs V3.6,
Что, ещё не взрывалась? Хороший повод съехать, рано или поздно
склонна взрываться (редко, но метко). Хотя данные обычно
вытаскивали по крайней мере при участии namesys'овского народа.
> я же привык работать с ext3, так как кажется она мне более
> надежной и удобной. Как вы думаете - стоит ли оставаться на
> reieser и, если да, стоит ли переезжать на 4-ю версию ? Почта
> хранится в maildir - при обращении к ящику с большим
> количеством сообщений система притормаживает.
Если хотите, можете попробовать пойти по такому пути -- насколько
понимаю, выкатывается более другая система взамен существующей?
- протестировать надёжность нового железа, включая диски и память
(bonnie++ + cpuburn, memtest86, stresslinux...);
- протестировать имеющийся или приходящий бесперебойник, в т.ч.
на корректность выключения системы при конце батарейки;
- спланировать дисковую подсистему, глядя в Multi-Disk HOWTO
и картинку выше;
- собрать серверную часть и попробовать проверить её на стенде
сгенерированными потоками по SMTP и по возможности -- POP3/IMAP
(про бенчмарки или load generator'ы тут не знаю, сам бы слал
муттом, боюсь);
- сбэкапить полученную систему;
- постараться смоделировать нештатные ситуации -- забивание
разных ФС, отключение питания (как с бесперебойником, так
и без него -- батареи тоже дохнут) -- контролируя целостность
пользовательских данных при помощи чего-нить вроде md5deep.
Если всё в порядке -- тогда уже приниматься за перенос данных.
On Sun, Dec 23, 2007 at 06:05:23PM +0300, Alexey Pechnikov wrote:
> А вот бэкап надо реорганизовывать или "размазывать" во времени.
> Например, rsync имеет опцию
> --bwlimit=KBPS limit I/O bandwidth; KBytes per second
> Может быть, это то, что вам нужно?
Если у вас уже работает ionice, может иметь смысл пускать сразу
nice rsync -- при этом будет мягче по дискам. Если не работает
-- может иметь смысл озадачиться своим ядром.
Правда, бэкапы при этом плавно теряют когерентность -- но чтоб
её обеспечить, надо что-то вроде LVM и/или XFS snapshots, а их
мне применять не доводилось.
> Выбираю ext3 за ее надежность; reiserfs имеет иные настройки по
> умолчанию, потому часто рекомендуется для соответствующих задач
Нет. reiserfs -- другая файловая система, никакими настройками
разницу с ext3 не нивелировать (ни для одной из этих ФС).
Я обычно применяю reiserfs в паре с RAID0, ext3 -- с RAID1,
xfs -- с RAID1/5.
> но чтение манов по ext3 позволит настроить как минимум не хуже.
Простите, но это попросту не соответствует действительности.
> Для начала на ext3 отключите atime,
Для rfs оно тоже отключается. И для xfs -- тоже.
> Еще для вашей задачи стоит попробовать опцию data=journal (в
> /etc/fstab использовать нельзя, надо указывать как параметр
> загрузки)
Это для корня -- Вы держите на корне что-либо критичное к I/O?
> для конкурентного ввода-вывода может оказаться очень полезной.
См. выше про XFS. В ext3 (и рейзере) нет delayed block
allocation и по словам разработчиков -- непонятно, когда
ещё появится. Ну и xfs -- extent-based filesystem, в отличие
от ext3, которая оперирует одним экстентом на весь block device,
насколько вообще понимаю. Это тоже помогает [xfs] прилично
работать в условиях жёсткой конкуренции за i/o.
> P.S. Утилита rm отвратительно работают с большим числом файлов
> в директории.
Ну-ну.
On Sun, Dec 23, 2007 at 09:19:28PM +0300, Alexey Pechnikov wrote:
> > надо будет проследить какое количество одновременных запросов
> > сейчас оптимально, хотя сейчас я думаю не о старой машине а о
> > том как буду организовывать новую.
> Зато у вас есть возможность потестировать на уже работающей
> системе, это полезно.
Полезно -- на стенде. На старой лучше аккуратно noatime добавить
(mount -o remount,noatime), куда безопасно.
On Sun, Dec 23, 2007 at 09:58:45PM +0300, Alexey Pechnikov wrote:
> Время было около 5 утра, уже сил не было разбираться :-)
Ой, если сил нет -- надо лочить консоль и валить от неё
высыпаться. Можно ж и не разгрести потом последствия одной
очепяточки, хотя мне пока скорее везло -- даже chown -R .*
небезболезненно, но вышло починить когда-то (дома :).
--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
Reply to: