http://habrahabr.ru/rss/post/75386/ ru editor@habrahabr.ru habrahabr.ru Sat, 11 Feb 2012 13:30:54 GMT http://habrahabr.ru/ http://habrahabr.ru/i/logo.gif http://habrahabr.ru/blogs/hosting/75386/#comment_3561580 http://habrahabr.ru/blogs/hosting/75386/#comment_3561580 Если только на заметку взять кому либо.]]> Mon, 10 Jan 2011 21:25:20 GMT icCE http://habrahabr.ru/blogs/hosting/75386/#comment_3560143 http://habrahabr.ru/blogs/hosting/75386/#comment_3560143 Mon, 10 Jan 2011 12:32:13 GMT grcool http://habrahabr.ru/blogs/hosting/75386/#comment_2508906 http://habrahabr.ru/blogs/hosting/75386/#comment_2508906 Sat, 13 Feb 2010 17:33:03 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2508893 http://habrahabr.ru/blogs/hosting/75386/#comment_2508893 Sat, 13 Feb 2010 17:30:12 GMT coolcold http://habrahabr.ru/blogs/hosting/75386/#comment_2205851 http://habrahabr.ru/blogs/hosting/75386/#comment_2205851 Sat, 21 Nov 2009 21:14:01 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2196635 http://habrahabr.ru/blogs/hosting/75386/#comment_2196635
В старой схеме типа как у Петерхоста у меня приходили уведомления — типа 5% процессора занимаешь!!111 Нехороший чувак!

Нужна какая-то тулза показывать сколько воркеры мои стоят, а сколько пашут :) Ну и следующий шаг должен быть — варьировать воркеры взависимости от тарифного плана.]]> Thu, 19 Nov 2009 13:28:44 GMT leotsarev http://habrahabr.ru/blogs/hosting/75386/#comment_2195705 http://habrahabr.ru/blogs/hosting/75386/#comment_2195705 2. С памятью сложный вопрос. Это уже всё равно больше чем обычно, а посчитать сложно. Там же память не суммируется.]]> Thu, 19 Nov 2009 09:50:38 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2195128 http://habrahabr.ru/blogs/hosting/75386/#comment_2195128
Как и в любом другом случае плюсов и минусов может быть больше, чем я в состоянии сейчас вот так вот заметить, но в целом такая схема вполне рабочая.]]> Thu, 19 Nov 2009 06:33:30 GMT infobox http://habrahabr.ru/blogs/hosting/75386/#comment_2194250 http://habrahabr.ru/blogs/hosting/75386/#comment_2194250 Wed, 18 Nov 2009 19:57:42 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2194176 http://habrahabr.ru/blogs/hosting/75386/#comment_2194176 Wed, 18 Nov 2009 19:29:55 GMT ibKpoxa http://habrahabr.ru/blogs/hosting/75386/#comment_2193417 http://habrahabr.ru/blogs/hosting/75386/#comment_2193417 Wed, 18 Nov 2009 16:04:10 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2193395 http://habrahabr.ru/blogs/hosting/75386/#comment_2193395 Такую схему, использовал и Сысоев, сейчас не помню для каких целей, можно порыться в его рассылке, года 2-3 назад было про это.]]> Wed, 18 Nov 2009 15:59:47 GMT infobox http://habrahabr.ru/blogs/hosting/75386/#comment_2192928 http://habrahabr.ru/blogs/hosting/75386/#comment_2192928 Wed, 18 Nov 2009 14:16:30 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2192912 http://habrahabr.ru/blogs/hosting/75386/#comment_2192912 Wed, 18 Nov 2009 14:13:04 GMT infobox http://habrahabr.ru/blogs/hosting/75386/#comment_2192853 http://habrahabr.ru/blogs/hosting/75386/#comment_2192853 Wed, 18 Nov 2009 14:02:29 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2192833 http://habrahabr.ru/blogs/hosting/75386/#comment_2192833 Разумеется то, что mod_access работает только под apache версии 1.3.хх и для каждого запроса требуется процесс является существенным ограичением для его использования, но при существующих обьемах памяти это уже не такая проблема, как это было лет 5 назад.
Во многих случаях связка nginx>>apache+mod_accell>>apache+mod_php является очень выигрышным вариантом.
]]> Wed, 18 Nov 2009 13:57:00 GMT infobox http://habrahabr.ru/blogs/hosting/75386/#comment_2187604 http://habrahabr.ru/blogs/hosting/75386/#comment_2187604 Tue, 17 Nov 2009 02:23:18 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2187594 http://habrahabr.ru/blogs/hosting/75386/#comment_2187594 Tue, 17 Nov 2009 02:09:17 GMT solisted http://habrahabr.ru/blogs/hosting/75386/#comment_2187591 http://habrahabr.ru/blogs/hosting/75386/#comment_2187591
Да, как раз в том докладе я говорил о невнятной ситуации с аккаунтингом даже с патчем Котерова. Естественно, сейчас он врёт совсем и требуется придумывать другие способы. Естественно, надо взвесить «за» и «против». Но как Вы видите из графиков и моих утверждениях, что сервера забиты чуть менее чем полностью согласно плана, проблема cpu на вообще не беспокоит. Если что-то будет «пожирать» его в заметных количествах — сработают все другие виды мониторинга.

У аккаунтинга есть и вторая проблема, которая вполне явно пробегает в моём докладе. Что я с ним буду делать? Для грубой оценки ситауции он помогает. Но и сейчас у меня появились инструменты для этой оценки. Но опыт показывает, что единственное что я могу сделать — это нажать красную кнопку «выключить». Ибо цифра не раскрывает суть проблемы. А хочется результат — или исправление, или апсейл, но апсейл опять же решающий проблему. В случае получения голой цифры, я ничего не могу сказать по проблеме и по путям её решения.

С новой же системой, у меня появились вполне понятные инструменты. Во-первых, это память. Если её не хватает — понятно, что нужно больше и я, и клиент будут понимать, что оплачивается и к какому вполне конкретному результату это приводит. Во-вторых, это количество воркеров. Если всё тормозит, понятно в каких местах искать, смотреть логи, отделять «тормоза» от нехватки воркеров от тормозов от каких-то задержек программ и итерационными методами приходить к решению. С одной стороны, я не имею цифры, с другой стороны, я всё разложил по полочкам.

Как-то так.]]> Tue, 17 Nov 2009 01:54:50 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2187581 http://habrahabr.ru/blogs/hosting/75386/#comment_2187581
Если да, мне кажется, при такой схеме работы, сбор данных аккаунтинга будет немного затруднен, т.к. они могут не совсем актуально отображать реальное положение вещей у того или иного пользователя. При использовании патча Дмитрия появляется один вкусный плюс — процесс апача пользователя завершается после обработки реквеста и мы моментально имеем в аккаунтинге процессорное время, затраченное на обработку этого реквеста (ядро собирает эти данные и дописывает их в файл аккаунтинга только при завершении процесса). Таким образом, собирая данные раз в N минут мы смело можем утверждать, что пользователь употребил столько-то процессорного времени в такой-то промежуток реального времени.

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

P.S. Поправьте, если я где-то ошибаюсь.]]> Tue, 17 Nov 2009 01:33:40 GMT solisted http://habrahabr.ru/blogs/hosting/75386/#comment_2187418 http://habrahabr.ru/blogs/hosting/75386/#comment_2187418 getpwuid() конечно, для setusercontext()
]]> Mon, 16 Nov 2009 23:02:22 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2187357 http://habrahabr.ru/blogs/hosting/75386/#comment_2187357 Mon, 16 Nov 2009 22:26:28 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2187355 http://habrahabr.ru/blogs/hosting/75386/#comment_2187355 Mon, 16 Nov 2009 22:23:55 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2187354 http://habrahabr.ru/blogs/hosting/75386/#comment_2187354 1. Если бы оно было, то, возможно, это бы немножко оттянуло такое решение. Но я не зря тут же в тексте упомянул про конфигурацию. Да, я вижу в рассылке письмо и ровно такой ход мысли у меня был и я чуть сам не написал в начале осени такой же вопрос. В нашем варианте мы получили возможность регулировать Zend и APC — можем давать, можем не давать. Не зря был упомянут и питон — мы рискнули и в принципе вписались по внутреннему бизнес-плану в окупаемость резидентных процессов, да ещё и с совершенно очевидным эффектом. Был необоснованный страх. И запускать свои я до сих пор никому не дам (эти-то имеют не подконтрольное пользователю регулирование). Совершенно не факт, что регулирование на уровне прокси не будет по производительности равно или даже дороже чем лишнее соединение. Да, я думаю сейчас апачу ещё сокет ввернуть на приём, и вообще настанет счастье. Т.е. некая второстепенная сумма причин отвела нас от мысли с nginx. А, ну и проблема привилегий. Осенью 2003 года это был «рывок», когда я зажмурившись воткнул vfork(). Ни разу не пожалел, хотя это грязный хак и все вокруг морщили носы.
2. peruser/itk не пробовали. Коллеги, хоть и используют, cтрашно ругаются. Но (1) — смысла не было. Патч от dklab… keepalive лишает нас nginx… а он в свою очередь нас спасает. Согласен про весьма спорную оценку выигрыша cpu. Но… коллеги говорят, что даже отказ от getpwd() «на глаз» заметен на хостинге (делается перед vfork() для setcontext() (или как она там точно называется)). Да и не такой уж и апгрейд процессора, чтобы уж ужас что. И сразу после апгрейда, мы клиентов на серверах увеличили (утилизировали один из старых, раскидав клиентов). И проблемы нет теперь вообще — т.е. нет клиентов, которые говорят, что они что-то там теряют, и мониторинг ничего такого не показывает. Хотя, это может быть действительно следствие демпфирования нагрузки, по аналогии со случайной задержкой в cron. Мы послезавтра уже на ХостОбзор, а потом я могу банально протестировать по результату BSD-аккаунтинга/времени. Пусть даже ab на «hello world», для оценки потянет.

