я хотел бы ещё раз затронуть тему — веб сервера и хостинга для ls, а так же посещаемости и нагрузки, которая она создаёт.

Привет, я хотел бы ещё раз затронуть тему — веб сервера и хостинга для ls, а так же посещаемости и нагрузки, которую она создаёт.

Прелюдия
Начал своё знакомство с ls с версии 0.51, развернул некое коммьюнити, на shared хостинге. Были конечно кое какие проблемы у самого хостера, которые решались в общей сложности 2 недели… И вот появились первые заинтересованные пользователи, начали приглашать новых заинтересованных, лед тронулся… Спустя какое то время, начали приходить письма от самого хостера, мол вы используете процессорного времени больше чем положено 460 — 500 минут вместо 60, посему пришлось сделать коммьюнити закрытым — количество процессорного времени сократилось.

Спустя какое то время я обновил версию до 1.01, скачал и докупил несколько плагинов, шаблон, начал улучшать внешний вид сообщества и вот теперь пришёл к тому, что нужно переезжать с этого хостинга на что нибудь помощнее, да так, чтобы при этом открыть его для не зарегистрированных пользователей при этом оставив возможность регистрации только по инвайтам. Вся беда заключается в том, как бы это сказать: тематика сообщества довольно популярная и создавалось сообщество с перспективой как раз на большой онлайн, и теперь мне трудно представить сколько примерно уникальных человек будет посещать ресурс ежедневно, на одном из недавно реинкорнировавшимся, конкурентном ресурсе зарегистрировано 6 тыс пользователей, причем это тупо форум. И вот теперь я стал перед вопросом хостинга для такого сайта и выбором веб сервера для него.

Начало
Начал с веб сервера, опыта у меня в этом плане маловато, но надо же с чего то начинать, пробовал разные:

-голый apache как выяснилось не подходит из за того, что много кушает ресурсов.
-Nginx+Apache+PHP5, ставил по этому гайду доброволец сис админ проведя тестовую нагрузку siege'ом выявил что на моем коряво настроенном веб сервере с лайвстритом, на облаке от клодо с 14 ядрами + 256 — 768 оперативки мягко говоря одновременно могут находится 45 пользователей, но при 50 он уже падает. Как же так, совсем не то что я ожидал, хотя руки корявые у меня, скорее всего. Вообще получилось так, что конфигурацию некоторых параметров nginx, мне подсказал сис адми, а вот апач при этом имел дефолтные настройки из гайда, видимо поэтому и ложился так быстро. Вообще было что то наподобии worker process 8 + use epoll; +timer_resolution 100ms; А в апаче я изменил только в prefork MPM MaxClients 24 поменял на 1500.

-Nginx+PHP-FastCGI+Memcached — к сожалению работаю в ночное время и застать добровольца сис админа я уже не смог, зато после установки данного сервера на тот же clodo, хоть и с немного другими параметрами, я решил установить xcache, после этого перестал работать как memcache, так и xcache, даже после aptitude purge [], сайт стал открываться только после изменения кэша на файловый, что как я понял не приемлемо в моём случае, т.к. дисковые операции медленнее чем операции в оперативной памяти.

Что меня потом сподвигло прочитать вот такую вот заметку, то есть тут веб сервер как я понимаю выносит самые тяжелые фаилы для работы в оперативке, но мне не совсем понятно как быть с бэкапами, как своевременно делать на таком сервере бекап, чтобы если вдруг упадет питание ребутнувшись с помощью какого то костыля поднимался сервер с данными последнего бекапа?

Помимо всего этого, разумеется, стоит вопрос о выборе хостинга, я так понимаю для начала мне нужно смотреть в сторону vds, а дальше в сторону ds. Облако я сразу отсекаю, потому что если начнут досить то будет как в этом комментарии, то есть сгорят все мои кровные. С другой стороны как написано в комментарии пониже можно изначально взять DS, но при этом платить стабильно одну и ту же сумму 49 евро и не бояться, что ресурсы сгорят как на облаке, кстати видел почти аналогичный DS сервер за те же деньги в hetznet'e. В принципе 49 евро не так уж и много, тем более можно продавать ресурсы своим друзьям/знакомым/etc и тогда платить нужно будет гораздо меньше, единственный подводный камень который я обнаружил, это то что нужно в 1 месяц заплатить двойную сумму, 1 месяц + физ.установка сервера, уже думал брать его но распланировав бюджет для меня это была непреодолимая неожиданность и я воздержался от покупки в этом месяце, т.к. уже распланировал деньги.

Но в принципе это и хорошо, потому что для меня всё ещё загадка, какой же всё таки веб сервер лучше использовать под высоко посещаемый сайт на LS, вот поэтому и прошу вас поделится своим ценным опытом в данном направлении.

