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: ran{}ran.pp.ru 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 11:53:12 Artem Chuprina написал(а): VW Запросто. Поскольку perl результаты glob пометит как бинарные строки, VW а тикль будет в utf-8 конвертить. У перла еще и не glob, а readdir будет. Т.е. сортировать не надо. Что на миллионе файлов может оказаться существенно. Удаление миллиона файлов занимает на тикле около 4-х минут на ноуте. Сдается мне, что перекодировка и сортировка в оперативке заметного вклада не дадут. Или есть нюанс?
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: 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 и полудесяток
24.12.07, Alexey Pechnikov[EMAIL PROTECTED] написал(а): Из шелла писал _одну_ строку - rm /test_100/*. И аргумент /test_100/* всего один, Как это один? Вы с оффтопиком не путаете? Разворачивание аргументов осуществляется оболочкой (shell), а не программой. -- WBR, Max Vasin JID: [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: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Если ничто уже не помогает, прочтите же, наконец, инструкцию!
--
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 и полудесяток
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: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Рюкзак не пересобирают, рюкзак укладывают! (c)Руна
--
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 и полудесяток
В сообщении от Tuesday 25 December 2007 00:31:28 Eugene Berdnikov написал(а): А тормоза у Печникова, наверное, из-за того, что шелл * пакует в монолитную строку через realloc(), а тикл пользуется чанковыми строками. Но и это не предел оптимизации. Думаю, perl с unlink() в реверсном цикле уделает этот тикль как бог черепаху... :-) Не совсем понял, как это объясняет жуткое скрежетание винтом от команды rm? Мало того, что тормозит, еще и винт мордует. Притом так, что я уже не рискую подобные тесты запускать, не хочется винт угробить.
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 и полудесяток
В сообщении от Sunday 23 December 2007 13:01:09 Timur S. Sattarov написал(а): Michael Shigorin wrote: Кажется, сперва думал, что полдюжины, потом заюзал пальцы для учёта и оказалось, что вторая рука не нужна :-) Мысль была банальная -- грамотная разводка I/O способна помочь ощутимо сильнее крутых рейдов и быстрых дисков самих по себе. Примеры тому наблюдаю с незавидной регулярностью. А где можно почитать про грамотную разводку I/O ? может есть примеры из собственного прошлого ? почему спрашиваю - сейчас стоит задача оптимизировать это самое I/O некоторое время назад в соседней ветке я описывал проблему с медленными дисками на сервере. Оптимизация - это настройка СУБД, оптимизация медленных запросов. На примере постгреса - ставим логирование всех запросов, которые выполняются дольше 400 мс (я выбрал такое значение, диски SATA) и избавляемся от них. Для того же постгреса рекомендуют разделять базы и журналы, но после выполнения вышеописанной оптимизации это может и не требоваться. Ну и логи отключите (реверс-прокси, веб-сервер...) - можно логировать что-то очень нужное, но сохранять все запросы слишком дорогое удовольствие. Некорректно сформированные запросы должен блокировать реверс-прокси, чтобы они не грузили веб-сервер. P.S. Настройка системы для черного ящика (чужого ПО) весьма неблагодарное занятие... По-хорошему, надо настраивать и ПО и систему совместно.
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 и полудесяток
Запросы, которые не могут быть обработаны, стоит сразу отбивать (это
верно для системы любого типа), это верно как с точки зрения
безопасности, так и с точки зрения производительности (именно в таком
порядке).
надо будет проследить какое количество одновременных запросов сейчас
оптимально, хотя сейчас я думаю не о старой машине а о том как буду
организовывать новую.
Зато у вас есть возможность потестировать на уже работающей системе, это
полезно.
Выбираю 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 и полудесяток
Michael Shigorin - debian-russian@lists.debian.org @ Sat, 22 Dec 2007
15:42:13 +0200:
MS Кажется, сперва думал, что полдюжины, потом заюзал пальцы для учёта
MS и оказалось, что вторая рука не нужна :-)
Я до дюжины на одной считаю. :-)
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Как в notepad тексты редактировать? Руками каждую букву набирать, что ли?
(c)vitus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 и полудесяток
Я на перле серьёзно писал лет 7 назад - сейчас видимо придется переучиваться на тикль. К тому же у cisco ivr на нем, тоже надо время от времени. На тикле много всего. Сам пишу на нем для debian серверов, в postgresql на pltcl, для виндоусов всех мастей, для виндовых кпк... Притом на ноуте под debian можно написать приложение, потом только проверить интерфейс под офтопиком и какие-то платформоспецифичные вещи (активсинк, вебкамера, etc.). P.S. Если бы я писал семь лет назад на тикле, а не вижуал бейсике, php, visual c++, borland c++ и проч., то и переучиваться бы не пришлось...
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]
