LINUX.ORG.RU

VDS и производиительность


0

3

Здравствуйте.

Очень надеюсь на вашу помощь. У нас следующая ситуация: имеется два крупных сайта и куча мелких, которые нужно где-то хостить. Мы арендовали довольно мощный сервер, и решив отделить крупные сайты друг от друга и от мелких (среди которых могут быть «дырявые»), создали на нем 3 VDS и разместили крупные на отдельных VDS и все мелкие на третьем VDS. В качестве системы виртуализации использовали OpenVZ, в качестве гостевых систем — Debian. Все это кое-как поработало некоторое время, а потом начались проблемы с производтельностью MySQL (иногда нагрузка процессора составляла 100% при совсем небольшой посещаемости). Закончилось все тем, что мы не смогли импортировать дамп, т.к. MySQL зависал.

Мы обратились к другому Linux-администратору, который посмотрел на это все и сказал нам следующее: 1. OpenVZ не умеет корректно работать с оперативной памятью, и, несмотря на то, что у нас есть 8 Гб, используется только 1,5 Гб, после чего крашится MySQL. 2. Практически все системы вируализации, сильно замедляют работу, т.к. на каждое обращение к винчестеру, делают несколько обращений. 3. Лучше в нашем случае вообще не использовать VDS, а установить несколько Apache в пределах одной системы, что даст высокую производетельность и достаточное отделение сайтов друг от друга.

Все переделывать — это серьезный шаг, и хочется быть уверенными, что предлагаемое решенеи самое лучшее. Что вы думаете по этому поводу? Правильно ли советует админ? Будем ли это достаточно безопасно, не будут ли одни сайты ложить другие? Или лучше все-таки использовать VDS, но заменить систему вируализации? Если так, то какую бы вы посоветовали? Мы уже используем ISPManager для 3-го VDS, возможно, нам стоит купить и использовать VDSManager для вируализации? Или действительно, все системы виртуализации «плохие»?


Системы виртуализации хорошие. Про OpenVZ таких ужасов не слышал.

Есть мнение, что Xen работает чуть быстрее.

Тормозит SQL - так и копайте в сторону SQL

Несколько апачей - ни разу не выход и дыра скрипта — дыра системы, а не только апача.

На сколько толстая база MySQL и как вы её устанавливали?

ps Дамп хорошо вытаскивается и при выключеном сервере баз данных.

helios ★★★★★ ()
Ответ на: комментарий от helios

В базе одна таблица на ~30 млн записей, остальные мелкие. Весит ~2 Гб. Сервер: Intel Core i7-920 Quad-Core, 8 GB RAM, 2x750 GB SATA-II HDD (Software-RAID 1).

Дамп надо не вытащить, а, наоборот, залить.

Yanis ()

Начнем с того, что вашему мускулю нужен тюнинг, причем желательно в исполнении профессионала.

Еще неплохо было бы пересмотреть двигло веб-сервера - подумайте о замене апача на лайти/джинкс с fastcgi/php-fpm (если у вас пых). При правильной настройке это даст прирост производительности раз в пять-десять (в среднем).

Изоляция через контейнеры, действительно, имеет смысл только при гигантском запасе по производительности (простенький сайтик на топовом ксеоне с кучей мозгов и сказей в raid0+1) либо когда пофигу на зависания клиентского софта (VDS-хостинги).

В вашем случае, единственное решение для безопасности, не сильно просаживающее производительность - мандатный контроль доступа. Из существующий альтернатив годится только одна (долго рассказывать почему) - SELinux, что соответственно жестко задает дистрибутив - RHEL/CentOS/Fedora (во всех остальных дистрах даже включение targeted enforced обычно нарушает нормальную работу системы). Плюс до кучи можно веб-сервера по чрутам распихать.

anonymous ()

> 1. OpenVZ не умеет корректно работать с оперативной памятью
Бред. Аналогично и по второму пункту.

Можно использовать VDS, можно не использовать. Но и то и другое делать правильно. Поищите какого-нибудь действительно адекватного админа с руками, даже в рамках существующей системы можно сделать все нормально.
И да, mysql дйествительно нужно тюнить. Как базу, так и сервер.

Valmont ★★★ ()

>и, несмотря на то, что у нас есть 8 Гб, используется только 1,5 Гб, после чего крашится MySQL

Небось 32-битное PAE-ведро вкорячили? (А в дебиане емнип openvz ведра как раз для i686 с pae собирают.)

nnz ★★★★ ()

Какой фееричный админ.
VDS в данном случае практически никаких накладных расходов не вызовет.

Для профилактики сделайте optimize table на все ваши mysql-таблицы. Посоздавайте нормальные индексы, наймите DBA.
В конце концов, поставьте 64-битные VDS.

Кроме всего прочего, рекомендую сделать один vds c mysql, он должен получше распоряжаться доступными ему ресурсами, чем несколько их.

Привет hetzner.de.

AnDoR ★★★★★ ()
Ответ на: комментарий от AnDoR

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

kam ★★ ()
cat /proc/user_beancounters
anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.