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

[planetaknig 0]

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

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

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 по макс.

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

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

[Beliz71 0]

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

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

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. Собрал тогда дополнительно еще и рейд.

[IT-Security 33]

Веб-сервер какой?

[planetaknig 0]

Apache 2

Изменено 18 февраля 2009 пользователем planetaknig

[IT-Security 33]

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

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

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

А вообще:

nginx + php-fastcgi FOREVER

[max-money 0]

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

[IT-Security 33]

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

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

[mitriy 5]

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

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

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

[IT-Security 33]

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

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

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

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

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

P4 DualCore 3.2, 2048mb DDR2

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

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

Debian Linux

Изменено 20 февраля 2009 пользователем IT-Security

[max-money 0]

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

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

[IT-Security 33]

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

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

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

[max-money 0]

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

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

[IT-Security 33]

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

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

[planetaknig 0]

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

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

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

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

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

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

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

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

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

Изменено 22 февраля 2009 пользователем planetaknig

[celsoft 6 072]

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

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

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

[max-money 0]

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

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

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

[Toren234x5 0]

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

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

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

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

[mitriy 5]

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

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

[IT-Security 33]

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

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

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

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

[lifestar 18]

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

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

Изменено 24 февраля 2009 пользователем Александр Медведев

[IT-Security 33]

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

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

Но вообще:

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

[planetaknig 0]

IT-Security

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

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

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

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

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

Изменено 25 февраля 2009 пользователем planetaknig

[IT-Security 33]

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

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

[max-money 0]

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

[planetaknig 0]

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

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