Перейти к публикации

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


Рекомендованные сообщения

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

А вообще:

nginx + php-fastcgi FOREVER :)

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

P4 DualCore 3.2, 2048mb DDR2

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

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

Debian Linux

Изменено пользователем IT-Security
Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

Изменено пользователем planetaknig
Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем Александр Медведев
Ссылка на сообщение
Поделиться на других сайтах

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

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

Но вообще:

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

Ссылка на сообщение
Поделиться на других сайтах

IT-Security

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

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

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

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

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

Изменено пользователем planetaknig
Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах
  • 2 недели спустя...
  • 1 месяц спустя...

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

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

Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

×
×
  • Создать...