Разбиение диска для увеличения производительности

Re: Разбиение диска для увеличения производительности

Во, блин, у меня примерно так-же разбито. Причем давно уже.

$ df -h Filesystem Size Used Avail Use% Mounted on /dev/hda6 432M 87M 346M 20% / /dev/hda5 16M 5,8M 8,6M 41% /boot /dev/hda7 4,0G 656M 3,4G 17% /home /dev/hda8 2,1G 561M 1,6G 27% /usr /dev/hda10 573M 108M 466M 19% /var /dev/hda11 573M 140M 433M 25% /var/spool/news /dev/hda12 283M 251M 33M 89% /var/spool/squid /dev/hda13 92M 2,2M 85M 3% /tmp /dev/hda14 11G 7,9G 2,7G 75% /mnt/dump

/tmp и /boot -- ext2, остальное рейзер. ИМХО, удобно.

Re: Разбиение диска для увеличения производительности

Мля!

$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda6 432M 87M 346M 20% /
/dev/hda5 16M 5,8M 8,6M 41% /boot
/dev/hda7 4,0G 656M 3,4G 17% /home
/dev/hda8 2,1G 561M 1,6G 27% /usr
/dev/hda10 573M 108M 466M 19% /var
/dev/hda11 573M 140M 433M 25% /var/spool/news
/dev/hda12 283M 251M 33M 89% /var/spool/squid
/dev/hda13 92M 2,2M 85M 3% /tmp
/dev/hda14 11G 7,9G 2,7G 75% /mnt/dump

Re: Разбиение диска для увеличения производительности

anonymous (*) (2003-06-02 20:52:06.719772):
Во-первых, всё высказанное - это МОЁ мнение. :-) Я никого не заставляю делать всё так, как у меня.

Во-вторых: "Так все таки выносим spool & cache на отдельные партиции ???". Да. Выносим. Но, скорее, из соображений безопасности. ;-) Причём, "безопасности" не компьютерного характера, а юридического: чтобы в случае "маски-шоу" всегда можно было винт вытащить из Mobile-Rack и выкинуть в окошко с 5-го этажа на асфальтовую площадку. Доходчиво? ;-)

В-третьих: "Вот это спорно... Живые юзера - нет, а вот демон запущенный не из под рута - вполне (если дополнительно ничего не предпринять).". Хех. Да как же он может "повлиять"??? Ему ядро не позволит. У демона строгая зона, где он может работать. К примеру, HTTPD (работает под юзерскими правами): он может читать html-документы (но не может в них писать, потому что права там rw-r-----, причём владелец - не тот юзер, под которым работает HTTPD) Другие демоны даже прочитать не могут, чего в каталоге htdocs - не состоят в группе http... ;-) И вот так сконфигурирована система ЦЕЛИКОМ. Т. е., то же самое с BIND'ом, с сендмылом и т. д.
Так что демон, даже тот, который начнет выёживаться, получит от ядра KILL signal и помрёт смертью храбрых.
Выльется это лишь в то, что я приду, выкачаю из инета последнюю версию, перековыряю конфиги и всё снова будет работать, как часы.

В четвертых: "То, что у вас нет паранои, еще не значит что за вами никто не следит :))". Ну про внешние серверы я промолчу - "лягут" они - так и хрен с ними: до внутренней сети враги вряд ли доберутся через Инет. А против врагов "внутренних" никакие препоны не помогут: в конце-концов, информацию они могут вынести и на флеш-дисках...

В-пятых: "А теперь подумайте на сколько ПОРЯДКОВ различаются времена доступа к памяти и диску! Игры с процессорным кешем становятся просто смешными..." Не так всё просто. Я ещё в первом своём постинге про это сказал: для быстрой машины будут ВСЕ эти игры глубоко параллельны (т. е., даже если постулаты из статьи верны, то разница в производительности будет вряд ли различаться более, чем на 0.5%: а это легко можно списать на погрешность измерений), а для медленной - всё будет грустно.
Так вот, про медленную машинку: RAM и так мало, а автор статьи предлагает забить в неё пару-тройку "лишних" FS ; процессор и так медленный, но автор статьи предлагает забить вычислительные мощности обработкой кода "лишних" FS. При этом, выполнение текущих задач тормозится (а, возможно, даже очень много сбрасывается в SWAP). Хотя можно ведь оставить одну FS (помимо SWAP'а и сетевых FS, ессно) и при этом освободить оперативную память и вычислительные ресурсы процессора.

Неужели ты с этим со всем будешь спорить???

R00T (02.06.2003 21:42:19)

Re: Разбиение диска для увеличения производительности

2 R00T (*) (2003-06-02 21:42:19.320749)

Конечно буду спорить.

> Да. Выносим. Но, скорее, из соображений безопасности. ;-) Причём, "безопасности" не компьютерного характера, а юридического: чтобы в случае "маски-шоу" всегда можно было винт вытащить из Mobile-Rack и выкинуть в окошко с 5-го этажа на асфальтовую площадку. Доходчиво? ;-)

