CMS DataLife Engine - Система управления сайтами

Sign in to follow this  
planetaknig

MySQL не выдерживает нагрузки на дедик

Recommended Posts

В общем есть проблема!

Выделеный сервер с параметрами:

CPU (Processor) Dual Xeon 2.66 Ghz

Hard Drive 146 GB 10K SCSI

RAM 2048 MB

гигабитный порт.

Все вроде гуд.

Cайт посещает 35 тыс юзеров в сутки. На сайте зарегено 800тыс записей в _users. 60 тыс новостей в таблице _post. Все параметры CPU и памяти в красной зоне!

По топ запросов вижу что постоянный update таблицы _users.(пересоздание индексов) Я так понимаю что проблема в этом. Может ошибаюсь.

Уже не знаю что делать. Сделал кеширование запросов. Поставил все параметры MySQL по макс.

Все ровно доступность сайта это проблема!

Скажите кто нибудь что делать? Готов оплатить результативное решение.

Share this post


Link to post
Share on other sites

В общем есть проблема!

Выделеный сервер с параметрами:

CPU (Processor) Dual Xeon 2.66 Ghz

Hard Drive 146 GB 10K SCSI

RAM 2048 MB

гигабитный порт.

Все вроде гуд.

Cайт посещает 35 тыс юзеров в сутки. На сайте зарегено 800тыс записей в _users. 60 тыс новостей в таблице _post. Все параметры CPU и памяти в красной зоне!

По топ запросов вижу что постоянный update таблицы _users.(пересоздание индексов) Я так понимаю что проблема в этом. Может ошибаюсь.

Уже не знаю что делать. Сделал кеширование запросов. Поставил все параметры MySQL по макс.

Все ровно доступность сайта это проблема!

Скажите кто нибудь что делать? Готов оплатить результативное решение.

Сталкивался с подобным. Лечилось увеличение ОЗУ. В моем случаи не хватало на сервере места под кеш.

PS. Собрал тогда дополнительно еще и рейд.

Share this post


Link to post
Share on other sites

И чего удивительного?Меняйте это ***** на nginx и будет Вам счастье.

Сразу ощутите разгрузку времени процессора и памяти.

Единственная проблема - переписать правила. Для раздачи статики особенно классно.

А вообще:

nginx + php-fastcgi FOREVER :)

Share this post


Link to post
Share on other sites

Не думаю что проблема в таблице _users, там массовых сортировок нету. А вот табличка _post уже великовата. Решений может быть несколько, увеличение оперативной памяти, преход на другую базу данных, изменение структыры _post (вынос полной и короткой новости в другую таблицу, это уменьшит вес и следовательно ускорит сортировку). nginx может частично улучшить ситуацию, но думаю что кардинальных улучшений не будет.

Share this post


Link to post
Share on other sites

Ошибаетесь, уважаемый. Освободится МАССА ресурсов, которые можно будет пустить на другие нужды.

Выносить и т.п. - до первого обновления. А потом всё по новой. Переход на другую базу - в рамках DLE невозможен.

Share this post


Link to post
Share on other sites

IT-Security, проблема на в фронтенде, а в мускуле. если у него постоянно висит апдейт.

и что за странная связка? имхо mod_php работает стабильнее и быстрее чем fast_cgi - тем более что нет еще стабильных билдов для него, надо заплатки ставить.

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

Share this post


Link to post
Share on other sites

У меня стоит nginx + fast_cgi и совершенно никаких проблем))Апач совершенно не нужен)

А насчёт проблем ТС:

"Все параметры CPU и памяти в красной зоне!"

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

Живой пример:

P4 DualCore 3.2, 2048mb DDR2

С апачем у нас выжиралась вся памяти и часть свопа на посещаемости в 2000 уников в сутки.

С nginx у нас остаётся в районе 300метров. Это ли не показатель?

Debian Linux

Edited by IT-Security

Share this post


Link to post
Share on other sites

Переход на другую базу - в рамках DLE невозможен.

Класс работы с базой переписать.

Share this post


Link to post
Share on other sites

Вы себе представляете переписывать ВСЕ запросы в DLE?Да и как потом человек обновляться будет?Думайте головой то. Был бы у него свой собственный движок - ещё можно было бы на такое пойти.

MySQL заменить на маршрутизатор СуБД и сделать в нём вместо query() функции select, insert, update, delete.

Но в DLE человеку ДАЖЕ если он на такое пойдёт или нельзя будет обновляться или придётся при каждом обновлении такую процедуру проделывать.

Share this post


Link to post
Share on other sites

mysql.class.php, 5 кб кода. Ни одного запроса переписывать не нужно. Даже если увеличить мощность сервера и оптимально все настроить, вырастет размер базы - опять возникнет эта проблема. Возможности MySQL по сортировке больших таблиц сильно ограничены.

IT-Security, я не кому ничего не навязую и никого ни в чем не убеждаю, я выскзал свое виденье этой проблемы. А обновление измененного движка по сравнению с грамотной настройкой сервера вобще ни что.

Share this post


Link to post
Share on other sites

Ваше решение подходит ТОЛЬКО для баз с таким же синтаксисом.

Далеко ходить не нужно - у MSSQL нету Limit. Тоесть все запросы связанные с limit надо переписывать.

