Комментарии 189
гг
Я в какой-то момент понял, что экономить на этом себе дороже — и сижу на SDS-2 — что вполне хватает на пару десятков сайтов и кучу разных скриптиков, которые постоянно что-то делают — нагружая и БД и сам сервер.
Переплатить всего-то 20 евро и избавиться от головной боли раз и навсегда — это ли не счастье)
А лоу-лоу энд впс на опенвз надо тюнить очень и очень сильно — там уже не позаходишь в «соседние» ресурсы за добавками :)
Я в какой-то момент понял, что экономить на этом себе дороже — и сижу на SDS-2 — что вполне хватает на пару десятков сайтов и кучу разных скриптиков, которые постоянно что-то делают — нагружая и БД и сам сервер.
Переплатить всего-то 20 евро и избавиться от головной боли раз и навсегда — это ли не счастье)
А лоу-лоу энд впс на опенвз надо тюнить очень и очень сильно — там уже не позаходишь в «соседние» ресурсы за добавками :)
Дайте угадаю, вас перевели на x86_64? Быстро, решительно мигрируйте назад на х86. У фаствпс не было возможности выбрать х86 ОС, пока я не стал их клиентом и таки убедил перевести меня на х86, памяти не хватало катастрофически, после того, как они под меня подняли х86 сервер у них официально появились х86 версии ОС, хотя меня они поначалу настойчиво убеждали в переписке, что они дескать тестили и не нашли разницы (ага, я на минимальном тарифе 100мб даже php-fpm собрать не мог из-за нехватки памяти, при этом на другом хостинге собиралось на 64 метрах при х86 ОС).
Насчет nginx дело говорят, кстати, настоятельно рекомендую освоить.
Насчет nginx дело говорят, кстати, настоятельно рекомендую освоить.
НЛО прилетело и опубликовало эту надпись здесь
Да, 64 битная. А в чем разница, не оттестили OpenVZ еще под такие операционки?
разница в потреблении памяти 64 vs 32-битными приложениями.
На хабре даже был топик:
habrahabr.ru/blogs/server_side_optimization/75229/
там в комментариях много и подробно рассказано.
На хабре даже был топик:
habrahabr.ru/blogs/server_side_optimization/75229/
там в комментариях много и подробно рассказано.
А Вы не обращали внимания на версию ядра?
1. вы думаете, своп бы вас спас? ок, он улучшил бы ситуацию, но постоянное свопирование да еще на впс — это висяк всей системы.
2.да, в опенвз нет свопа, но зачем сразу устраивать истерику и кричать, что OpenVZ — мастдай? это попахивает юнешеским максимализмом.
У вас есть четкие ограничения по ресурсам — задача админа сервера сделать так, чтобы процессы приложений в них кладывались.
3.замена апача на жиксу — лучший вариант в данной ситуации, но это не 100% решение проблемы.
я не вижу вашей статы по уникам, хитам и тп, так что сложно делать вывод о нагрузке на ваш сайт. но если у вас достаточно серьезная посещаемость, то нет ничего удивительного, что вам не хватает 600МБ — это копейки для апача и тем более мускуля.
Вывод: ставьте жиксу и покупайте нормальный дедик.
2.да, в опенвз нет свопа, но зачем сразу устраивать истерику и кричать, что OpenVZ — мастдай? это попахивает юнешеским максимализмом.
У вас есть четкие ограничения по ресурсам — задача админа сервера сделать так, чтобы процессы приложений в них кладывались.
3.замена апача на жиксу — лучший вариант в данной ситуации, но это не 100% решение проблемы.
я не вижу вашей статы по уникам, хитам и тп, так что сложно делать вывод о нагрузке на ваш сайт. но если у вас достаточно серьезная посещаемость, то нет ничего удивительного, что вам не хватает 600МБ — это копейки для апача и тем более мускуля.
Вывод: ставьте жиксу и покупайте нормальный дедик.
Ну, если быть точным, там есть немного странный своп — который один на весь сервер :) Сути, правда, не меняет, плюсую ваш комментарий)
Вы в курсе, что память на openvz и на xen считается по-разному, причем сильно по-разному? И что абсолютно при тех же настройках программы под openvz могут жрать в несколько раз больше памяти?
ngnix в контексте openvz (а значит, многих-многих vps) лучше апача тем, что он однопоточный и поэтому не имеет тех проблем с памятью на openvz, что многопоточный апач. А не из-за того, что он супер-круче и всегда лучше менять апач на ngnix, как многие думают. На xen разницы существенной между ними нет, если статику не отдавать.
ngnix в контексте openvz (а значит, многих-многих vps) лучше апача тем, что он однопоточный и поэтому не имеет тех проблем с памятью на openvz, что многопоточный апач. А не из-за того, что он супер-круче и всегда лучше менять апач на ngnix, как многие думают. На xen разницы существенной между ними нет, если статику не отдавать.
про разный подсчет памяти вкурсе, но не видел, чтобы разница была в разы.
жиксу я посоветовал ставить именно по озвученным вами причинам.
жиксу я посоветовал ставить именно по озвученным вами причинам.
А OpenVZ — действительно мастдай. У него есть свои преимущества — говорят, i/o быстрее, еще что-то, но что касается памяти — если упираетесь на VPS в память, то очень вероятно, что виноват контейнер, а не софт.
Конкретный пример — процесс mysql (+innodb). Пусть он занимает 30м RES и 160m VIRT (сейчас глянул, у меня так). На xen он, соответственно, вычтет 30 из 400 мегабайт (+ будет иметься возможность скинуть все в своп при необходимости), на openVZ — вычтет 160 из 400 (+ будет падать с Unable to fork new process, если память кончится)
Конкретный пример — процесс mysql (+innodb). Пусть он занимает 30м RES и 160m VIRT (сейчас глянул, у меня так). На xen он, соответственно, вычтет 30 из 400 мегабайт (+ будет иметься возможность скинуть все в своп при необходимости), на openVZ — вычтет 160 из 400 (+ будет падать с Unable to fork new process, если память кончится)
Я говорю лишь за себя, что для меня, как клиента, такой продукт как OpenVZ не выгоден. Виртуализация, как государственная власть, хороша тогда, когда ты ее не замечаешь. И не заморачиваешься, а какая там у меня технология виртуализации…
Только 2 сайта имеют хоть какую-то посещаемость. На каждом примерно 40 хостов в сутки и 100 хитов. Итого имеем 80 хостов и 200 хитов.
Только 2 сайта имеют хоть какую-то посещаемость. На каждом примерно 40 хостов в сутки и 100 хитов. Итого имеем 80 хостов и 200 хитов.
80 хостов, 200 хитов, и вам не хватило 600 метров памяти? Вы меня, конечно, извините, но тут не только OpenVZ виновен. А вернее даже, совсем не он. У меня на 512мб апач вполне выдерживает без напряга пол тысячи — тысячу уников в сутки, не сильно напрягаясь. Вернее, совсем не напрягаясь, стабильно потребляя не больше 380мб памяти.
Вам все таки стоит уделить еще немного внимания конфигурации сервера, для таких показателей посещаемости вам и 192 метров «за глаза» хватит.
Вам все таки стоит уделить еще немного внимания конфигурации сервера, для таких показателей посещаемости вам и 192 метров «за глаза» хватит.
Согласен, о том и речь. 192 хватало, пока мы не першли на openvz. Все остальное там не менялось, конфиги и настройки все те же.
Посмотрите в сторону зарубежных openvz хостеров. Есть весьма отличные тарифы, с достаточным для OpenVZ количеством памяти. Например на самой дешевой vps от burst.net даже без дополнительной настройки 200 хитов в сутки проблемой не станут. Главное оставьте MaxRequestsPerChild 300, дабы не давать разъедаться «детям», уж больно они любят «откусывать» огромными кусками память, не освобождая ее (в частности, на OpenVZ именно такой эффект наблюдается, но если вовремя процессы будут убиваться, нехватки памяти не будет).
На 192mb связка Apache+Nginx у меня держала siege -c200
с какой скоростью оно отдавало страницы при этом?
На рендеринг уходило около 700ms (в вакууме 20-40ms), на отдачу страницы секунды 3-7.
Ну, это только получение страницы, насколько я понимаю, siege картинки не вытаскивает.
Ну, это только получение страницы, насколько я понимаю, siege картинки не вытаскивает.
а вы размер страницы проверяли?
siege -c200 и более мощные VDS не выдерживают зачастую — nginx начинает отдавать «bad gateway» — апач не справляется. Да и 200 коннектов к mysql базе…
siege -c200 и более мощные VDS не выдерживают зачастую — nginx начинает отдавать «bad gateway» — апач не справляется. Да и 200 коннектов к mysql базе…
Проверял, стандартный, 8-10 килобайт, без отказов.
Как-то так.
Ну, -c200, не так много, мне кажется.
У меня ноут Dell Inspiron 1525 с KDE, не падает при -c500
Как-то так.
Ну, -c200, не так много, мне кажется.
У меня ноут Dell Inspiron 1525 с KDE, не падает при -c500
Да при желании и на eeepc -с4000 sieg'eм можно главную страницу сайта на друпале выгружать — и siege не скажет, что сайт недоступен — ему nginx будет отдавать страничку же.
Нужно в это же время с другого PC (и с другого канала, желательно) пытаться попасть на сайт.
А вообще — тестировать нагрузку лучше с ключем -b — при -c200 -b вы получаете 200 обращений в секунду, а не 200 обращений в сферическом вакууме.
Можно использовать -dX, где X — задержка каждого бота. Просто без таких ключей — ваши -c200 — кони в сферическом вакууме, честно) статистика по количеству обращений в минуту может сильно колебаться.
Нужно в это же время с другого PC (и с другого канала, желательно) пытаться попасть на сайт.
А вообще — тестировать нагрузку лучше с ключем -b — при -c200 -b вы получаете 200 обращений в секунду, а не 200 обращений в сферическом вакууме.
Можно использовать -dX, где X — задержка каждого бота. Просто без таких ключей — ваши -c200 — кони в сферическом вакууме, честно) статистика по количеству обращений в минуту может сильно колебаться.
Насчёт коннектов к СУБД, там memcached был еще, короче по теме топика, 192 это нормальный объем.
Я не спорю, суть в том, что у ТС проблемы не с памятью.
Я не спорю, суть в том, что у ТС проблемы не с памятью.
Нет, это вполне конкретная проблема с памятью у OpenVZ.
Сам много раз сталкивался с картиной вида:
vdsXXX# reboot
reboot: cannot alocate memory.
Да, понятно, что настроить можно. Но всё-таки fastvps берет вполне ощутимые деньги. В том же ДЦ можно снизить цены в 2 раза и не прогореть.
Там кстати ещё и SATA диски роль играют.
Сам много раз сталкивался с картиной вида:
vdsXXX# reboot
reboot: cannot alocate memory.
Да, понятно, что настроить можно. Но всё-таки fastvps берет вполне ощутимые деньги. В том же ДЦ можно снизить цены в 2 раза и не прогореть.
Там кстати ещё и SATA диски роль играют.
Прошу прощения, где вы нашли стандартный размер страницы в 8-10к?
А какой движок?
У меня тройка процессов апача вот не справляется с главной страницей вордпресса — достаточно быстро начинается превышения таймаута
У меня тройка процессов апача вот не справляется с главной страницей вордпресса — достаточно быстро начинается превышения таймаута
Вы, как клиент, вообще не должны знать ничего про технологии виртуализации в целом и про OpenVZ в частности. Если Вам приходится задумываться над такими вещами — задумайтесь, не сменить ли хостинг-провайдера. Потому что правильная настройка OpenVZ — это его задача, и он не должен делать это вашей проблемой.
ЫЫЫыыы… если вы ничего не понимаете в администрировании серверов, то нечего заниматься не своим делом. А если понимаете, то должны понимать какие ограничения накладывает VPS и как с ними жить.
Администрирование серверов — тема очень обширная :)
Да, безусловно — лучше, если клиент имеет представление об OpenVZ, может посмотреть в UBC, соответственно настроить свою систему. Это облегчит жизнь и ему самому, и хостеру.
Но это условие не должно быть обязательным. Клиенту вообще должно быть без разницы, какую систему виртуализации использует хостер. И работать в VPS должен быть способен средний красноглазый юникс-админ, как бы это ни было противно. Обеспечить эту работу — задача хостера. За деньги клиента, хе-хе.
Да, безусловно — лучше, если клиент имеет представление об OpenVZ, может посмотреть в UBC, соответственно настроить свою систему. Это облегчит жизнь и ему самому, и хостеру.
Но это условие не должно быть обязательным. Клиенту вообще должно быть без разницы, какую систему виртуализации использует хостер. И работать в VPS должен быть способен средний красноглазый юникс-админ, как бы это ни было противно. Обеспечить эту работу — задача хостера. За деньги клиента, хе-хе.
Зачем вам кошки, если вы не умеете их готовить?
Имею VDS с обычный такой конфиг: nginx+MySQL+PHP. Имею с пяток движков. Банальные Joomla и WP. Все это крутиться на 200МБ, выдает 6000 хитов в сутки и не напрягает проц имея среднюю LA 0.2.
Не умеет администрировать и настраивать софт, не беритесь это делать. А уж коли взялись, то не кричите, что хостинг провайдер плохой в ситуации когда сами косячите. Юзал не один VDS и точно могу сказать, что по отношению цена-качество и общаей адекватности это сейчас лучше хостинг провайдер в этом сегменте рынка.
Имею VDS с обычный такой конфиг: nginx+MySQL+PHP. Имею с пяток движков. Банальные Joomla и WP. Все это крутиться на 200МБ, выдает 6000 хитов в сутки и не напрягает проц имея среднюю LA 0.2.
Не умеет администрировать и настраивать софт, не беритесь это делать. А уж коли взялись, то не кричите, что хостинг провайдер плохой в ситуации когда сами косячите. Юзал не один VDS и точно могу сказать, что по отношению цена-качество и общаей адекватности это сейчас лучше хостинг провайдер в этом сегменте рынка.
Для хостинга проектов пользуемся Linode. У них есть датацентр в Лондоне (перед покупкой стоит проверить пинги и скорость скачивания на http://www.linode.com/speedtest/). Для виртуализации используется Xen, с надежностью проблем быть не должно.
Также можно попробовать cloud серверы, например, Amazon EC2 или Rackspace Cloud.
Также можно попробовать cloud серверы, например, Amazon EC2 или Rackspace Cloud.
по поводу linode — поддерживаю, пинги низкие, надежность высокая и главное — не в россии.
в Лондоне ДЦ у них недавно появился, но до штатовских пинги тоже хорошие.
Единственный минус у линоды, что они не используют HVM, а потому на том что стоит у них нужны специальные ядра.
Попробуйте если у вас убунту в конце месяца сделать апгрейд на 10.04 )) обновите ядро и не сможете загрузится )) Я понимаю, что они предоставляют нужные ядра, но все же ))
Единственный минус у линоды, что они не используют HVM, а потому на том что стоит у них нужны специальные ядра.
Попробуйте если у вас убунту в конце месяца сделать апгрейд на 10.04 )) обновите ядро и не сможете загрузится )) Я понимаю, что они предоставляют нужные ядра, но все же ))
То, что нет свопа — это так, цветочки. Почитайте habrahabr.ru/blogs/hosting/53236/. Если есть возможность — переходите на xen/kvm.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А в чем собственно проблема: в отсутствии swap они меня предупредили заранее. О возможности временами выделение памяти больше, чем указано в тарифе я знал. Но гарантированные ресурсы не кто у тебя не отнимет
проблема в том, что ОпенВЗ считает _виртуальную_, а не физическую память.
А некоторые процессы выделяют виртуальную «про запас»
А некоторые процессы выделяют виртуальную «про запас»
Она считает выделеное адрессное пространство. Что логично
Это не логично, это бред полный, если понимать, что такое виртуальная память и как она обычно используется.
Зато цена раза в 2 ниже, чем на ХЕН
?! что за бред? считается именно выделенная память. Т.е. распределённая. Если у кого-то кривые руки и он резервирует память выделением — то не фиг такие программы исполоьзовать, для этого есть кошерные способы резервирования адресного пространства без выделения физической памяти.
В пишете: «считается именно выделенная память». Да, считается выделенная ВИРТУАЛЬНАЯ память. А не выделенная физическая память. Выделение виртуальной памяти — это и есть кошерный способ выделения адресного пространства без выделения физической памяти.
ВИРТУАЛЬНАЯ память может выделяться в любых разумных количествах. В том числе и под OpenVZ. Это всего лишь адресное пространство процесса и оно никак не связано с реальной памятью.
Итак небольшой ликбез.
Виды памяти:
1.) Физическая — самое что ни на есть настоящая память, требует адресного пространства. при нехватке может свопироваться на диск.
2) Виртуальная память. Суть есть адресное пространство не связанное с физической памятью. Предполагается что в будущем программа выделит физическую память под это адресное пространство. Попытка обратиться к такой памяти, как правило, вызывает исключительную ситуацию.
Чувствуете разницу? Виртуальная память это просто зарезервированный диапазон адресов и ничего больше. Её можно выделять сколько угодно в любых разумных пределах.
Умные программисты выделяют виртуальную память, а затем, когда понадобится выделить физическую память отображают её на уж зарезервированную виртуальную.
Глупые, ленивые и/или криворукие программисты сразу распределяют физическую память в странной надежде, что это не приведёт к её фактическому распределению до момента первого использования. Вот только это зависит от ядра, ОС и вообще бабушка на двое сказала. С тем же успех по некоторым экзотическими ядрами или платформами это приведёт к выделению всего запрошенного объёма и, в лучшем случае, к неимоверному росту свопа. По какой причине эти криворукие программисты так делаю — науке не известно, скорее всего потому, что не разобрались в работе менеджера памяти, а оно «работает — ну, и ладно». Именно потому эти программисты и называются криворукими. Более того даже с точи зрения здравого смысла логика «мне нужно 10 МБ памяти, а я выделю 512 МБ про запас, ну, подумаешь, в свопе полежит» весьма порочна и с таким подходом нужно идти на вижуал-басике писать.
Итак небольшой ликбез.
Виды памяти:
1.) Физическая — самое что ни на есть настоящая память, требует адресного пространства. при нехватке может свопироваться на диск.
2) Виртуальная память. Суть есть адресное пространство не связанное с физической памятью. Предполагается что в будущем программа выделит физическую память под это адресное пространство. Попытка обратиться к такой памяти, как правило, вызывает исключительную ситуацию.
Чувствуете разницу? Виртуальная память это просто зарезервированный диапазон адресов и ничего больше. Её можно выделять сколько угодно в любых разумных пределах.
Умные программисты выделяют виртуальную память, а затем, когда понадобится выделить физическую память отображают её на уж зарезервированную виртуальную.
Глупые, ленивые и/или криворукие программисты сразу распределяют физическую память в странной надежде, что это не приведёт к её фактическому распределению до момента первого использования. Вот только это зависит от ядра, ОС и вообще бабушка на двое сказала. С тем же успех по некоторым экзотическими ядрами или платформами это приведёт к выделению всего запрошенного объёма и, в лучшем случае, к неимоверному росту свопа. По какой причине эти криворукие программисты так делаю — науке не известно, скорее всего потому, что не разобрались в работе менеджера памяти, а оно «работает — ну, и ладно». Именно потому эти программисты и называются криворукими. Более того даже с точи зрения здравого смысла логика «мне нужно 10 МБ памяти, а я выделю 512 МБ про запас, ну, подумаешь, в свопе полежит» весьма порочна и с таким подходом нужно идти на вижуал-басике писать.
В том то и проблема что у OpenVZ есть настройка которая запрещает выделять виртуальную память. Простой пример. Java по умолчанию резервирует пространство в 256Мб (VIRT), но в настроенном таким образом OpenVZ контейнере она будет падать с воплями о том что памяти мало. Это делается хостерами чтобы гарантировать, что вы не сможете себе отхватить больше памяти чем реально вам должно быть доступно. Так-как указание того что я хочу 256Мб позволяет захватить ее в дальнейшем. Как результат я запуская жава сервер могу отхавать у всех память :)
Вообще-то это, как я уже говорил, проблема кривых программо-писателей. Виртуальное адресное пространство, оно во-первых, тоже не бесконечное. Во-вторых, никто нигде не обещает, что запрошенная память НЕ будет выделяться. Наоборот везде написано, что она БУДЕТ выделена и полагаться на какие-то недокументированные особенности конкретной системы — крайне плохая практика. И, наконец, если оно не работает под OpenVZ, то оно с большой долей вероятности не заработает или создаст проблемы на всякого рода сомнительный архитектурах и ядрах. Потом с удивлением узнаёшь, что на системе с 1ТБ ОЗУ не хватает памяти.
Причем не только выделяют память про запас. В xen тред не стоит ничего, в openvz с настройками ОС по умолчанию — это 10 мегабайт оперативной памяти просто в пустоту на каждый тред. Вывод: если программа использует треды, то она может жрать под openvz в разы больше памяти. А треды используют почти все.
Чочо? Откуда дровишки? Нить в linux обладает ровно такой же структурой как процесс и стоит практически столько же. Так что не надо тут ляля.
На каждый запущенный тред в виртуальной памяти выделяется место под стек. Сколько — зависит от *nix-а. По умолчанию в среднем линуксе — 10 мегабайт. Под openvz эти мегабайты учитываются как занятая память. Семки есть?
ulimit -s
У меня — 8 мегабайт :)
У меня — 8 мегабайт :)
Вообще-то стек в linux по умолчанию далеко не 8 мегабайт. Во вторых это же возникает и при использовании процесса так-как в linux треды и процессы практически равнозначны. Так что не надо ляля.
А сколько, по-вашему? запустите ulimit -s на современных дистрибутивах и сами убедитесь. И еще не понял, где вы увидели, чтобы я говорил, что с процессами все не так.
> А некоторые процессы выделяют виртуальную «про запас»
Так может надо бить разработчиков таких программ, а не хостеров? Я вообще не понимаю, как MySQL может выделить например 128 Мб и использовать из них только 40. А зачем выделять остальные 80? Чтоб врагам не достались?
Так может надо бить разработчиков таких программ, а не хостеров? Я вообще не понимаю, как MySQL может выделить например 128 Мб и использовать из них только 40. А зачем выделять остальные 80? Чтоб врагам не достались?
А может вы соблаговолите посмотреть что творится в /etc/mysql/my.cnf? У вас оптимальный конфиг с оптимизацией использования памяти?
Подозреваю, что не очень, так как MySQL может выполнять несколько тысяч запросов в секунду, что явно больше, чем требуется.
Кроме того, там так много параметров, что я пости ничего не поянл. Впрочем, у меня где-то есть статья с mysqlperformanceblog, там вроде разъясняется это.
Потому пока я (временно конечно) смирился с тем, что MySQL бездельничает и кушает 128 Мб памяти. Впрочем, интересную мысль увидел выше, про стек для каждого потока: ведь программам без рекурсии с запасом должно хватать нескольких десятков килобайт, значит тут есть, куда оптимизировать :)
Кроме того, там так много параметров, что я пости ничего не поянл. Впрочем, у меня где-то есть статья с mysqlperformanceblog, там вроде разъясняется это.
Потому пока я (временно конечно) смирился с тем, что MySQL бездельничает и кушает 128 Мб памяти. Впрочем, интересную мысль увидел выше, про стек для каждого потока: ведь программам без рекурсии с запасом должно хватать нескольких десятков килобайт, значит тут есть, куда оптимизировать :)
OpenVZ считает ПАМЯТЬ без разделения на виртуальную и физическую. Если вам провайдер выделил 512МБ + какой-то overhead ПАМЯТИ, то это именно та память, в рамках которой вы и будете крутиться. Так что оптимизируйте программы.
Я тоже нарвался на эти грабли, когда у разработчиков простейшие скрипты выбирали по 1ГБ (!) памяти «про запас», что приводило к занятию всей свободной и остановке контейнера. После пары пистонов те же скрипты съедали по 20МБ. Все, проблема была решена.
Я тоже нарвался на эти грабли, когда у разработчиков простейшие скрипты выбирали по 1ГБ (!) памяти «про запас», что приводило к занятию всей свободной и остановке контейнера. После пары пистонов те же скрипты съедали по 20МБ. Все, проблема была решена.
А на чем вы сидели раньше? Также, не стоит путать, что OpenVZ и Xen/KVM это совершенно разные технологии виртуализации, отличающиеся полностью. Да, у OpenVZ есть траблы с выделением памяти, но дешевле взять не 512, а гиг памяти, чем брать контейнер на Xen с 256 (обычно это так)
на виртуалки на KVM переходите. В личку могу подсказать где найти виртуалки в том же ДЦ, что и fastvps по разумной цене.
что то вроде 2.6 ггц, 1024 RAM, 80 GB HDD за 13 евро в месяц.
Случаем не zsh.su?
Где, если не секрет? :-)
Переходите на Hyper-V. Там все ресурсы жестко регламентированы и блокируются под каждую VDS.
В OpenVZ тоже ресурсы жестко регламентированы и блокируются под каждую VDS.
А вот здесь я не соглашусь — OpenVZ, Virtuozza это не совсем честная виртуализация с возможностью оверселлинга и эмуляцией ОС
Hyper-V, Xen, KVM, Vmware — же это «честная» полная виртуализация аппартной среды, где физические параметры сервера создаются при его запуске, и не меняются динамически. Грубо горя изначально отъедается кусок сервера в рамках которого вы можете ставить любую ОС и работать с ним как с «железкой».
Hyper-V, Xen, KVM, Vmware — же это «честная» полная виртуализация аппартной среды, где физические параметры сервера создаются при его запуске, и не меняются динамически. Грубо горя изначально отъедается кусок сервера в рамках которого вы можете ставить любую ОС и работать с ним как с «железкой».
Про Xen верно не до конца, т.к. он умеет и полную и паравиртуализацию делать.
И какую практическую разницу все это это несет в контексте исходной проблемы с оперативной памятью? OpenVZ вполне может гарантировать определенный объем оперативной памяти для VDS, и когда пишут 256метров памяти гарантированно, то это и значит, что 256 метров памяти гарантированно, хоть есть оверселлинг, хоть его нет.
ulimit -s 512
хм, был апач первый — стал апач второй…
1) поставьте nginx/lighttpd перед апачом
2) снижайте у апача количество воркеров, выключайте все ненужные модули
3) снижайте лимиты памяти для php
4) разберитесь уже наконец нормально с конфигом mysql
5) грохнуть bind стоит, посмотреть что еще лишнего назапускали…
сам использую у них ovz1, после приложения прямых рук ровно половина памяти свободна почти всегда, нагрузка есть только на проц ;)
1) поставьте nginx/lighttpd перед апачом
2) снижайте у апача количество воркеров, выключайте все ненужные модули
3) снижайте лимиты памяти для php
4) разберитесь уже наконец нормально с конфигом mysql
5) грохнуть bind стоит, посмотреть что еще лишнего назапускали…
сам использую у них ovz1, после приложения прямых рук ровно половина памяти свободна почти всегда, нагрузка есть только на проц ;)
1) пока не стали
2) сделали
3) сделали
4) сделали
5) bind нужен
2) сделали
3) сделали
4) сделали
5) bind нужен
1) очень даже зря не стали. Работы на 10 минут, а результат налицо.
Даже в голове не укладывается, как apache/tomcat/etc можно наружу без акселератора выставлять :)
А можно где-нить почитать про это? Моя нуб в этом деле, что-то исчерпывающее в сети есть?
можно далеко не ходить:
habrahabr.ru/blogs/nginx/
там много полезной информации.
Ну а также:
ru.wikipedia.org/wiki/Nginx
wiki.nginx.org/NginxRu
И конечно же сайт автора:
sysoev.ru/nginx/
habrahabr.ru/blogs/nginx/
там много полезной информации.
Ну а также:
ru.wikipedia.org/wiki/Nginx
wiki.nginx.org/NginxRu
И конечно же сайт автора:
sysoev.ru/nginx/
Вместо bind можно поставить nsd, он легче.
Сам ищу сейчас хороший VPS. Пока очень привлекает rackspacecloud.com благодаря системе оплаты где деньги берут за реально потраченные рессурсы и наличию своего CDN и все это за разумные деньги.
Кратко о найденных мной минусах rackspacecloud, может пригодится
1. Платный трафик.
2. При выключении сервера данные теряются. Бекапы платные.
3. При масштабировании виртуалко перезагружается, т.е. нет масштабирования «на лету».
4. Скудноватая панель, в том числе в плане данных о потраченных деньгах(списываются в конце месяца), видно, что дорабатывается по ходу дела.
5. Не самое лучшее время ответа.
Плюсы я думаю вы сами знаете.
1. Платный трафик.
2. При выключении сервера данные теряются. Бекапы платные.
3. При масштабировании виртуалко перезагружается, т.е. нет масштабирования «на лету».
4. Скудноватая панель, в том числе в плане данных о потраченных деньгах(списываются в конце месяца), видно, что дорабатывается по ходу дела.
5. Не самое лучшее время ответа.
Плюсы я думаю вы сами знаете.
StartServers 1
MinSpareServers 1
MaxSpareServers 1
MaxClients 2
что сделали сами поняли? :)
у вас одну картинку запросили пока сервер не вынул ее в сеть новый запрос не примет — конечно, у вас все повиснет, пир этом вы память совершенно не используете.
Эти параметры крутят что бы найти приемлемое соотношение cpu/память
MinSpareServers 1
MaxSpareServers 1
MaxClients 2
что сделали сами поняли? :)
у вас одну картинку запросили пока сервер не вынул ее в сеть новый запрос не примет — конечно, у вас все повиснет, пир этом вы память совершенно не используете.
Эти параметры крутят что бы найти приемлемое соотношение cpu/память
>> Но мало того, ресурсы OpenVZ распределяет динамически, а значит, память у нашего сервера в любой момент может отъедать другие сервера, в результате чего, apache2 падает без предупреждения.
это полное непонимание темы
это полное непонимание темы
Я понимаю. Но нам уже не до хорошего, можно конечно cron заставить сервак подымать после падения, но проще урезать все, чтобы не падало хотя бы.
вот поэтому для картинок с джаваскриптиками и нужен nginx, чтобы, если уж трогать апач, то по делу.
оффтоп:
а кто-то может сказать что-то про виртуализацию на VMware ESXi 4?
а кто-то может сказать что-то про виртуализацию на VMware ESXi 4?
Вообще кому интересно есть спец. предложение по Hyper-V 512 Мб всего за 100 р. для тех кто с *nix переходит.
Спасибо, но блин на несколько дней по раньше бы :) А то уже заказали у них два сервака для работы :)
Я сам на OpenVZ. Я правда, на других системах не сидел, но отсутсвие свапа мне кажется логичным — он слишком сильно будет тормозить систему.
По поводу апача — ограничьте число MaxClients, апач действительно может на каждого детя жрать по 4-10 Мб, согласен возмутительно, но давайте свои претензии направлять к его разработчикам?
Кроме того, могли бы перейти на использвоание потоков вместо форка процессов.
Ну и насчет ngnix вам правильно посоветовали. ПО моим наблюдениям, nginx не быстрее апача, но памяти ест при отдаче статики в разы меньше.
В общем, ваши претензии вызваны в основном неумением настраивать и администрировть сервер.
А вот теперь про реальные недостатки: злодеи-хостеры делают на одной машине кучу VPS'ок, из-за чего неактивно работающие сервера выпадают в своп. Жутко бесит, когда приходится ждать открытия страницы по 5-10 секунд, или соединения по фтп (если к серверу не было обращений некоторое время). Есть мысль поставить процесс в крон, который будет каждую минуту трясти основные сервисы и не давать им выпадать в своп, потому что каких-то других средств борьбы я не вижу.
По поводу апача — ограничьте число MaxClients, апач действительно может на каждого детя жрать по 4-10 Мб, согласен возмутительно, но давайте свои претензии направлять к его разработчикам?
Кроме того, могли бы перейти на использвоание потоков вместо форка процессов.
Ну и насчет ngnix вам правильно посоветовали. ПО моим наблюдениям, nginx не быстрее апача, но памяти ест при отдаче статики в разы меньше.
В общем, ваши претензии вызваны в основном неумением настраивать и администрировть сервер.
А вот теперь про реальные недостатки: злодеи-хостеры делают на одной машине кучу VPS'ок, из-за чего неактивно работающие сервера выпадают в своп. Жутко бесит, когда приходится ждать открытия страницы по 5-10 секунд, или соединения по фтп (если к серверу не было обращений некоторое время). Есть мысль поставить процесс в крон, который будет каждую минуту трясти основные сервисы и не давать им выпадать в своп, потому что каких-то других средств борьбы я не вижу.
Коллега, Вы предложили обратиться к разработчикам? В это нет смысла.
Я купил услугу, в ней написано 600 Мб памяти(что на проверку оказалось какой-то другой «динамической» памятью). У меня претензии к хостеру, разумеется, потому, что я получил не то что ожидал.
Я купил услугу, в ней написано 600 Мб памяти(что на проверку оказалось какой-то другой «динамической» памятью). У меня претензии к хостеру, разумеется, потому, что я получил не то что ожидал.
> Я купил услугу, в ней написано 600 Мб памяти(что на проверку оказалось какой-то другой «динамической» памятью)
Гм, ну это как раз и есть боле-менее «настоящая» память, так как если бы вы взяли Linux-систему без свопа, с 600 Мб паямти, примерно так же все бы и было, только что вместо cannot allocate memory система бы просто убивала лишние процессы.
Гм, ну это как раз и есть боле-менее «настоящая» память, так как если бы вы взяли Linux-систему без свопа, с 600 Мб паямти, примерно так же все бы и было, только что вместо cannot allocate memory система бы просто убивала лишние процессы.
Это даже лучше чем система с 600 МБ, т.к. обычно ядро и некоторые библиотеки разделяемые, что может весьма экономить память.
Вы забываете, что такую же нагрузку тянула предыдущая виртуализация с 192 Мб памяти.
А если ворошить прошлое, то я лично поддерживал сервер с 128Mb и свопом 400 — хитов было в 5 раз больше (apache 1.х, nginx еще не сущестовал) — а своп был почти не занят
А если ворошить прошлое, то я лично поддерживал сервер с 128Mb и свопом 400 — хитов было в 5 раз больше (apache 1.х, nginx еще не сущестовал) — а своп был почти не занят
Это неправильные хостеры и они делают неправильные VPS'ы! :) Не пользуйтесь такими!
поддержу многих высказавшихся — юзайте XEN. я достаточно давно сижу на свебе, VDS по тарифу VX-2, пока вполне доволен. разве что панели у них нет ровно никакой, а это временами напрягает, всё же рутинные действия можно и не из консоли гонять.
Как так kill — не процесс?
# which kill /bin/kill # file /bin/kill /bin/kill: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
Подскажите кто знает что лучше использовать в моем случае.
Есть выделенный сервер. Арендую его я и 4 моих знакомых. Итого 5 человек.
Задача — создать изолированное окружение для каждого.
На сервере крутятся очень разные проекты. примерно 20 сайтов на пхп. 10 из них на битриксе. проекты на Django. Большой нагрузки нет нигде.
Какую технологию лучше всего использовать? Задачи четко поделить ресурсы нет. Главное — безопасность. Пусть 1 виртуальная машина сожрет 90 % ресурсов, есть ей надо — ничего.
2х Ядерный АМД, 4 гб ОЗУ.
Есть выделенный сервер. Арендую его я и 4 моих знакомых. Итого 5 человек.
Задача — создать изолированное окружение для каждого.
На сервере крутятся очень разные проекты. примерно 20 сайтов на пхп. 10 из них на битриксе. проекты на Django. Большой нагрузки нет нигде.
Какую технологию лучше всего использовать? Задачи четко поделить ресурсы нет. Главное — безопасность. Пусть 1 виртуальная машина сожрет 90 % ресурсов, есть ей надо — ничего.
2х Ядерный АМД, 4 гб ОЗУ.
Я в шоке. Сколько людей не имеют преставления о виртуальной памяти…
Пообещал зостер 600 Мб? Так он и дал честные 600 Мб! Возьмите физический компутер с 600 МБ, откулючите у него своп и получите те же проблеммы.
И уж если браться за администрирования своими руками, то нужно всё же как-то подготовится и разобраться в вопросе — на реальной машине апач сожрал бы всю память, ушёл глубоко в своп, а система бы сказочно тормозила и непрерывно работал диском. А потом удивляются почему при двадцати пользователях сайт тормозит, а при сотне уже страшный хабраффект.
На 600 Мб можно настроить очень приличный сайт, который будет держать весьма солидную нагрузку в сотню пользователей (конечно, сильно зависит от движка).
Пообещал зостер 600 Мб? Так он и дал честные 600 Мб! Возьмите физический компутер с 600 МБ, откулючите у него своп и получите те же проблеммы.
И уж если браться за администрирования своими руками, то нужно всё же как-то подготовится и разобраться в вопросе — на реальной машине апач сожрал бы всю память, ушёл глубоко в своп, а система бы сказочно тормозила и непрерывно работал диском. А потом удивляются почему при двадцати пользователях сайт тормозит, а при сотне уже страшный хабраффект.
На 600 Мб можно настроить очень приличный сайт, который будет держать весьма солидную нагрузку в сотню пользователей (конечно, сильно зависит от движка).
Я тоже в шоке. Сколько людей думают, что имеют представление о виртуальной памяти…
Проблемы без свопа будут не те же. Поразмыслите о следующем факте:
malloc(больше600Мб) в одном случае сработает (т.е. вернёт какой-то ненулевой указатель), а в другом — нет.
Может быть, тогда вы поймёте, как работает виртуальная память ;)
Проблемы без свопа будут не те же. Поразмыслите о следующем факте:
malloc(больше600Мб) в одном случае сработает (т.е. вернёт какой-то ненулевой указатель), а в другом — нет.
Может быть, тогда вы поймёте, как работает виртуальная память ;)
malloc(больше600Мб) в одном случае означает кривые руки, а в другом — нет.
Расскажите об этом авторам Sun JVM. А также X Window, Firefox и KDE.
хм. В моей личной практике подобное ниразу не наблюдалось.
Отключите своп (для чистоты эксперимента) и посмотрите размер VIRT у Java-процессов, у Firefox и т.д.
И Вы туда же. И что нас говорит размер VIRT? Это общий объём выделенного процессу адресного пространства. Включая адресное пространство разделяемых библиотек и общих областей памяти, отображаемых на память файлов и т.п. В том числе и физическая память, конечно же. Но эта цифра ни коим боком не говорит о том, как была выделена память, «подтверждена» (commited) ли она и т.п.
С OpenVZ проблема ИМЕННО в том, что в нем ограничивается VIRT память, а не RES. Вам это, по-моему, уже раз 10 написали тут.
kmike вам уже написал, но подумайте на досуге, почему вот такой код:
выводит разные строки в Xen и в OpenVZ при одинаковом выделенном количестве памяти, меньшем 512Мб? И может быть, вы даже догадаетесь, как на на это влияет значение /proc/sys/vm/overcommit_memory, кто знает…
#include <sys/mman.h>
#include <stdio.h>
#define LEN (1024L*1024*512)
int main() {
char *data = mmap(NULL, LEN, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
if (data != MAP_FAILED) {
printf("suxxess %p\n", data);
munmap(data, LEN);
} else {
printf("fail\n");
}
return 0;
}
выводит разные строки в Xen и в OpenVZ при одинаковом выделенном количестве памяти, меньшем 512Мб? И может быть, вы даже догадаетесь, как на на это влияет значение /proc/sys/vm/overcommit_memory, кто знает…
Но вообще речь шла о том, как устроена память, а не о том, как писать программы. А кроме malloc есть ещё и mmap…
Похоже ваш сайтик опять упал, только из-за хабраэффекта на картинку! :)
Действительно, Вы правы. Надо искать правильных хостеров.
Да нет же, не в хостинге дело, вы как-то напарили с настройками. У меня под подобные же нагрузки, что вы где-то выше описывали у фаствпса взят план OVZ-4 и памяти свободно, как правило от 50 до 40%. И при этом я не гуру в настройках серваков. Попробуйте еще покопаться в настройках, может поможет.
Вам уже посоветовали не раз — ставьте nginx. Настроить — дел на 5 минут, установить и того меньше. А впску разгрузите сильно.
nginx + static_gzip + ngx_http_limit_zone_module. Ещё стоит sphinx прикрутить, несколько ограничить аппетиты апача.
Не пожалеете.
Не пожалеете.
В OVZ все просто
Вам продают больше свапа чем памяти, но продают под видом памяти
Вам продают больше свапа чем памяти, но продают под видом памяти
Всем коллегам большое спасибо. Я попробую подытожить все выше сказанное:
1. Не меняя хостера:
a. Надо попробовать Nginx – может сильно помочь в случае отдачи статики. Это первое что мы попробуем сделать.
b. Попросить хостера переключить на 32 битную ос. Боюсь без очередного всего контента не получится, но на худой конец – тоже вариант.
c. Купить дедик. Но это дорого, мы все-таки на vps пока останемся.
2. Поменять хостера:
a. KVM
b. Xen
c. cloud серверы
Еще раз спасибо, было конструктивно!
1. Не меняя хостера:
a. Надо попробовать Nginx – может сильно помочь в случае отдачи статики. Это первое что мы попробуем сделать.
b. Попросить хостера переключить на 32 битную ос. Боюсь без очередного всего контента не получится, но на худой конец – тоже вариант.
c. Купить дедик. Но это дорого, мы все-таки на vps пока останемся.
2. Поменять хостера:
a. KVM
b. Xen
c. cloud серверы
Еще раз спасибо, было конструктивно!
У меня буквально на этой неделе была такая проблема.
Сначала писало Cannot allocate memory: fork: Unable to fork new process. Увеличил тарифный план до 2 гб оперативки. Все равно не помогло.
Потом порылся в логах нашел что у Virtualmin какая то утечка памяти из за нехватки какого то PAM модуля. Установил, больше проблем с этим небыло
Потом началась другая беда, Cannot open: Disk quota exceeded.
Мучал саппорт примерно неделю. Сначала увеличили количество процессов с 300 до 600, не помогло. Оказалось что ошибка с квотой выдается изза лимита на количество файлов в системе. Очень долго штурмовал их, увеличили и щас все отличненько :)
Сначала писало Cannot allocate memory: fork: Unable to fork new process. Увеличил тарифный план до 2 гб оперативки. Все равно не помогло.
Потом порылся в логах нашел что у Virtualmin какая то утечка памяти из за нехватки какого то PAM модуля. Установил, больше проблем с этим небыло
Потом началась другая беда, Cannot open: Disk quota exceeded.
Мучал саппорт примерно неделю. Сначала увеличили количество процессов с 300 до 600, не помогло. Оказалось что ошибка с квотой выдается изза лимита на количество файлов в системе. Очень долго штурмовал их, увеличили и щас все отличненько :)
Зачем говорить, что openVZ — зло, если зло — урезанные лимиты и/или оверселлинг, позволяемый им?
Кстати, kill — это процесс :)
Как человек, работающий с Virtuozzo/OpenVZ с 2002 года, не увидел в статье ничего касательно проблем именно OpenVZ. Не очень понятно, почему автор считает злом именно систему?
Зло — это криво разработанный ХОСТЕРОМ тарифный план с нерационально расставленными лимитами. Но правильная расстановка лимитов — это отдельный и очень сложный вопрос, который зачастую приходится решать индивидуально для каждой задачи. А если админы хостера расставили цифры «от балды» — ну, тут каждый человек сам себе злобный Буратино.
Зло — это «техподдержка на уровне вас атакуют, поставьте nginx». Да, такое встречается, к сожалению. Но это, опять же, проблема хостера, а не OpenVZ.
Иными словами, всё «зло» OpenVZ — это её простота, позволившая почти каждой кухарке стать хостинг-провайдеров. Но по этому же принципу можно вести холиворы на тему «зло — это виндовс, потому что позволила работать на компьютере ничего не соображающим в них людям». Ну да, конечно — давайте вернёмся во времена FIDO. Это прогресс, его не остановить.
Зло — это криво разработанный ХОСТЕРОМ тарифный план с нерационально расставленными лимитами. Но правильная расстановка лимитов — это отдельный и очень сложный вопрос, который зачастую приходится решать индивидуально для каждой задачи. А если админы хостера расставили цифры «от балды» — ну, тут каждый человек сам себе злобный Буратино.
Зло — это «техподдержка на уровне вас атакуют, поставьте nginx». Да, такое встречается, к сожалению. Но это, опять же, проблема хостера, а не OpenVZ.
Иными словами, всё «зло» OpenVZ — это её простота, позволившая почти каждой кухарке стать хостинг-провайдеров. Но по этому же принципу можно вести холиворы на тему «зло — это виндовс, потому что позволила работать на компьютере ничего не соображающим в них людям». Ну да, конечно — давайте вернёмся во времена FIDO. Это прогресс, его не остановить.
> Первое что нам пришлось сделать, это перенести все сайты и базы,… пришлось повозиться со всем этим хозяйством
Ха-ха-ха, лохи.
>… С этого момента никакие программы запустить не удавалось…
И руки из ж… ы растут.
Ха-ха-ха, лохи.
>… С этого момента никакие программы запустить не удавалось…
И руки из ж… ы растут.
Типичная проблема людей, не знающих ничего про OpenVZ.
Во-первых, wiki.openvz.org/Resource_shortage — это если кратко. Во-вторых, wiki.openvz.org/UBC — это если подробно, там целая книжка, читать по порядку все ссылки. Прочитав и, главное, поняв это всё (ну или хотя бы основное), приходите опять и напишите, что вы заблуждались. В идеале, конечно, хорошо было бы, чтобы ваш хостер тоже всё это прочёл, понял, и помог вам. А он как бы не делает этого, оставляя вас один на один с вашей бедой (что можно было предположить заранее, когда он не стал помогать вам с миграцией).
Отдельно по поводу свопа. Своп есть, он общий для всех контейнеров, сконфигурирован на хост-системе. Странички памяти процессов пользователя вполне себе могут в этот своп попасть (ровно тем же образом, как и на обычной линукс-системе). На свежих ядрах можно даже посмотреть изнутри контейнера, сколько страниц его памяти упало в своп — это held параметра swappages в /proc/user_beancounters.
Надеюсь, я был конструктивен и то, что я написал выше, вам как-то поможет. Вы же, к сожалению, не были конструктивны. Нет бы спросить совета на openvz форуме — наверняка каждый первый смог бы вам подсказать смотреть в /proc/user_beancounters. Вместо этого вы, промучавшись несколько недель, пишете пост в стиле «скандалы! интриги! расследования!», в котором виноваты все, кроме вас… Это неконструктивно, хотя, может, полезно для популярности?
Во-первых, wiki.openvz.org/Resource_shortage — это если кратко. Во-вторых, wiki.openvz.org/UBC — это если подробно, там целая книжка, читать по порядку все ссылки. Прочитав и, главное, поняв это всё (ну или хотя бы основное), приходите опять и напишите, что вы заблуждались. В идеале, конечно, хорошо было бы, чтобы ваш хостер тоже всё это прочёл, понял, и помог вам. А он как бы не делает этого, оставляя вас один на один с вашей бедой (что можно было предположить заранее, когда он не стал помогать вам с миграцией).
Отдельно по поводу свопа. Своп есть, он общий для всех контейнеров, сконфигурирован на хост-системе. Странички памяти процессов пользователя вполне себе могут в этот своп попасть (ровно тем же образом, как и на обычной линукс-системе). На свежих ядрах можно даже посмотреть изнутри контейнера, сколько страниц его памяти упало в своп — это held параметра swappages в /proc/user_beancounters.
Надеюсь, я был конструктивен и то, что я написал выше, вам как-то поможет. Вы же, к сожалению, не были конструктивны. Нет бы спросить совета на openvz форуме — наверняка каждый первый смог бы вам подсказать смотреть в /proc/user_beancounters. Вместо этого вы, промучавшись несколько недель, пишете пост в стиле «скандалы! интриги! расследования!», в котором виноваты все, кроме вас… Это неконструктивно, хотя, может, полезно для популярности?
Я думаю, это все-таки должен был сделать хостер, а не клиент, который к тому же «в администрировании я не особо силен».
О! А скажите, моя идея сделать крон-процесс, который каждую минуту будет дергать основные сервисы, чтобы они не выпадали в своп — прокатит? И не разозлится ли хостер? А то меня бесит, что сайт открывается по 5-10 секунд, если к нему давно не было обращений.
Добрый вечер, уважаемый ТС и все хабробвчнае :)
Мы искренне благодарим Вас за хорошее пропесочивание и признаем, что проблема действительно имела место быть. Однако, она никак не связана с упоминаемым оверселлингом, мы ни в коем случае не допускаем превышения проданной памяти над реальной и стараемся держать резерв не менее 30% от общей памяти ноды.
Проблема, из-за которой были трудности у ТС нами обнаружена и локализована.
Вчера вечером была выполнена корректировка лимитов на ресурсы всех контейнеров на сервере OVZ29, в том числе и на Вашем виртуальном сервере.
Это было сделано в целях исправления проблемы, которая имела место в новой версии VDSManager.
Из-за этой проблемы контейнеры получали заниженное в 10 раз количество памяти ядра (kmemsize). Как мы заметили, у Вас очень много отказов по именно этому ресурсу, это могло
вызывать ошибки «cannot fork» и приводить к неработоспособности ПО.
Сейчас проблема полностью исправлена и работа ПО должна прийти в норму, мы приносим Вам свои извинения за доставленные неудобства. Надеемся, что дальнейшая работа Вашего VPS будет такой же беспроблемной, как и на XEN.
По поводу некорректного ответа поддержки на счет ддос-атаки, пожалуйста, скиньте на complain@fastvps.ru номер тикета, я смог найти только про подбор паролей, но это никак на работу VPS не влияло.
По поводу Вашей картинки, надо увеличить количество MaxClients и поставить Nginx.
Хабраэффект на Апаче выдержать не так легко, как хотелось бы.
С уважением, Гаврилин Павел
С уважением, Одинцов Павел
FastVPS LLC
Мы искренне благодарим Вас за хорошее пропесочивание и признаем, что проблема действительно имела место быть. Однако, она никак не связана с упоминаемым оверселлингом, мы ни в коем случае не допускаем превышения проданной памяти над реальной и стараемся держать резерв не менее 30% от общей памяти ноды.
Проблема, из-за которой были трудности у ТС нами обнаружена и локализована.
Вчера вечером была выполнена корректировка лимитов на ресурсы всех контейнеров на сервере OVZ29, в том числе и на Вашем виртуальном сервере.
Это было сделано в целях исправления проблемы, которая имела место в новой версии VDSManager.
Из-за этой проблемы контейнеры получали заниженное в 10 раз количество памяти ядра (kmemsize). Как мы заметили, у Вас очень много отказов по именно этому ресурсу, это могло
вызывать ошибки «cannot fork» и приводить к неработоспособности ПО.
Сейчас проблема полностью исправлена и работа ПО должна прийти в норму, мы приносим Вам свои извинения за доставленные неудобства. Надеемся, что дальнейшая работа Вашего VPS будет такой же беспроблемной, как и на XEN.
По поводу некорректного ответа поддержки на счет ддос-атаки, пожалуйста, скиньте на complain@fastvps.ru номер тикета, я смог найти только про подбор паролей, но это никак на работу VPS не влияло.
По поводу Вашей картинки, надо увеличить количество MaxClients и поставить Nginx.
Хабраэффект на Апаче выдержать не так легко, как хотелось бы.
С уважением, Гаврилин Павел
С уважением, Одинцов Павел
FastVPS LLC
OpenVZ — это дрянь, конечно. Но у FastVPS саппорт адекватный и отзывчивый, да и саму виртуализацию они настроили максимально. А вот когда OpenVZ соединяется с долбоебизмом и безалаберностью саппорта (FirstVDS.ru) — это уже совсем печаль.
>Но какой же нормальный сайт обходится без атак со стороны юных длиннопальцых >прыщавых хакеров. Apache2 начал регулярно падать…
Какие спецы, такие у них и хакеры.
Какие спецы, такие у них и хакеры.
Господи, да хватит же уже использовать апач на VDS, ну сколько можно? T__T
Это типичный FUD. Апач прекрасно можно использовать на любом недорогом xen/kvm VDS и он будет занимать мало памяти и держать ту же нагрузку при настройках по умолчанию. А вот на openvz с апачем будет облом из-за особенностей openvz. Думаю, что это даже именно из-за openvz апач заслужил славу тормозного и прожорливого монстра.
К сожалению он и является тормозным прожорливым монстром, даже при отключении всех ненужных модулей и ковыряния в параметрах чилдренов.
Достаточно просто сравнить использование памяти и ресурсов процессора со всякими другими вебсерверами, чтобы это понять.
Мое мнение — от апача надо отказываться во всех случаях, кроме тех, где он жизненно необходим и переход на другой веб-сервер выльется в громадный гемор.
Достаточно просто сравнить использование памяти и ресурсов процессора со всякими другими вебсерверами, чтобы это понять.
Мое мнение — от апача надо отказываться во всех случаях, кроме тех, где он жизненно необходим и переход на другой веб-сервер выльется в громадный гемор.
У меня апач почему-то ест 6 мегабайт памяти на то, чтобы запуститься и потом по паре сотен килобайт на каждый процесс джанги. Процесс джанги занимает в среднем 20 мегабайт. Пара сотен килобайт по сравнению с 20 мегабайт — это такая мелочь. Что нужно делать, чтобы упереться в апачевскую скорость выдачи результатов — ума не приложу. Основное время тратится, понятное дело, на обработку запросов — логику, реализованную на скриптовом языке, и на обращение к базе, а не на работу апача. Он мог бы работать в 10 раз медленнее без каких-либо негативных эффектов.
Я просто не понимаю, что я могу выиграть, перейдя на другой сервер. Максимум — это 6 мегабайт оперативной памяти (если ngnix питается святым духом и не занимает оперативки совсем) и маленькую долю мс от времени загрузки страницы (ну пусть вместо 1000 запр/сек будет 100000 запр/сек, это ускорение загрузки страницы на 0.00099с, чего абсолютно никто не заметит).
Это все без каких-то хитрых настроек, перекомпиляций и тд. Понятное дело, mod_php отключен. И еще, понятное дело, с отдачей статики разговор другой.
Я просто не понимаю, что я могу выиграть, перейдя на другой сервер. Максимум — это 6 мегабайт оперативной памяти (если ngnix питается святым духом и не занимает оперативки совсем) и маленькую долю мс от времени загрузки страницы (ну пусть вместо 1000 запр/сек будет 100000 запр/сек, это ускорение загрузки страницы на 0.00099с, чего абсолютно никто не заметит).
Это все без каких-то хитрых настроек, перекомпиляций и тд. Понятное дело, mod_php отключен. И еще, понятное дело, с отдачей статики разговор другой.
Удивительно. Можно увидеть версию апача и httpd.conf?
Апач установлен через aptitude install apache2 в debian lenny. Основной httpd.conf, как сейчас понял, вообще не трогал. Из модулей подключил mod_wsgi. Удостоверился, что mod_php и тд не подключены. Настройки mpm_worker и mpm_prefork нас тут не интересуют совсем, т.к. они не влияют ни на что в моем случае. Апач подгружает mod_wsgi, а mod_wsgi дальше сам порождает процессы с джангой. Это самый такой стандартный способ запуска питоньих приложений. Да, слабость моей позиции — про статику речь сейчас не идет.
прежде чем хостеру переходить на openvz нада было долго и вдумчива курить мануалы, первое сообщение в начале топика… очень распространенная проблема в опенвз, нада настраивать ресурсы под конкретный чилд или хотя бы сделать больше чем дефолтные. openvz не маст дай, но рулить им хлопотней чем XEN, например
Попробуйте уменьшить размер стека который система выделяет на процесс. В OpenVZ учитывается выделенная но не используемая память (в часности изза того что нет свопа)
Тут есть обсуждение www.webhostingtalk.com/showthread.php?t=855618
Тут есть обсуждение www.webhostingtalk.com/showthread.php?t=855618
хы) похоже на вольный перевод моей статьи) по мотивам, по крайней мере. И название то же)
кривые руки detected!
просблема в том что кое-кто не увеличил параметр kmemsize, о чем хостеры часто забывают. а так, ваш апаче спокойно бы выжил на 256 метрах. даже без свапа, которого в системах виртуализации просто нет.
просблема в том что кое-кто не увеличил параметр kmemsize, о чем хостеры часто забывают. а так, ваш апаче спокойно бы выжил на 256 метрах. даже без свапа, которого в системах виртуализации просто нет.
Выход в FreeBSD Jail?
Кстати о fastvps:
Если собираетесь у них хоститься, то учтите, что манибек у них ограниченный:
«Средства можно вернуть только за полные неиспользованные месяцы предоплаченной услуги.»
Соответственно, деньги за 29 дней вернуть не сможете.
Если собираетесь у них хоститься, то учтите, что манибек у них ограниченный:
«Средства можно вернуть только за полные неиспользованные месяцы предоплаченной услуги.»
Соответственно, деньги за 29 дней вернуть не сможете.
а кто сходу скажет хостера как fastvps только с Xen'ом и примерно такими же ценами, кроме России?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хостинг FastVPS.ru или почему OpenVZ Это зло