Что же у вас там такое в спулах что вы готовы винтами с пятого этажа бросаться?

> Хех. Да как же он может "повлиять"??? Ему ядро не позволит. У демона строгая зона, где он может работать.

Ага, пример - squid/sendmail/whatever с невынесенным на отдельныую партицию спулом/кешем (мы же только бойцов боимся, так вот предположим - их нет) берет и сжирает все место в /var тем самым останавливая _ВСЕ_.

>В четвертых: "То, что у вас нет паранои, еще не значит что за вами никто не следит :))". Ну про внешние серверы я промолчу - "лягут" они - так и хрен с ними: до внутренней сети враги вряд ли доберутся через Инет. А против врагов "внутренних" никакие препоны не помогут: в конце-концов, информацию они могут вынести и на флеш-дисках...

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

>Не так всё просто. Я ещё в первом своём постинге про это сказал: для быстрой машины будут ВСЕ эти игры глубоко параллельны (т. е., даже если постулаты из статьи верны, то разница в производительности будет вряд ли различаться более, чем на 0.5%: а это легко можно списать на погрешность измерений), а для медленной - всё будет грустно.

BULLSHIT!!!!
При правильно подобранных fs/fs options мы получием выигрыш в перфомансе который меряется десятками процентов!!!

>Так вот, про медленную машинку: RAM и так мало, а автор статьи предлагает забить в неё пару-тройку "лишних" FS ; процессор и так медленный, но автор статьи предлагает забить вычислительные мощности обработкой кода "лишних" FS. При этом, выполнение текущих задач тормозится (а, возможно, даже очень много сбрасывается в SWAP)

Не смешите мои коленки... Мы же не поднимаем squid/sendmail/httpd/whatever на 386м с 4мя мегами... А на машинке с хотя бы 256 Мегами памяти я не почувствую что ядро занимает на 100 кб больше... Плюс не надо передергивать... В оригинальном постинге вы заявляли что перфоманс просядет потому что FS будут "переключаться"
а не потому что "памяти на user-space processes останется меньше".
И что значит 'забить вычислительные мощности обработкой кода "лишних" FS' ??? От наличия нескольких FS нагрузка на CPU не будет больше по сравнению со случаем одной (самой "тяжелой") FS...

>всё высказанное - это МОЁ мнение. :-) Я никого не заставляю делать всё так, как у меня.

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

Re: Разбиение диска для увеличения производительности

"Что же у вас там такое в спулах что вы готовы винтами с пятого этажа бросаться?"
Да мало ли чего там может оказаться (вплоть - до провокаций от наложки). Оно нам надо? Винт стоит 40$. А "попасть" из-за этого винта можно на десятки тысяч. ;-)

"Ага, пример - squid/sendmail/whatever с невынесенным на отдельныую партицию спулом/кешем (мы же только бойцов боимся, так вот предположим - их нет) берет и сжирает все место в /var тем самым останавливая _ВСЕ_."
Да, конечно... Про квоты мы, разумеется, забыли. Забыли ещё и про то, что порядка 1% размера устройства является неиспользуемой областью для всех, кроме root'а ... Что легко позволяет root'у исправить положение с нехваткой места и глюками демонов.

"При чем здесь информация? Речь шла только о поддержании сервера в неукладываемом состоянии или хотя бы чтобы сервисы если и ложились то по одному... И если вас устраивает ситуация что "внешние сервера ложатся" то меня, как и многих здесь, - нет."
Ситуация, когда внешние сервера "ложатся" устраивает не меня, а моё начальства. Ситуацию, когда серверы "ложатся по одному" обеспечивает, как раз-таки, то, что каждый сервис работает под своим UID/GID. А машина в "неукладываемом состоянии" быть не может по определению. В конце-концов, в ней какой-нибудь диод пробить может... ;-)))

@перфоманс просядет потому что FS будут "переключаться"
а не потому что "памяти на user-space processes останется меньше". @
Хм. А разве нет? Ты с одного раздела, скажем, XFS перепиши 100Гб инфы на раздел с ReiserFS. Замерь время. Потом перепиши те же 100Гб с ReiserFS на ReiserFS. Замерь время. (для чистоты эксперимента желательно использовать одинаковые носители с одинаковым размером разделов и их расположением на носителях)
Результат опубликуй здесь......... Если решишься, конечно, сообщить экспериментальные данные о своей неправоте.