Share this post


Link to post
Share on other sites

Дело в том что по команде top видно что самую нагрузку несет именно база данных.

Размер базы 550 метров.

Пересоздавал структуру, вливал все по новому в таблицы.

Убраны счетчики просмотров. Никаких левых модов. Чисто движок 7.5

Я уже даже убрал запрос update что бы не апдейтилась таблица _users. Так как там под 800 тыс записей. Но это вовсе не помогает.

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

В PhpMyAdmin можно смотреть параметры для текущего состояния с кратким описанием что они значат.

Так вот большинство параметров указывают на не оптимизированные запросы и неправильную индексацию таблиц.

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

Edited by planetaknig

Share this post


Link to post
Share on other sites

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

В чем она неоптимальна? Вам не кажеться что вам нехватает серверных ресурсов чтобы сотни тысяч раз перелопачивать 500 мегабайт файлов в сутки? Меня вот удивляет иногда некоторое отношение пользователей, заявляющих тут неоптимизированная БД. В чем она неоптимизирована? Ничего и никогда не берется из ниоткуда, это закон физики. И всегда нужно чем то жертвовать, нужна большая производительность увечивайте CPU и память. Нехотите увеличивать, уменьшайте БД. Вам уже дали правильные советы по увеличиванию производительности, вы же утверждаете что БД неоптимизирована. В чем она неоптимизирована? Давайте конкретно говорите.

И параметры в phpMyAdmin не говорять о неоптимизированности БД, они говорят о нехватки памяти, о низких значениях кеша и приходится делать файловые операции и о том что приходится создавать временные файлы, т.к. все в память не уменьшается.

Share this post


Link to post
Share on other sites

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

В чем она неоптимальна? Вам не кажеться что вам нехватает серверных ресурсов чтобы сотни тысяч раз перелопачивать 500 мегабайт файлов в сутки?

Полностью согласен с тем и другим. Яркий пример - форумы, они часто имеют базу и больше и вполне нормально работают на MySQL. MySQL просто не предназначен для сортировки такого количестваданных. Поиск в индексах работает моментально даже в базах в десятки раз больше, а вот с сортировкий явные проблемы. По этому при использовании MySQL для больших баз нужно выносить все поля кроме тех что используются для сортировки в отдельную таблиицу или тестовые файлы + LEFT JOIN и все отлично, размер таблицы для сортировки уменьшится раз так в 10. Но для маленьких таблиц со стороны использования ресурсов это не очень выгодно. Второй вариант поэксперементировать с другими базами данных.

Share this post


Link to post
Share on other sites

1.Не гоните на Мускуль вон Гугл живет с Мускулем и нормально ничего у него не отваливаетьсо а совет посмотри к мускулю патчи от Гугла и Group by уберите нафиг...Перепишите часть кода и перенесите Мускуль на другой серв

2. поставьте Мемкеш на мускуль

3.перенесите мускуль на другой серв

Ну и поставьте связку нгних +нгних+ фаст сдж и будет вам счастье

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Приведи мне пример IPB2, который живёт на шареде с большей посещаемостью, чем у ТС =)) Со всеми включенными опциями он даже не всегда запустится из-за нехватки памяти)))Кстати есть ещё идея - может тут ещё и поисковые роботы виноваты и создают лишнюю нагрузку?

А насчёт движка (Не в обиду автору), но в таком кастрированном функционале (на фоне создания бизнес-проектов) тормозить нечему.

ТС - отруби моментальное обновление счётчика новостей, вруби кэширование, покрути настройки.

Всё это сделано было?

Share this post


Link to post
Share on other sites

ну на вскидку можно разделить таблицу _post на две - одна будет содержать параметры новости и по ней будет идти сортировка, а другая содержит уже саму новость - из неё дёргаем без сортировок - сразу по ID. Типо того)

А вообще, старик, действительно надо бы сервер второй подкупать или увеличивать мощность нынешнего

Edited by Александр Медведев

Share this post


Link to post
Share on other sites

Не замечал падения скорости на nginx + fast_cgi, если честно.

Возможно просто не было задач, которые бы тормозили.

Но вообще:

<!-- Время генерации страницы: 0.0046 секунд --> (Свой движок, 3 запроса)

Share this post


Link to post
Share on other sites

IT-Security

ТС - отруби моментальное обновление счётчика новостей, вруби кэширование, покрути настройки.

Всё это сделано было?

Еще пол года назад было сделано. Отключен даже update даты последнего визита юзера. В онлайне просто по 600 юзеров.

Обновлял версию mysql сервера до последней.

Думаю базу вынести на отдельный дедик.

Edited by planetaknig

Share this post


Link to post
Share on other sites

Вынесите...Или на дедик или можно ещё MySQL оставить где он есть, а сам сайт перенести на VPS или наоборот.

VPS хорош тем, что его можно расширить до дедика впоследствии.

Share this post


Link to post
Share on other sites

Можно рассмотреть вариант дополнительного кеширования с помощью memcached

Share this post


Link to post
Share on other sites

Все варианты кеширования испробованы.

Перенес все на новый сервер. +2Гб оперативки. Около миллиона пользователей зарегено. Проблемма как была так и осталась!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this