subject:"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 задача.

после установки валидации пользователей - ситуация улучшилась,
но бэкап периодически грузит машину, если в это время есть
приличное количество писем на отправку - то висит куча
процессов ожидающих ответа от дисковой системы. Я прекрасно
понимаю что надо реорганизовывать дисковую подсистему и даже
уже наметил что-то в качестве решения. И тут поднимается вопрос
о грамотной разводке I/O, поэтому

Re: OpenVZ, VServer и полу десяток

On Mon, Dec 24, 2007 at 05:03:00PM +0300, Victor Wagner wrote:
   Я до дюжины на одной считаю. :-)
  А почему 12, а не 31? :^)
  (2^5=32)
 Считать в двоичной системе на пальцах - нужна очень высокая
 координация и заученный автоматизм. А до 12 (по костяшкам)
 старинный метотд.

Спасибо, не знал и не подумал.  Хотя напоминалка про количество
дней в месяцах известна :)

-- 
  WBR, Michael Shigorin [EMAIL PROTECTED]
  -- Linux.Kiev http://www.linux.kiev.ua/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

PreScriptum: ещё один кросспост (который тоже надо бы
усушить и на freesource.info, наверное). Просьба отвечать
в одну рассылку.

On Sat, Dec 22, 2007 at 05:31:08PM +0300, Alexey Pechnikov wrote:
Если администрить вместо одной ОС десяток виртуальных ОС, тут
человеческих ошибок администрирования станет столько, что уже
без разницы, насколько исходно прямое средство виртуализации.

Краткий диагноз по диагонали половины субтреда:
Алексей, Вы боитесь того, что даже не попробовали пощупать.
В данном случае совершенно напрасно.

Веб-сервера, включая пресловутый апач (если им еще кто-то
пользуется) тоже виртуальный хостинг поддерживают.

Это не тот виртуальный. Примерно как сказать, что X Windows
-- среда для работы приложений Windows [хотя есть rdesktop, vnc
и wine ;].

И т.д. Не исключаю, что может возникнуть необходимость
в виртуализации ОС, но не у всех и не всегда.

Речь пошла не о виртуальном железе. А о виртуальных контекстах.
Это гораздо легче и удобнее. Практично бывает тогда, когда
по-хорошему задачу бы надо вынести на отдельный тазик, но его
либо никто не даст, либо некуда поставить.

Пример на пальцах -- думаю, я подниму apache1+mod_perl+mod_php4
и, скажем, apache2+mod_php5 на одном тазу, вот только осмысленно
будет разнести их в два, а то и в три разных VE. И всем будет
только лучше, как правило.

On Sat, Dec 22, 2007 at 05:34:48PM +0300, alex kuklin wrote:
Вообще, виртуальный хостинг и паравиртуализация - настолько
разные вещи, что обсуждать их рядом совершенно бессмысленно.

Именно!

On Sat, Dec 22, 2007 at 05:50:34PM +0300, Alexey Pechnikov wrote:
P.S. Чем вас не устраивает вариант запустить отдельные
экземпляры веб-сервера для каждого пользователя? Линукс система
многопользовательская от рождения, виртуализация для работы
нескольких пользователей в общем случае не требуется.

Виден богатый теоретический опыт :-(

On Sat, Dec 22, 2007 at 06:01:42PM +0300, Alexey Pechnikov wrote:
Тем, что управление ресурсами в линуксе - достаточно слабое.
Т.е. ситуация, когда сайт сжирает весь проц и память крайне
слабо контролируется без openvz или аналога.

Именно.

Управлять надо тем, что на сервер ставите и такую дрянь
выбрасывать сразу. При чем тут линукс? Пример из другой
области: чтобы избавиться от пробок на дорогах, будем строить
каждому водителю по магистрали?

Если бы Вы были водителем с опытом езды в крупных городах,
а заодно и сисадмином с опытом управления неединичным количеством
систем -- наверняка моментально бы оценили очень точную аналогию
про отбойник.

Я живу в Киеве и наблюдаю за озером трассу с Московского моста на
Петровку. Так вот можно гарантировать, что утром на мосту опять
была крупная авария или дорожные работы: около девяти утра поток
на Петровку почти отсутствовал. А пробка была небось перед
аварией и грандиозная.

Не знаю, какую премию Дарвина (работу+жильё через этот мост?)
надо было вручить тем, кто придумал делать там реверсивку, но
сейчас вроде как наконец дотумкали, что нужен именно отбойник.

Вы же предлагаете коллегам совершить ту же ошибку, что и
большевики: считать людей идеальными. Нетути их таких,
какие более похожи -- скрипты на php/perl не пишут.

Могу разве что предложить поиграться на досуге с тем же ovz,
vserver, мож ещё чем вроде xen/qemu/virtualbox/vmware, чтоб
по крайней мере не дезинформировать людей о том, что где полезно
и работает, а что куда совать смысла нет.

On Sun, Dec 23, 2007 at 03:22:43PM +0300, Alexey Pechnikov wrote:
Разумная гигиена должна соблюдаться и для программного
обеспечения, тут я с вашей аналогией согласен.

провокация
И при этом используете Debian, а не ALT или Owl? Хех.
/провокация

Конечно, с точки зрения админа сайта поставить готовый движок

Админу писать свой -- заведомо хуже. Даже компетентному
разработчику, как правило, полезней поискать хорошую открытую
базу и отталкиваться от неё, возвращая свои наработки для общей
пользы, чем городить своё. Исключение мне известно одно: когда
мера безопасности шоб никто не догадался такой ценой считается
оправданной.

В связи с вышеизложенным, не считаю технологию виртуализации
той панацеей, за которую ее пытаются выдать маркетологи.

Здрасьте, мы ж не маркетологи. Их давайте дружно игнорировать,
а между собой говорить по существу.

Качественно написанный код не требует засовывать его в подобные
контейнеры. Не маразм ли - например, яву, выполняющуюся в
виртуальной машине, т.е. контейнере, пихают еще в один
контейнер, на кой ляд такая виртуальная машина?

Если бы из этого поделия не было так часто можно выбраться...
Да и узнать о том, сколько оно может попытаться глотнуть
виртуальной (sic:) памяти при каком-нить -Xmx 256m -- тоже
отдельный прикол.

Получается, бардак растет на всех уровнях

Вам явно противопоказано пользоваться протоколами на основе
TCP/IP с таким обострённым чувством прекрасного... :)

Пример из другой области: чтобы избавиться от пробок на
дорогах, будем строить каждому водителю по магистрали?
Пример из этой

Re: OpenVZ, VServer и полу десяток

2007-12-25 Пенетрантность Victor Wagner

On 2007.12.25 at 11:53:12 +0300, Artem Chuprina wrote:

 
  VW Запросто. Поскольку perl результаты glob пометит как бинарные строки,
  VW а тикль будет в utf-8 конвертить.
 
 У перла еще и не glob, а readdir будет.  Т.е. сортировать не надо.  Что
 на миллионе файлов может оказаться существенно.

Тикловый glob  - не сортирует.

 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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 критично.

 Систему можно поставить на тот же диск (или диски), где логи
 и бэкап.  Если вжиматься в 6HDD и всовывать их в один ящик,
 то это похоже на такой вариант (воспринимать не буквально):

Я, кстати, так и делал. Только журнал клал туда же куда и систему (там
машинка маленькая была -- 2 HDD).

 Может оказаться хорошо поставить жёсткие квоты на 90--95%
 каждой файловой системы -- в этих

Re: openvz, vserver

On Tue, Dec 25, 2007 at 03:17:42AM +0300, Alexey Pechnikov wrote:
 Во сколько раз возрастает количество вызовов при названном подходе?

В сумме накладные расходы для веб-хостинга на двухмоторном
сервере четырёхлетней давности при использовании vserver 1.x 
составляли порядка 2--3%.  Для openvz они обязаны быть выше,
поскольку user beancounters тоже не бесплатные, но это как раз
та ситуация, когда добавить процессора или оптимизировать
что-нибудь ещё и увеличить управляемость вполне того стоит.

Аналогию с постоянным полным приводом приводить не буду,
а получение ориентировки по накладным с ovz оставляется 
в качестве домашнего упражнения читателю forum.openvz.org
-- причём за ссылку на чьё-нить пригодное исследование 
буду благодарен.

-- 
  WBR, Michael Shigorin [EMAIL PROTECTED]
  -- Linux.Kiev http://www.linux.kiev.ua/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

2007-12-25 Пенетрантность Eugene Berdnikov

On Tue, Dec 25, 2007 at 11:08:35AM +0600, Ivan Dubrov wrote:
 Вот статейка есть на тему производительности:
 http://www.hpl.hp.com/techreports/2007/HPL-2007-59.pdf

Спасибо; выводы на с. 13.

-- 
  WBR, Michael Shigorin [EMAIL PROTECTED]
  -- Linux.Kiev http://www.linux.kiev.ua/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenVZ, VServer и полу десяток

On Tue, Dec 25, 2007 at 02:15:23PM +0300, Victor Wagner wrote:
 On 2007.12.25 at 11:53:12 +0300, Artem Chuprina wrote:
 
  
   VW Запросто. Поскольку perl результаты glob пометит как бинарные строки,
   VW а тикль будет в utf-8 конвертить.
  
  У перла еще и не glob, а readdir будет.  Т.е. сортировать не надо.  Что
  на миллионе файлов может оказаться существенно.
 
 Тикловый glob  - не сортирует.

 Перловый, думаю, тоже не сортирует.

 И ещё я предлагал реверсировать цикл. Переписывание всего
 каталога при удалении первого файла -- тоже время,
 там набегает N^2.
-- 
 Eugene Berdnikov


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenVZ, VServer и полудесят ок

2007-12-25 Пенетрантность Alex Kuklin


Eugene Berdnikov wrote:

On Tue, Dec 25, 2007 at 02:15:23PM +0300, Victor Wagner wrote:
  

On 2007.12.25 at 11:53:12 +0300, Artem Chuprina wrote:



 VW Запросто. Поскольку perl результаты glob пометит как бинарные строки,
 VW а тикль будет в utf-8 конвертить.

У перла еще и не glob, а readdir будет.  Т.е. сортировать не надо.  Что
на миллионе файлов может оказаться существенно.
  

Тикловый glob  - не сортирует.



 Перловый, думаю, тоже не сортирует.

 И ещё я предлагал реверсировать цикл. Переписывание всего
 каталога при удалении первого файла -- тоже время,
 там набегает N^2.
  

Какое переписывание всего каталога?
Там, вообще-то, b-tree унутре.

--
Alex


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenVZ, VServer и полу десяток

2007-12-25 Пенетрантность Victor Wagner

On 2007.12.25 at 14:27:24 +0300, Eugene Berdnikov wrote:

 
  И ещё я предлагал реверсировать цикл. Переписывание всего
  каталога при удалении первого файла -- тоже время,
  там набегает N^2.

Насколько я помню, операционные системы такими глупостями не занимаются.
Даже vfat нифига не переписывает весь каталог при удалении файла.
А просто помечает соответствующий directory entry как свободный.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