P.S. Просьба не разводить холиваров из этого топика.

58 комментариев

avatar
На средненьком VPS вертится небольшой сайтик с посещаловкой ~1к/сутки. Стоит nginx+apache+memcached. Проблем не наблюдалось. Про большие нагрузки сказать немогу, так как не испытывали.

Что меня потом сподвигло прочитать вот такую вот заметку, то есть тут веб сервер как я понимаю выносит самые тяжелые фаилы для работы в оперативке, но мне не совсем понятно как быть с бэкапами, как своевременно делать на таком сервере бекап, чтобы если вдруг упадет питание ребутнувшись с помощью какого то костыля поднимался сервер с данными последнего бекапа?
В RAM сохранять все немного опасно. Упадет питание — упадет все что было в энергозависимой памяти. Будете заново поднимать все в память, но только старую версию, ту которая еще была на HDD (еще раз напоминаю, все то что было в RAM пропадет). Конечно можно извращаться: пробовать по крону делать нагрузку на сервер синхронизацию данных каждых n минут между RAM и HDD. Написать на баше скрипт который бы загонял необходимые данные с HDD в RAM (ну и что там еще нужно чтобы делал) и ставим в автозагрузку. Также надо не забыть, что RAM не такая уж резиновая объемная как HDD.

Мне кажется более рационально будет просто разместить все в RAID (на SSD) + вынести статику (картинки, видео, и т.п.) на поддомен (на отдельный сервер, рядом в стойку). Еще можно поставить рядом в стойку отдельный сервер и вынести туда БД.
avatar
Согласен, очень опасная затея, ведь можно лишится сразу всего, если не позаботился о бэкапе. Кстати если кому интересно погуглите tmpfs, это и есть специальная фаиловая система из оперативки, на которую будет выносится тяжелый контент или «БД?». То, что оперативка не резиновая, знаю не понаслышке, домашний динозавр оснащен всего 1gb этого добра, но дело в том, что на ds который меня заинтересовал — 32 gb DDR3, при этом, как я понимаю можно жестко ограничить объем данного tmpfs диска/раздела, например 5 gb, вот все и не дает покоя мне данная вещь) хотя, конечно, мне ещё рано до этого ведь я даже nginx толком настроить не могу.
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
avatar
Спасибо, как раз там я и хотел брать, с hetzner много заморочек с кредитными картами как я понял.
комментарий был удален
avatar
1. ИМХО — какой смысл кешировать в память при 256 — 768 оперативки, как у вас написано в статье? Вот у вас и падает при 50 пользователях.
2. Зачем пользовать nginx+apache? Ради .htaccess, который лень переписать на конфиг nginx'а?
avatar
Нет, спорил с другом по поводу nginx vs apache, он был за апач) Поэтому я решил начать с симбиоза этих двух серверов, ну и несомненный плюс в этом есть, безопасность, т.к. апач доступен только с локалхоста. А rewrite как я понял в nginx делается вот так.
avatar
несомненный плюс в этом есть, безопасность, т.к. апач доступен только с локалхоста

Нет такого плюса. В конфигурации nginx + php-fpm последний доступен вообще только через сокеты. Ни одного преимущества в данной конкретной задаче апач не даст. С другой стороны, избавление от апача не ускорит сервер в разы, но определенный прирост будет. Мануал если что — livestreet.ru/blog/dev_documentation/10626.html
avatar
Уважаемый censured, вы бы вместо абстрактных разглагольствований, написали бы реальный цифры, сколько ходит народу, сколько вы ожидаете. Вы вообще в курсе что worker process 8 для nginx надо делать только на 8 ядерных системмах7 MPM MaxClients 1500 это вообще жесть, такое ощущение, что у вас от 100к человек и более в сутки народу.
avatar
Уважаемый darkden, если бы вы прочли топик то вы бы должны были уловить, что worker process 8 был сделан на 14 ядерном clodo scale сервере, вдабавок я написал примерные цифры. В данный момент зарегистрировано ~ 200 человек.
avatar
14 не бывает, скажем так вам выделили 14, но в облаке правила другие и настройки там другие, а 200 это вообще ни о чем, их выдержит даже атом с гигом на борту, при это нагрузки даже не будет.
avatar
Ясно, спасибо за «полезную» информацию)
avatar
Продолжайте в том же духе… Вы не можете поставить задачу и настроить тоже, вместо сарказма лучше почитали про бы 14 ядерное безобразие:
habrahabr.ru/company/clodo/blog/107445/
В комментариях там есть все.
А это на сладенькое:
netstat -nap|grep EST|wc -l
1748