R00T (02.06.2003 23:46:49)

Re: Разбиение диска для увеличения производительности

2 R00T (*) (2003-06-02 23:46:49.683089)

> Да, конечно... Про квоты мы, разумеется, забыли.

Ничуть. Только такой способ ограничения daemon'а ест гораздо больше ресурсов чем просто тупое вынесение его спула на отдельную партицию...

> Забыли ещё и про то, что порядка 1% размера устройства является неиспользуемой областью для всех, кроме root'а ...

Интересно, и как это поможет sendmail'у если squid скушал весь /var ???

>Что легко позволяет root'у исправить положение с нехваткой места и глюками демонов.

Безусловно... Только вот до того как root вмешается лежать будут _ВСЕ_ сервисы.

>Ситуацию, когда серверы "ложатся по одному" обеспечивает, как раз-таки, то, что каждый сервис работает под своим UID/GID.

См. выше

>А машина в "неукладываемом состоянии" быть не может по определению. В конце-концов, в ней какой-нибудь диод пробить может... ;-)))

Да, согласен, от hardware failures никто не защищен...

>Хм. А разве нет? Ты с одного раздела, скажем, XFS перепиши 100Гб инфы на раздел с ReiserFS. Замерь время. Потом перепиши те же 100Гб с ReiserFS на ReiserFS. Замерь время. (для чистоты эксперимента желательно использовать одинаковые носители с одинаковым размером разделов и их расположением на носителях)

Ну, в такой постановке эксперимента есть БОЛЬШАЯ проблема - он ничего не доказывает. Если трансфер xfs -> reiser будет медленней то я могу сказать что это xfs медленная... Если уж сравнивать - то худшее время транфера (reiser -> xfs / xfs - > reiser) с худшим временем (xfs -> xfs / reiser -> reiser). Обязуюсь проделать (может и не на 100Гб а поменьше) при первой физической возможности.

Re: Разбиение диска для увеличения производительности

Детский сад, хотя группа вроде уже и не ясельная
Почему-то в статье и в обсуждении/кидании понтов фигурирует один диск
А если их 2, 3, 4, ..... ?

Приведу только один факт. Как-то раз было посчитано, сколько дисков надо, чтобы поставить Oracle так, как рекомендует Oracle.С учетом всех рейдов и рекомендаций разбросов фйлов базы по разным дискам вышло _27_ физических дисков, объединенных в разные рйды. Это без учета системы и по минимуму для каждого типа райда.

avg (03.06.2003 6:21:29)

Re: Re: Разбиение диска для увеличения производительности

А лучше всего, конечно, скопировать сперва из reiserfs в ramfs, а потом из reiserfs в reiserfs ;)

green (03.06.2003 10:15:30)

Re: Разбиение диска для увеличения производительности

2avg (*) (2003-06-03 06:21:29.80752): Почему "понты"? Я ясно написал, что система со свопом у меня живут на одном диске, данные - на другом. Вполне разумно.

R00T (03.06.2003 12:04:46)

Официальный релиз Wind River's BSD/OS 5.0

>Ага, пример - squid/sendmail/whatever с невынесенным на отдельныую партицию спулом/кешем (мы же только бойцов боимся, так вот предположим - их нет) берет и сжирает все место в /var тем самым останавливая _ВСЕ_.

Пионэры билять.

sendmail.cf

O MinFreeBlocks=number

squid.conf

cache_swap_low cache_swap_high

Sun-ch (03.06.2003 13:17:00)

Re: Разбиение диска для увеличения производительности

трабла в сквиде и иже с ним в том, что при нежданном выключении питания он не успевает прекратить запись в свой кэш/лог и т.п., соответственно при включении - в разделе появляются сбойные участки, потерянные файлы и т.п., если выносить /var/spool/squid и /var/log в отдельные разделы, из можно без опасности для системы и проверить, да хоть переформатить тот кэш... а если в одном разделе - все приплыли... хотя кончно, да, при установке системы не надо возиться с разбиением... времени экономится куча :)

Официальный релиз Wind River's BSD/OS 5.0

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

Это как ? Сквид питается от отдельной батарейки ?

Sun-ch (03.06.2003 14:04:20)

Re: Разбиение диска для увеличения производительности

