Известно, что если вынести базу (MySQL) на отдельный физический диск, то суммарная производительность веб-сервера
(открытие страниц, увеличение лимита максимального числа посетителей и т.д.) должна по идее возрасти.
Но вот насколько именно, примеров пока найти не удалось. Если, скажем, на 30-50%, то еще можно
раскошелиться на отдельный винт, если на 3-5%, то понятно дело, овчинка выделки не стоит.Кто-пробовал этот метод повышения производительности, есть какие-либо практические результаты?
> Известно, что если вынести базу (MySQL) на отдельный физический диск, то суммарная
> производительность веб-сервера
> (открытие страниц, увеличение лимита максимального числа посетителей и т.д.) должна по
> идее возрасти.
> Но вот насколько именно, примеров пока найти не удалось. Если, скажем, на
> 30-50%, то еще можно
> раскошелиться на отдельный винт, если на 3-5%, то понятно дело, овчинка выделки
> не стоит.Хотите пообсуждать сферический сервер в вакууме?
Врядли вы инженер, скорее "экономист", судя по слову "раскошелиться" аж на целый один винт.Будь вы инженером или экономистом, любые решения надо принимать взвешенно, после проведения анализа. Задавать вопросы "как же у меня работает сервер-то, а ?" - глупо.
> Кто-пробовал этот метод повышения производительности, есть какие-либо практические результаты?
Если вы инженер - то предлагаю подумать о том, как же "как это работает?".
Если вы экономист - то ответ прост - "да".
> Хотите пообсуждать сферический сервер в вакууме?
> Врядли вы инженер, скорее "экономист", судя по слову "раскошелиться" аж на
> целый один винт.А без флейма обойтись можно? Ну и что, если мне нужен один винт - это что, крамола?
У меня один сервер, и больше не нужно - вы способны рассуждать в пределах конкретно очерченной задачи, или вам по силам охват только дата-центров планетарного масштаба?
> Будь вы инженером или экономистом, любые решения надо принимать взвешенно, после проведения
> анализа. Задавать вопросы "как же у меня работает сервер-то, а ?"
> - глупо.Какое вам дело до моей профессии? Не более, чем мой интерес к вашей.
> Если вы инженер - то предлагаю подумать о том, как же "как
> это работает?".
> Если вы экономист - то ответ прост - "да".О чем думать, что "да"? Вы хоть постигли суть заданного вопроса?
Ответ на него лежит вовсе не в бинарной плоскости, как вы решили.В-общем, как говорится - "первый нах".
>> Хотите пообсуждать сферический сервер в вакууме?
> А без флейма обойтись можно? Ну и что, если мне нужен один
> винт - это что, крамола?Значит у вас просто ещё не выходили из строя винчестера.
Как первый вылетит - быстро освоите, и что такое "зеркало", и что такое "бэкап".>[оверквотинг удален]
> в пределах конкретно очерченной задачи, или вам по силам охват только
> дата-центров планетарного масштаба?
>> Будь вы инженером или экономистом, любые решения надо принимать взвешенно, после проведения
>> анализа. Задавать вопросы "как же у меня работает сервер-то, а ?"
>> - глупо.
> Какое вам дело до моей профессии? Не более, чем мой интерес к
> вашей.
>> Если вы экономист - то ответ прост - "да".
> О чем думать, что "да"? Вы хоть постигли суть заданного вопроса?
> Ответ на него лежит вовсе не в бинарной плоскости, как вы решили.Вы пропустили главную мысль, выделю её отдельно специально для вас: любые решения надо принимать взвешенно, после проведения анализа.
Вы данных предоставили, чтобы говорить что-то большее чем "да" или "нет"?
Называть это "конкретно очерченной задачей" - неверно.> В-общем, как говорится - "первый нах".
Поздравляю.
> Значит у вас просто ещё не выходили из строя винчестера.
> Как первый вылетит - быстро освоите, и что такое "зеркало", и что
> такое "бэкап".Милейший, вы думаете, что о "зеркале" и "бекапе" на этом форуме знаете вы один?
Я собирал зеркала еще в эпоху NT4 (1997 г.), кто-то может, еще раньше, так что не надо нас лечить. И хостингом занимаюсь лет 7, не профессионально, но свой опыт все же имеется.
Если бы занимался профессионально, то конечно, уже давно бы знал ответ на свой вопрос.Почему вы думаете, что если кто-то задал вопрос о чем-то конкретном, то он глупее остальных и не знает о рейдах, бекапах, ncq и прочих материях, и надо обязательно увести дискуссию в сторону от основного вопроса?
> Вы пропустили главную мысль, выделю её отдельно специально для вас: любые
> решения надо принимать взвешенно, после проведения анализа.
> Вы данных предоставили, чтобы говорить что-то большее чем "да" или "нет"?
> Называть это "конкретно очерченной задачей" - неверно.В-общем, буду вам весьма признателен, если вы прекратите здесь пи$деть не по делу и вынуждать тратить мое время на ваши пустопорожние реплики.
> Известно, что если вынести базу (MySQL) на отдельный физический диск, то суммарная
> производительность веб-сервера
> (открытие страниц, увеличение лимита максимального числа посетителей и т.д.) должна по
> идее возрасти.А не поделитесь информацией - ОТКУДА это известно? Мне, например, это неизвестно. У меня на 10 серверах и Вэб-сервер и мускул работают на одном физическом диске. На 2-х файлы базы лежат на отдельных больших дисках - исключительно для надежности. На особо критичных серверах диски в зеркале (RAID1). На файлопомойке - RAID5 из 16 полутерабайтных дисках.
> Но вот насколько именно, примеров пока найти не удалось. Если, скажем, на
> 30-50%, то еще можно
> раскошелиться на отдельный винт, если на 3-5%, то понятно дело, овчинка выделки
> не стоит.Овчинка в виде 1.500-2.000 рублей (наверное, бешеные деньги, да) стоит хотя бы из соображения надежности. Хотя тут более правильно искать овчинку в виде RAID-контроллеров. А для увеличения производительности Вэб-сервера посмотрите лучше в сторону nginx и fast-cgi. И использовании различных механизмов кэширования. Ну и более производительного железа (как процессора, так и более быстрых жестких дисков). О соответствии овчинки и выделки Вам тут вряд ли посоветуют - это не форум экономистов.
> А не поделитесь информацией - ОТКУДА это известно? Мне, например, это
> неизвестно. У меня на 10 серверах и Вэб-сервер и мускул работают
> на одном физическом диске. На 2-х файлы базы лежат на отдельных
> больших дисках - исключительно для надежности. На особо критичных серверах диски
> в зеркале (RAID1). На файлопомойке - RAID5 из 16 полутерабайтных дисках.Не поделюсь - она ОБЩЕИЗВЕСТНА, как например, та, что хлеб делается из пшеницы.
Поэтому конкретный источник не укажу. По крайней мере, мне она известна лет 10, просто на практике ни разу не использовал.> Овчинка в виде 1.500-2.000 рублей (наверное, бешеные деньги, да) стоит хотя
> бы из соображения надежности.Нет, если выделить один диск, то надежность как раз упадет, поскольку данные и так находятся на RAID. Если уж добавлять, то тоже в виде рейда.
> Хотя тут более правильно искать овчинку в виде RAID-контроллеров.
> А для увеличения производительности Вэб-сервера посмотрите лучше
> в сторону nginx и fast-cgi. И использовании различных механизмов кэширования. Ну
> и более производительного железа (как процессора, так и более быстрых жестких
> дисков). О соответствии овчинки и выделки Вам тут вряд ли посоветуют
> - это не форум экономистов.Уважаемый, все это давно сделано, тем не менее, спасибо что напомнили.
Экономисты тут ни причем, поскольку речь идет сугубо о конкретных цифрах.
Если, например, прирост составит 3-5%, то даже неэконоимсту ясно, что овчинка выделки не стоит. Впрочем, я уже это говорил, по второму кругу объяснять неинтересно.
> Не поделюсь - она ОБЩЕИЗВЕСТНА, как например, та, что хлеб делается из
> пшеницы.а как же черный? :)
> а как же черный? :)Черный - делают из черной пшеницы. :)
Простите за оффтоп. Ну, собственно, если ОБЩЕИЗВЕСТНА, то и ладно.
> Кто-пробовал этот метод повышения производительности, есть какие-либо практические результаты?Насколько могу судить, мускль активные таблицы предпочитает держать в ОЗУ, поэтому критичными по диску будут операции записи. Скажем, MSSQL временные таблицы желает создавать исключительно на диске, поэтому вынос раздела под временные таблицы на RAM-диск дает грандиозный прирост производительности. У мускля все (ну, не все, но многое) и так крутится в памяти, поэтому прироста большого не будет. Несколько процентов, до десяти. Скорей всего - 2-5% в среднем за длинный период под значимой нагрузкой.
Более рациональным считаю увеличение объема ОЗУ.
>> Кто-пробовал этот метод повышения производительности, есть какие-либо практические результаты?
> Насколько могу судить, мускль активные таблицы предпочитает держать в ОЗУ, поэтому критичными
> по диску будут операции записи. Скажем, MSSQL временные таблицы желает создавать
> исключительно на диске, поэтому вынос раздела под временные таблицы на RAM-диск
> дает грандиозный прирост производительности. У мускля все (ну, не все, но
> многое) и так крутится в памяти, поэтому прироста большого не будет.
> Несколько процентов, до десяти. Скорей всего - 2-5% в среднем за
> длинный период под значимой нагрузкой.
> Более рациональным считаю увеличение объема ОЗУ.Ваш ответ ответ интересен для дискуссии, спасибо.
Да, вы совершенно правы насчет RAM и его увеличения.
Но предположим, что все меры по оптимизации использовании RAM уже использованы, php-eaccelarator и nginx работает, величина памяти доведена до максимально возможной для конкретной материнки, скажем, 8 ГБ.
И вот интересно в этом случае - дает ли дополительный диск для базы существенный прирост?
Как вы уже сказали, это может составлять 2-5%. Ну, если это так, то конечно, не стоит.Хотя и тут есть некоторая перспектива - использовать для базы современные многопортовые SSD, у которых время произвольного доступа может быть гораздо лучше традиционных ЖД.
> И вот интересно в этом случае - дает ли дополительный диск для базы существенный прирост?Однозначного ответа нет, потому что все зависит от нескольких факторов.
В вашем случае речь идет о дисковых иопсах (iops = input/output per second). Диск имеет физический конструктивный предел иопсов. Система и приложения (и СУБД в т.ч.) запрашивают иопсы в процессе работы. Если запрашивается иопсов больше, чем может выполнить диск, диск становится узким местом. Добавив второй диск, и разнеся иопсы по разным устройствам, мы, казалось бы, удвоим количество доступных иопсов, но обычно этого не происходит.Если запрашивается меньше иопсов, чем может выполнить диск, то второй диск прироста почти не даст. Ну, в пределах нескольких процентов. Если СУБД запрашивает иопсов больше, чем дает диск, то выделение отдельного диска под БД снова почти не поможет. Ну, скажем, если диск может 1000 иопсов, система и прочие приложения запрашивают 100, а СУБД - 2000, то в среднем СУБД получит 950 иопсов, а прочий софт - 50. Если вынести БД на отдельный диск с 1000 иопсов, то СУБД получит 1000, а прочий софт со старого диска - 100.
Единственный случай, когда второй диск даст ощутимый прирост - это когда прочие приложения потребляют очень много иопсов, и у СУБД аппетит тоже высок. Например, СУБД хочет 1000, и прочие приложения - 3000. А диск может лишь 1000 иопсов. Тогда СУБД получит 250, а прочие - 750. Ясно, что выделив СУБД отдельный диск, мы дадим ей вчетверо больше иопсов.
Вообще, проблема иопсов решается разными способами - например, раскруткой шпинделя дисков до 10-15к оборотов в минуту, или таггед-кьюингом, или кешем чтения/записи. Еще есть SSD которые имеют высокие мгновенные значения иопсов, но сравнительно небольшой ресурс наработки иопсов на отказ. Еще есть RAM-диски, у которых иопсы вообще заоблачные, но у них сравнительно небольшой объем, и нужны хитрые техники работы с ними.
В общем, выяснить, поможет оно вам или нет - можно только после анализа нагрузки на дисковую подсистему. И если узкое место в дисках, то выбор лечения тоже может быть разным.
-
> Хотя и тут есть некоторая перспектива - использовать для базы современные многопортовые
> SSD, у которых время произвольного доступа может быть гораздо лучше традиционных ЖД.Я отдаю предпочтение вот таким штукам:
http://techreport.com/articles.x/9312
http://techreport.com/articles.x/16255Конечно, объем у них сравнительно невелик, но зато по скорострельности они кроют и классические диски, и твердотельные флешовые.
Когда вместо 500-1000 иопсов получается 10000-11000 - это серьезно.http://techreport.com/r.x/gigabyte-iram/iometer-trans-data.gif
DeadLoco:Спасибо. По вашим ответам понял главное - что перенос базы на отдельный носитель по результатам может быть неоднозначен, т.е. как давать прирост, так и нет.
В таком случае повременю, пока не исчерпаются все имеющие резервы производительности системы и она войдет в "насыщение".
По поводу RAM в качестве эмулятора скоростного накопителя тоже знаю, но эти решения дороги, и в данном бюджетном случае (когда стоит вопрос "ставить дополнительный ЖД для базы или нет") конечно, не имеет смысла. Пожалуй, пусть пока полежит в качестве резерва.
Или организовать с его помощью более интересный RAID, чем 1-й?
> DeadLoco:
> Спасибо. По вашим ответам понял главное - что перенос базы на отдельный
> носитель по результатам может быть неоднозначен, т.е. как давать прирост, так
> и нет.Как же так, а ? Задача конкретно очерчена, а ответ - "результат может быть неоднозначен" ?
Странно, не находите ли ?> В таком случае повременю, пока не исчерпаются все имеющие резервы производительности системы и она войдет в "насыщение".
А вот как вы определяете, какие ресурсы у вас уже в насыщении, а какие нет?
Если вы знаете, какие ресурсы, как используются - то значит знаете - поможет вам дополнительный винчестер или нет - так какого на форуме задавать вопросы?.> Пожалуй, пусть пока полежит в качестве резерва.
> Или организовать с его помощью более интересный RAID, чем 1-й?С помощью одного винта - интересный RAID ? Человек, который 7 лет занимается хостингом ?
Бредить прекратите.
Даже отвечать не стану - все равно не поймет, т.к. читает между строк, выбирая наиболее понятные ему места.
Есть такие форумы, на которых автор топика может удалять реплики околачивающих груши.
Жаль, здесь нет такой возможности.
> Даже отвечать не стану - все равно не поймет, т.к. читает между
> строк, выбирая наиболее понятные ему места.Ну, это вы ровно про себя написали.
Вы же через три строки читали http://www.opennet.me/openforum/vsluhforumID8/7176.html#1И вы, видимо, не в состоянии понять фразы:
"Хотите пообсуждать сферический сервер в вакууме?" - в которой говорится о том, что информации о вашем конкретном сервере недостаточно.
"Если вы инженер - то предлагаю подумать о том, как же "как это работает?"." - в которой говорится о том, что, по-видимому, вы слабо представляете как на самом деле работает ваш конкретный сервер.
> Жаль, здесь нет такой возможности.А я что-то неправильное сказал ? :-)
> Или организовать с его помощью более интересный RAID, чем 1-й?Выше уже заметили, что из двух дисков ничего интереснее зеркала не получится. ЖБОД и страйп - это приключения на свою задницу. Все интересное начинается с десятки на рейд-эдишнах, а это минимум четыре диска плюс правильный, нефейковый контроллер с бубочкой. Что тоже выливается в серьезные деньги.
> Выше уже заметили, что из двух дисков ничего интереснее зеркала не получится.
> ЖБОД и страйп - это приключения на свою задницу. Все интересное
> начинается с десятки на рейд-эдишнах, а это минимум четыре диска плюс
> правильный, нефейковый контроллер с бубочкой. Что тоже выливается в серьезные деньги.Спасибо, вы укрепили мое мнение, поэтому оставлю двухдисковое зеркало как есть, а этот третий положу на полочку как холодный резерв.
Или поставлю отдельным третьим, а на него буду рсинкать бекап с зеркала. Пушистому зверьку это определенно не понравится :)
