Сеть мб падала?
Если сам сервер - то достаточно странно.
net.ipv4.icmp_echo_ignore_all=1
http://www.percona.com/doc/percona-server/5.5/diagnostics/user_stats.html?id=percona-server:features:userstatv2
Мск РТ - наблюдаю проблемы до Hetzner и OVH.
4 2 ms 2 ms 2 ms ae-9.m10-ar4.msk.ip.rostelecom.ru [94.25.14.17] 5 2 ms 2 ms 2 ms 95.167.92.68 6 56 ms 60 ms 69 ms 79.133.94.222 7 * * * Превышен интервал ожидания для запроса. 8 * * * Превышен интервал ожидания для запроса.
Такого не должно быть.
vzctl stop 101 => мягкая остановка, до 2 минут ждет остановки впс. Далее просто киляет.
vzctl stop 101 --fast => не ждет 2 минуты и просто все киляет.
Если вдруг vps продолжает работать (зависла) -> пишем в багтрекер.---------- Добавлено 10.09.2013 в 16:03 ----------Раньше был баг https://bugzilla.openvz.org/show_bug.cgi?id=2510
Unstopable container: Child 170622 exited with status 7
Glueon, На питоне это вышло как многопоточное приложение. Возможных ошибок достаточно мало. Никаких проблем пока не заметил.
Нет. Открывает порт, слушает команды от сайта.
В зависимости от команды выполняет по шаблону те или иные действия через subprocess.call -> vzctl + некоторые доп скрипты.
И плюс на сайте в ЛК клиета доступны некоторые действия
API на ноде аналогично можно накодить. У меня например на питоне реализовано. Можно хоть на php сделать.
Cannot allocate memory это почти всегда криво настроенные UBC лимиты OpenVZ на ядрах RHEL5.
При этом оперативка на сервере может и быть свободной на серваке. На ядрах ovz RHEL5 - много сложных параметров на память. На ядрах ovz RHEL6 - все гуд (там 2 параметра ram и swap).
Если "коробка" это VDSmanager -> то там (на сколько я знаю) -> параметры выставляют на все и нет поддержки swap (для новых ядер).---------- Добавлено 09.09.2013 в 21:44 ----------Даже если предположить, что памяти на всей ноде больше нет - скорее всего сработает oom killer и что-нибудь кильнет.
Очень сомневаюсь, что кто-то будет так оверселлить память и не следить за тем сколько ее реально юзают.
Cannot allocate memory в первую очередь говорит о кривых UBC лимитах на ovz ядрах base RHEL5.
Из-за оверселла скорее будет проседать I/O, так как большая концентрация впсок + небольшое количество оперативки под файловый кеш.
Если же оперативка совсем закончится или сервер начнет активно свопаться - будут дикие лаги (впски будут фактически недоступны).