On Tue, Dec 25, 2007 at 11:53:54AM +0300, Alexander GQ Gerasiov wrote:
 В ксене _эмулируются_ только сетевые устройства (ну еще видео,
 если ты его будешь использовать). Процессор там используется
 вполне настоящий.

Это если он умеет так использоваться (новые оптероны, X2,
Xeon 5xxx, Core2 Duo).  Прикол в том, что в зеонах при
переключении виртуальных контекстов L2 cache сбрасывается.

 И там и там оверхэд в рантайме мизерный. Единственное что
 реально экономится в случае с vserver/openvz - память.

Тут рядом ссылочка на hp labs была -- почитайте, что ли,
чтоб не вводить других в такое же заблуждение.

-- 
  WBR, Michael Shigorin [EMAIL PROTECTED]
  -- Linux.Kiev http://www.linux.kiev.ua/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

On Tue, Dec 25, 2007 at 10:42:56AM +0300, Alex Kuklin wrote:
С точки зрения процессов оверхед такой мизерный, что возможно
одновременное исполнение сотен VE с апачем, раздающим статику,
в каждом, на вполне обычной машине.

Ну статику при этом лучше nginx раздаёт. :)

Возможно, для вас это мелочь и четыре-восемь процессорных ядер
на сервере вместо одного-двух есть разумная плата за удобство.
Доктор, а как у меня openvz крутилось на машинке p3-1333/512
памяти? Я что-то делал не так?

Да и у меня vserver работал вон на Duron 800/512 (и сидело там
просто дофига всего сразу -- во многом на вытягивании из того
железа всего, что можно было, и напрактиковался ;), сейчас ovz
тянет нагрузки на банальных младшеньких оптеронах и X2, которые
так со стороны и не заподозрить.

Прав был сэр Крэй насчёт того, что быстрый процессор -- это ещё
вовсе не быстрая система... и насчёт прокладки между стулом и
клавиатурой кто-то тоже был прав. :)

--
WBR, Michael Shigorin [EMAIL PROTECTED]
-- Linux.Kiev http://www.linux.kiev.ua/

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenVZ, VServer и полудесяток

2007-12-25 Пенетрантность Dmitry Fedorov

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

2007-12-25 Пенетрантность Alexander Vlasov

On Mon, Dec 24, 2007 at 10:20:32PM +0300, ph wrote:
Если нужна безопасность, главное правило - держать разные части
системы на разных машинах, и, лучше, не подключенных к
интернету, а запросы пропускать через риверс-прокси. База
данных точно должна быть видна только из локальной сети.

Опять же не сочтите за нахальную (а просто за :) рекламу --
но при озадаченности оной есть более подходящие линуксы.

Где база сразу не торчит, потому что майнтейнеры тоже так думают.

Мы ничего не потеряем, но сильно повысим надежность и
безопасность. vserver, например, рекомендуется использовать
даже если разделения не требуется - с одним экземпляром ос где
крутится всё что надо, на голой хост-системе.

ovz тоже -- это оставляет больше шансов остановить даже
проломленную машину, воспользовавшись доступом туда, куда
пускают совсем не отовсюду (в терминологии ovz это HN,
hwardware node).

--
WBR, Michael Shigorin [EMAIL PROTECTED]
-- Linux.Kiev http://www.linux.kiev.ua/

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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 at jabber.kiev.ua


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

2007-12-25 Пенетрантность Alex Kuklin

Michael Shigorin wrote:

On Mon, Dec 24, 2007 at 10:20:32PM +0300, ph wrote:

Если нужна безопасность, главное правило - держать разные части
системы на разных машинах, и, лучше, не подключенных к
интернету, а запросы пропускать через риверс-прокси. База
данных точно должна быть видна только из локальной сети.

Где база сразу не торчит, потому что майнтейнеры тоже так думают.

Вообще-то в дебиане база доступна только по 127.0.0.1 :)

Ага. Примерно так я и делаю сейчас системы. В идеале - HW node вообще на
флешке.

--
Alex

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

2007-12-25 Пенетрантность Mikhail A Antonov

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: openvz, vserver

2007-12-25 Пенетрантность Denis Smirnov

25.12.07, Michael Shigorin[EMAIL PROTECTED] написал(а):

Если администрить вместо одной ОС десяток виртуальных ОС, тут
человеческих ошибок администрирования станет столько, что уже
без разницы, насколько исходно прямое средство виртуализации.
Краткий диагноз по диагонали половины субтреда:
Алексей, Вы боитесь того, что даже не попробовали пощупать.
В данном случае совершенно напрасно.

Из личного опыта -- использование виртуалок повышает требования к
оперативке, зато _резко_ упрощает администрирование. И при этом при
сокращении усилий на администрирование повышает безопасность системы в
целом.

Все сложности ovz проявляются только тогда, когда речь встает о
решении проблем которые без ovz не решаются в принципе (как то тонкая
нарезка лимитов).

Веб-сервера, включая пресловутый апач (если им еще кто-то
пользуется) тоже виртуальный хостинг поддерживают.
Это не тот виртуальный. Примерно как сказать, что X Windows
-- среда для работы приложений Windows [хотя есть rdesktop, vnc
и wine ;].

виртуальный хостинг на apache и security несовместимы
принципиально. Особенно весело будет после выхода PHP 6, в которой
safe_mode не будет. Я такой чудесный виртуальный хостинг похакаю за
несколько минут. Если там, конечно, будет mod_php ;)

И т.д. Не исключаю, что может возникнуть необходимость
в виртуализации ОС, но не у всех и не всегда.
Речь пошла не о виртуальном железе. А о виртуальных контекстах.
Это гораздо легче и удобнее. Практично бывает тогда, когда
по-хорошему задачу бы надо вынести на отдельный тазик, но его
либо никто не даст, либо некуда поставить.
Пример на пальцах -- думаю, я подниму apache1+mod_perl+mod_php4
и, скажем, apache2+mod_php5 на одном тазу, вот только осмысленно
будет разнести их в два, а то и в три разных VE. И всем будет
только лучше, как правило.

У меня nginx frontend живет в отдельной VE. И это весьма удобно. Я
знаю что человеку чтобы поиметь мою систему нужно:
- поиметь nginx;
- а уж потом поиметь apache;

и при этом он все равно получит доступ только к системе где всего лишь
часть данных. И даже если он сможет получить рутовые права ему это не
поможет.

Вообще, виртуальный хостинг и паравиртуализация - настолько
разные вещи, что обсуждать их рядом совершенно бессмысленно.
Именно!

К тому же паравиртуализация бывает тоже разной. ovz/vserver это можно
сказать jail на стероидах даже, а не виртуализация.

P.S. Чем вас не устраивает вариант запустить отдельные
экземпляры веб-сервера для каждого пользователя? Линукс система
многопользовательская от рождения, виртуализация для работы
нескольких пользователей в общем случае не требуется.
Виден богатый теоретический опыт :-(

в общем случае -- ключевое :) На реальной практике ой как требуется.
Кстати не зря, например, те же ACL считаются обязательными для
сертификации на высокие уровни безопасности. Причем ACL'и на все что
только можно, не только на файлы.

А нормального лимита по I/O в линуксе как не было, так и нет, и не
скоро будет. Так что без виртуализации на сколь-нибудь сложных
программных комплексах не обойтись (разве что разносить по отдельным
физическим машинкам).
Тем, что управление ресурсами в линуксе - достаточно слабое.
Т.е. ситуация, когда сайт сжирает весь проц и память крайне
слабо контролируется без openvz или аналога.
Именно.

_!_

У нас МКАД до установки отбойников в народе называли дорога смерти,
это так, к слову...

Реверсивки это для идеальных людей. Точно также как и обойтись
юниксовыми правами доступа можно при условии что все программы пишут
идеальные программисты. Я, кстати, ни одного в природе не видел.

Де-факто ovz, ovz, и еще раз ovz. А вот там где его действительно не
хватает (нужна еще большая степень виртуализации) смотреть на
xen/vmware. vserver де-факто сложнее в администрировании чем ovz (если
в ovz гайки не пытаться закручивать).

Hint: есть ведь JNI. И получается что не такая уж эта ява и виртуальная.
И таки резать её по ресурсом все равно невозможно -- слишком уж слаба
она по своим возможностями именно как _контейнера_.

Re: openvz, vserver

2007-12-25 Пенетрантность Alexey Pechnikov

В определенных ситуациях использование виртуального сервера оправдано, я это в
каждом сообщении говорил. Но вопрос остается в силе - когда виртуализация _не
может быть_ использована? Например, для перегруженного сервера (с какими
параметрами?), еще в каких-то случаях. Где граница применимости?

Несколько сайтов на одном ip. Вроде как было придумано для экономии ресурсов
(в данном случае ip-адресов). Идея та же самая. На один физический сервер
зарегистрировано много сайтов, стоит себе одна железка, на ней один апач и
т.п.

И т.д. Не исключаю, что может возникнуть необходимость
в виртуализации ОС, но не у всех и не всегда.

Возможно. Вопрос: есть N подключений к апачу 1, и M к апачу 2. Насколько
уменьшатся допустимые Nmax и Mmax после виртуализации?

По ovz мне тесты подсказали, уже есть что тестировать. Попробую.

провокация
И при этом используете Debian, а не ALT или Owl? Хех.
/провокация

Дебиан - понятно, а остальное, наверное, для тех, у кого нет дебиана :-)

В определенных областях хороших наработок не удается найти, потому и пишется
свое. Тут уже вопрос стоит, как интегрировать с существующими наработками,
чтоб меньше писать с нуля. И в первую очередь имеет смысл выбрать, с чем
стоит работать, а что лучше реализовать самому или поискать другую
реализацию.

Получается, бардак растет на всех уровнях

Скажем так, я пытаюсь понять, как хотели лучше разработчики и что у них
потом получилось. И тоже стараюсь делать как лучше, а не ориентироваться
на как всегда. Администрирование и разработку разделить стало очень сложно
(очень много готовых решений всех мастей), потому много вопросов появляется
именно по вопросам администрирования.

И, как я вижу, навык поставить виртуальную машину и запустить
быдлокод в ней все увереннее заменяет собой умение писать
грамотный код.

Можно поинтересоваться списком Ваших проектов и тем,
как оценивали качество хотя бы просто кода?

Крупных решений немного - а точнее, всего два, система мерчендайзинга и
документоборот. Плюс некоторые вычислительные - восстановление трехмерного
рельефа дна, создание дифракционных линз, еще кое-что.

Оценивал по наличию единого читаемого стиля кода и использованным алгоритмам.
Согласен, что код форума нет необходимости оптимизировать, как, скажем,
быстрое преобразование Фурье, но, к примеру, десятки раз вычислять одно
значение или сто раз стучаться к БД вместо написания и вызова хранимой
процедуры для меня достаточно, чтобы больше не вспоминать о таком ПО.

Про форумы всё понятно, вот только плеваться проще, чем хотя бы
отобрать хорошие и советовать людям, когда спрашивают.

В рассылке периодически пробегают обсуждения в том числе и форумов. И часть из
них вполне удовлетворяют достаточно строгим требованиям, так что выбирать
есть из чего.

P.S. Вы, кажется, предлагаете платную поддержку debian?

