Небольшая статья, описывающая цели использования различных разделов, а также какие файловые системы на них лучше использовать и какие опции монтирования указывать.
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, ессно) и при этом освободить оперативную память и вычислительные ресурсы процессора.
> Да. Выносим. Но, скорее, из соображений безопасности. ;-) Причём, "безопасности" не компьютерного характера, а юридического: чтобы в случае "маски-шоу" всегда можно было винт вытащить из 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...
>всё высказанное - это МОЁ мнение. :-) Я никого не заставляю делать всё так, как у меня.
Слава богу что у остальных голова есть чтобы понять азы администрирования....
"Что же у вас там такое в спулах что вы готовы винтами с пятого этажа бросаться?"
Да мало ли чего там может оказаться (вплоть - до провокаций от наложки). Оно нам надо? Винт стоит 40$. А "попасть" из-за этого винта можно на десятки тысяч. ;-)
"Ага, пример - squid/sendmail/whatever с невынесенным на отдельныую партицию спулом/кешем (мы же только бойцов боимся, так вот предположим - их нет) берет и сжирает все место в /var тем самым останавливая _ВСЕ_."
Да, конечно... Про квоты мы, разумеется, забыли. Забыли ещё и про то, что порядка 1% размера устройства является неиспользуемой областью для всех, кроме root'а ... Что легко позволяет root'у исправить положение с нехваткой места и глюками демонов.
"При чем здесь информация? Речь шла только о поддержании сервера в неукладываемом состоянии или хотя бы чтобы сервисы если и ложились то по одному... И если вас устраивает ситуация что "внешние сервера ложатся" то меня, как и многих здесь, - нет."
Ситуация, когда внешние сервера "ложатся" устраивает не меня, а моё начальства. Ситуацию, когда серверы "ложатся по одному" обеспечивает, как раз-таки, то, что каждый сервис работает под своим UID/GID. А машина в "неукладываемом состоянии" быть не может по определению. В конце-концов, в ней какой-нибудь диод пробить может... ;-)))
@перфоманс просядет потому что FS будут "переключаться"
а не потому что "памяти на user-space processes останется меньше". @
Хм. А разве нет? Ты с одного раздела, скажем, XFS перепиши 100Гб инфы на раздел с ReiserFS. Замерь время. Потом перепиши те же 100Гб с ReiserFS на ReiserFS. Замерь время. (для чистоты эксперимента желательно использовать одинаковые носители с одинаковым размером разделов и их расположением на носителях)
Результат опубликуй здесь......... Если решишься, конечно, сообщить экспериментальные данные о своей неправоте.
> Да, конечно... Про квоты мы, разумеется, забыли.
Ничуть. Только такой способ ограничения 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Гб а поменьше) при первой физической возможности.
Детский сад, хотя группа вроде уже и не ясельная
Почему-то в статье и в обсуждении/кидании понтов фигурирует один диск
А если их 2, 3, 4, ..... ?
Приведу только один факт. Как-то раз было посчитано, сколько дисков надо, чтобы поставить Oracle так, как рекомендует Oracle.С учетом всех рейдов и рекомендаций разбросов фйлов базы по разным дискам вышло _27_ физических дисков, объединенных в разные рйды. Это без учета системы и по минимуму для каждого типа райда.
2avg (*) (2003-06-03 06:21:29.80752): Почему "понты"? Я ясно написал, что система со свопом у меня живут на одном диске, данные - на другом. Вполне разумно.
>Ага, пример - squid/sendmail/whatever с невынесенным на отдельныую партицию спулом/кешем (мы же только бойцов боимся, так вот предположим - их нет) берет и сжирает все место в /var тем самым останавливая _ВСЕ_.
трабла в сквиде и иже с ним в том, что при нежданном выключении питания он не успевает прекратить запись в свой кэш/лог и т.п., соответственно при включении - в разделе появляются сбойные участки, потерянные файлы и т.п., если выносить /var/spool/squid и /var/log в отдельные разделы, из можно без опасности для системы и проверить, да хоть переформатить тот кэш... а если в одном разделе - все приплыли...
хотя кончно, да, при установке системы не надо возиться с разбиением... времени экономится куча :)
Тут была интересная тема затронута - относительно файловых систем.
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 работает норамльно?
> А два раза не смог загрузиться - требовал root password for maintenance и запуска fsck. При проходе fsck (оба раза) пришлось очень много раз нажать Enter
А я сразу изменяю init-скрипт и убираю это гамно. Если при
проверке файловая система оказывается коррумпированной, я
сразу же в скрипте запускаю fsck -fy. Почему? 1) у меня все
сервера удаленные 2) Если фс накроется, то значит там нечто
настолько ужасное, что даже руками я вряд ли смог бы что-то
сделать.Только восстановление из резервной копии. За много лет
я видел такое только один раз.
2 nazarov_serg
>но смысл-то какой в использовании ext3 перед ext2?
IMHO, смысл есть. :)) Я с трудом могу вспомнить когда последний раз использовал fsck. Если у вас система не тяжело нагруженная, то может даже имеет смысл заставить fs писать вначале в журнал. Кстати как поживает ваш Oracle?