Тут была интересная тема затронута - относительно файловых систем. xfs и reiserfs не пробовал. А вот от журнальных функций ext3 не в восторге. Есть UPS. К нему подключено аж 3 сервака - 2 - win2000 и 1 redhat-2.4.7(почтовый). Где-то за пол-года 3 раза отключали энергию и UPS успевал сесть. Один раз redhat после отключения загрузился нормально - быстро прочекил файловую систему(не в пример ext2). А два раза не смог загрузиться - требовал root password for maintenance и запуска fsck. При проходе fsck (оба раза) пришлось очень много раз нажать Enter ( to fix inode или attach их к lost+found). Причем последний раз (сегодня) в lost+found оказался кусок важного письма (и которого не оказалось в почтовом ящике). С win2000(NTFS) (как пример) никаких подобных проблем ни разу не наблюдал. Неужели у меня одного такие проблемы и у всех ext3 работает норамльно?

nazarov_serg

Re: Разбиение диска для увеличения производительности

2 Sun-ch (*) (2003-06-03 13:17:00.057342)

>sendmail.cf

>O MinFreeBlocks=number

>squid.conf

>cache_swap_low cache_swap_high

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

>Пионэры билять.

А это я коментировать не буду...

Re: Разбиение диска для увеличения производительности

2 avg (*) (2003-06-03 06:21:29.80752)

>Почему-то в статье и в обсуждении/кидании понтов фигурирует один диск
А если их 2, 3, 4, ..... ?

Так я только за ,) Моей концепции "разделяй и властвуй" это нисколько не противоречит.

Re: Re: Разбиение диска для увеличения производительности

> Причем последний раз (сегодня) в lost+found оказался кусок важного письма

Юзайте qmail и ваши волосы... Кроме избавления от /var/spool/mail вы получаете гарантированную запись полученного письма на диск.

Gartner предупреждает

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

Если это не так, то прога идет в /dev/null

К sendmail и squid это не относится

Sun-ch (03.06.2003 18:28:33)

Gartner предупреждает

UPS должен уметь останавливать сервер.

Sun-ch (03.06.2003 18:31:46)

Re: Re: Разбиение диска для увеличения производительности

> А два раза не смог загрузиться - требовал root password for maintenance и запуска fsck. При проходе fsck (оба раза) пришлось очень много раз нажать Enter

А я сразу изменяю init-скрипт и убираю это гамно. Если при
проверке файловая система оказывается коррумпированной, я
сразу же в скрипте запускаю fsck -fy. Почему? 1) у меня все
сервера удаленные 2) Если фс накроется, то значит там нечто
настолько ужасное, что даже руками я вряд ли смог бы что-то
сделать.Только восстановление из резервной копии. За много лет
я видел такое только один раз.

Re: Разбиение диска для увеличения производительности

2 Sun-ch (*) (2003-06-03 18:28:33.924181)

>> Это уже обсуждалось. Если вы свято верите что все проги работают могласно документации и не сбоят - вы счастливый человек.

> Если это не так, то прога идет в /dev/null

> К sendmail и squid это не относится

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

Вот вы используете firewall ? а зачем ???? ведь все ваши сервиса непробиваемы и правильно сконфигурены....

Re: Re: Разбиение диска для увеличения производительности

> При установленной опции atime в inode происходит запись access time > при каждом чтении. Оно нам всегда надо?

Иногда бывает надо - atime в /usr позволяет определить, какие из установленных пакетов действительно нужны (используются), а какие нет.

hilight (04.06.2003 0:47:45)

Re: Разбиение диска для увеличения производительности

2anonymous (*) (2003-06-03 18:32:00.943442)

Спасиб за идею (fsck из скрипта) - но смысл-то какой в использовании ext3 перед ext2? Или опция writeback гарантированно поможет?.

nazarov_serg

Re: Официальный релиз Wind River's BSD/OS 5.0

было б классно, если бы питался... увы, от одного блока питания... вырубили свет - хана сквиду

Gartner предупреждает

разница между нами

ps ax | less

PID TT STAT TIME COMMAND

433 ?? --- 15067:25.08 (squid) (squid)

Sun-ch (04.06.2003 12:00:15)

Re: Разбиение диска для увеличения производительности

2 nazarov_serg
>но смысл-то какой в использовании ext3 перед ext2?

IMHO, смысл есть. :)) Я с трудом могу вспомнить когда последний раз использовал fsck. Если у вас система не тяжело нагруженная, то может даже имеет смысл заставить fs писать вначале в журнал. Кстати как поживает ваш Oracle?

Alter (04.06.2003 12:39:01)

Re: Re: Re: Разбиение диска для увеличения производительности

Иногда - понятно.... Я бы даже сказал про взлом и время доступа к /etc/shadow... Добавляем в список... Еще варианты?

Dimai (04.06.2003 18:32:51)

Re: Разбиение диска для увеличения производительности

2nazarov_serg: обнови ядро, в таком древнем скорее всего не только ext3 глючит