А мы -- платную поддержку ALT Linux.
+1, и это ни разу не ода быдлу. Заказчик может хотеть немного
странного и при этом в общем и в целом быть нормальным, вменяемым
и стоящим дела. Идеальных (по концу работы, не по ТЗ и началу)
мне ещё не встречалось.

Если вы работаете с заказчиком с момента составления ТЗ, вполне возможно
сообщить, что определенные технологии и продукты безопаснее

Re: openvz, vserver

2007-12-25 Пенетрантность Alexander GQ Gerasiov

На Tue, 25 Dec 2007 13:20:10 +0200
Michael Shigorin [EMAIL PROTECTED] записано:

On Tue, Dec 25, 2007 at 11:53:54AM +0300, Alexander GQ Gerasiov wrote:
В ксене _эмулируются_ только сетевые устройства (ну еще видео,
если ты его будешь использовать). Процессор там используется
вполне настоящий.

Это если он умеет так использоваться (новые оптероны, X2,
Xeon 5xxx, Core2 Duo). Прикол в том, что в зеонах при
переключении виртуальных контекстов L2 cache сбрасывается.
Для старых процессоров тоже ни разу не эмуляция. У ксена юзерспейс не
отличается от x86 и не требует эмуляции, а для аппаратно зависимой
части кернел-спейса используется паравиртуализация с обращением к
гипервизору. Да, есть накладные расходы на дополнительные инструкции
процессора, но они действительно невелики, по сравнению с эмуляторами,
даже с быстрыми.

И там и там оверхэд в рантайме мизерный. Единственное что
реально экономится в случае с vserver/openvz - память.

Тут рядом ссылочка на hp labs была -- почитайте, что ли,
чтоб не вводить других в такое же заблуждение.
У меня есть сильное подозрение, что на результаты их экспериментов
неслабо повлияла проблема с тормознутой ксеновской сетью. Там
действительно есть ряд проблем с производительностью. (А еще со
стабильностью работы software switch, например.)
Но то что всервер/опенвз эффективнее ксена - это и так ясно, но разница
вовсе не существенная. Что тесты hp labs вполне подтверждают.

--
Best regards,
Alexander GQ Gerasiov

Contacts:
e-mail: [EMAIL PROTECTED]
Homepage: http://gq.net.ru

signature.asc
Description: PGP signature

Re: openvz, vserver

On Tue, Dec 25, 2007 at 02:47:29PM +0300, Alex Kuklin wrote:
 ovz тоже -- это оставляет больше шансов остановить даже
 проломленную машину, воспользовавшись доступом туда, куда
 пускают совсем не отовсюду (в терминологии ovz это HN, 
 hwardware node).
 Ага. Примерно так я и делаю сейчас системы. В идеале - HW node
 вообще на флешке.

Хочется, но боязно... а долго уже живут?

Тут продают CF RAID что-то по $50, и ещё журналы охота
повыселять (у небольших CF должно хватать пропускной), 
но как-то на себе обкатывать пока не добрался.

-- 
  WBR, Michael Shigorin [EMAIL PROTECTED]
  -- Linux.Kiev http://www.linux.kiev.ua/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

2007-12-25 Пенетрантность Artem Chuprina

Michael Shigorin - debian-russian@lists.debian.org  @ Tue, 25 Dec 2007 
12:12:08 +0200:

  Разумная гигиена должна соблюдаться и для программного
  обеспечения, тут я с вашей аналогией согласен.

 MS провокация
 MS И при этом используете Debian, а не ALT или Owl?  Хех.
 MS /провокация

Так разумная же...  У Совы она точно параноидальная.

-- 
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

2007-12-25 Пенетрантность Иван Лох

On Tue, Dec 25, 2007 at 12:12:08PM +0200, Michael Shigorin wrote:
 провокация
 И при этом используете Debian, а не *** или Owl?  Хех.
 /провокация

Характерной особенностью пользователей Debian является то, что
они _знают_ почему они его используют. Поэтому если у Вас внезапно
появилось ощущение, что здесь можно раздуть рекламный флейм, который
опосредованно увеличит Ваши доходы, то Вы, безусловно, заблуждаетесь.
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

  Для администрирования сайта жизненно необходим рутовый доступ? Дожили...

 Рутовый доступ был необходим для решения проблем с сервером.
 В частности, мне нужно было поправить настройки апача - а сделать это я
 не мог.

Установить доступ на запись к нужному конфигу сайта учетной записи 
пользователя и дать права на перезапуск своего сайта. Не знаю, можно ли в 
апач перезапустить отдельный сайт, но надеюсь, да (иначе странный выбор для 
хостинга, имхо).

  В самом деле, отличный пример - зачем настраивать sudo, если можно
  поставить виртуалку и дать к ней рутовый доступ. Нет, серьезно, блестящий
  пример непотребного использования виртуализации.

 sudo даст мне доступ к другим ресурсам в системе, что мне совершенно не
 надо.

Так это как настроить. sudo собственной инициативой не обладает, к счастью.

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

2007-12-24 Пенетрантность Max Dmitrichenko


Alexey Pechnikov wrote:

Для администрирования сайта жизненно необходим рутовый доступ? Дожили...
  

Рутовый доступ был необходим для решения проблем с сервером.
В частности, мне нужно было поправить настройки апача - а сделать это я
не мог.



Установить доступ на запись к нужному конфигу сайта учетной записи 
пользователя и дать права на перезапуск своего сайта. Не знаю, можно ли в 
апач перезапустить отдельный сайт, но надеюсь, да (иначе странный выбор для 
хостинга, имхо).
  
Вы не знаете, можно ли перезапустить отдельный сайт в апаче и беретесь 
судить о том, что можно применять в хостинге, а что - нет?

И как много у вас таких теоретических суждений, выдаваемых с видом эксперта?
Вот давайте вы сначала немного изучите предметную область, получите 
минимальный _практический_ опыт администрирования публично доступных 
серверов, а потом уже обсудим вкус устриц, ок?


--
Alex


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

On Monday 24 December 2007 12:24, Alex Kuklin wrote:
 Вы не знаете, можно ли перезапустить отдельный сайт в апаче и беретесь 
 судить о том, что можно применять в хостинге, а что - нет?
 И как много у вас таких теоретических суждений, выдаваемых с видом эксперта?
 Вот давайте вы сначала немного изучите предметную область, получите 
 минимальный _практический_ опыт администрирования публично доступных 
 серверов, а потом уже обсудим вкус устриц, ок?

Не хотел переходить на личности, но я очень хорошо помню момент, когда г-н
Печников стал писать в рассылку. Поток флейма сингулярно подскачил в несколько
раз.

-- 
Макс Дмитриченко


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

В сообщении от Monday 24 December 2007 12:24:24 Alex Kuklin написал(а):
 Alexey Pechnikov wrote:
  Для администрирования сайта жизненно необходим рутовый доступ?
  Дожили...
 
  Рутовый доступ был необходим для решения проблем с сервером.
  В частности, мне нужно было поправить настройки апача - а сделать это я
  не мог.
 
  Установить доступ на запись к нужному конфигу сайта учетной записи
  пользователя и дать права на перезапуск своего сайта. Не знаю, можно ли в
  апач перезапустить отдельный сайт, но надеюсь, да (иначе странный выбор
  для хостинга, имхо).

 Вы не знаете, можно ли перезапустить отдельный сайт в апаче и беретесь
 судить о том, что можно применять в хостинге, а что - нет?
 И как много у вас таких теоретических суждений, выдаваемых с видом
 эксперта? Вот давайте вы сначала немного изучите предметную область,
 получите минимальный _практический_ опыт администрирования публично
 доступных серверов, а потом уже обсудим вкус устриц, ок?

Полагаете, мои мысли насчет неуместного использования виртуальных машин 
ошибочны в силу того, что я не знаю реализацию виртуального хостинга в апаче? 
Речь шла о том, что в данном указанном вами примере можно обойтись без 
виртуализации. И без рутового доступа. К реализации виртуального хостинга в 
апаче все это не имеет ни малейшего отношения (можно запустить и не один 
экземпляр апач, с разными скриптами запуска и настроить sudo, это далеко не 
всегда уместно, но _возможно_; заметим, что в виртуальном окружении и так 
будет свой экземпляр веб-сервера, только что выиграем от самого виртуального 
окружения?).

P.S. Я не из вредности, действительно интересно услышать некоторые общие 
соображения о _необходимости_ виртуализации. Пока что вижу только, что в 
некоторых частных ситуациях таким путем можно частично защититься от кривости 
применяемых решений. И то это помощь для хостера, а не для клиентов - потому 
что ресурс все равно ляжет, но в контексте виртуальной машины, что защитит 
лишь пользователей других ресурсов. Скажем так, не антибиотик, а ампутация.

Re: openvz, vserver

2007-12-24 Пенетрантность Maxim Kudelya


Alex Kuklin wrote:

Alexey Pechnikov wrote:
Установить доступ на запись к нужному конфигу сайта учетной записи 
пользователя и дать права на перезапуск своего сайта. Не знаю, можно 
ли в апач перезапустить отдельный сайт, но надеюсь, да (иначе странный 
выбор для хостинга, имхо).
  
Вы не знаете, можно ли перезапустить отдельный сайт в апаче и беретесь 
судить о том, что можно применять в хостинге, а что - нет?
И как много у вас таких теоретических суждений, выдаваемых с видом 
эксперта?
Вот давайте вы сначала немного изучите предметную область, получите 
минимальный _практический_ опыт администрирования публично доступных 
серверов, а потом уже обсудим вкус устриц, ок?
Это Вы лихо взяли, ведь изучать-то нечего, LAMP на свалке, shell на 
свалке, быдлоадмины

в пути на свалку, остается сплошная теория из серии:
http://static.oper.ru/data/gallery/l1048751000.jpg

--
maxym


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenVZ, VServer и полудесяток

2007-12-24 Пенетрантность Max Vasin

24.12.07, Alexey Pechnikov[EMAIL PROTECTED] написал(а):
 Из шелла писал _одну_ строку - rm /test_100/*. И
 аргумент /test_100/* всего один,
Как это один? Вы с оффтопиком не путаете? Разворачивание аргументов
осуществляется оболочкой (shell), а не программой.

-- 
WBR,
Max Vasin

JID: [EMAIL PROTECTED]

Re: openvz, vserver

2007-12-24 Пенетрантность Andrey Lyubimets


Alexey Pechnikov wrote:

В сообщении от Monday 24 December 2007 12:24:24 Alex Kuklin написал(а):
  

Alexey Pechnikov wrote:


Для администрирования сайта жизненно необходим рутовый доступ?
Дожили...
  

Рутовый доступ был необходим для решения проблем с сервером.
В частности, мне нужно было поправить настройки апача - а сделать это я
не мог.


Установить доступ на запись к нужному конфигу сайта учетной записи
пользователя и дать права на перезапуск своего сайта. Не знаю, можно ли в
апач перезапустить отдельный сайт, но надеюсь, да (иначе странный выбор
для хостинга, имхо).
  

Вы не знаете, можно ли перезапустить отдельный сайт в апаче и беретесь
судить о том, что можно применять в хостинге, а что - нет?
И как много у вас таких теоретических суждений, выдаваемых с видом
эксперта? Вот давайте вы сначала немного изучите предметную область,
получите минимальный _практический_ опыт администрирования публично
доступных серверов, а потом уже обсудим вкус устриц, ок?



Полагаете, мои мысли насчет неуместного использования виртуальных машин 
ошибочны в силу того, что я не знаю реализацию виртуального хостинга в апаче? 
  
Я полагаю, что ваше суждение мало связано с реальной жизнью, а применимо 
лишь к некоторому сферическому серверу в вакууме.
И предлагаю вернуться к разговору о том, как, зачем и почему можно|нужно 
использовать виртуализацию после обретения вами практического опыта 
работы с реальными серверами.


--
Alex



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenVZ, VServer и полудесят ок

Alexey Pechnikov пишет:

В сообщении от Monday 24 December 2007 10:15:15 Mikolaj Golub написал(а):

On Sun, 23 Dec 2007 18:05:23 +0300 Alexey Pechnikov wrote:

--
Mikolaj Golub

Тебе ж говорят, rm тут ни при чём! Звёздочку для него шелл раскрывает -
http://gazette.linux.ru.net/rus/articles/abs-guide/x12531.html
разбираться, а так - вот именно, что повод похаять, но исправлять этот самый
rm надобности нет. Вообще говоря, наличие указанного бага в
узкоспециализированном языке (шелл) и отсутствие в языке с широкой областью
применения (тикль) заставляет подумать о том, что пора шелл выкинуть на
свалку. Благо заменить есть чем - функциональных языков хватает.

Ой-ёй, зачем такие экстремистские высказывания?
Не умеешь в баше скрипты готовить - пиши в тикле или в чём другом, зачем
орать при этом - пора шелл выкинуть?

--
С уважением, Любимец Андрей Алексеевич

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenVZ, VServer и полудесяток

2007-12-24 Пенетрантность Artem Chuprina

Alexey Pechnikov - debian-russian@lists.debian.org @ Mon, 24 Dec 2007
12:19:52 +0300:

--
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

2007-12-24 Пенетрантность Alexander Vlasov

У сб, 2007-12-22 у 17:31 +0300, Alexey Pechnikov пише:

 Если администрить вместо одной ОС десяток виртуальных ОС, тут человеческих 
 ошибок администрирования станет столько, что уже без разницы, насколько 
 исходно прямое средство виртуализации. Нормальный софт и так хорошо 
 виртуализуется, например, в постгресе можно создавать отдельные кластеры, но 
 чаще слышу о запуске виртуалок с единственным кластером на дефолтовом 
 порту... Веб-сервера, включая пресловутый апач (если им еще кто-то 
 пользуется) тоже виртуальный хостинг поддерживают. И т.д. Не исключаю, что 
 может возникнуть необходимость в виртуализации ОС, но не у всех и не всегда.

Не знаю что и сказать. Недетская каша.


-- 
Alexander Vlasov
ZULU-UANIC
JID: zulu at jabber.kiev.ua


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenVZ, VServer и полудесяток

2007-12-24 Пенетрантность Dmitry V. Agalakov

В сообщении от 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 и полудесяток

2007-12-24 Пенетрантность Artem Chuprina

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 и полу десяток

2007-12-24 Пенетрантность Victor Wagner

On 2007.12.24 at 16:21:22 +0300, Dmitry V. Agalakov wrote:

 В сообщении от Sunday 23 December 2007 21:38:05 Artem Chuprina написал(а):
   MS Кажется, сперва думал, что полдюжины, потом заюзал пальцы для учёта
   MS и оказалось, что вторая рука не нужна :-)
  Я до дюжины на одной считаю. :-)
 А почему 12, а не 31? :^)
 (2^5=32)

Считать в двоичной системе на пальцах - нужна очень высокая координация
и заученный автоматизм. А до 12 (по костяшкам) старинный метотд.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

 Я полагаю, что ваше суждение мало связано с реальной жизнью, а применимо
 лишь к некоторому сферическому серверу в вакууме.
 И предлагаю вернуться к разговору о том, как, зачем и почему можно|нужно
 использовать виртуализацию после обретения вами практического опыта
 работы с реальными серверами.

Пока я не увидел, ради чего использовать виртуализацию на своих серверах. Вы 
упомянули про ограничение ресурсов (про разграничение прав доступа не будем, 
это уж кому как нравится реализовывать) - для ограничения ресурсов одного 
приложения создавать виртуальную машину мне кажется неоправданным. Если я не 
путаю, в солярисе для этих надобностей есть так называемые контейнеры, и 
вроде даже их начинали портировать под линукс. Также в ядрах выше 2.6.21 
какие-то игры с планировщиками идут, может быть, необходимое ограничение 
ресурсов можно реализовать через задание приоритета процесса? Дисковое 
пространство ограничить можно несколькими способами, это проблем не вызывает, 
остается ввод-вывод и ресурсы процессора и памяти. Допустимый объем ОЗУ 
многим приложениям можно указывать (или это можно на уровне системы 
сделать?). Или вы просто ставите виртуальную машину, не разбираясь, есть ли 
альтернативные пути решения?

Re: openvz, vserver

2007-12-24 Пенетрантность Max Dmitrichenko

 Это Вы лихо взяли, ведь изучать-то нечего, LAMP на свалке, shell на
 свалке, быдлоадмины
 в пути на свалку, остается сплошная теория из серии:
 http://static.oper.ru/data/gallery/l1048751000.jpg

Так все от задач зависит. Но почему-то независимо от моих или ваших задач 
рекламируется один путь - виртуализация, один веб-сервер - апач, одна БД - 
мускул и так далее (немного утрирую, но тем не менее что-то похожее 
наблюдается). Пусть будет виртуализация, но не потому, что модно, а потому, 
что это единственный способ решить определенные задачи. Но где взять 
информацию, какие именно задачи решаются только таким образом и где найти 
другие пути решения? Когда я говорю о том, что выбор одного решения в 
роли священной коровы приводит к множеству негативных последствий, речь 
идет о рассмотрении альтернатив, но ни одной альтернативы хотя бы за этот год 
я в рассылке не видел. Вот решил спросить - вдруг кто подскажет. Пока еще 
надеюсь на это.

Re: openvz, vserver

On Monday 24 December 2007 18:09, Alexey Pechnikov wrote:
 Пока я не увидел, ради чего использовать виртуализацию на своих серверах.

Не используй! Виртуализация - это хрень и забудь про нее. Точка.

-- 
Макс Дмитриченко


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

2007-12-24 Пенетрантность Dmitry Nezhevenko

On Mon, Dec 24, 2007 at 09:49:09AM +0300, Alexey Pechnikov wrote:
 
 Я не разрушать предлагал, а подумать. Эффективность сильно зависит от видения 
 ситуации в целом, а технологии это лишь средство решения задач. Задачи нужно 
 суметь поставить, вместо беготни за разрекламированными технологиями 
 (когда-то была ява с ее виртуальной машиной, теперь вот виртуализация...). 
 Ваш пример выше очень даже хорошо подтвердил мою точку зрения.
 

JVM и OpenVZ/vserver/xen/whatever - вещи перпендикулярные и решают совершенно 
разные задачи. 

-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: OpenVZ, VServer и полудесяток

2007-12-24 Пенетрантность yuri . nefedov


On Mon, 24 Dec 2007, Victor Wagner wrote:


Считать в двоичной системе на пальцах - нужна очень высокая координация
и заученный автоматизм. А до 12 (по костяшкам) старинный метотд.


  О! А это как? У меня и костяшек 5...

Re: openvz, vserver


Alexey Pechnikov wrote:

Я полагаю, что ваше суждение мало связано с реальной жизнью, а применимо
лишь к некоторому сферическому серверу в вакууме.
И предлагаю вернуться к разговору о том, как, зачем и почему можно|нужно
использовать виртуализацию после обретения вами практического опыта
работы с реальными серверами.



Пока я не увидел, ради чего использовать виртуализацию на своих серверах. Вы 
упомянули про ограничение ресурсов (про разграничение прав доступа не будем, 
это уж кому как нравится реализовывать) - для ограничения ресурсов одного 
приложения создавать виртуальную машину мне кажется неоправданным. Если я не 
путаю, в солярисе для этих надобностей есть так называемые контейнеры, и 
вроде даже их начинали портировать под линукс. 
Если вы потрудитесь изучить вопрос, прежде чем рассуждать, то вы 
увидите, что OpenVZ как раз и реализует модель паравиртуализации, при 
которой расходы на создание каждого нового VE мизерны.
Это не создание полной виртуальной машины со своим процессором, памятью 
и железом, а разграничение на уровне (грубо говоря) вызовов ядра.


--
Alex


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenVZ, VServer и пол удесяток

On 23-Dec-2007, Alexey Pechnikov wrote:

   P.S. Утилита rm отвратительно работают с большим числом файлов в
   директории. Я пишу свои скрипты на tcl, которые выполняют то же самое на
   несколько порядков быстрее. В то же время ls работает нормально, не знаю,
   в чем проблема.  
  Кстати да, искал альтернативу rm/ls/mv, неужели лучше писать самому в
  скриптах ?
 сложностей не составило. Если вы системные скрипты пишете на bash, то я вам 
 просто сочувствую. На bash я делаю только скрипты для /etc/init.d/ Временами 
 в рассылке пробегают темы о различных извращениях для ценителей bash, но это, 
 видно, не для меня, читаю (интересно же) с ужасом :-)
Для init.d bash как раз не рекомендуются, есть специальные шеллы с минимизацией
количества форков при загрузке..
Насчет сочувствия - сочувствую тем кто не читает вообще никакие доки,
даже howto и faq, не умеет пользоваться гуглом и думает что в этом
виноват bash.
Эта проблема есть вообще _везде_ - ограничение на длину команды(без которого 
было
бы всё _намного_ хуже), ядро эти * не понимает, bash заменяет такие
маски на полный список соотв. файлов, длина команды получается адской.
Решение:
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.
и, кстати, на 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

Но это очень не эффективно - по форку на файл.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

2007-12-24 Пенетрантность Eugene Berdnikov

On 24-Dec-2007, Alexey Pechnikov wrote:

Полагаете, мои мысли насчет неуместного использования виртуальных машин
ошибочны в силу того, что я не знаю реализацию виртуального хостинга в апаче?
В силу того, что вы не имеете представления о программировании и о
безопасности. Ошибки есть везде, они могут быть в ядре, в каких-то
других запущенных демонах, в библиотеках. Причины их могут лежать на
аппартном уровне и программно вообще не обходиться.
Поэтому виртуализация появилось ещё в середине прошлого века, хотя тогда
это обходилось несоизмеримо дороже чем сейчас.
Если нужна безопасность, главное правило - держать разные части системы на
разных
машинах, и, лучше, не подключенных к интернету, а запросы пропускать через
риверс-прокси.
База данных точно должна быть видна только из локальной сети.

Речь шла о том, что в данном указанном вами примере можно обойтись без
виртуализации. И без рутового доступа.
заметим, что в виртуальном окружении и так
В экземпляров веб-сервера будет не один и не два, а намного больше,
и запускаете их не вы.
будет свой экземпляр веб-сервера, только что выиграем от самого виртуального
окружения?).
Мы ничего не потеряем, но сильно повысим надежность и безопасность.
vserver, например, рекомендуется использовать даже если разделения не
требуется - с одним экземпляром ос где крутится всё что надо, на голой
хост-системе.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenVZ, VServer и полу десяток

On Mon, Dec 24, 2007 at 01:42:54PM +0300, Artem Chuprina wrote:
 Alexey Pechnikov - debian-russian@lists.debian.org  @ Mon, 24 Dec 2007 
 12:19:52 +0300:
  AP Из шелла писал _одну_ строку - rm /test_100/*. И 
  AP аргумент /test_100/* всего один, откуда возьмется Argument list 
 too 
  AP long?
 
 Из мана на используемый шелл, а что?
 
 Не, судя по отсутствию Argument list too long этот rm - builtin, и
 шелл, как следствие, скорее всего, busybox...  И именно в его исходники
 и надо смотреть.

 Во-первых, ограничение размера аргументов -- это ограничение execve(),
 статус возврата E2BIG. В линуксе традиционно был лимит в 128KB. Шелл
 сначала раскручивает *, затем делает fork() и попытку execve(/bin/rm).

 Во-вторых, я сильно сомневаюсь, что есть нормальный (не-busybox'овый)
 шелл, у которого rm -- встроенная команда. Потому что исторически
 у rm есть немало опций, разбирать которые шеллом замучаешься...
 Да и нет, собственно, причин делать rm встроенным.

 А тормоза у Печникова, наверное, из-за того, что шелл * пакует в
 монолитную строку через realloc(), а тикл пользуется чанковыми строками.
 Но и это не предел оптимизации. Думаю, perl с unlink() в реверсном цикле
 уделает этот тикль как бог черепаху... :-)
-- 
 Eugene Berdnikov


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenVZ, VServer и полудесяток

В сообщении от Tuesday 25 December 2007 00:31:28 Eugene Berdnikov написал(а):
  А тормоза у Печникова, наверное, из-за того, что шелл * пакует в
  монолитную строку через realloc(), а тикл пользуется чанковыми строками.
  Но и это не предел оптимизации. Думаю, perl с unlink() в реверсном цикле
  уделает этот тикль как бог черепаху... :-)

Не совсем понял, как это объясняет жуткое скрежетание винтом от команды rm? 
Мало того, что тормозит, еще и винт мордует. Притом так, что я уже не рискую 
подобные тесты запускать, не хочется винт угробить.

Re: openvz, vserver

В сообщении от Monday 24 December 2007 21:01:11 Alex Kuklin написал(а):
 Alexey Pechnikov wrote:
  Я полагаю, что ваше суждение мало связано с реальной жизнью, а применимо
  лишь к некоторому сферическому серверу в вакууме.
  И предлагаю вернуться к разговору о том, как, зачем и почему можно|нужно
  использовать виртуализацию после обретения вами практического опыта
  работы с реальными серверами.
 
  Пока я не увидел, ради чего использовать виртуализацию на своих серверах.
  Вы упомянули про ограничение ресурсов (про разграничение прав доступа не
  будем, это уж кому как нравится реализовывать) - для ограничения ресурсов
  одного приложения создавать виртуальную машину мне кажется неоправданным.
  Если я не путаю, в солярисе для этих надобностей есть так называемые
  контейнеры, и вроде даже их начинали портировать под линукс.

 Если вы потрудитесь изучить вопрос, прежде чем рассуждать, то вы
 увидите, что OpenVZ как раз и реализует модель паравиртуализации, при
 которой расходы на создание каждого нового VE мизерны.
 Это не создание полной виртуальной машины со своим процессором, памятью
 и железом, а разграничение на уровне (грубо говоря) вызовов ядра.

Во сколько раз возрастает количество вызовов при названном подходе?

Each VPS performs and executes exactly like a
 stand-alone server; VPSs can be rebooted independently and have root access, 
users, IP addresses, memory, processes, files, applications, system libraries
 and configuration files.

Если возрастает незначительно, согласен. Но пока что я конкретных цифр не 
видел, может, плохо искал. Мои соображения следующие: раз дублируются все 
системные вещи (не знаю, как грамотно сказать), то нагрузка от каждого 
виртуального окружения по порядку величины равна нагрузке от основной 
системы. Возможно, для вас это мелочь и четыре-восемь процессорных ядер на 
сервере вместо одного-двух есть разумная плата за удобство.

Re: OpenVZ, VServer и пол удесяток

2007-12-24 Пенетрантность Andrey Lyubimets

On 25-Dec-2007, Alexey Pechnikov wrote:

Тогда по идее rm -rf /test/test_1/ должно работать быстро, поскольку
список файлов не передается Здесь-то что мешает?
Надо пройти по всем файлам рекурсивно, сделать unlink, если какой-то процесс
держит файл открытым, удаление будет откладываться, как и удаление каталогов к
которых он находится.
что наверняка и проиходит.
обходных путей несколько, в разной степени корретных, но я сомневаюсь, что тикл
их использует. Разве что если эти
файлы от как сам и держит:)

Решение:
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, который
тоже еще надо проверить по скорости.
у find всё ok со скоростью, особенно если перенаправлять стандартный
вывод в другую программу.
xargs будет формировать из ст.входа куски максимальной длины и запускать
с поочередно rm со след.куском
__поиск и удаление работают паралельно__, расход оперативной памяти
будет ограничен, а если rm не будет успевать удалять файлы то find`у
придется его ждать.
а последовательный вариант - это сформировать весь массив, ждать когда
отработает find, интерпретировать его вывод, потом запускать rm для
каждого файла.
Идея понятна. Только на тикле это рабочее решение, а на баше - лишь пример.
на баше это тоже рабочее решение.
просто крайней неоптимальное.
Хотя если в используемом шёлле подобные команды встроены, то и проблемы быть
не должно.
а) проблема с unlink`ами никуда не делась
б) лучше использовать xargs. это один из случаея, когда xargs очень рулит.
в) оптимальные задачи для шелла вообще это перенаправление выхода и
входа. фактически накладных расходов минимум - несколько системных
вызовов и дальше всё делает ядро.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

2007-12-24 Пенетрантность Ivan Dubrov

Alexey Pechnikov wrote:
 Во сколько раз возрастает количество вызовов при названном подходе?
   
 Each VPS performs and executes exactly like a
  stand-alone server; VPSs can be rebooted independently and have root access, 
 users, IP addresses, memory, processes, files, applications, system libraries
  and configuration files.

 Если возрастает незначительно, согласен. Но пока что я конкретных цифр не 
 видел, может, плохо искал. Мои соображения следующие: раз дублируются все 
 системные вещи (не знаю, как грамотно сказать), то нагрузка от каждого 
 виртуального окружения по порядку величины равна нагрузке от основной 
 системы. Возможно, для вас это мелочь и четыре-восемь процессорных ядер на 
 сервере вместо одного-двух есть разумная плата за удобство.
   
Вот статейка есть на тему производительности:
http://www.hpl.hp.com/techreports/2007/HPL-2007-59.pdf


-- 
WBR,
Ivan S. Dubrov



signature.asc
Description: OpenPGP digital signature

Re: openvz, vserver


Alexey Pechnikov пишет:

Это Вы лихо взяли, ведь изучать-то нечего, LAMP на свалке, shell на
свалке, быдлоадмины
в пути на свалку, остается сплошная теория из серии:
http://static.oper.ru/data/gallery/l1048751000.jpg


Так все от задач зависит. Но почему-то независимо от моих или ваших задач 
рекламируется один путь - виртуализация, один веб-сервер - апач, одна БД - 
мускул и так далее (немного утрирую, но тем не менее что-то похожее 
наблюдается). Пусть будет виртуализация, но не потому, что модно, а потому, 
что это единственный способ решить определенные задачи. Но где взять 
информацию, какие именно задачи решаются только таким образом и где найти 
другие пути решения? Когда я говорю о том, что выбор одного решения в 
роли священной коровы приводит к множеству негативных последствий, речь 
идет о рассмотрении альтернатив, но ни одной альтернативы хотя бы за этот год 
я в рассылке не видел. Вот решил спросить - вдруг кто подскажет. Пока еще 
надеюсь на это.



Алексей, посмотри на виртуализацию с другой стороны --
не всегда твоя задача сможет загрузить имеющееся в твоём распоряжении железо, 
а если она использует его менее чем на 10%, то, возможно,сам задумаешься  - 
чем бы его нагрузить, а может - начальство за тебя подумает ;-)
Тут хочешь-не хочешь - вспомнишь и про виртуализацию.Особенно, если придётся 
делить ресурсы сервера с кем то ещё.


--
С уважением, Любимец Андрей Алексеевич


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

2007-12-24 Пенетрантность Konstantin Matyukhin

 Алексей, посмотри на виртуализацию с другой стороны --
 не всегда твоя задача сможет загрузить имеющееся в твоём распоряжении железо,
 а если она использует его менее чем на 10%, то, возможно,сам задумаешься  -
 чем бы его нагрузить, а может - начальство за тебя подумает ;-)
 Тут хочешь-не хочешь - вспомнишь и про виртуализацию.Особенно, если придётся
 делить ресурсы сервера с кем то ещё.

Сразу предвижу возражение: зачем под задачу, которая требует 486
процессор покупать Коре Дуо? Пора завязывать толочь воду в ступе-то.

-- 
С уважением,
Константин Матюхин

Re: OpenVZ, VServer и пол удесяток

2007-12-24 Пенетрантность Andrey Lyubimets

On 25-Dec-2007, Alexey Pechnikov wrote:
 Не совсем понял, как это объясняет жуткое скрежетание винтом от команды rm? 
 Мало того, что тормозит, еще и винт мордует. Притом так, что я уже не рискую 
 подобные тесты запускать, не хочется винт угробить.
Рекомендую запустить действительно тесты, а вообще сделать бэкап важных
данных.. Винты любят дохнуть очень произвольно. И причина этого не в rm.
А не проще ли примонтировать что-нить напр. tmpfs куда надо? 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver


Konstantin Matyukhin пишет:
Алексей, посмотри на виртуализацию с другой стороны -- не всегда твоя 
задача сможет загрузить имеющееся в твоём распоряжении железо, а если 
она использует его менее чем на 10%, то, возможно,сам задумаешься  - чем
 бы его нагрузить, а может - начальство за тебя подумает ;-) Тут 
хочешь-не хочешь - вспомнишь и про виртуализацию.Особенно, если придётся

 делить ресурсы сервера с кем то ещё.


Сразу предвижу возражение: зачем под задачу, которая требует 486 процессор
 покупать Коре Дуо?

этой осенью мы были вынуждены купить железки на 1.5ГГц Целеронах, хотя
заказывали с 566МГц процессорами (их нам тоже за глаза).
С другой стороны - цена процессорной мощи того же коре дуо может быть много
меньше цены одного юнита в стойке.

Пора завязывать толочь воду в ступе-то.

завязываю, просто люди очевидных вещей не понимают(ИМХО)

--
С уважением, Любимец Андрей Алексеевич


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

  Если возрастает незначительно, согласен. Но пока что я конкретных цифр не
  видел, может, плохо искал. Мои соображения следующие: раз дублируются все
  системные вещи (не знаю, как грамотно сказать), то нагрузка от каждого
  виртуального окружения по порядку величины равна нагрузке от основной
  системы. Возможно, для вас это мелочь и четыре-восемь процессорных ядер
  на сервере вместо одного-двух есть разумная плата за удобство.

 Вот статейка есть на тему производительности:
 http://www.hpl.hp.com/techreports/2007/HPL-2007-59.pdf

Вот спасибо - именно то, что надо! С xen и openvz вопрос решен.

Re: openvz, vserver

On 25-Dec-2007, Alexey Pechnikov wrote:

Мои соображения следующие: раз дублируются все
системные вещи (не знаю, как грамотно сказать), то нагрузка от каждого
виртуального окружения по порядку величины равна нагрузке от основной
системы.
Твои соображения демонстрируют лишь непонимаение базовых концепций, не
желании их узнать(хотя бы, открыв википедию).
Не желание их знать - законное право, зачем это демонстрировать?
не их желании
знать

Возможно, для вас это мелочь и четыре-восемь процессорных ядер на
сервере вместо одного-двух есть разумная плата за удобство.
* Virtual servers share the same system call interface and do not
* have any emulation overhead.
* Virtual servers do not have to be backed by opaque disk
* images, but can share a common file system and common sets of
* files (through copy-on-write hard links). This makes it easier
* to back-up a system and to pool disk space amongst virtual
* servers.
* Processes within the virtual server run as regular
* processes on the host system. This is somewhat more
* memory-efficient and I/O-efficient than whole-system
* emulation, which cannot return unused memory or share a
* disk cache with the host and other virtual servers.
* Processes within the virtual server are queued on the
* same scheduler as on the host, allowing guests
* processes to run concurrently on SMP systems. This is
* not trivial to implement with whole-system emulation.
* Networking is based on isolation rather than
* virtualization, so there is no additional overhead
* for packets.

--
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

2007-12-24 Пенетрантность Dmitry Nezhevenko

Alexey Pechnikov wrote:

В сообщении от Monday 24 December 2007 21:01:11 Alex Kuklin написал(а):

Alexey Pechnikov wrote:

Я полагаю, что ваше суждение мало связано с реальной жизнью, а применимо
лишь к некоторому сферическому серверу в вакууме.
И предлагаю вернуться к разговору о том, как, зачем и почему можно|нужно
использовать виртуализацию после обретения вами практического опыта
работы с реальными серверами.

Пока я не увидел, ради чего использовать виртуализацию на своих серверах.
Вы упомянули про ограничение ресурсов (про разграничение прав доступа не
будем, это уж кому как нравится реализовывать) - для ограничения ресурсов
одного приложения создавать виртуальную машину мне кажется неоправданным.
Если я не путаю, в солярисе для этих надобностей есть так называемые
контейнеры, и вроде даже их начинали портировать под линукс.

Если вы потрудитесь изучить вопрос, прежде чем рассуждать, то вы
увидите, что OpenVZ как раз и реализует модель паравиртуализации, при
которой расходы на создание каждого нового VE мизерны.
Это не создание полной виртуальной машины со своим процессором, памятью
и железом, а разграничение на уровне (грубо говоря) вызовов ядра.

Во сколько раз возрастает количество вызовов при названном подходе?

Each VPS performs and executes exactly like a
stand-alone server; VPSs can be rebooted independently and have root access,
users, IP addresses, memory, processes, files, applications, system libraries

and configuration files.

Если возрастает незначительно, согласен.
Не значительно. Вышеописанный оверхед заключается в начальном запуске
системы. Если систему (VE) не перегружать по 10 раз на дню, то его и нет.
С точки зрения процессов оверхед такой мизерный, что возможно
одновременное исполнение сотен VE с апачем, раздающим статику, в каждом,
на вполне обычной машине.

Но пока что я конкретных цифр не
видел, может, плохо искал.

Плохо искали. Для openvz есть подробный анализ
Мои соображения следующие: раз дублируются все
системные вещи (не знаю, как грамотно сказать), то нагрузка от каждого
виртуального окружения по порядку величины равна нагрузке от основной
системы.

Там НЕ дублируются системные вещи. Понимаете, НЕ дублируются.
Возможно, для вас это мелочь и четыре-восемь процессорных ядер на
сервере вместо одного-двух есть разумная плата за удобство.

Доктор, а как у меня openvz крутилось на машинке p3-1333/512 памяти? Я
что-то делал не так?

--
Alex

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

On Tue, Dec 25, 2007 at 03:17:42AM +0300, Alexey Pechnikov wrote:
   Пока я не увидел, ради чего использовать виртуализацию на своих серверах.
   Вы упомянули про ограничение ресурсов (про разграничение прав доступа не
   будем, это уж кому как нравится реализовывать) - для ограничения ресурсов
   одного приложения создавать виртуальную машину мне кажется неоправданным.
   Если я не путаю, в солярисе для этих надобностей есть так называемые
   контейнеры, и вроде даже их начинали портировать под линукс.
 
  Если вы потрудитесь изучить вопрос, прежде чем рассуждать, то вы
  увидите, что OpenVZ как раз и реализует модель паравиртуализации, при
  которой расходы на создание каждого нового VE мизерны.
  Это не создание полной виртуальной машины со своим процессором, памятью
  и железом, а разграничение на уровне (грубо говоря) вызовов ядра.
 
 Во сколько раз возрастает количество вызовов при названном подходе?
 
 Each VPS performs and executes exactly like a
  stand-alone server; VPSs can be rebooted independently and have root access, 
 users, IP addresses, memory, processes, files, applications, system libraries
  and configuration files.
 

Это еще от технологии виртуализации зависит. Если взять тот же XEN, то там
происходит именно эмуляция виртуального железа, плюс патченое ядро,
которое умеет работать с этим XEN-овским железом. В таком случае все что
написано выше -- верно. Даже shared memory не шарится между виртаулками.

А вот тот-же vserver больше похож на чрут + N-ое количество костылей для
разделения ресурсов. Грубо говоря для того, чтобы внутри виртуалки была своя 
нумерация процессов (т.е чтобы у init'а был PID=1 и чужиме процессы не были 
видны). Ну и аналогично для сети, файловой системы.

Сильно большого оверхеда во втором случае не будет.

-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: OpenVZ, VServer и полудесят ок

Michael Shigorin wrote:
 Кажется, сперва думал, что полдюжины, потом заюзал пальцы для
 учёта и оказалось, что вторая рука не нужна :-)

 Мысль была банальная -- грамотная разводка I/O способна помочь
 ощутимо сильнее крутых рейдов и быстрых дисков самих по себе.
 Примеры тому наблюдаю с незавидной регулярностью.
   

А где можно почитать про грамотную разводку I/O ?
может есть примеры из собственного прошлого ?
почему спрашиваю - сейчас стоит задача оптимизировать это самое I/O
некоторое время назад в соседней ветке я  описывал проблему с медленными
дисками на сервере.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

Управлять надо тем, что на сервер ставите и такую дрянь выбрасывать
сразу. При чем тут линукс?

Если в винде жестко ограничить множество используемых программ, то оно
тоже вполне себе стабильно работает. Аналогия ясна?

Не совсем корректная аналогия, поскольку офтопик не самодостаточен. Выкидываем
антивирус, файрволл и проч. Ставим веб-сервер и постгрес, подключаем
широкополосный доступ в инет. Долго проработает?

Разумная гигиена должна соблюдаться и для программного обеспечения, тут я с
вашей аналогией согласен. Но сегодняшний нигилизм в отношении качества ПО
приводит уже к серьезным последствиям, которые невозможно игнорировать. Я не
говорю о том, что надо все php-поделия выкинуть из репозитория, хотя возможно
это было бы правильно идеологически. Но засилие дерьмого софта привело к
неразборчивости пользователей. Конечно, с точки зрения админа сайта поставить
готовый движок проще... но пользователю приходится мириться с утечкой личных
данных, периодической недоступностью ресурса и т.п. Причем такой подход уже
фактически не зависит от бюджета проекта - доминирует подход пипл хавает, ну
и ладно.

В связи с вышеизложенным, не считаю технологию виртуализации той панацеей, за
которую ее пытаются выдать маркетологи. Качественно написанный код не требует
засовывать его в подобные контейнеры. Не маразм ли - например, яву,
выполняющуюся в виртуальной машине, т.е. контейнере, пихают еще в один
контейнер, на кой ляд такая виртуальная машина? Перл 6, моно, .net и прочие
тоже полюбили виртуальные машины, которые админу приходится зачастую
виртуализовать. Получается, бардак растет на всех уровнях, и чем дальше, тем
больше средств защиты и ниже общая безопасность системы (средств много, но
все низкого качества, пытаются друг друга дублировать в надежде
закрыть перекрестные дыры).

Пример из другой области: чтобы избавиться от пробок на
дорогах, будем строить каждому водителю по магистрали?

Пример из этой области - введение разделителей встречных полос заметно
снижает количество серьезных аварий.

Не тот пример. Разделители - берьер административный. Аналогия разделителю -
соблюдение стандартов при проектировании, кодировании и тестировании. И вот
это действительно будет полезно. Формальная методика не нужна профессионалу -
потому что он и так действует системно, но число профессионалов в нынешнем ИТ
исчезающе малая величина. И, как я вижу, навык поставить виртуальную машину и
запустить быдлокод в ней все увереннее заменяет собой умение писать грамотный
код.

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 и полудесят ок

2007-12-23 Пенетрантность Vladislav Naumov

Alexey Pechnikov wrote:
 В сообщении от Sunday 23 December 2007 13:01:09 Timur S. Sattarov написал(а):
   
 Michael Shigorin wrote:
 
 Кажется, сперва думал, что полдюжины, потом заюзал пальцы для
 учёта и оказалось, что вторая рука не нужна :-)

 Мысль была банальная -- грамотная разводка I/O способна помочь
 ощутимо сильнее крутых рейдов и быстрых дисков самих по себе.
 Примеры тому наблюдаю с незавидной регулярностью.
   
 А где можно почитать про грамотную разводку I/O ?
 может есть примеры из собственного прошлого ?
 почему спрашиваю - сейчас стоит задача оптимизировать это самое I/O
 некоторое время назад в соседней ветке я  описывал проблему с медленными
 дисками на сервере.
 

 Оптимизация - это настройка СУБД, оптимизация медленных запросов. На примере 
 постгреса - ставим логирование всех запросов, которые выполняются дольше 400 
 мс (я выбрал такое значение, диски SATA) и избавляемся от них. Для того же 
 постгреса рекомендуют разделять базы и журналы, но после выполнения 
 вышеописанной оптимизации это может и не требоваться. Ну и логи отключите 
 (реверс-прокси, веб-сервер...) - можно логировать что-то очень нужное, но 
 сохранять все запросы слишком дорогое удовольствие. Некорректно 
 сформированные запросы должен блокировать реверс-прокси, чтобы они не грузили 
 веб-сервер.

 P.S. Настройка системы для черного ящика (чужого ПО) весьма неблагодарное 
 занятие... По-хорошему, надо настраивать и ПО и систему совместно.

   
Спасибо за ответ,
уточню - есть система, прищедшая по наследству, основная задача которой
- почта,
количество пользователей - порядка 20 тысяч, сколько из них активных не
знаю, может 6-7 тыс.
свои проблемы со скоростью винтов (20-30 мегабайт в секунду, даже с
кэшем) я уже выкладывал в соседней ветке.
из-за не совсем грамотной настройки - письма не сразу отвергаются при
ошибках  во время SMTP сессии (не тот юзер, переполнен ящик), а сначала
получаются а потом отлупливаются обратно. Load Average поднимается до
1000-1500 проц в большинстве своем занят iowait. после установки
валидации пользователей - ситуация улучшилась, но бэкап периодически
грузит машину, если в это время есть приличное количество писем на
отправку - то висит куча процессов ожидающих ответа от дисковой системы.
Я прекрасно понимаю что надо реорганизовывать дисковую подсистему и даже
уже наметил что-то в качестве решения. И тут поднимается вопрос о
грамотной разводке I/O, поэтому очень хотелось бы послушать, что именно
делают другие специалисты для того чтобы *грамотно* организовать
дисковую подсистему.

Попутно пара вопросов - в текущей системе стоит reiserfs V3.6, я же
привык работать с ext3, так как кажется она мне более надежной и
удобной. Как вы думаете - стоит ли оставаться на reieser и, если да,
стоит ли переезжать на 4-ю версию ? Почта хранится в maildir - при
обращении к ящику с большим количеством сообщений  система притормаживает.

--
Bye
TimHisTeam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

Пример из этой области - введение разделителей встречных полос заметно
снижает количество серьезных аварий.

Увы, многим приходится работать в нынешнем ИТ, а не в совершенном грядущем.
И вот этот навык - он действительно весьма полезен сейчас.

И, как я вижу, навык поставить виртуальную машину и
запустить быдлокод в ней все увереннее заменяет собой умение писать грамотный
код.

А вот потом, когда весь код будет грамотным, написанным с соблюдением
стандартов при проектировании, кодировании и тестировании - тогда мы с
удовольствием сбросим оковы виртуальных машин.
А если не мы - так дети наши...

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 17:59:42 Vladislav Naumov написал(а):
Пример из этой области - введение разделителей встречных полос заметно
снижает количество серьезных аварий.

Не тот пример. Разделители - берьер административный. Аналогия
разделителю - соблюдение стандартов при проектировании, кодировании и
тестировании. И вот это действительно будет полезно. Формальная методика
не нужна профессионалу - потому что он и так действует системно, но число
профессионалов в нынешнем ИТ исчезающе малая величина.

И, как я вижу, навык поставить виртуальную машину и
запустить быдлокод в ней все увереннее заменяет собой умение писать
грамотный код.

Не надо прогибаться (c) под быдлокодеров. Не верю, что вас под угрозой
расстрела заставляют ставить форум или что-либо еще на том же
apache+php+mysql, а вот если лень поискать достойную замену, так и скажите.

Re: OpenVZ, VServer и полудесят ок

Alexey Pechnikov wrote:

 А вот бэкап надо реорганизовывать или размазывать во времени. Например, 
 rsync имеет опцию
 --bwlimit=KBPS  limit I/O bandwidth; KBytes per second
 Может быть, это то, что вам нужно? 

   
Да, сейчас бэкап идет с помощью backuppc, думаю что эта опция будет полезна.
с другой стороны - backuppc создает много файлов, что опять дает
нагрузку на ФС.
 Запросы, которые не могут быть обработаны, стоит сразу отбивать (это верно 
 для системы любого типа), это верно как с точки зрения безопасности, так и с 
 точки зрения производительности (именно в таком порядке).
   
надо будет проследить какое количество одновременных запросов сейчас
оптимально, хотя сейчас я думаю не о старой машине а о том как буду
организовывать новую.

 Выбираю ext3 за ее надежность; reiserfs имеет иные настройки по умолчанию, 
 потому часто рекомендуется для соответствующих задач, но чтение манов по ext3 
 позволит настроить как минимум не хуже. Для начала на ext3 отключите atime, 
 diratime и включите индекс директорий. После этого сможете эффективно 
 работать с десятками и сотнями тысяч файлов в директории (тестировал и с 
 миллионом файлов, но это на практике пока не потребовалось). Есть и другие 
 полезные опции, но мне хватает вышеназванных. Имхо, рейзер нестабильная ФС с 
 непонятной поддержкой и на свой сервер я ее никогда не поставлю (да и зачем - 
 ощутимых преимуществ не вижу). Еще для вашей задачи стоит попробовать опцию 
 data=journal (в /etc/fstab использовать нельзя, надо указывать как параметр 
 загрузки), для конкурентного ввода-вывода может оказаться очень полезной.

   
Значит наш взгляд на ext2/ext3 совпадает. про atime/diratime я знал,
а как включается индекс директорий ?
тоже опция монтирования ?
(нет, я конечно посмотрю в man :), просто интересно мнение и опыт)
небольшое уточнение про опцию data=journal в опциях ядру - это
справедливо только для корневой ФС, остальные легко меняются на ходу и в
fstab.
 P.S. Утилита rm отвратительно работают с большим числом файлов в директории. 
 Я 
 пишу свои скрипты на tcl, которые выполняют то же самое на несколько порядков 
 быстрее. В то же время ls работает нормально, не знаю, в чем проблема. На 
 примере миллиона файлов: rm /test_100/* думает часами и зверски насилует 
 винт, в то время как на тикле foreach fn [glob /test_100/*] {file delete 
 $fn} работает две-три минуты и почти не шелестит винтом. Посмотрите, может, и 
 у вас где подобные грабли закопаны.
   

Кстати да, искал альтернативу rm/ls/mv, неужели лучше писать самому в
скриптах ?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

2007-12-23 Пенетрантность alex kuklin

Alexey Pechnikov wrote:

В сообщении от Sunday 23 December 2007 17:59:42 Vladislav Naumov написал(а):

Пример из этой области - введение разделителей встречных полос заметно
снижает количество серьезных аварий.

Не тот пример. Разделители - берьер административный. Аналогия
разделителю - соблюдение стандартов при проектировании, кодировании и
тестировании. И вот это действительно будет полезно. Формальная методика
не нужна профессионалу - потому что он и так действует системно, но число
профессионалов в нынешнем ИТ исчезающе малая величина.

Ну щаз, административный. Вполне себе физический. Барьерчик такой. Бетонный.
Административные средства - это штраф и лишение прав (читай, штрафы либо
расторжение договоров с владельцем ресурса).

И, как я вижу, навык поставить виртуальную машину и
запустить быдлокод в ней все увереннее заменяет собой умение писать
грамотный код.

Понимаете, сударь. Есть задачи, которые надо решать.
И ресурсы, которые на это есть.
Перетащить все на надежные и правильно спроектированные решения -
расходы, как правило, совершенно нереальные. Гораздо реальнее
использовать ovz.
Если я буду всегда и везде использовать идеологически верный подход в
ущерб делу - ... расстрела, конечно, не будет я просто вылечу в трубу.

А для домашних/личных применений... ну, не прогибайтесь, воля ваша.

--
Alex

--
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

В сообщении от Sunday 23 December 2007 19:37:25 alex kuklin написал(а):
Alexey Pechnikov wrote:
В сообщении от Sunday 23 December 2007 17:59:42 Vladislav Naumov
написал(а):
Пример из этой области - введение разделителей встречных полос заметно
снижает количество серьезных аварий.

Не тот пример. Разделители - берьер административный. Аналогия
разделителю - соблюдение стандартов при проектировании, кодировании и
тестировании. И вот это действительно будет полезно. Формальная
методика не нужна профессионалу - потому что он и так действует
системно, но число профессионалов в нынешнем ИТ исчезающе малая
величина.

Ну щаз, административный. Вполне себе физический. Барьерчик такой.
Бетонный. Административные средства - это штраф и лишение прав (читай,
штрафы либо расторжение договоров с владельцем ресурса).

Я про двойную сплошную говорил. В ИТ по ней ездят вдоль и поперек...

Увы, многим приходится работать в нынешнем ИТ, а не в совершенном
грядущем. И вот этот навык - он действительно весьма полезен сейчас.

И, как я вижу, навык поставить виртуальную машину и
запустить быдлокод в ней все увереннее заменяет собой умение писать
грамотный код.

Дай быдлу все, что ему захочется, и оно чудесно превратится в
интеллигенцию. Блаженны верующие, ибо их... (с)

Когда я вижу описание кластера на десятках машин для поддержания форума на
apache+php+mysql возникают обоснованные сомнения в эффективности этого
подхода. Так что насчет ущерба делу я бы не был столь категоричен. Тем более,
что, считая виртуализацию своим спасением, вы снижаете планку требований к
используемому ПО. Воля ваша...

P.S. Вы, кажется, предлагаете платную поддержку debian? Сдается мне,
консультант должен иметь характер и умение настоять на своем, чтобы помочь
заказчику, который сам не знает, чего хочет и которому впиаривают много
всякой хрени.

Re: openvz, vserver

2007-12-23 Пенетрантность Artem Chuprina

Alexey Pechnikov - debian-russian@lists.debian.org @ Sun, 23 Dec 2007
15:22:43 +0300:

Управлять надо тем, что на сервер ставите и такую дрянь выбрасывать
сразу. При чем тут линукс?

AP Не совсем корректная аналогия, поскольку офтопик не
AP самодостаточен. Выкидываем антивирус, файрволл и проч. Ставим
AP веб-сервер и постгрес, подключаем широкополосный доступ в
AP инет. Долго проработает?

Файрвол в комплекте, а постгрес и веб-сервер тут как раз попадают в
категорию и такую дрянь выбрасывать сразу. Ибо при функциональности,
превосходящей отдавать статические файлы (для которой постгрес вообще
не нужен) я не знаю веб-сервера, управляемого достаточно хорошо.
Классический апач не позволяет толком рулить памятью и процессорным
временем, если на нем динамика висит (позволяет только для CGI в
отдельных процессах, что само по себе порой непозволительная роскошь).
У постгреса, кажется, такой настройки в принципе нету.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Нет применения человеческому разуму! (c)JB

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenVZ, VServer и полудесяток

2007-12-23 Пенетрантность Artem Chuprina

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 и полудесят ок

Alexey Pechnikov wrote:
 Зато у вас есть возможность потестировать на уже работающей системе, это 
 полезно.

   
да уж, радость та ещё :)
 С помощью 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

   
как я понял - включается это сразу при форматировании, по крайней мере -
отформатированные не так давно партиции.
 Кстати да, искал альтернативу rm/ls/mv, неужели лучше писать самому в
 скриптах ?
 

 У меня доступ к файлам производится из сервера приложений (aol web server), 
 так что все равно пишу на тикле и проблем, подобных вышеозначенной, не 
 возникает. При тестировании работы с большим количеством файлов в директории 
 вылезла проблема с rm, а поскольку тестовый скрипт также на тикле, написать 
 foreach fn [glob /test_100/*] {file delete $fn}
 вместо
 rm /test_100/*
 сложностей не составило. Если вы системные скрипты пишете на bash, то я вам 
 просто сочувствую. На bash я делаю только скрипты для /etc/init.d/ Временами 
 в рассылке пробегают темы о различных извращениях для ценителей bash, но это, 
 видно, не для меня, читаю (интересно же) с ужасом :-)

   

на bash как то нелогично :)
я думал про perl, но если не поможет - придется учить тикль ...


-- 
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

Если типичные запросы выполняются порядка 100мс, проблем не возникает. А если
все тормозит, то ограничение ресурсов приведет к еще большему замедлению, что
пользователю не в радость.

Re: OpenVZ, VServer и полудесят ок

Alexey Pechnikov wrote:

 В любой момент включается. Только надо проверить, что в уже созданных 
 директориях индекс создается - я не разбирался, в какой момент он создается, 
 на всякий случай существующие директории скопировал, старые удалил и перенес 
 на взамен них копию. Время было около 5 утра, уже сил не было разбираться :-)

   
Понятно, спасибо, буду вчитываться в маны по mount и tune2fs

Я на перле серьёзно писал лет 7 назад - сейчас видимо придется
переучиваться на тикль.
К тому же у cisco ivr на нем, тоже надо время от времени.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenVZ, VServer и полудесяток

2007-12-23 Пенетрантность Eugene Berdnikov

 Я на перле серьёзно писал лет 7 назад - сейчас видимо придется
 переучиваться на тикль.
 К тому же у cisco ivr на нем, тоже надо время от времени.

На тикле много всего. Сам пишу на нем для debian серверов, в postgresql на 
pltcl, для виндоусов всех мастей, для виндовых кпк... Притом на ноуте под 
debian можно написать приложение, потом только проверить  интерфейс под 
офтопиком и какие-то платформоспецифичные вещи (активсинк, вебкамера, etc.).

P.S. Если бы я писал семь лет назад на тикле, а не вижуал бейсике, php, visual 
c++, borland c++  и проч., то и переучиваться бы не пришлось...

Re: openvz, vserver

On Sun, Dec 23, 2007 at 09:36:30PM +0300, Alexey Pechnikov wrote:
В сообщении от Sunday 23 December 2007 19:37:25 alex kuklin написал(а):
Если я буду всегда и везде использовать идеологически верный подход в
ущерб делу - ... расстрела, конечно, не будет я просто вылечу в трубу.
А для домашних/личных применений... ну, не прогибайтесь, воля ваша.

Когда я вижу описание кластера на десятках машин для поддержания форума на
apache+php+mysql возникают обоснованные сомнения в эффективности этого
подхода.

Ваши сомнения обоснованы в том смысле, что были посчитаны затраты на
технику и проведено сравнение с затратами на квалифицированных админов?

Если да, то сравните свои расчёты с предыдущим оратором: кто-то из вас
ошибся, если нет -- советую таки посчитать. Кстати, результат для
Москвы и Урюпинска может быть удивительно разным.
--
Eugene Berdnikov

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

В сообщении от Sunday 23 December 2007 22:58:57 Eugene Berdnikov написал(а):
 On Sun, Dec 23, 2007 at 09:36:30PM +0300, Alexey Pechnikov wrote:
  В сообщении от Sunday 23 December 2007 19:37:25 alex kuklin написал(а):
   Если я буду всегда и везде использовать идеологически верный подход в
   ущерб делу - ... расстрела, конечно, не будет я просто вылечу в
   трубу. А для домашних/личных применений...  ну, не прогибайтесь, воля
   ваша.
 
  Когда я вижу описание кластера на десятках машин для поддержания форума
  на apache+php+mysql возникают обоснованные сомнения в эффективности этого
  подхода.

  Ваши сомнения обоснованы в том смысле, что были посчитаны затраты на
  технику и проведено сравнение с затратами на квалифицированных админов?

  Если да, то сравните свои расчёты с предыдущим оратором: кто-то из вас
  ошибся, если нет -- советую таки посчитать. Кстати, результат для
  Москвы и Урюпинска может быть удивительно разным.

Возможно, мы и в самом деле по-разному считаем - я планирую развитие своих 
проектов на 2 - 3 года вперед. Сервера располагаются на хостинговой площадке 
в москве. Если сервера стоят в своем офисе и не планируется увеличение 
количества пользователей на порядок и увеличение функционала системы тоже на 
порядок (соответственно, и требуемых ресурсов), может, и абы как сойдет. 
При планируемом увеличении потребляемых ресурсов на два порядка виртуализация 
кривого кода (ага, тоже ресурсов требует) интереса не представляет 
(ограничить ресурсы для выполнения запроса можно, но какое будет время 
отклика?).

Re: openvz, vserver

2007-12-23 Пенетрантность alex kuklin

Alexey Pechnikov wrote:

В сообщении от Sunday 23 December 2007 19:37:25 alex kuklin написал(а):

Alexey Pechnikov wrote:

В сообщении от Sunday 23 December 2007 17:59:42 Vladislav Naumov

написал(а):

Пример из этой области - введение разделителей встречных полос заметно
снижает количество серьезных аварий.

Не тот пример. Разделители - берьер административный. Аналогия
разделителю - соблюдение стандартов при проектировании, кодировании и
тестировании. И вот это действительно будет полезно. Формальная
методика не нужна профессионалу - потому что он и так действует
системно, но число профессионалов в нынешнем ИТ исчезающе малая
величина.

Ну щаз, административный. Вполне себе физический. Барьерчик такой.
Бетонный. Административные средства - это штраф и лишение прав (читай,
штрафы либо расторжение договоров с владельцем ресурса).

Я про двойную сплошную говорил. В ИТ по ней ездят вдоль и поперек...

А я - про бетонный/стальной отбойник. Именно он существенно снижает
количество серьезных ДТП.

Увы, многим приходится работать в нынешнем ИТ, а не в совершенном
грядущем. И вот этот навык - он действительно весьма полезен сейчас.

И, как я вижу, навык поставить виртуальную машину и
запустить быдлокод в ней все увереннее заменяет собой умение писать
грамотный код.

Дай быдлу все, что ему захочется, и оно чудесно превратится в
интеллигенцию. Блаженны верующие, ибо их... (с)

Я не считаю виртуализацию панацеей. Я считаю виртуализацию удобным
инструментом для установки бронированных стенок между разными песочницами.

Кстати, есть еще одно место, где виртуализация помогает.
В частности, вчера имел сомнительное удовольствие решать проблемы с
упавшим сайтом, не имея админского доступа к машине и тыкаясь местами,
как слепой котенок. В случае, если бы проект был в ovz-контейнере, а у
меня к тому контейнеру полный доступ, жить было бы существенно легче.

Да, необходимо решать задачи нормально.
Но между обнаружением проблемы и появлением переработанной версии часто
проходит порядочно времени, и это время проект должен жить.
P.S. Вы, кажется, предлагаете платную поддержку debian? Сдается мне,
консультант должен иметь характер и умение настоять на своем, чтобы помочь
заказчику, который сам не знает, чего хочет и которому впиаривают много
всякой хрени.

Если при каждом случае я буду предлагать все переделать, я не буду ничем
отличаться от пионеров.

И эффективность работы будет соответствующая.
Прежде чем весь мир... кривого софта .. мы разрушим до основанья,
нужно понять, что это будет стоить заказчику.

--
Alex

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

2007-12-23 Пенетрантность Artem Chuprina

Alexey Pechnikov - debian-russian@lists.debian.org @ Sun, 23 Dec 2007
22:02:38 +0300:

Файрвол в комплекте, а постгрес и веб-сервер тут как раз попадают в
категорию и такую дрянь выбрасывать сразу. Ибо при
функциональности, превосходящей отдавать статические файлы (для
которой постгрес вообще не нужен) я не знаю веб-сервера,
управляемого достаточно хорошо. Классический апач не позволяет
толком рулить памятью и процессорным временем, если на нем динамика
висит (позволяет только для CGI в отдельных процессах, что само по
себе порой непозволительная роскошь). У постгреса, кажется, такой
настройки в принципе нету.

AP Если типичные запросы выполняются порядка 100мс, проблем не
AP возникает. А если все тормозит, то ограничение ресурсов приведет к
AP еще большему замедлению, что пользователю не в радость.

Только в случае виртуализации оно будет не в радость лишь пользователям
этого сайта. А не всех, которые хостятся на этой машине. Что,
соответственно, будет проблемой только тех, кто создал этот сайт, а не
заодно и всех, кого угораздило нечаянно оказаться на той же машине.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Машины пока еще от копирования защищены хитрой немецкой технологией сборка
трезвымAlex Korchmar в [EMAIL PROTECTED]

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenVZ, VServer и полудесято к

2007-12-23 Пенетрантность Alexey Trunyov

On Sun, 23 Dec 2007 18:35:24 +0500
Timur S. Sattarov [EMAIL PROTECTED] wrote:

 уточню - есть система, прищедшая по наследству, основная задача которой
 - почта,
 количество пользователей - порядка 20 тысяч, сколько из них активных не
 знаю, может 6-7 тыс.
 свои проблемы со скоростью винтов (20-30 мегабайт в секунду, даже с
 кэшем) я уже выкладывал в соседней ветке.
 из-за не совсем грамотной настройки - письма не сразу отвергаются при
 ошибках  во время SMTP сессии (не тот юзер, переполнен ящик), а сначала
 получаются а потом отлупливаются обратно. Load Average поднимается до
 1000-1500 проц в большинстве своем занят iowait. после установки
 валидации пользователей - ситуация улучшилась, но бэкап периодически
 грузит машину, если в это время есть приличное количество писем на
 отправку - то висит куча процессов ожидающих ответа от дисковой системы.
 Я прекрасно понимаю что надо реорганизовывать дисковую подсистему и даже
 уже наметил что-то в качестве решения. И тут поднимается вопрос о
 грамотной разводке I/O, поэтому очень хотелось бы послушать, что именно
 делают другие специалисты для того чтобы *грамотно* организовать
 дисковую подсистему.

Оригинальной ветки не видел, но, может, запускать бэкап с более низким 
приоритетом io? (man 1 ionice)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: openvz, vserver

В сообщении от Monday 24 December 2007 02:00:28 Artem Chuprina написал(а):
AP Если типичные запросы выполняются порядка 100мс, проблем не
AP возникает. А если все тормозит, то ограничение ресурсов приведет к
AP еще большему замедлению, что пользователю не в радость.

Полностью согласен. Только опыт показывает, что админ, поставивший на сервер
связку LAMP, зачастую обладает кривыми ручками и способен напортачить во
всем. То есть на быдлокодера найдется и свой быдлоадмин. При том, что лет
пять назад средняя квалификация линуксового админа была намного выше. Куда-то
не туда ИТ индустрия катится.

И, кстати, о постгресе - при дефолтовых настройках он почти не ест память, в
отличие от мускуля, который сжирает все ресурсы, которые находит. Бредовые
аппетиты того же php тоже вполне известны. И если еще можно понять человека,
который ваяет первый в жизни сайт и думает лишь бы запустилось, то понять
разработчиков мускуля и пхп я не в силах. Может, как раз полагают, что кому
приспичит, засунут все в виртуальную машину... вот и получается замкнутый
круг.

Re: openvz, vserver