next Опубликовано 9 мая, 2012 Жалоба Поделиться Опубликовано 9 мая, 2012 (изменено) Заказал burst.net VPS, до этого пользовался год imhoster.net, претензий к последнему не было в качестве обслуживания, и работоспособности.На imhostere была debian, 6.0, установлены только лишь необходимые приложения для компила сервера, и mysql; нет апача, пиашпимайадмина, и т.п. Жрала без запуска ea ~ 50 - 70 mb RAM;А теперь ситуация с burst.net; Жрет как корова после зимы! В режиме простоя 290-320 РАМ, приложения те же что и на imhostere, т.е. * Make * GCC * libmysqlclient15-dev * libpcre3-dev * zlib1g-dev + myslq-server;Помогите возможно приложениями для мониторинга что жрет дохрена, и почему? в стандартном top - показывает следующее: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 15 0 2024 700 604 S 0.0 0.1 0:01.87 init 1240 daemon 18 0 1800 472 384 S 0.0 0.1 0:00.00 portmap 1302 root 25 0 33436 1384 1028 S 0.0 0.3 0:00.00 rsyslogd 1314 root 18 0 5484 960 572 S 0.0 0.2 0:00.00 sshd 1339 root 25 0 2672 1220 1012 S 0.0 0.2 0:00.00 mysqld_safe 1451 mysql 16 0 153m 18m 5824 S 0.0 3.7 0:00.64 mysqld 1453 root 22 0 1664 536 468 S 0.0 0.1 0:00.00 logger 1533 daemon 18 0 2152 424 292 S 0.0 0.1 0:00.00 atd 1568 root 18 0 2284 860 676 S 0.0 0.2 0:00.00 cron 1578 root 18 0 36880 7836 4384 S 0.0 1.5 0:00.07 apache2 1580 www-data 18 0 37232 4892 1216 S 0.0 0.9 0:00.00 apache2 1582 www-data 15 0 36968 4792 1240 S 0.0 0.9 0:00.00 apache2 1583 www-data 15 0 37248 4936 1240 S 0.0 0.9 0:00.00 apache2 1584 www-data 15 0 36952 4704 1188 S 0.0 0.9 0:00.00 apache2 1755 www-data 15 0 36880 4644 1144 S 0.0 0.9 0:00.00 apache2 1776 www-data 15 0 36880 4612 1128 S 0.0 0.9 0:00.00 apache2 1778 www-data 15 0 36936 4680 1180 S 0.0 0.9 0:00.00 apache2Но лаги все же ощутимы, в CP для VPS - вижу что жрет +-300MB Ram;Решение: проблема в Mysql сервере расположенного на OpenVZ;После написания всего одной строчки ulimit -s 1024; Нагрузка MySQL резко снизилась с 300 до 130 MB;Далее выполнил следующее:$ nano /etc/inid.d/rcпрописал в этой файл во вторую строчку комманду ulimit -s 1024; Для того, что бы после перезагрузки это приминялось так же. Проблема исчезла полностью. (Т.е. MySQL (не оптимизированный вообще никак, тупо дефолт) стала кушать порядка 60-70 mb; что вполне не может не радовать.UPD: Не используйте OpenVZ; Виртуализация полный шлак и дерьмо. Разобрался во всем сам, гугля в гугле + практика. Тупой DDoS на настроенный vps, с теми же правилами что на imhostere в iptables, + пара других конфигов, жрут памяти около 2ГБ! При ддосе с помощью никчемных паблик тулз достаточно положить очень легко любой сервер на OpenVZ, сколько бы там не было бы RAM, CPU и канал. Изменено 10 мая, 2012 пользователем next Ссылка на комментарий Поделиться на другие сайты Поделиться
Functor Опубликовано 9 мая, 2012 Жалоба Поделиться Опубликовано 9 мая, 2012 (изменено) Этот вопрос необходимо задать саппорту burst.net Изменено 9 мая, 2012 пользователем Functor Ссылка на комментарий Поделиться на другие сайты Поделиться
poiuty Опубликовано 10 мая, 2012 Жалоба Поделиться Опубликовано 10 мая, 2012 проблема в виртуализации не покупайте OpenVZлучше напишите так: "я не понимаю в чем проблема, но мне кажется, что во всем виновата виртуализация OpenVZ" 1 Ссылка на комментарий Поделиться на другие сайты Поделиться
next Опубликовано 10 мая, 2012 Автор Жалоба Поделиться Опубликовано 10 мая, 2012 проблема в виртуализации не покупайте OpenVZлучше напишите так: "я не понимаю в чем проблема, но мне кажется, что во всем виновата виртуализация OpenVZ"возможно вы правы. хоть OpenVZ дешевле XEN, но это и оправданно в технологиях приминимых для VZ и XEN;За вчерашнюю ночь, и день, оптимизировал хостинг, что при онлайне (живых на WoE 80 человек) хостинг, с АПАЧЕМ, мускулем, и половиной десятка других процессов, кушала ~ 150MB, и 400 - 500 mhz; Ссылка на комментарий Поделиться на другие сайты Поделиться
Renegade Bastard Опубликовано 10 мая, 2012 Жалоба Поделиться Опубликовано 10 мая, 2012 почему апач аж капсом?~# ps aux |grep apacheroot 1271 0.0 0.9 37768 9676 ? Ss May04 0:43 /usr/sbin/apache2 -k startwww-data 26046 0.0 0.8 39052 9096 ? S 14:38 0:00 /usr/sbin/apache2 -k startwww-data 26048 0.0 1.1 41180 11544 ? S 14:38 0:00 /usr/sbin/apache2 -k startwww-data 26051 0.0 0.7 38704 8020 ? S 14:38 0:00 /usr/sbin/apache2 -k startwww-data 26065 0.0 0.7 38732 7672 ? S 14:46 0:00 /usr/sbin/apache2 -k startwww-data 26067 0.1 1.1 41552 11704 ? S 14:46 0:00 /usr/sbin/apache2 -k startwww-data 26068 0.1 1.0 41068 10648 ? S 14:46 0:00 /usr/sbin/apache2 -k startwww-data 26069 0.0 0.7 38816 8028 ? S 14:46 0:00 /usr/sbin/apache2 -k startwww-data 26070 0.2 1.1 41904 11404 ? S 14:49 0:00 /usr/sbin/apache2 -k startwww-data 26071 0.0 0.5 38272 5428 ? S 14:50 0:00 /usr/sbin/apache2 -k start Ссылка на комментарий Поделиться на другие сайты Поделиться
Renegade Bastard Опубликовано 10 мая, 2012 Жалоба Поделиться Опубликовано 10 мая, 2012 Да, кстати, советую изредка прогонятьsync; echo 3 > /proc/sys/vm/drop_cachesгдето раз-два в недельку. Раз ты уж на опенВЗ с ограниченными ресурсами. 1 Ссылка на комментарий Поделиться на другие сайты Поделиться
next Опубликовано 14 мая, 2012 Автор Жалоба Поделиться Опубликовано 14 мая, 2012 Да, кстати, советую изредка прогонятьsync; echo 3 > /proc/sys/vm/drop_cachesгдето раз-два в недельку. Раз ты уж на опенВЗ с ограниченными ресурсами.За очистку кеша спасибо. Но на OpenVZ кеша нет. На ХЕN есть. Я уже давно сменил на XEN проблем не знаю вообще. 1 Ссылка на комментарий Поделиться на другие сайты Поделиться
Рекомендуемые сообщения