Pull to refresh

Хостинг FastVPS.ru или почему OpenVZ Это зло

Reading time 3 min
Views 20K
Пару лет назад мы с товарищем купили виртуальный сервер на двоих у компании FastVPS.ru. Сервер был отличный, и нас очень радовал низкой стоимостью и большим функционалом. Вдумайтесь, на сервере был поднят bind для всех наших доменов, 8 сайтов, пара баз данных для них, ftp сервер, postfix, trac и xml rpc сервер на питоне. И все это отлично работало пока… пока ребята из FastVPS не перешли на новую мега-технологию виртуализации OpenVZ.

Первое что нам пришлось сделать, это перенести все сайты и базы, настройки и прочее на новый сервак, потому как сквозного переноса сделать было нельзя. Честно сказать, в администрировании я не особо силен, поэтому на это ушла неделя. Пока вкурили HOW-TO и best practice по debian, пока забекапили все, в общем, пришлось повозиться со всем этим хозяйством.

И вот настал долгожданный момент Х, когда осталось лишь нажать Enter и снова увидеть родные до боли страницы сайтов. Сайты загрузились, и мы было уже откупорили непочатую пачку с соком (великий пост все таки). Однако нашу радость прервало странное сообщение в ssh консоли сервера:
Cannot allocate memory: fork: Unable to fork new process (которое не давало мне спать еще несколько недель). С этого момента никакие программы запустить не удавалось. И если бы не знание некоторых особенностей линукса, сервер совсем бы вышел из-под контроля.

Товарищ мой, который, надо сказать, с unix и linux давно знаком (и знал, что kill – это не процесс, и потому не выделяет памяти, а значит работает по-любому) с миной сильнейшего удивления на лице выговорил только одну фразу — «этого не может быть». Как оказалось впоследствии, на обычных, пусть даже очень древних, компьютерах системные ресурсы в linux не кончаются. Но тут был другой случай.

После часа непрерывного гугления в четыре руки и просмотра выдачи top, ps, free, apache2ctl fullstatus, а так же анализа логов, стало ясно — процессы апача (который раньше работал на 192 Мб RAM), сожрали всю память на новой системе с 400 Мб RAM (мы решили, что небольшой апгрейд не помешает). Сделали тюнинг потребления памяти mysql, тюнинг памяти и prefork apache2 и php, и, показалось, система задышала. Но какой же нормальный сайт обходится без атак со стороны юных длиннопальцых прыщавых хакеров. Apache2 начал регулярно падать, даже при очень низких параметрах префорка процессов (что удалось выяснить впоследствии, благодаря наблюдениям за сайтами в течении нескольких недель).
Параметры ДО переезда (192 Мб RAM):
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
< IfModule mpm_prefork_module >
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0

В конце концов, мы поняли, в чем дело. У новой системы не было swap файла. Обратились в саппорт, но поддержка свелась к «Поставьте nginx, вас атакуют. А swap раздел создать невозможно» (здесь под словом «атака» я имею ввиду подбор паролей, поиск уязвимостей, прощупывание сканнером и т.д. Но не DDoS атаку). Снова погуглили, и, действительно, OpenVZ не может эмулировать swap в системе linux. Но мало того, ресурсы OpenVZ распределяет динамически, а значит, память у нашего сервера в любой момент могут отъесть другие сервера, в результате чего apache2 падает без предупреждения. Мы вначале даже не поверили в это, увеличив тарифный план на хостинге до 600 Мб. Но это абсолютно никак не изменило ситуации, веб сервер как падал, так и падает на более или менее разумных параметрах префорка.
Параметры после (на которых не падает апач) 600 Мб RAM:
Timeout 90
KeepAlive On
MaxKeepAliveRequests 50
KeepAliveTimeout 3
< IfModule mpm_prefork_module >
StartServers 1
MinSpareServers 1
MaxSpareServers 1
MaxClients 2
MaxRequestsPerChild 300

Может мы действительно чего-то не понимаем, и надо было еще погемороиться с nginx? Но, мне кажется, что OpenVZ — это классический пример, когда продукт разрабатывается не для конечных пользователей, а для продавцов услуги. Так что виртуальные хостинги OpenVZ теперь никому не рекомендую, и ищу разумные заменители. Коллеги – буду рад, если Вы мне посоветуете, как больше не иметь проблем с хостингом.

UPD: В результате выяснилось, что на момент публикации поста прошло 12 часов, как ошибка была найдена и устранена. Поэтому сейчас даже без nginx на OpenVZ все работает нормально. К FastVPS.ru претензий больше не имею, ниже можно увидеть комментарий компании.
Tags:
Hubs:
+39
Comments 189
Comments Comments 189

Articles