cat /etc/apache2/apache2.conf| grep MaxC
# MaxClients: maximum number of simultaneous client connections
    MaxClients          150

load average: 1.25, 1.29, 1.43

Это при 70к зарегистрированных и среднем онлайне 350, так что ваши 200 вообще семечки, там любая самая простецкая настройка подойдет.
avatar
Вы видимо что то не так поняли, я не собираюсь использовать облачный хостинг как эталон, я использовал его лишь для теста настройки веб сервера. 200 'это на данный момент в закрытом режиме, я конечно не хочу зарекаться, что сразу навалит 100 тыс пользователей, но я мягко говоря не хотел бы попасть в ситуацию когда навалит скажем 500 и всё будет лагать, повторюсь тематика сообщества довольно популярная, поэтому я хочу сразу всё настроить так, чтобы не было потом стыдно. Соответственно проведя аудит хостинг компаний я сделал вывод, что для моих нужд подойдет DS, может я конечно ошибаюсь, но сравнив цену и ресурсы vds и ds я сделал выбор в пользу ds.
avatar
Не опозоритесь. Это же облако, увеличите конфигурацию на время, пока не найдете нормального сисадмина, который настроит все.

Посещаемость моего ресурса — до 500 в день. Сайт расположен на сервере clodo, оперативы 514мб-4г. ОС и сервак ставили специалисты clodo, я дальше никак не настраивал, ибо я ничего не шарю в этом. В итоге, все прекрасно работает пока и по деньгам выходит рублей 350-400 в мес.
avatar
Вы как будто не читаете, что я пишу. Я не хочу использовать облачный хостинг, для данного сообщества по нескольким причинам

Могу попасть под дос от конкурирующего ресурса, и деньги просто сгорят, будто это были живые посетители и хостингу будет абсолютно пофигу, он сошлется на то, что это были живые посетители и т.д. в наше время задосить не так уж и сложно, даже те же 300 мнимых пользователей которых я буквально на минуту натравил на сайт конкурента создал заметные задержки в работе сайта.

количество нужных ресурсов, можно взять почти за те же самые деньги на DS, да тут экономии никакой не будет конечно, но что мешает использовать неиспользуемые ресурсы DS для других сайтов, например сделать сайты друзьям, знакомым, etc…

Вы конечно извините, но я создал топик, чтобы узнать мнение людей у которых уже был подобный опыт ведения обслуживания и настройки веб сервера для LS под высокую нагрузку, а то, что вы сделали vds в клодо с ихними «настройками» ещё не говорит о том, что они идеальны, скорее всего вы просто создали vds ls с голым апачем, у них там такой есть, я даже пробовал поставить 2 таких в целях поинтересоваться чего же они там накрутили, но сколько не делал, процесс установки vds оканчивался ошибкой.
avatar
Вы вообще в курсе что worker process 8 для nginx надо делать только на 8 ядерных системмах7
Вы вообще в курсе, что worker process можно сделать каким угодно и количество ядер — рекомендация.
Например для 8 ядерного 8 воркеров — рекомендация, а 12 например — оптимум
avatar
Да в курсе и даже абсолютно в курсе ибо там есть еще куча разные факторов, например как число винтов, объем памяти и еще куча других мелочей, а про 12 вокеров на 8 на ядерных системах, аргументы в студию.

2censured: 300 мнимых пользователей это вообще ни о чем, тот же атом с гигом на борту их сможет вполне потянуть, нагрузка здесь уже будет заметна и эффект от их появления в первый раз будет, а потом после подстройки опять будет ни о чем… При ошибках в создании vds надо было в саппорт писать…
avatar
про 12 вокеров на 8 на ядерных системах, аргументы в студию.
это здравый смысл, воркер не обязательно может что-либо обрабатывать. может просто висеть с нулевой загрузкой cpu. теоретически вы можете упереться в max connection.
avatar
Вау!!! Хаба, хаба… 5 балов. Своеобразных у Вас здравый смысл… По нему получается, что ресурсы, которых обычно не хватает или впритык, надо отдать на ненужный воркер, который не грузит cpu, хотя это и не возможно шедулер это не позволит, но 100% занимает память которую лучше отдать на кеш, плюс Вы видимо вообще ни разу документацию nginx не видели, так вот открою Вам «страшную» правду, один вокер способен обработать 10к соединений, а 8 соответственно 80к.
avatar
вы наркоман.
бросайте это дело и идите читать про незакрытые коннекты с кипалайвом.
avatar
О Я смотрю Вы диагнозы ставить умеете, доктор а шо Вы здесь делаете, ведь Ваши знания в данной области курам на смех…
avatar
мне даже спорить с вами лень.
дам подсказки:
* сколько простаивающий воркер жрет памяти?
* сколько воркер с worker_connection = max отбирает процессорного времени с учетом того, что все коннекты для этого воркера находятся в состоянии keep-alive
* сюда же, сколько воркеров остаются рабочими и сколько при этом они потребяют процессорного времени?
* сколько нужно оперативной памяти для работы mysql при 80к соединениях и будет ли играть роль прирост памяти для кэша в размере одного простаивающего воркера?
avatar
Конечно спорить лень, Вы уже проиграли… Никаких цифр, только голословные предположения.
* в теории 2.5 мб, в реальности от 8 до 56 мб, при наших 256 мб предоплаченых это важно
* это как сюда относится, вокер ест ресурс в любом случаи, а так как мы говорит про облако, то это лишние деньги на ветер
* это тут причем
* я смотрю вы про кеширование даже не слышали, это вам надо теории читать, для начала, плюс 80к написано чтобы показать что упереться в max connection, даже с 1 вокером сложно.

