Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)
On Tue, Dec 25, 2007 at 11:39:00AM +0200, I wrote:
> > > Мысль была банальная -- грамотная разводка I/O способна
> > > помочь ощутимо сильнее крутых рейдов и быстрых дисков самих
> > > по себе. Примеры тому наблюдаю с незавидной регулярностью.
> > А где можно почитать про грамотную разводку I/O ?
> В т.ч. в Multi-Disk HOWTO.
http://tldp.org/HOWTO/Multi-Disk-HOWTO.html
PS: к нему в пару хорошо идёт Partition HOWTO:
http://tldp.org/HOWTO/Partition/index.html
ещё:
http://www.freesource.info/wiki/HCL/XranenieDannyx/SravnenieFajjlovyxSistem
http://www.freesource.info/wiki/HCL/XranenieDannyx/SoftwareRAID
http://www.freesource.info/wiki/RazbienieDiska
и (несколько устарело, но):
http://people.redhat.com/alikins/system_tuning.html
И вот ещё письмо mithraen@:
---
Date: Tue, 25 Dec 2007 13:14:10 +0300
From: Denis Smirnov
Subject: Re: оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)
> > На примере постгреса - ставим логирование всех запросов,
> > которые выполняются дольше 400 мс (я выбрал такое значение,
> > диски SATA) и избавляемся от них. Для того же постгреса
> > рекомендуют разделять базы и журналы, но после выполнения
> > вышеописанной оптимизации это может и не требоваться. Ну и логи
> > отключите (реверс-прокси, веб-сервер...) - можно логировать
> > что-то очень нужное, но сохранять все запросы слишком дорогое
> > удовольствие.
> Это решение "от софта" -- его танцевать полезно, но не всегда
> возможно (например, эти самые логи могут быть нужны). Тогда надо
> понимать сильные и слабые стороны используемых ФС и RAID -- и всё
> равно при необходимости плясать ещё и от железа.
На всякий случай напоминаю любителям пораскидывать все по разным
шпинделям о tablespaces в постгресе. Раскидывать отдельные таблички по
разным шпинделям может быть ой как полезно.
Жаль в постгресе до сих пор нельзя делать индексы сразу по всем
наследникам конкретной таблицы (необходимо для unique значений), когда
это появится, будет вообще чудесная возможность практически не трогая
frontend выкидывать редко используемые _отдельные row_ на другой
шпиндель.
> В случае базы и веб-сервера может иметь смысл для начала
> отбросить логи на отдельный диск или массив (физически отдельные
> шпиндели). В зависимости от используемой шины -- возможно, на
> отдельный канал или контроллер (для IDE-дисков, где остались --
> правило как для SATA: "один шлейф, один девайс").
Это вообще святое. Сколько раз на это забивал, и сколько раз это
забивание било граблями очень метко по лбу.
> Для файловых систем, на которых ничто не закладывается на время
> доступа к данным (спулеры могут и почто-ньюсочиталки) -- показано
> применять опцию монтирования noatime, которая сокращает
> количество операций записи на ФС (той же ext3 неплохо помогает).
Это вообще must have.
> Про dir_index уже рассказали, на ядрах 2.4 этого не было и с ext3
> на толстых каталогах было просто печально. Поэтому там жили xfs
> с reiserfs.
> Журналируемым файловым системам, по крайней мере xfs, по
> доверенным слухам здорово помогает вынос журнала на отдельный
> шпиндель -- мне тут mithraen@altlinux рассказывал, да всё никак
> руки не дойдут попробовать.
По крайней мере везде, где идет работа с большим количеством мелких
файлов помогает просто волшебно.
Самое простое обоснование -- экономия лишних seek, ибо журнал обычно
далеко от того места куда пишем данные :) На xfs еще некоторые
операции могут ограничиваться записью только у журнал (AFAIR если
временный файлик создали, записали в него и быстро прибили до того как
он успел реально отправиться на диск, все эти операции отразятся
только в журнале).
>> Некорректно сформированные запросы должен блокировать
>> реверс-прокси, чтобы они не грузили веб-сервер.
> Или mod_security. Хотя для веба там, где некритично -- может
> куда больше помочь инструктирование гугля ходить со средней
> частотой (при помощи google webmaster tools), вот кто бы ещё
> яндексам рассказал про существующие расширения robots.txt насчёт
> частоты... (inktomi, msn, northernlight проще рубить на файрволе
> -- всё равно у нас они никому по существу не упали, а тот же msn
> был замечен в игнорировании robots.txt)
Реверс-сервер сам по себе не просто экономит, а ЭКОНОМИТ ресурсы.
Уменьшение требований к ресурсам на порядок я своими глазами видел. Но
это там в оперативку а не диски упирались.
> Спул в одну сторону (на что-то вроде RAID10 или несколько RAID1
> -- у RAID5/6 всё грустно при записи), mailbox'ы или то, куда
> почта доставляется -- в другую, логи -- в третью, бэкап -- в
> четвёртую.
В случае с RAID надо еще не забывать чтобы размер блока у RAID и FS
совпадали. Для RAID0/5 критично.
> Систему можно поставить на тот же диск (или диски), где логи
> и бэкап. Если вжиматься в 6HDD и всовывать их в один ящик,
> то это похоже на такой вариант (воспринимать не буквально):
Я, кстати, так и делал. Только журнал клал туда же куда и систему (там
машинка маленькая была -- 2 HDD).
> Может оказаться хорошо поставить жёсткие квоты на 90--95%
> каждой файловой системы -- в этих пределах наступает затык
> по производительности всех известных мне ФС.
С квотами я не подружился, а вот приучить мониторинг ругаться
нехорошими словами уже на 80% было полезно.
У меня квоты разве что на vz.
>> Попутно пара вопросов - в текущей системе стоит reiserfs V3.6,
> Что, ещё не взрывалась? Хороший повод съехать, рано или поздно
> склонна взрываться (редко, но метко). Хотя данные обычно
> вытаскивали по крайней мере при участии namesys'овского народа.
Там где на данные до такой степени пофиг чтобы ставить reiser уж лучше
xfs. reiser хорошо для кэша squid'а, например. И то это для меня
сейчас скорее теория -- давно с reiser предпочитал не связываться.
> - протестировать надёжность нового железа, включая диски и память
> (bonnie++ + cpuburn, memtest86, stresslinux...);
wtf stresslinux?
> - собрать серверную часть и попробовать проверить её на стенде
> сгенерированными потоками по SMTP и по возможности -- POP3/IMAP
> (про бенчмарки или load generator'ы тут не знаю, сам бы слал
> муттом, боюсь);
apt-cache show postal
> - сбэкапить полученную систему;
> - постараться смоделировать нештатные ситуации -- забивание
> разных ФС, отключение питания (как с бесперебойником, так
> и без него -- батареи тоже дохнут) -- контролируя целостность
> пользовательских данных при помощи чего-нить вроде md5deep.
> Если всё в порядке -- тогда уже приниматься за перенос данных.
Кстати отключение питание хорошо моделировать с одновременно запущеным
бенчмарком на дисковую. У меня ext3 с data=journal всю жизнь
великолепно выживала резеты. А тут за полгода два фатальных сбоя...
> Правда, бэкапы при этом плавно теряют когерентность -- но чтоб
> её обеспечить, надо что-то вроде LVM и/или XFS snapshots, а их
> мне применять не доводилось.
XFS snapshots лучше применять именно что одновременно с LVM. Некоторое
время назад использовал эту схему -- был очень доволен.
Надо не забывать что при бэкапе некоторых приложений (например СУБД)
этого мало, надо еще их предупреждать заранее что хотим такое
проделать, чтобы их файлы были в когерентном состоянии.
> > Еще для вашей задачи стоит попробовать опцию data=journal (в
> > /etc/fstab использовать нельзя, надо указывать как параметр
> > загрузки)
> Это для корня -- Вы держите на корне что-либо критичное к I/O?
man tune2fs до просветления. В том числе на предмет дефолтов при монтировании.
data=journal, к тому же, не только для экономии на I/O. Скорее
наоборот (хотя на БД действительно почему-то дает и экономию на I/O).
> > для конкурентного ввода-вывода может оказаться очень полезной.
> См. выше про XFS. В ext3 (и рейзере) нет delayed block
> allocation и по словам разработчиков -- непонятно, когда
> ещё появится. Ну и xfs -- extent-based filesystem, в отличие
> от ext3, которая оперирует одним экстентом на весь block device,
> насколько вообще понимаю. Это тоже помогает [xfs] прилично
> работать в условиях жёсткой конкуренции за i/o.
Если я правильно понимаю, то у ext3 "экстентов" именно что нет. Там
блоки. Экстент это нечто вроде "блока переменной длины". Я бы обозвал
даже скорее "кластером переменной длины".
> Ой, если сил нет -- надо лочить консоль и валить от неё
> высыпаться. Можно ж и не разгрести потом последствия одной
> очепяточки, хотя мне пока скорее везло -- даже chown -R .*
> небезболезненно, но вышло починить когда-то (дома :).
Подтверждаю. Да, вплоть до того что в случае аварийной ситуации гасить
нафиг сервер и идти спать оставив записку и выключив мобильник. Ибо от
того что можно натворить будучи невменяемым за консолью уволят куда
скорее (да и побьют больнее) чем за такую выходку.
---
BTW в т.ч. ругаться на забитые ФС умеет monit.
--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
Reply to: