VPS на OpenVZ тормозит, сайт недоступен. Ubuntu + LAMP. (много скринов)?

Question

[Ильяс М]

Имеется VPS на OpenVZ с «железом»:

ВПС в Германии.



Это мой второй опыт обращения с VPS, знаний в настройке сервера у меня практически нет. Первый опыт закончился настройкой VPS по мануалам. На сервере на данный момент стоит Ubuntu 11 x86 с апачем и мускулом, систему настраивал знакомый сисадмин. В качестве панели используется ISPConfig.



Проблема:

Яндекс-метрика и Гугл-аналитикс раза два в день пишут о недоступности сайта, который висит на ВПС. Сам сайт периодически подвисает на 30 секунд, иногда и до минуты. Сайт работает на достаточно ресурсоемком движке аудио-плеера Oplayer, допиленном под работу c api LastFM. При работе по SSH из Putty или WinSCP случаются «фризы», сервер будто останавливается и не отвечает на запросы в течение 5-10 секунд.



Лог апача за сегодня:

pastebin.com/6LFM06f6



Скрин команды top





Скрин команды htop





Скрин панели OpenVZ





Скрин панели OpenVZ — Details (лимиты)





В суппорт писал о недоступности сайта, ответили что с их стороны все хорошо:

«i have check it, but cant find any mistake.»



Мои мысли:

— Неоптимизированная настройка сервера.

— Нужно перейти на Nginx, чтобы снизить нагрузку на сервер.

— Другой клиент перегружает физический сервер, в результате чего из-за недостатков OpenVZ мой впс тормозит.



Уважаемые хабралюди, какие могут быть причины подобных тормозов и подвисания ВПС?

Comments

[Ильяс М]

UPD: проблема была в хостере, перешел на KVM — vps от DigitalOcean и радуюсь, никаких проблем.

Answer 1

[EugeneOZ]

Перейдите на Linode или DigitalOcean (или другой xen/kvm-хостинг), чтобы не зависеть от соседей. Иначе мысль «это соседи» будет преследовать Вас постоянно.
Раз уж у Вас MySQL кушает 45% CPU — купите ей отдельную VPS. Лучше иметь две VPS поменьше, но одна отдельно под БД, чем VPS побольше на всё сразу. В том же ДЦ, чтобы локальный трафик бесплатным был и почти без latency. И масштабировать будет проще.

Answer 2

[Влад Животнев]

tcp send buffers тоже заканчивался много раз — wa может быть отсюда. Хотя 84% оно бы не дало.
И ещё у вас нет кешей в памяти — скорее всего, из-за криворукой настройки openvz у хостера (старой версии/неправильных лимитов/etc). Если там всё плохо — то ваша vps-ка вполне себе может вообще ничего не складывать в память лично (а все кеши в общей системе принадлежат жирному соседу).
Лимиты памяти настроены через жопу, vswap не используется.

В общем, самый простой совет — переехать для начала подальше от этого хостера с таким конфигом. Либо на ovz с корректными лимитами на память, либо на KVM/Xen.

Answer 3

[Anastasia_K]

поинтересуйтесь в техподдержке, как часто и в какое время делается бекап ВМ.

Comments

[Ильяс М]

спасибо, спрошу

Answer 4

[nikzh]

В выводе команды top обратите внимание на 84.8% wa — разбираться надо отсюда (что-то кушает жёсткий диск, либо он сам по себе плохой, либо могут быть другие варианты).

Comments

[Evengard]

Тоже подумал именно про HDD в первую очередь. lotop попробуйте

[Ильяс М]

Благодарю за ответ. На текущий момент вывод команды Top такой:
top — 18:07:52 up 2 days, 4:31, 1 user, load average: 0.55, 0.77, 0.82
Tasks: 27 total, 1 running, 26 sleeping, 0 stopped, 0 zombie
Cpu(s): 18.9%us, 5.2%sy, 0.0%ni, 75.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4194304k total, 336592k used, 3857712k free, 0k buffers
Swap: 0k total, 0k used, 0k free, 0k cached

В чем могут быть проблемы с вводом-выводом (wa)? И как можно это проверить?

Answer 5

[semaster]

на VPS с OpenVZ проблемы с вводом-выводом могут зависеть и не от вас, а от соседей по серверу

Comments

[Ильяс М]

понимаю. Как проверить то, что нагрузку на сервер дает не мой не настроенный впс, а именно другой клиент?

Answer 6

[Алексей]

Сам себе злобный буратино с php-cgi… известная картинка facepalm.jpg

Comments

[Алексей]

P.S. да еще с open_basedir — который сильно тормозит диск…

[Ильяс М]

Да, забавно, ощущаю себя чайником, есть за что.
Посоветуйте, пожалуйста, конкретные действия.
Open_basedir отключить?
Переключить с php-cgi на php-fpm?

[Юрий Попов]

Переключить с php-cgi на php-fpm — обязательно.

Answer 7

[smartlight]

Только меня удивила пикча со скрином htop, где одно ядро загружено на 100%, а остальные нет?

Comments

[Михаил Р]

При создании контейнера выделили только одно ядро?

Answer 8

[joneleth]

Munin поставьте и поглядите статистику. И проверьте /proc/user_beancounters

Answer 9

[Виктор Таран]

достаточно легкая проблема встречал пару раз.
1. iotop -oka в момент провисания.
2. munin в помощь ставь смотри мониторь.
3. Если тебя смущяет именно 30 сек то эту проблему пол года решал.
То ты не туда копаеш !!
Все достаточно тупо увеличь время таймаута до 600 в апаче других решений не нашлось.
Эта пробелма обсалютно у всех хостеров. Связана с I-O файловой системы и принципом работы апача. Далее если требуется понижай таймаут.
В моем случае переход на ssd решил проблему в корне.