Берем среднее цифру размера вокера за 25 мб, то лишних 4 вокера займут 100мб памяти, которые вы позиционируете как созданные Вашим здравым смыслом. Очевидно, что они съедают половину доступной по умолчанию памяти и заставят владельца платить за воздух.

Вы вообще понимаете, что такое keep-alive?
Так же в цифрах и примера расскажите при чем здесь «незакрытые коннекты с кипалайвом.»
avatar
* в теории 2.5 мб, в реальности от 8 до 56 мб, при наших 256 мб предоплаченых это важно
видимо у меня особенный воркер раз он жрет 1600к памяти
ps v 21169                                                                                  PID TTY STAT TIME MAJFL TRS DRS RSS %MEM СOMMAND                                                                                                
21169 ? S   0:25  1 637 5706 1600 0.1 nginx: worker process                                                                                


ajax-соединения с keep-alive убьют ваш воркер и вы потеряете процессорное время. ах нуда, каждый пользователь может создавать от 2 коннектов, так что 80к вы можете смело делить пополам. причем 80к — это ваши галюцинации, поскольку ядро линукса без тюнинга и патчей не позволит создать больше 65к соединений

можете дальше продолжать настраивать сервера строго по документации и мифическим 80к
avatar
Это у Вас он мало нагруженный и свежезапущеный:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
www-data 25704  0.0  0.1  49592 11056 ?        S<   Jul15  48:45 nginx: worker process
www-data 25705  0.0  0.1  48524 10008 ?        S<   Jul15  35:42 nginx: worker process
www-data 25706  0.0  0.1  47572  8824 ?        S<   Jul15  20:40 nginx: worker process
www-data 25707  0.0  0.1  46644  8128 ?        S<   Jul15  16:40 nginx: worker process


USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
www-data  9714  0.3  0.0 169336 30240 ?        S<   Aug27  70:41 nginx: worker process
www-data  9715  0.3  0.1 195888 56928 ?        S<   Aug27  64:04 nginx: worker process
www-data  9716  0.2  0.1 192692 53564 ?        S<   Aug27  53:17 nginx: worker process
www-data  9717  0.2  0.1 181832 42408 ?        S<   Aug27  51:12 nginx: worker process
www-data  9718  0.3  0.0 171100 32012 ?        S<   Aug27  62:42 nginx: worker process
www-data  9719  0.2  0.0 169680 30292 ?        S<   Aug27  51:21 nginx: worker process
www-data  9720  0.3  0.0 170004 30824 ?        S<   Aug27  60:52 nginx: worker process
www-data  9721  0.2  0.1 187416 48244 ?        S<   Aug27  56:04 nginx: worker process
www-data  9722  0.0  0.0 142496  5492 ?        S    Aug27   4:33 nginx: cache manager process

Считайте…

65к соединений? Снова 5 балов, проблема в том у веб сервера соединения входящие, а не исходящие, проблема с исходящими в том что портов всего 65к и 1к из них заняты(рассказать под что?) и можно использовать только 64к. А теперь подкреплю свои слова ссылочкой, там без всяких патчей ядра на сервер принимаю 1 миллион соединений. Обратите внимание в комментариях есть вопрос А сколько можно принять в себя соединений? и ответ на него.

ЗЫ: А теперь возьмем Вашу теорию про 10к/2 соединений, а у Вас есть проекты на которых в один момент народу столько, что они сделают 5к соединений в один момент? Знаю что нет, а число вокерв делают равным числу процессор, для лучшей отзывчивости веб сервера пользователю.
avatar
Ещё раз убедился в том, что вы не внимательно читаете сообщения.
avatar
Вам виднее… Удачи Вам, с таким подходом, Вам ее надой будет целый состав и огромную тележку.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.