Мда, чувствую, накопилось причин заглянуть в Москву :) И с Бобуком уже год встречаюсь, и вообще давно не был :) Я думаю, это будет декабрь :) ]]> Mon, 16 Nov 2009 22:23:23 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2187337 http://habrahabr.ru/blogs/hosting/75386/#comment_2187337 Mon, 16 Nov 2009 22:14:18 GMT DmitryKoterov http://habrahabr.ru/blogs/hosting/75386/#comment_2187330 http://habrahabr.ru/blogs/hosting/75386/#comment_2187330
Хабросообщество! Если ты знаешь инструмент, который позволяет ставить запросы браузеров в очередь, когда достигнут лимит на определенное число коннектов к backend-ам для одного виртуального хоста, напиши пожалуйста, сюда, что это за инструмент.]]> Mon, 16 Nov 2009 22:12:21 GMT DmitryKoterov http://habrahabr.ru/blogs/hosting/75386/#comment_2187298 http://habrahabr.ru/blogs/hosting/75386/#comment_2187298 Mon, 16 Nov 2009 21:57:00 GMT adnull http://habrahabr.ru/blogs/hosting/75386/#comment_2187282 http://habrahabr.ru/blogs/hosting/75386/#comment_2187282 2. P4 Celeron 960 RAM 4Gb перекочевал в Core2Quad RAM 8Gb. SATA в обоих. Я специально поэтому обратил внимание на то, что ситуация начала устаканиваться ещё на старом оборудовании и что процессор вообще практически тут роли не сыграл (хотя какую-то сыграл, конечно).]]> Mon, 16 Nov 2009 21:50:41 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2187271 http://habrahabr.ru/blogs/hosting/75386/#comment_2187271 Mon, 16 Nov 2009 21:45:42 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2186693 http://habrahabr.ru/blogs/hosting/75386/#comment_2186693
1. Не могли бы Вы чуть подробнее расписать, почему решение этой проблемы на уровне reverse proxy Вас не устраивает в теоретическом смысле? (Про то, что в nginx нет требуемой функциональности, и про то, что limit_conn не годится, я понимаю.)

2. Пробовали ли Вы на каждом из dedicated-апачей запускать peruser-, itk- или dklab-патчи, дабы сравнить, делает ли погоду нагрузка от лишнего fork() или нет? У меня есть некоторые подозрение, что fork() здесь как раз погоды не должен делать. (Вывод «Мы выиграли процессорное время за счёт отказа от постоянных vfork()» меня не совсем убедил, т.к. процессор мог выиграться не из-за отказа от fork(), а из-за того, что Вы ограничили число воркеров на особо «жрущего» клиента; раньше процессор «жрался» 20 воркерами такого клиента, а теперь их у него только 3, вот и выигрыш.)

А вообще, я бы с удовольствием с Вами как-нибудь выпил кофе, было бы интересно пообщаться.]]> Mon, 16 Nov 2009 18:41:49 GMT DmitryKoterov http://habrahabr.ru/blogs/hosting/75386/#comment_2186656 http://habrahabr.ru/blogs/hosting/75386/#comment_2186656 1. Сколько в среднем клиентов (т.е. dedicated-апачей) у Вас на одной машине?
2. Каковы примерно характеристики машины (память, проц)?]]> Mon, 16 Nov 2009 18:30:46 GMT DmitryKoterov http://habrahabr.ru/blogs/hosting/75386/#comment_2186538 http://habrahabr.ru/blogs/hosting/75386/#comment_2186538 Mon, 16 Nov 2009 17:35:25 GMT sunnybear http://habrahabr.ru/blogs/hosting/75386/#comment_2186490 http://habrahabr.ru/blogs/hosting/75386/#comment_2186490 Mon, 16 Nov 2009 17:21:37 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2186487 http://habrahabr.ru/blogs/hosting/75386/#comment_2186487 ]]> Mon, 16 Nov 2009 17:20:36 GMT piroman http://habrahabr.ru/blogs/hosting/75386/#comment_2186340 http://habrahabr.ru/blogs/hosting/75386/#comment_2186340 Mon, 16 Nov 2009 16:19:40 GMT ESQUELETO http://habrahabr.ru/blogs/hosting/75386/#comment_2186286 http://habrahabr.ru/blogs/hosting/75386/#comment_2186286 Вернее тогда так: налетай, разберай!]]> Mon, 16 Nov 2009 16:02:23 GMT adnull http://habrahabr.ru/blogs/hosting/75386/#comment_2186283 http://habrahabr.ru/blogs/hosting/75386/#comment_2186283 Mon, 16 Nov 2009 16:00:39 GMT piroman http://habrahabr.ru/blogs/hosting/75386/#comment_2186282 http://habrahabr.ru/blogs/hosting/75386/#comment_2186282 Mon, 16 Nov 2009 15:59:47 GMT egorinsk http://habrahabr.ru/blogs/hosting/75386/#comment_2186277 http://habrahabr.ru/blogs/hosting/75386/#comment_2186277 Mon, 16 Nov 2009 15:57:15 GMT schors http://habrahabr.ru/blogs/hosting/75386/#comment_2186233 http://habrahabr.ru/blogs/hosting/75386/#comment_2186233 Mon, 16 Nov 2009 15:45:23 GMT mihajlo