Комментарии 77
Спасибо за интересные исследование.
Сейчас столкнулись с аналогичными проблемы, но после прочтения появились некоторые оригинальные выходы из нашей ситуации.
Сейчас столкнулись с аналогичными проблемы, но после прочтения появились некоторые оригинальные выходы из нашей ситуации.
Могу сказать одно — спасибо за хостинг. Хостинг который нравится мне и на который перевожу постепенно друзей.
У вас отличный хостинг и соппорт.
Хостинг отличный, а нет ли желания добавить поддержку хостинга неттопов? я вот очень сильно думаю в это сторону, но к агаве идти не хочется.
Cпасибо. Думали об этом, но боюсь, что неттопы будут нескоро. Мы сами-то стоим в дорогущем датацентре…
По неттопам, возможно, вам стоит обратиться в www.webdc.ru?
По неттопам, возможно, вам стоит обратиться в www.webdc.ru?
Ясно, у www.webdc.ru очень круто и для единичного случая думаю не выгодно им.
Хочется такой домашней и свойское размещение серверов, для небольших эксперементов, почти как вы.
Еще хотел спросит, думаю уйти из masterhost (по причине питона), насколько реально у вас получить 5 gb?
И что за странность в тарифе PARMA ,CALMA. Calma стоит дороже — и кол-во сайтови баз 2, PARAMA дешевле и кол-во сайтов и баз 10 O_o?
просто при цене 400 рублей я сейчас имею 5gb, 5 доменов, бд 10. или — это лучше в частном порядке? ^_^?
Хочется такой домашней и свойское размещение серверов, для небольших эксперементов, почти как вы.
Еще хотел спросит, думаю уйти из masterhost (по причине питона), насколько реально у вас получить 5 gb?
И что за странность в тарифе PARMA ,CALMA. Calma стоит дороже — и кол-во сайтови баз 2, PARAMA дешевле и кол-во сайтов и баз 10 O_o?
просто при цене 400 рублей я сейчас имею 5gb, 5 доменов, бд 10. или — это лучше в частном порядке? ^_^?
Хостинг python-а вообще более загрузный вариант по причине того, что все приложение висит в памяти постоянно и сразу готово к обработке.
Про дополнительное место напишите в support@diphost.ru
А по неттопам вот тут представитель webdc признается, что косвенно у них есть такое: habrahabr.ru/blogs/hosting/74283/#comment_2143112
Про дополнительное место напишите в support@diphost.ru
А по неттопам вот тут представитель webdc признается, что косвенно у них есть такое: habrahabr.ru/blogs/hosting/74283/#comment_2143112
С тарифами понял, те только CALMA имеет python?
ты спутал. ruweb.net :)
Ну тем более :)
Вернее тогда так: налетай, разберай!
Вернее тогда так: налетай, разберай!
А вы именно в России хотите? У нас в европе очень неслабый дедик на двоих вышел дешевле чем мы брали 2 VPS'ки у наших хостеров)
прочёл с удовольствием
Попробовать к вам перейти что ли с ХЦ.
Возьмите тест на 2 недели.
Никто не мешает две недели попробовать :) Кнопка прямо из панели. Обычно только эксперимент показывает ответ. В случае хостинга. Сервера сейчас набиты близко к «под завязку», эксперимент будет честным.
Спасибо за честный ответ про сервера. Просто обычно в тестовый период бывает всё замечательно, а потом начинаются проблемы (привет, Мажордомо!).
Буду пробовать.
Буду пробовать.
Это, кстати, проблема достаточно известная и хостерам. Мы даже думали (и сейчас такая мысль бегает) устанавливать какую-нибудь «считалку», чтобы она грузила сервер. Какие бы мы, или конкуренты, занудами не были — нам всем такая ситуация не интересна.
Это всё не избавляет на самом деле нас от проблем. И оборудование подгорает, и вышеописанный способ 100% ничего не защищает. Всякое бывает. Вплоть до «пропустили момент когда уже пора новый сервер». Хотя, теперь конечно легче :)
Это всё не избавляет на самом деле нас от проблем. И оборудование подгорает, и вышеописанный способ 100% ничего не защищает. Всякое бывает. Вплоть до «пропустили момент когда уже пора новый сервер». Хотя, теперь конечно легче :)
Все мы люди, все мы ошибаемся, что-то забываем. Это нормальное явление. Главное сообщать клиенту правду о проблемах и сроках их решения. А не пытаться водить за нос клиента.
Извините, накипело!
Просто с Мажордомо получилось очень плохая ситуация. Тестовый период всё работало хорошо, сайт открывался шустро и я был всем доволен. Оплатил 2 месяца хостинга.
Через 2 недели после оплаты, сайт стал еле-еле грузиться ака *.народ.ру в давние времена. На 3 день тормозов я написал в суппорт, по этому поводу. Суппорт ответил, что на их стороне всё хорошо, а проблемы с моим каналом. Ответил я уже с логом трэйсроута и объяснением, что сайт тормозит из-под любого провайдера Москвы (qwerty, corbina, стрим и неизвестный провайдер на работе). Суппорт посоветовал мне сменить мой тяжелый свежеустановленный webasyst shop-script на что-то более легкое. На этом мой разговор и все дела с Мажордомо закончились.
Извините, накипело!
Просто с Мажордомо получилось очень плохая ситуация. Тестовый период всё работало хорошо, сайт открывался шустро и я был всем доволен. Оплатил 2 месяца хостинга.
Через 2 недели после оплаты, сайт стал еле-еле грузиться ака *.народ.ру в давние времена. На 3 день тормозов я написал в суппорт, по этому поводу. Суппорт ответил, что на их стороне всё хорошо, а проблемы с моим каналом. Ответил я уже с логом трэйсроута и объяснением, что сайт тормозит из-под любого провайдера Москвы (qwerty, corbina, стрим и неизвестный провайдер на работе). Суппорт посоветовал мне сменить мой тяжелый свежеустановленный webasyst shop-script на что-то более легкое. На этом мой разговор и все дела с Мажордомо закончились.
O! У Вас webasyst? Нам было бы интересно узнать о его работе побольше без относительно результата.
Ага, с Мажордомо — все правда, сайт, на локалхосте открывается за 20 мс максимум, там на шареде уже пара секунд, а если у нему давно не обращались — и того дольше :( Обращения к БД есть — но там таблицы максимум из 100 записей и максимум 2-3 простых запроса к ним (сам же руками писал).
Вариант apache2+mod_fcgid <-> php remote fcgi не рассматривали?
Чисто интуитивно мне кажется, что тут можно сэкономить. Заодно и акселератор для php можно будет использовать.
Чисто интуитивно мне кажется, что тут можно сэкономить. Заодно и акселератор для php можно будет использовать.
apache2 worker, ага
И словить от него проблемы реализации тредов у php/apache :))))
какие такие проблемы, если php remote fcgi? :)
Ой, да. Но не важно :) Шило на мыло в нашем случае.
Ну, экономия будет только по памяти. И то — небольшая. Зато появляется дополнительная прослойка (fcgi)
В общем — шило на мыло имхо.
В общем — шило на мыло имхо.
Филипп, Вы-таки слезли с 4 ветки FreeBSD :)?
это круто!
Так много знакомо :-) Спасибо за статью, жду еще. Сложные проблемы и красивые решения, они всегда есть :-)
Казалось бы, причем тут майкрософт?
да. Интересно. Как вариант — попробовать выделять тем клиентам, у кого 1-2 сайт — апачей по количеству сайтов. А остальным — чуть больше. И перераспределять, если сайтов становится много. Или мало.
Проще. Клиенту выдаётся пакет — тариф. Тариф ассоциируется с аккаунтом на сервере. Аккаунт в достаточно ограниченных (для «кластеризации» в буквальном смысле этого слова) рамках от-до с разной тарификацией выделяет себе воркеры апачей и память. Такое понятие как количество сайтов становится бессмысленным. Всем хорошо. Все знают за что платят и что получают.
Филипп, не могли бы Вы ответить на вопросы:
1. Сколько в среднем клиентов (т.е. dedicated-апачей) у Вас на одной машине?
2. Каковы примерно характеристики машины (память, проц)?
1. Сколько в среднем клиентов (т.е. dedicated-апачей) у Вас на одной машине?
2. Каковы примерно характеристики машины (память, проц)?
1. Сейчас стоит теоретическая пороговая цифра 200. Но мы в виду отсутствия рук и времени сейчас забили на отслежку сильно ретивых (ну только тех кого порезали три недели назад). При этом, везде уже под 190 и есть запас. Пока его переходить не будем, но похоже — 250 выдержит. Надо учитывать, что у нас некрасивейшим образом там mysql на тех же серверах, с innodb.
2. P4 Celeron 960 RAM 4Gb перекочевал в Core2Quad RAM 8Gb. SATA в обоих. Я специально поэтому обратил внимание на то, что ситуация начала устаканиваться ещё на старом оборудовании и что процессор вообще практически тут роли не сыграл (хотя какую-то сыграл, конечно).
2. P4 Celeron 960 RAM 4Gb перекочевал в Core2Quad RAM 8Gb. SATA в обоих. Я специально поэтому обратил внимание на то, что ситуация начала устаканиваться ещё на старом оборудовании и что процессор вообще практически тут роли не сыграл (хотя какую-то сыграл, конечно).
я не знаю почему ты Pentium D называешь селероном :)
Ну почему сразу «некрасивейшим»… MySQL потребляет в основном диск, а Apache — CPU. Так что они не так уж и часто прересекаются по ресурсам… разве что по памяти, это да (но это лечится наращиванием памяти).
Я уже давно не тестировал, но 5 лет назад вынос mysql на отдельный сервер дал поразительный эффект. Во-первых, диск. PHP-же в основном. Да ещё и wordpress какой-нибудь — как начнёт вытягивать свои инклуды. Во-вторых, процессы, которые желают выполнится, причём, практически одновременно. Эффект примерно тот же, что заставил в cron вставлять по умолчанию случайный разброс по времени (с fbsd 4.10 что ли).
И отдельный вопрос, который хотелось бы обсудить. Если я правильно понял, то главный смысл в том, чтобы ограничить число процессов-воркеров для одного клиента. Иными словами, ограничить число одновременных коннектов к каждому сайту, чтобы запросы, для которых «не хватило воркера», вставали в очередь.
1. Не могли бы Вы чуть подробнее расписать, почему решение этой проблемы на уровне reverse proxy Вас не устраивает в теоретическом смысле? (Про то, что в nginx нет требуемой функциональности, и про то, что limit_conn не годится, я понимаю.)
2. Пробовали ли Вы на каждом из dedicated-апачей запускать peruser-, itk- или dklab-патчи, дабы сравнить, делает ли погоду нагрузка от лишнего fork() или нет? У меня есть некоторые подозрение, что fork() здесь как раз погоды не должен делать. (Вывод «Мы выиграли процессорное время за счёт отказа от постоянных vfork()» меня не совсем убедил, т.к. процессор мог выиграться не из-за отказа от fork(), а из-за того, что Вы ограничили число воркеров на особо «жрущего» клиента; раньше процессор «жрался» 20 воркерами такого клиента, а теперь их у него только 3, вот и выигрыш.)
А вообще, я бы с удовольствием с Вами как-нибудь выпил кофе, было бы интересно пообщаться.
1. Не могли бы Вы чуть подробнее расписать, почему решение этой проблемы на уровне reverse proxy Вас не устраивает в теоретическом смысле? (Про то, что в nginx нет требуемой функциональности, и про то, что limit_conn не годится, я понимаю.)
2. Пробовали ли Вы на каждом из dedicated-апачей запускать peruser-, itk- или dklab-патчи, дабы сравнить, делает ли погоду нагрузка от лишнего fork() или нет? У меня есть некоторые подозрение, что fork() здесь как раз погоды не должен делать. (Вывод «Мы выиграли процессорное время за счёт отказа от постоянных vfork()» меня не совсем убедил, т.к. процессор мог выиграться не из-за отказа от fork(), а из-за того, что Вы ограничили число воркеров на особо «жрущего» клиента; раньше процессор «жрался» 20 воркерами такого клиента, а теперь их у него только 3, вот и выигрыш.)
А вообще, я бы с удовольствием с Вами как-нибудь выпил кофе, было бы интересно пообщаться.
Погуглил немного по разным reverse-proxy. Похоже, ни один из них не умеет ставить запросы в очередь по превышению числа использования backend-ов. (Включая nginx, lighttpd, perlbal, даже squid, pound, LiteSpeed; и потом я смотрел, нет ли чего-то готового на twisted.)
Хабросообщество! Если ты знаешь инструмент, который позволяет ставить запросы браузеров в очередь, когда достигнут лимит на определенное число коннектов к backend-ам для одного виртуального хоста, напиши пожалуйста, сюда, что это за инструмент.
Хабросообщество! Если ты знаешь инструмент, который позволяет ставить запросы браузеров в очередь, когда достигнут лимит на определенное число коннектов к backend-ам для одного виртуального хоста, напиши пожалуйста, сюда, что это за инструмент.
А вот знаю такой инструмент, называется он mod_accell, производства рук Игоря Сысоева, автора nginx. Там есть возможность задать количество одновременных коннектов к бэкенду + количество коннектов, ожидающих освобождения соединения.
Разумеется то, что mod_access работает только под apache версии 1.3.хх и для каждого запроса требуется процесс является существенным ограичением для его использования, но при существующих обьемах памяти это уже не такая проблема, как это было лет 5 назад.
Во многих случаях связка nginx>>apache+mod_accell>>apache+mod_php является очень выигрышным вариантом.
Разумеется то, что mod_access работает только под apache версии 1.3.хх и для каждого запроса требуется процесс является существенным ограичением для его использования, но при существующих обьемах памяти это уже не такая проблема, как это было лет 5 назад.
Во многих случаях связка nginx>>apache+mod_accell>>apache+mod_php является очень выигрышным вариантом.
Гхм… чую бесовщину. Лишний шаг сразу. Неочевидный выигрыш от «каждому процесс» — собственно от этого и убегали…
В чем-то упрошение, в чем-то усложнение, тут образуются маленькие процессики (~2mb), которые все созданы заранее, а дальше все равно старый добрый тяжелый апач, пока что от него никуда не деться, но вот этот маленький процессик перед апачем позволяет релизовать ограничение на число коннектов на один бэкэнд без вышеприведенный схемы. Т.е. запускать тяжелый апач так, как все это умеют делать, но при этом не дать сьесть все ресурсы одному клиенту.
И сколько запустить таких «процессиков»?
Как сколько?! 1 к 1 по числу «тяжелых» процессов. Да, память в итоге используется больше, но есть возможность сэкономить на памяти родительских процессов, минус 1 для каждого клиента, что тоже мелочь, но приятно, возможно так на так и выйдет.
Такую схему, использовал и Сысоев, сейчас не помню для каких целей, можно порыться в его рассылке, года 2-3 назад было про это.
Такую схему, использовал и Сысоев, сейчас не помню для каких целей, можно порыться в его рассылке, года 2-3 назад было про это.
Ну каке вариант да. Правда, я не вижу особого смысла экономит ТАКОЕ количество памяти…
Без разницы. Честно говоря. Это же автомат делает. И апач внутри себя ведь тоже все эти виртуалхосты поддерживает.
Зато в схеме с двумя апачами нет необходимости держать процессы, т.е. занимать память для тех клиентов, к которым сейчас сообщений нет.
Как и в любом другом случае плюсов и минусов может быть больше, чем я в состоянии сейчас вот так вот заметить, но в целом такая схема вполне рабочая.
Как и в любом другом случае плюсов и минусов может быть больше, чем я в состоянии сейчас вот так вот заметить, но в целом такая схема вполне рабочая.
1. Не, понятно что работающая. Занятно. Спасибо, кстати :)
2. С памятью сложный вопрос. Это уже всё равно больше чем обычно, а посчитать сложно. Там же память не суммируется.
2. С памятью сложный вопрос. Это уже всё равно больше чем обычно, а посчитать сложно. Там же память не суммируется.
Меня с твоими схемами Щорс, больше всего беспокоит — как мне понять, тормозные у меня сайты или нет.
В старой схеме типа как у Петерхоста у меня приходили уведомления — типа 5% процессора занимаешь!!111 Нехороший чувак!
Нужна какая-то тулза показывать сколько воркеры мои стоят, а сколько пашут :) Ну и следующий шаг должен быть — варьировать воркеры взависимости от тарифного плана.
В старой схеме типа как у Петерхоста у меня приходили уведомления — типа 5% процессора занимаешь!!111 Нехороший чувак!
Нужна какая-то тулза показывать сколько воркеры мои стоят, а сколько пашут :) Ну и следующий шаг должен быть — варьировать воркеры взависимости от тарифного плана.
Да, всё именно так. Мы картинку для пояснения специально вставили. Я ещё тот Моисей ;)
1. Если бы оно было, то, возможно, это бы немножко оттянуло такое решение. Но я не зря тут же в тексте упомянул про конфигурацию. Да, я вижу в рассылке письмо и ровно такой ход мысли у меня был и я чуть сам не написал в начале осени такой же вопрос. В нашем варианте мы получили возможность регулировать Zend и APC — можем давать, можем не давать. Не зря был упомянут и питон — мы рискнули и в принципе вписались по внутреннему бизнес-плану в окупаемость резидентных процессов, да ещё и с совершенно очевидным эффектом. Был необоснованный страх. И запускать свои я до сих пор никому не дам (эти-то имеют не подконтрольное пользователю регулирование). Совершенно не факт, что регулирование на уровне прокси не будет по производительности равно или даже дороже чем лишнее соединение. Да, я думаю сейчас апачу ещё сокет ввернуть на приём, и вообще настанет счастье. Т.е. некая второстепенная сумма причин отвела нас от мысли с nginx. А, ну и проблема привилегий. Осенью 2003 года это был «рывок», когда я зажмурившись воткнул vfork(). Ни разу не пожалел, хотя это грязный хак и все вокруг морщили носы.
2. peruser/itk не пробовали. Коллеги, хоть и используют, cтрашно ругаются. Но (1) — смысла не было. Патч от dklab… keepalive лишает нас nginx… а он в свою очередь нас спасает. Согласен про весьма спорную оценку выигрыша cpu. Но… коллеги говорят, что даже отказ от getpwd() «на глаз» заметен на хостинге (делается перед vfork() для setcontext() (или как она там точно называется)). Да и не такой уж и апгрейд процессора, чтобы уж ужас что. И сразу после апгрейда, мы клиентов на серверах увеличили (утилизировали один из старых, раскидав клиентов). И проблемы нет теперь вообще — т.е. нет клиентов, которые говорят, что они что-то там теряют, и мониторинг ничего такого не показывает. Хотя, это может быть действительно следствие демпфирования нагрузки, по аналогии со случайной задержкой в cron. Мы послезавтра уже на ХостОбзор, а потом я могу банально протестировать по результату BSD-аккаунтинга/времени. Пусть даже ab на «hello world», для оценки потянет.
Мда, чувствую, накопилось причин заглянуть в Москву :) И с Бобуком уже год встречаюсь, и вообще давно не был :) Я думаю, это будет декабрь :)
1. Если бы оно было, то, возможно, это бы немножко оттянуло такое решение. Но я не зря тут же в тексте упомянул про конфигурацию. Да, я вижу в рассылке письмо и ровно такой ход мысли у меня был и я чуть сам не написал в начале осени такой же вопрос. В нашем варианте мы получили возможность регулировать Zend и APC — можем давать, можем не давать. Не зря был упомянут и питон — мы рискнули и в принципе вписались по внутреннему бизнес-плану в окупаемость резидентных процессов, да ещё и с совершенно очевидным эффектом. Был необоснованный страх. И запускать свои я до сих пор никому не дам (эти-то имеют не подконтрольное пользователю регулирование). Совершенно не факт, что регулирование на уровне прокси не будет по производительности равно или даже дороже чем лишнее соединение. Да, я думаю сейчас апачу ещё сокет ввернуть на приём, и вообще настанет счастье. Т.е. некая второстепенная сумма причин отвела нас от мысли с nginx. А, ну и проблема привилегий. Осенью 2003 года это был «рывок», когда я зажмурившись воткнул vfork(). Ни разу не пожалел, хотя это грязный хак и все вокруг морщили носы.
2. peruser/itk не пробовали. Коллеги, хоть и используют, cтрашно ругаются. Но (1) — смысла не было. Патч от dklab… keepalive лишает нас nginx… а он в свою очередь нас спасает. Согласен про весьма спорную оценку выигрыша cpu. Но… коллеги говорят, что даже отказ от getpwd() «на глаз» заметен на хостинге (делается перед vfork() для setcontext() (или как она там точно называется)). Да и не такой уж и апгрейд процессора, чтобы уж ужас что. И сразу после апгрейда, мы клиентов на серверах увеличили (утилизировали один из старых, раскидав клиентов). И проблемы нет теперь вообще — т.е. нет клиентов, которые говорят, что они что-то там теряют, и мониторинг ничего такого не показывает. Хотя, это может быть действительно следствие демпфирования нагрузки, по аналогии со случайной задержкой в cron. Мы послезавтра уже на ХостОбзор, а потом я могу банально протестировать по результату BSD-аккаунтинга/времени. Пусть даже ab на «hello world», для оценки потянет.
Мда, чувствую, накопилось причин заглянуть в Москву :) И с Бобуком уже год встречаюсь, и вообще давно не был :) Я думаю, это будет декабрь :)
Для полной картины в самом начале статьи дана ссылка на мой же доклад. 34 минуты :) Я, конечно, немного запинаюсь, размахиваю руками и дышу в микрофон, но общий смысл понятен.
Да, как раз в том докладе я говорил о невнятной ситуации с аккаунтингом даже с патчем Котерова. Естественно, сейчас он врёт совсем и требуется придумывать другие способы. Естественно, надо взвесить «за» и «против». Но как Вы видите из графиков и моих утверждениях, что сервера забиты чуть менее чем полностью согласно плана, проблема cpu на вообще не беспокоит. Если что-то будет «пожирать» его в заметных количествах — сработают все другие виды мониторинга.
У аккаунтинга есть и вторая проблема, которая вполне явно пробегает в моём докладе. Что я с ним буду делать? Для грубой оценки ситауции он помогает. Но и сейчас у меня появились инструменты для этой оценки. Но опыт показывает, что единственное что я могу сделать — это нажать красную кнопку «выключить». Ибо цифра не раскрывает суть проблемы. А хочется результат — или исправление, или апсейл, но апсейл опять же решающий проблему. В случае получения голой цифры, я ничего не могу сказать по проблеме и по путям её решения.
С новой же системой, у меня появились вполне понятные инструменты. Во-первых, это память. Если её не хватает — понятно, что нужно больше и я, и клиент будут понимать, что оплачивается и к какому вполне конкретному результату это приводит. Во-вторых, это количество воркеров. Если всё тормозит, понятно в каких местах искать, смотреть логи, отделять «тормоза» от нехватки воркеров от тормозов от каких-то задержек программ и итерационными методами приходить к решению. С одной стороны, я не имею цифры, с другой стороны, я всё разложил по полочкам.
Как-то так.
Да, как раз в том докладе я говорил о невнятной ситуации с аккаунтингом даже с патчем Котерова. Естественно, сейчас он врёт совсем и требуется придумывать другие способы. Естественно, надо взвесить «за» и «против». Но как Вы видите из графиков и моих утверждениях, что сервера забиты чуть менее чем полностью согласно плана, проблема cpu на вообще не беспокоит. Если что-то будет «пожирать» его в заметных количествах — сработают все другие виды мониторинга.
У аккаунтинга есть и вторая проблема, которая вполне явно пробегает в моём докладе. Что я с ним буду делать? Для грубой оценки ситауции он помогает. Но и сейчас у меня появились инструменты для этой оценки. Но опыт показывает, что единственное что я могу сделать — это нажать красную кнопку «выключить». Ибо цифра не раскрывает суть проблемы. А хочется результат — или исправление, или апсейл, но апсейл опять же решающий проблему. В случае получения голой цифры, я ничего не могу сказать по проблеме и по путям её решения.
С новой же системой, у меня появились вполне понятные инструменты. Во-первых, это память. Если её не хватает — понятно, что нужно больше и я, и клиент будут понимать, что оплачивается и к какому вполне конкретному результату это приводит. Во-вторых, это количество воркеров. Если всё тормозит, понятно в каких местах искать, смотреть логи, отделять «тормоза» от нехватки воркеров от тормозов от каких-то задержек программ и итерационными методами приходить к решению. С одной стороны, я не имею цифры, с другой стороны, я всё разложил по полочкам.
Как-то так.
Я или плохо читал, или одно из двух — но сколько было и сколько добавили в тазики памяти?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Борьба с нагрузкой на DiPHOST.Ru. Success story