Re: оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)
On 25 декабря 2007, Alexander Vlasov wrote: > Это значит смерть машины в случае вылета одного из дисков. Угу. > Я зеркалирую своп. И это правильно. По всем докам, что я видел. -- Best regards, Mikhail Bart-mdv- @ SolarNet IRC: irc.solarnet.ru WWW: http://www.solarnet.ru/ -- Гении рождаются раз в тысячу лет, и всякий раз не вовремя. -- Евгений Кащеев signature.asc Description: This is a digitally signed message part.
Re: оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)
У вт, 2007-12-25 у 11:39 +0200, Michael Shigorin пише: > PreScriptum: раз уж написалось -- даю копию в [EMAIL PROTECTED], > просьба отвечать (при необходимости) в ту рассылку, где прочитали. > > из-за не совсем грамотной настройки - письма не сразу > > отвергаются при ошибках во время SMTP сессии (не тот юзер, > > переполнен ящик), а сначала получаются а потом отлупливаются > > обратно. Load Average поднимается до 1000-1500 > > Насколько помню, на kernel.org проверяли, что на 1024 оно > обнуляется, на собственном опыте... ;) По моему опыту -- не обнуляется... > [ sdc, sdd: высокая скорость, умеренная ёмкость] > sdc1 своп (pri=75) > sdd1 своп (pri=75) > sdc2 sdd2спул (RAID1, xfs, noatime?) > > [ sde, sdf: средняя скорость, повышенная надёжность] > sde1 своп (pri=50) > sdf1 своп (pri=50) > sde2 sdf2maildirs (RAID1, ext3/xfs, !noatime) Это значит смерть машины в случае вылета одного из дисков. Я зеркалирую своп. > -- Alexander Vlasov ZULU-UANIC JID: zulu jabber.kiev.ua -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесяток
25.12.07, Alex Kuklin<[EMAIL PROTECTED]> написал(а): > Eugene Berdnikov wrote: > >> Тикловый glob - не сортирует. > > Перловый, думаю, тоже не сортирует. perldoc -t -f glob glob EXPR [...] Beginning with v5.6.0, this operator is implemented using the standard "File::Glob" extension. See File::Glob for details. man File::Glob NAME File::Glob - Perl extension for BSD glob routine DESCRIPTION File::Glob::bsd_glob() implements the FreeBSD glob(3) routine, which is a superset of the POSIX glob() The POSIX defined flags for bsd_glob() are: [...] "GLOB_NOSORT" By default, the pathnames are sorted in ascending ASCII order; this flag prevents that sorting (speeding up bsd_glob()). GLOB(P) The glob() function shall store the number of matched pathnames into pglob->gl_pathc and a pointer to a list of pointers to pathnames into pglob->gl_pathv. The pathnames shall be in sort order as defined by the current setting of the LC_COLLATE category; [...] GLOB_NOSORT Ordinarily, glob() sorts the matching pathnames according to the current setting of the LC_COLLATE category; Вывод: по умолчанию - сортируют.
Re: [Sysadmins] оптимизац ия дисковой подсистемы (linux multi-disk serv er 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, по > доверенным слухам здорово помогает вынос журнала на отдельный > шпиндель -- мне тут [EMAIL PROTECTED] рассказывал, да всё никак > руки не дойдут попробовать. По крайней мере везде, где идет работа с большим количеством мелких файлов помогает просто волшебно. Самое простое обоснование -- экономия лишних 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 критично. > Систему можно поставить на тот же диск (или диски), где логи > и бэкап. Если вжиматься в
оптимизация дисковой подсистемы (linux multi-disk server howto) (w as: OpenVZ, VServer и полудесяток)
PreScriptum: раз уж написалось -- даю копию в [EMAIL PROTECTED], просьба отвечать (при необходимости) в ту рассылку, где прочитали. 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, по доверенным слухам здорово помогает вынос журнала на отдельный шпиндель -- мне тут [EMAIL PROTECTED] рассказывал, да всё никак руки не дойдут попробовать. > Некорректно сформированные запросы должен блокировать > реверс-прокси, чтобы они не грузили веб-сервер. Или 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 тыс. Есть знакомые провайдеры -- в [EMAIL PROTECTED] > свои проблемы со скоростью винтов (20-30 мегабайт в секунду, > даже с кэшем) я уже выкладывал в соседней ветке. Дисков-то много и в каком уровне RAID? (сорри, ветку искать лень, а эту мож ещё почитаю на неделе по скорингу) > из-за не совсем грамотной настройки - письма не сразу > отвергаются при ошибках во время SMTP сессии (не тот юзер, > переполнен ящик), а сначала получаются а потом отлупливаются > обратно. Load Average поднимается до 1000-1500 Насколько помню, на kernel.org проверяли, что на 1024 оно обнуляется, на собственном опыте... ;) > проц в большинстве своем занят iowait. Да-да, типичная i/o bound задача. > после установки валидации пользователей - ситуация улучшилась, > но бэкап периодически грузит машину, если в это время есть > приличное количество писем на отправку - то висит куча > процессов ожидающих ответа от дисковой системы. Я прекрасно > понимаю что надо реорганизовывать дисковую подсистему и даже > уже наметил что-то в качестве решения. И тут поднимает
Re: OpenVZ, VServer и полудесяток
В сообщении от Tuesday 25 December 2007 11:53:12 Artem Chuprina написал(а): > VW> Запросто. Поскольку perl результаты glob пометит как бинарные строки, > VW> а тикль будет в utf-8 конвертить. > > У перла еще и не glob, а readdir будет. Т.е. сортировать не надо. Что > на миллионе файлов может оказаться существенно. Удаление миллиона файлов занимает на тикле около 4-х минут на ноуте. Сдается мне, что перекодировка и сортировка в оперативке заметного вклада не дадут. Или есть нюанс?
Re: OpenVZ, VServer и полудесяток
Victor Wagner -> debian-russian@lists.debian.org @ Tue, 25 Dec 2007 11:10:31 +0300: >> А тормоза у Печникова, наверное, из-за того, что шелл * пакует в >> монолитную строку через realloc(), а тикл пользуется чанковыми строками. VW> Тикль 8.1 и выше в этом месте пользуется списком. Внутреннее VW> представление списка - что-то вроде argc+argv[], чуточку посложнее из-за VW> того что сами элементы списка - не просто строки. >> Но и это не предел оптимизации. Думаю, perl с unlink() в реверсном цикле >> уделает этот тикль как бог черепаху... :-) VW> Запросто. Поскольку perl результаты glob пометит как бинарные строки, VW> а тикль будет в utf-8 конвертить. У перла еще и не glob, а readdir будет. Т.е. сортировать не надо. Что на миллионе файлов может оказаться существенно. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] НИИ требуются: 1. Кто бы мог подумать. Кнышев. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесяток
В сообщении от Tuesday 25 December 2007 06:51:57 ph написал(а): > On 25-Dec-2007, Alexey Pechnikov wrote: > > Тогда по идее rm -rf /test/test_1/ должно работать быстро, поскольку > > список файлов не передается Здесь-то что мешает? > > Надо пройти по всем файлам рекурсивно, сделать unlink, если какой-то > процесс держит файл открытым, удаление будет откладываться, как и удаление > каталогов к которых он находится. что наверняка и проиходит. > обходных путей несколько, в разной степени корретных, но я сомневаюсь, что > тикл их использует. Разве что если эти файлы от как сам и держит:) > При тестировании запускал один скрипт, который и обращался к файлам. Больше никто их не трогал. Проверил на двух разных машинах, поскольку удивился полученному эффекту. Никакие обходные пути не нужны, раз доступ однопользовательский.
Re: OpenVZ, VServer и полудесяток
> Для init.d bash как раз не рекомендуются, есть специальные шеллы с > минимизацией количества форков при загрузке.. Признаться, время загрузки совсем не интересует, секундой больше или меньше для меня не принципиально. Вопрос в удобстве поддержки скриптов. > Насчет сочувствия - сочувствую тем кто не читает вообще никакие доки, > даже howto и faq, не умеет пользоваться гуглом и думает что в этом > виноват bash. > Эта проблема есть вообще _везде_ - ограничение на длину команды(без > которого было бы всё _намного_ хуже), ядро эти "*" не понимает, bash > заменяет такие маски на полный список соотв. файлов, длина команды > получается адской. Тогда по идее rm -rf /test/test_1/ должно работать быстро, поскольку список файлов не передается... Здесь-то что мешает? > Решение: > find /test/test_1/ -type f |xargs rm > Немного более кошерно: > find /test/test_1/ -type f -print0 |xargs -0 rm -f > Вообще это может и сам find: > find /test/test_1/ -type f -delete > Но xargs более универсальная вещь. > Глубина рекурсии для поиска по умолчанию не ограничена, чтобы не трогать > подкаталоги: > find /test/test_1/ -type f -maxdepth=1 |xargs rm > > > Насчет вашего варианта на тикле - он хуже(съест дофига ram, если файлов > много), и явно медленнее решения с find. Интересно, откуда это следует. Буду пробовать. Сдается мне, что если запускаю один интерпретатор тикля, то это будет не медленнее варианта с find, который тоже еще надо проверить по скорости. > и, кстати, на bash, вы могли бы написать аналогично: > cd /test/test_00/ > for f in $(ls ) > do > rm "$f" > done > Если не хочеться менять каталог - добавьте путь в ls и rm или > используйте файл: > for f in $(find /test/test_000/ -type f); do rm "$f"; done > > Но это очень не эффективно - по форку на файл. Идея понятна. Только на тикле это рабочее решение, а на баше - лишь пример. Хотя если в используемом шелле подобные команды встроены, то и проблемы быть не должно.
Re: OpenVZ, VServer и полудесяток
В сообщении от Tuesday 25 December 2007 00:31:28 Eugene Berdnikov написал(а): > А тормоза у Печникова, наверное, из-за того, что шелл * пакует в > монолитную строку через realloc(), а тикл пользуется чанковыми строками. > Но и это не предел оптимизации. Думаю, perl с unlink() в реверсном цикле > уделает этот тикль как бог черепаху... :-) Не совсем понял, как это объясняет жуткое скрежетание винтом от команды rm? Мало того, что тормозит, еще и винт мордует. Притом так, что я уже не рискую подобные тесты запускать, не хочется винт угробить.
Re: OpenVZ, VServer и полудесяток
On Mon, 24 Dec 2007, Artem Chuprina wrote: [EMAIL PROTECTED] -> debian-russian@lists.debian.org @ Mon, 24 Dec 2007 20:27:21 +0300 (MSK): >> Считать в двоичной системе на пальцах - нужна очень высокая координация >> и заученный автоматизм. А до 12 (по костяшкам) старинный метотд. >> y> О! А это как? У меня и костяшек 5... Мутанты среди нас... Я, впрочем, считаю по фалангам, а не по костяшкам. Большим пальцем по остальным четырем, ага. Дошло! И с костяшками тоже :)
Re: OpenVZ, VServer и полудесяток
[EMAIL PROTECTED] -> debian-russian@lists.debian.org @ Mon, 24 Dec 2007 20:27:21 +0300 (MSK): >> Считать в двоичной системе на пальцах - нужна очень высокая координация >> и заученный автоматизм. А до 12 (по костяшкам) старинный метотд. >> y> О! А это как? У меня и костяшек 5... Мутанты среди нас... Я, впрочем, считаю по фалангам, а не по костяшкам. Большим пальцем по остальным четырем, ага. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Попрошу благородного дона не обобщать с утра пораньше! (С)энта -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесяток
On Mon, 24 Dec 2007, Victor Wagner wrote: Считать в двоичной системе на пальцах - нужна очень высокая координация и заученный автоматизм. А до 12 (по костяшкам) старинный метотд. О! А это как? У меня и костяшек 5...
Re: OpenVZ, VServer и полудесяток
Dmitry V. Agalakov -> debian-russian@lists.debian.org @ Mon, 24 Dec 2007 16:21:22 +0300: >> MS> Кажется, сперва думал, что полдюжины, потом заюзал пальцы для учёта >> MS> и оказалось, что вторая рука не нужна :-) >> Я до дюжины на одной считаю. :-) DVA> А почему 12, а не 31? :^) DVA> (2^5=32) Неудобно. Я пробовал. Операция увеличения на 1 (AKA "посчитать следующий") слишком сложная. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Рюкзак не пересобирают, рюкзак укладывают! (c)Руна -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесяток
В сообщении от Sunday 23 December 2007 21:38:05 Artem Chuprina написал(а): > MS> Кажется, сперва думал, что полдюжины, потом заюзал пальцы для учёта > MS> и оказалось, что вторая рука не нужна :-) > Я до дюжины на одной считаю. :-) А почему 12, а не 31? :^) (2^5=32) -- WestCall SPb dept. Phone: +7-(812)-320-0500 ext. 4580 e-mail: [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесяток
Alexey Pechnikov -> debian-russian@lists.debian.org @ Mon, 24 Dec 2007
12:19:52 +0300:
>> AP> P.S. Утилита rm отвратительно работают с большим числом файлов в
>> директории. Я AP> пишу свои скрипты на tcl, которые выполняют то же самое
>> на несколько порядков AP> быстрее. В то же время ls работает нормально, не
>> знаю, в чем проблема. На AP> примере миллиона файлов: rm /test_100/*
>> думает часами и зверски насилует AP> винт, в то время как на тикле foreach
>> fn [glob /test_100/*] {file delete AP> $fn} работает две-три минуты и
>> почти не шелестит винтом. Посмотрите, может, и AP> у вас где подобные
>> грабли закопаны.
>>
>> Сдается мне, что ту проблема с работой glob в шелле а не с утилитой rm. И
>> вообще использование * при работе с миллионом файлов в shell кажется мягко
>> говоря странным. Неужели не нарвались на Argument list too long? Ну да,
>> возможно еще один повод похаять shell и порадоваться за тикль, но к
>> сожалению без шелла никуда :-(
>>
>> --
>> Mikolaj Golub
AP> Из шелла писал _одну_ строку - rm /test_100/*. И
AP> аргумент "/test_100/*" всего один, откуда возьмется "Argument list too
AP> long?"
Из мана на используемый шелл, а что?
Не, судя по отсутствию "Argument list too long" этот rm - builtin, и
шелл, как следствие, скорее всего, busybox... И именно в его исходники
и надо смотреть.
--
Artem Chuprina
RFC2822: Jabber: [EMAIL PROTECTED]
Если ничто уже не помогает, прочтите же, наконец, инструкцию!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесяток
24.12.07, Alexey Pechnikov<[EMAIL PROTECTED]> написал(а): > Из шелла писал _одну_ строку - rm /test_100/*. И > аргумент "/test_100/*" всего один, Как это один? Вы с оффтопиком не путаете? Разворачивание аргументов осуществляется оболочкой (shell), а не программой. -- WBR, Max Vasin JID: [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесяток
В сообщении от Monday 24 December 2007 10:15:15 Mikolaj Golub написал(а):
> On Sun, 23 Dec 2007 18:05:23 +0300 Alexey Pechnikov wrote:
>
> AP> P.S. Утилита rm отвратительно работают с большим числом файлов в
> директории. Я AP> пишу свои скрипты на tcl, которые выполняют то же самое
> на несколько порядков AP> быстрее. В то же время ls работает нормально, не
> знаю, в чем проблема. На AP> примере миллиона файлов: rm /test_100/*
> думает часами и зверски насилует AP> винт, в то время как на тикле foreach
> fn [glob /test_100/*] {file delete AP> $fn} работает две-три минуты и
> почти не шелестит винтом. Посмотрите, может, и AP> у вас где подобные
> грабли закопаны.
>
> Сдается мне, что ту проблема с работой glob в шелле а не с утилитой rm. И
> вообще использование * при работе с миллионом файлов в shell кажется мягко
> говоря странным. Неужели не нарвались на Argument list too long? Ну да,
> возможно еще один повод похаять shell и порадоваться за тикль, но к
> сожалению без шелла никуда :-(
>
> --
> Mikolaj Golub
Из шелла писал _одну_ строку - rm /test_100/*. И
аргумент "/test_100/*" всего один, откуда возьмется "Argument list too
long?" Если бы в тикле оно не работало, да, полез бы в исходники rm
разбираться, а так - вот именно, что повод похаять, но исправлять этот самый
rm надобности нет. Вообще говоря, наличие указанного бага в
узкоспециализированном языке (шелл) и отсутствие в языке с широкой областью
применения (тикль) заставляет подумать о том, что пора шелл выкинуть на
свалку. Благо заменить есть чем - функциональных языков хватает.
Re: OpenVZ, VServer и полудесяток
On Sun, 23 Dec 2007 18:05:23 +0300 Alexey Pechnikov wrote:
AP> P.S. Утилита rm отвратительно работают с большим числом файлов в
директории. Я
AP> пишу свои скрипты на tcl, которые выполняют то же самое на несколько
порядков
AP> быстрее. В то же время ls работает нормально, не знаю, в чем проблема. На
AP> примере миллиона файлов: rm /test_100/* думает часами и зверски
насилует
AP> винт, в то время как на тикле foreach fn [glob /test_100/*] {file
delete
AP> $fn} работает две-три минуты и почти не шелестит винтом. Посмотрите,
может, и
AP> у вас где подобные грабли закопаны.
Сдается мне, что ту проблема с работой glob в шелле а не с утилитой rm. И
вообще использование * при работе с миллионом файлов в shell кажется мягко
говоря странным. Неужели не нарвались на Argument list too long? Ну да,
возможно еще один повод похаять shell и порадоваться за тикль, но к сожалению
без шелла никуда :-(
--
Mikolaj Golub
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесяток
> Я на перле серьёзно писал лет 7 назад - сейчас видимо придется > переучиваться на тикль. > К тому же у cisco ivr на нем, тоже надо время от времени. На тикле много всего. Сам пишу на нем для debian серверов, в postgresql на pltcl, для виндоусов всех мастей, для виндовых кпк... Притом на ноуте под debian можно написать приложение, потом только проверить интерфейс под офтопиком и какие-то платформоспецифичные вещи (активсинк, вебкамера, etc.). P.S. Если бы я писал семь лет назад на тикле, а не вижуал бейсике, php, visual c++, borland c++ и проч., то и переучиваться бы не пришлось...
Re: OpenVZ, VServer и полудесяток
> > С помощью tune2fs включаем dir_index. Получим вот такую информацию о > > разделе: > > > > # /sbin/tune2fs -l /dev/sda1|grep index > > Filesystem features: has_journal resize_inode dir_index filetype > > needs_recovery sparse_super large_file > > как я понял - включается это сразу при форматировании, по крайней мере - > отформатированные не так давно партиции. В любой момент включается. Только надо проверить, что в уже созданных директориях индекс создается - я не разбирался, в какой момент он создается, на всякий случай существующие директории скопировал, старые удалил и перенес на взамен них копию. Время было около 5 утра, уже сил не было разбираться :-) > на bash как то нелогично :) > я думал про perl, но если не поможет - придется учить тикль ... Сам писал раньше на перле, и много писал. Потом по совету некоторых участников этой рассылки пригляделся к тиклю - и переписал на нем все свои перловые и сишные проекты. Сейчас спокойно занимаюсь развитием и техподдержкой двух крупных проектов, плюс еще много чем (не один, с командой, но мы все разом "перепрыгнули" на тикль, притом за полгода сумели перенести крупный проект с перла и с++ и написать еще один уже на тикле. потом, конечно, пришлось еще полгода код блоками переписывать, поскольку первый вариант был рабочий, но написан "коряво"). На перле с большим трудом тянул один проект. Питон иногда использую, перл - уже нет. Так что сравнивать есть с чем.
Re: OpenVZ, VServer и полудесяток
Michael Shigorin -> debian-russian@lists.debian.org @ Sat, 22 Dec 2007 15:42:13 +0200: MS> Кажется, сперва думал, что полдюжины, потом заюзал пальцы для учёта MS> и оказалось, что вторая рука не нужна :-) Я до дюжины на одной считаю. :-) -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Как в notepad тексты редактировать? Руками каждую букву набирать, что ли? (c)vitus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесяток
> > Запросы, которые не могут быть обработаны, стоит сразу "отбивать" (это
> > верно для системы любого типа), это верно как с точки зрения
> > безопасности, так и с точки зрения производительности (именно в таком
> > порядке).
>
> надо будет проследить какое количество одновременных запросов сейчас
> оптимально, хотя сейчас я думаю не о старой машине а о том как буду
> организовывать новую.
Зато у вас есть возможность потестировать на уже работающей системе, это
полезно.
> > Выбираю ext3 за ее надежность; reiserfs имеет иные настройки по
> > умолчанию, потому часто рекомендуется для соответствующих задач, но
> > чтение манов по ext3 позволит настроить как минимум не хуже. Для начала
> > на ext3 отключите atime, diratime и включите индекс директорий. После
> > этого сможете эффективно работать с десятками и сотнями тысяч файлов в
> > директории (тестировал и с миллионом файлов, но это на практике пока не
> > потребовалось). Есть и другие полезные опции, но мне хватает
> > вышеназванных. Имхо, рейзер нестабильная ФС с непонятной поддержкой и на
> > свой сервер я ее никогда не поставлю (да и зачем - ощутимых преимуществ
> > не вижу). Еще для вашей задачи стоит попробовать опцию data=journal (в
> > /etc/fstab использовать нельзя, надо указывать как параметр загрузки),
> > для конкурентного ввода-вывода может оказаться очень полезной.
>
> Значит наш взгляд на ext2/ext3 совпадает. про atime/diratime я знал,
> а как включается индекс директорий ?
> тоже опция монтирования ?
С помощью tune2fs включаем dir_index. Получим вот такую информацию о разделе:
# /sbin/tune2fs -l /dev/sda1|grep index
Filesystem features: has_journal resize_inode dir_index filetype
needs_recovery sparse_super large_file
> (нет, я конечно посмотрю в man :), просто интересно мнение и опыт)
> небольшое уточнение про опцию data=journal в опциях ядру - это
> справедливо только для корневой ФС, остальные легко меняются на ходу и в
> fstab.
Да, спасибо за уточнение. Сам я пробовал как раз на корневой ФС, для моих
задач счел эту опцию ненужной.
> > P.S. Утилита rm отвратительно работают с большим числом файлов в
> > директории. Я пишу свои скрипты на tcl, которые выполняют то же самое на
> > несколько порядков быстрее. В то же время ls работает нормально, не знаю,
> > в чем проблема. На примере миллиона файлов: rm /test_100/* думает
> > часами и зверски насилует винт, в то время как на тикле foreach fn [glob
> > /test_100/*] {file delete $fn} работает две-три минуты и почти не
> > шелестит винтом. Посмотрите, может, и у вас где подобные грабли закопаны.
>
> Кстати да, искал альтернативу rm/ls/mv, неужели лучше писать самому в
> скриптах ?
У меня доступ к файлам производится из сервера приложений (aol web server),
так что все равно пишу на тикле и проблем, подобных вышеозначенной, не
возникает. При тестировании работы с большим количеством файлов в директории
вылезла проблема с rm, а поскольку тестовый скрипт также на тикле, написать
foreach fn [glob /test_100/*] {file delete $fn}
вместо
rm /test_100/*
сложностей не составило. Если вы системные скрипты пишете на bash, то я вам
просто сочувствую. На bash я делаю только скрипты для /etc/init.d/ Временами
в рассылке пробегают темы о различных извращениях для ценителей bash, но это,
видно, не для меня, читаю (интересно же) с ужасом :-)
Re: OpenVZ, VServer и полудесяток
> уточню - есть система, прищедшая по наследству, основная задача которой
> - почта,
> количество пользователей - порядка 20 тысяч, сколько из них активных не
> знаю, может 6-7 тыс.
> свои проблемы со скоростью винтов (20-30 мегабайт в секунду, даже с
> кэшем) я уже выкладывал в соседней ветке.
> из-за не совсем грамотной настройки - письма не сразу отвергаются при
> ошибках во время SMTP сессии (не тот юзер, переполнен ящик), а сначала
> получаются а потом отлупливаются обратно. Load Average поднимается до
> 1000-1500 проц в большинстве своем занят iowait. после установки
> валидации пользователей - ситуация улучшилась, но бэкап периодически
> грузит машину, если в это время есть приличное количество писем на
> отправку - то висит куча процессов ожидающих ответа от дисковой системы.
А вот бэкап надо реорганизовывать или "размазывать" во времени. Например,
rsync имеет опцию
--bwlimit=KBPS limit I/O bandwidth; KBytes per second
Может быть, это то, что вам нужно?
Запросы, которые не могут быть обработаны, стоит сразу "отбивать" (это верно
для системы любого типа), это верно как с точки зрения безопасности, так и с
точки зрения производительности (именно в таком порядке).
> Попутно пара вопросов - в текущей системе стоит reiserfs V3.6, я же
> привык работать с ext3, так как кажется она мне более надежной и
> удобной. Как вы думаете - стоит ли оставаться на reieser и, если да,
> стоит ли переезжать на 4-ю версию ? Почта хранится в maildir - при
> обращении к ящику с большим количеством сообщений система притормаживает.
Выбираю ext3 за ее надежность; reiserfs имеет иные настройки по умолчанию,
потому часто рекомендуется для соответствующих задач, но чтение манов по ext3
позволит настроить как минимум не хуже. Для начала на ext3 отключите atime,
diratime и включите индекс директорий. После этого сможете эффективно
работать с десятками и сотнями тысяч файлов в директории (тестировал и с
миллионом файлов, но это на практике пока не потребовалось). Есть и другие
полезные опции, но мне хватает вышеназванных. Имхо, рейзер нестабильная ФС с
непонятной поддержкой и на свой сервер я ее никогда не поставлю (да и зачем -
ощутимых преимуществ не вижу). Еще для вашей задачи стоит попробовать опцию
data=journal (в /etc/fstab использовать нельзя, надо указывать как параметр
загрузки), для конкурентного ввода-вывода может оказаться очень полезной.
P.S. Утилита rm отвратительно работают с большим числом файлов в директории. Я
пишу свои скрипты на tcl, которые выполняют то же самое на несколько порядков
быстрее. В то же время ls работает нормально, не знаю, в чем проблема. На
примере миллиона файлов: rm /test_100/* думает часами и зверски насилует
винт, в то время как на тикле foreach fn [glob /test_100/*] {file delete
$fn} работает две-три минуты и почти не шелестит винтом. Посмотрите, может, и
у вас где подобные грабли закопаны.
Re: OpenVZ, VServer и полудесяток
В сообщении от Sunday 23 December 2007 13:01:09 Timur S. Sattarov написал(а): > Michael Shigorin wrote: > > Кажется, сперва думал, что полдюжины, потом заюзал пальцы для > > учёта и оказалось, что вторая рука не нужна :-) > > > > Мысль была банальная -- грамотная разводка I/O способна помочь > > ощутимо сильнее крутых рейдов и быстрых дисков самих по себе. > > Примеры тому наблюдаю с незавидной регулярностью. > > А где можно почитать про грамотную разводку I/O ? > может есть примеры из собственного прошлого ? > почему спрашиваю - сейчас стоит задача оптимизировать это самое I/O > некоторое время назад в соседней ветке я описывал проблему с медленными > дисками на сервере. Оптимизация - это настройка СУБД, оптимизация медленных запросов. На примере постгреса - ставим логирование всех запросов, которые выполняются дольше 400 мс (я выбрал такое значение, диски SATA) и избавляемся от них. Для того же постгреса рекомендуют разделять базы и журналы, но после выполнения вышеописанной оптимизации это может и не требоваться. Ну и логи отключите (реверс-прокси, веб-сервер...) - можно логировать что-то очень нужное, но сохранять все запросы слишком дорогое удовольствие. Некорректно сформированные запросы должен блокировать реверс-прокси, чтобы они не грузили веб-сервер. P.S. Настройка системы для "черного ящика" (чужого ПО) весьма неблагодарное занятие... По-хорошему, надо настраивать и ПО и систему совместно.
