Мой форум тяжелый ?!

[civfanat]

хостер говорит, что мой форум нагружает сервер и краник дёргает

версия ipb 2.1.4, сконвертирован из 1.3

 

посещаемость в чём измерять ? ну пишет форум, что за "полчаса 100 человек"

На форуме сообщений: 72652

Зарегистрировано пользователей: 6256 (реально живых около 500)

 

на счётчике mail.ru вот пик например есть:

 

день 10 янв

посетители 979

хосты 1,063

новые 804

визиты 9,583

 

при этом ещё один пик для примера, но был он на ipb 1.3;

 

день 9 дек

посетители 1,099

хосты 1,153

новые 883

визиты 10,189

 

это какой форум ? тяжёлый ? я на shared хостинге

[Valera]

-------

хостер говорит, что мой форум нагружает сервер

-------

Придется менять его.

[Drug]

есть ли счетчик от top.mail.ru

кто хостер?

 

и самое главное какой объем MySQL базы?

[civfanat]

счетчик http://top.mail.ru

указать ID 645345

размер базы 100 мег

 

-------------------------------------------------

хостер прислал фрагмент лога:

 

Top Process %CPU 14.0 httpd [forum.домен.ru] [/index.php?s99115423dd10c92df22e2ab1d06f264d&showforum76]

 

Top Process %CPU 8.7 httpd [forum.доменru] [/style_images/1/calen.gif]

 

Top Process %CPU 7.5 httpd [www.домен.ru] [/files/patches/civiv152/Civ4Patch1.52.sfx.part08.rar]

 

первое я могу понять (поиск... ресурсы...)

третье я могу понять (многопоточное скачивание, там файл 5 мег)

 

а вот как закачкой файла calen.gif размером 369 байт можно загрузить процессор на %CPU 8.7 ? или есть способы ? это статичный gif

что-то не сходится в логах или я не понимаю механизм формирования нагрузки на файле в 369 байт

 

-------------------------------------------------

далее

я вот сейчас смотрю myphpadmin форумную базу

и вижу интересную вещь:

при проверке таблиц выдаётся

 

Problems with indexes of table `ibf_cal_events`

More than one INDEX key was created for column `event_calendar_id`

 

Problems with indexes of table `ibf_dnames_change`

More than one INDEX key was created for column `dname_member_id`

 

Problems with indexes of table `ibf_topics`

More than one INDEX key was created for column `forum_id`

 

читаю Ошибки MySQL, причины

там говорят, что это наверняка ошибка хоста

 

и правда - КАК я могу создавать по три индекса на столбец ? возможно, после падения сервера какое-то автовосстановление серверной mySql происходит ?

 

есть какие-нибудь мысли по поводу происхождения индексов ? форум их САМ на лету по-моему не делает ? скорее это работа серверной mySql ?

 

кстати, на ipb 1.3 при равной посещаемости форума претензий ко мне не было (цифры в первом посте), разве что файлами типа [/files/patches/civiv152/Civ4Patch1.52.sfx.part08.rar] я периодически удручал (диалапщик, качающий такие 5 мег-файлы на 30 потоках - страшная сила )

 

что думать... то ли лыжи, то ли я... то ли на ipb 2.1.4 напрасно переехал или всё-таки надо у хостера причину искать ?

[Drug]

вот что интерсно было:

http://top.mail.ru/dynamics?what=hits&peri...14.html&ok=+OK+

 

Ну и хостинг у вас у goldhost.ru у них самый крутой тариф 15$ там места много дают, но под форум нужно не места много, а повышенная нагрузка на базу MySQL и апач сервер как резульатт повышена нагрузка на CPU сервера.

 

Но я думаю что у вас тариф и того меньше поэтому не удивительно, думаю за 20$-30$ в месяц в найдете в инете хостинг под ваш форум без ругани на нагрузку!

 

Top Process %CPU 14.0 httpd [forum.домен.ru] [/index.php?s99115423dd10c92df22e2ab1d06f264d&showforum76]

 

Top Process %CPU 8.7 httpd [forum.доменru] [/style_images/1/calen.gif]

 

Top Process %CPU 7.5 httpd [www.домен.ru] [/files/patches/civiv152/Civ4Patch1.52.sfx.part08.rar]

 

дело в том что нет нормального учета и то что вам привел хостер понятное дело пред хотя и обяснимо дело в том что один http процесс на сервере обслуживает не один запрос, а много но последний из них могла быть загрузка картинки а в суме нагрузка получилась 7.8%

 

Но опять таки это пиковая нагрузка и совсем не показатель общей нагрузки на сервер!

 

то ли на ipb 2.1.4 напрасно переехал

нет хороший двиг!

 

Problems with indexes of table `ibf_cal_events`

More than one INDEX key was created for column `event_calendar_id`

 

Problems with indexes of table `ibf_dnames_change`

More than one INDEX key was created for column `dname_member_id`

 

Problems with indexes of table `ibf_topics`

More than one INDEX key was created for column `forum_id`

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

[civfanat]

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

т.е. явно наблюдается завязка на движок 2.1.3..4

 

удалил лишние приблудные индексы в 2.1.4

время выполнения запросов возросло в 10 раз, скорость работы форума возросла визуально раз в 5

 

наблюдаем развитие ситуации совместно с хостером...

 

вот кстати ещё косячок наблюдаю:

на сервере время 20:50

в админке форума время 20:50

а на титул форума пишет Сейчас: 23.01.2006 - 17:50

...

раньше этого не было

куда копать-то...

[gta]

удалил лишние приблудные индексы в 2.1.4

время выполнения запросов возросло в 10 раз, скорость работы форума

а где их удалить? А то форум от скорости страдает

[.silent]

вот кстати ещё косячок наблюдаю:

на сервере время 20:50

в админке форума время 20:50

а на титул форума пишет Сейчас: 23.01.2006 - 17:50

...

раньше этого не было

куда копать-то...

временной пояс пользователя может?

[civfanat]

не, наверное не временной пояс

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

ну найду - в админке где-то кажется было

 

>> а где их удалить?

у меня cPanel

там MySQL Databases

в ней внизу phpMyAdmin

там выбираешь свою форумскую базу

появится список таблиц с чекбоксами слева

внизу есть "отметить все" - метишь

далее "с отмеченными - проверить"

в итоге пишет на экран предупреждения про лишние индексы

теперь по очереди идёшь в те таблицы, которые фигурируют в предупреждениях

будет список индексов, красным крестиком удаляешь их с конца списка, кроме первого PRIMARY индекса

если phpMyAdmin обведёт вопрос на удаление красной рамкой - НЕ УДАЛЯЙ этот индекс

затем выбираешь все таблицы и снова делаешь проверку, затем "починить" (в англ. REPAIR)

 

разумеется, перед подвигом надо сделать бэкап базы

[Valera]

Так ты не удалил индексы, ты их исправил(от дублирования)! Если бы ты удалил индексы у тебя форум тут же умер!

[.silent]

Valera, а разве mySQL позволяет создавать дубли индексов?

[Valera]

--------

Valera, а разве mySQL позволяет создавать дубли индексов?

--------

Нет, но ошибки такие видимо бывают (например в результате сбоя).

[Vic'er]

а разве mySQL позволяет создавать дубли индексов?

конечно позволяет. только под другим именем.

[civfanat]

снова хостер краником

 

как всё происходит

User ххх has already more than 'max_user_connections' active connections

начинают выскакивать эти сообщения, начинаются тооормоооза...

здесь поиском по max_user_connections прошёлся - других фраз, кроме как "у хостера ошибка" и "была в (самопальном) скрипте ошибка" я не увидел

этот max_user_connections разве должен подвешивать всё на свете ? как я представляю, если коннекты исчерпаны, то посетителю просто выдаётся сообщение max_user_connections как замена сообщению "система занята, повторите попытку чуть позже"

 

у меня 2.1.4 без модов

в админке поставил "4 cpu"

вчера пофиксил последнюю объявленную уязвимость - и (случайно или нет) этот max_user_connections вчера начал беспредельничать (раньше было потихоньку, прочихается и дальше в путь)

пользователей на форуме было 40% от обычного

посмотрел таблицу сессий - 51 сессия на момент выключения хостером доступа форум-юзера к базе

 

сопутствующая симптоматика - перед такими тормозами начинают теряться картинки при обновлении страницы

например, отрисовывается половина смайлов и кнопок... если ещё раз нажать Обновить страницу, то положение может ухудшиться - потеряются 80% картинок

если каждую картинку вручную жать Обновить - то только так все и можно заполучить в кеш браузера... вот такие "приступы" затем max_user_connections

 

может ли это быть симптомом какой-нибудь известной ошибки в настройке хоста ?

 

подскажите, пожалуйста, как можно изловить средствами клиента и средствами хостера кто вешает сессии (есть подозрение на ботов)

[Valera]

==============

сопутствующая симптоматика - перед такими тормозами начинают теряться картинки при обновлении страницы

например, отрисовывается половина смайлов и кнопок... если ещё раз нажать Обновить страницу, то положение может ухудшиться - потеряются 80% картинок

==============

Выпадение картинок связано с тем что апачу не хватает памяти, для их раздачи. (увеличьте память серверу минимально на 512мб)

 

кстати

---------------------

Top Process %CPU 8.7 httpd [forum.доменru] [/style_images/1/calen.gif]

 

Top Process %CPU 7.5 httpd [www.домен.ru] [/files/patches/civiv152/Civ4Patch1.52.sfx.part08.rar]

---------------------

это вам разве ни о чем не говорит?

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

 

------------

третье я могу понять (многопоточное скачивание, там файл 5 мег)

------------

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

[civfanat]

посмотрел системный mysql_slow_queries.log

 

обнаружил вопиющие тормоза на таких запросах:

 

# Time: 060104 15:13:05

# User@Host: моё @ localhost []

# Query_time: 63 Lock_time: 0 Rows_sent: 5199 Rows_examined: 5199

use имя_базы;

SELECT /*!40001 SQL_NO_CACHE */ * FROM `ibf_members`;

 

# Time: 060104 15:15:29

# User@Host: моё @ localhost []

# Query_time: 764 Lock_time: 0 Rows_sent: 74080 Rows_examined: 74080

SELECT /*!40001 SQL_NO_CACHE */ * FROM `ibf_posts`;

 

63 секунды на худой конец сойдут, но 764 секунды !!

 

различие в отсутствии во втором случае команды use имя_базы;

 

соответственно, появляется гипотеза о том, что запрос SELECT * FROM `ibf_posts` пробегает по ВСЕМ базам хоста, коль такое долгое время исполнения или есть объяснение попроще ?

 

второе - надо найти в исходниках место порождения SELECT * FROM `ibf_posts` и предварить его командой use имя_базы; (косяк исходников IPB 2.1.4 ??)

 

комментарии ?

[Valera]

---------

SELECT * FROM `ibf_posts`

---------

Никто никуда не пробегает!

 

Для того что бы манипулировать с базой необходимо:

1) параметры коннекта с mysql

2) имя базы

-----------------------------------

 

Без втрого пункта, У ТЕБЯ СЕЛЕКТ такой_то ТЭЙБЛ, НЕ ЗАРАБОТАЕТ!!!

поэтому твои предположение о косяке неверно!

 

 

 

 

----------

63 секунды на худой конец сойдут, но 764 секунды !!

----------

У тебя даже простой селект может выполнять много часов (если по тайм ауту соединение не отвалится), но только на жутко тормозящем сервере!!!

[профф]

или есть объяснение попроще ?

Второй запрос выбирает в 15 раз больше строк и каждая строка в несколько раз больше, чем строка в первом запросе (в среднем)

 

Те запросы делает не форум, а утилита бекапа базы (mysqldump). 764 секунды все же много. У тебя бекапы случайно не в час пик делаются? Их всегда надо делать при минимальной нагрузке (ночью).

 

# Time: 060104 15:13:05

# Time: 060104 15:15:29

Абсолютно неправильное время для бекапов. Но часиков в 10-11 вечера все же было бы более неправильно

[borchuk]

различие в отсутствии во втором случае команды use имя_базы;

 

Главное различие не в этом. В первом случае была таблица с мемберами, а второй раз с постами.

А таблица постов она всегда самая тяжёлая. ~90% всей базы где то...

[civfanat]

бэкапы ??? я их делаю вручную через cpanel, форум не отключаю (ой) вообще, это интересная мысль - надо будет сверить времена бэкапов с временами в логе

 

значит, полный селект делает ТОЛЬКО внешний бэкап ? и в движке форума нет полного селекта таблицы постов ?

 

В первом случае была таблица с мемберами, а второй раз с постами.

А таблица постов она всегда самая тяжёлая. ~90% всей базы где то...

в ней было 80 мег, когда стоял IPB 1.3 - и тормозов не было

теперь 100 мегабайт и IPB 2.1.4 - и появились тормоза

таковы факты

 

потому ищу причину тормозов и мне не нравится, что в логе для простого селекта нет команды USE, в других же логированных "перегрузочных" запросах USE присутствует - и перегрузка много меньше при бОльшей сложности запроса

 

прилагаю шот про индексы таблицы ibf_posts, 50 Кб

может косяк какой заметите

Изменено 3 Февраля 2006 пользователем civfanat

[профф]

Тебе уже дважды сказали причину такой разницы во времени запросов. Без USE используется только база выбранная последним USE. Если USE вообще не было, то будет ошибка. Если таблица не найдена, то будет ошибка (нигде искать больше не будет)

 

советы:

1. В админке поставить полнотекстовый поиск (или вообще вырубить поиск)

2. В админке зайти в оптимизацию и поэкспирементировать с настройками.

3. бекапы делать при минимальной нагрузке (как правило она ночью)

 

Стоят какие-нибудь моды?

[civfanat]

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

 

давайте всё-таки ПРЕДПОЛОЖИМ, что ошибка есть - либо в ipb, либо в mysql, либо в их настройках, либо в настройках серверного кеширования (оп.система)

 

рассуждения:

в логах нет USE

запрос исполнился

значит, USE был? хотя и не был указан явно перед запросом select *

тогда вопрос КОГДА БЫЛ USE?

если USE нет в логе, значит USE добыт из кеша?

вопрос - какова задержка добычи USE из кеша?

возможное осложнение - чтение всего кеша ради добычи USE (возможный источник задержки?)

 

когда говорят "форум тяжёлый, сервер тормозит, решение - переселиться на выделенный сервер", то выделенный сервер как раз и позволяет проигнорировать эту мою гипотетическую ошибку

ведь на моём сервере кеш весь мой, по соседским "кешикам" шариться для поиска USE не приходится

 

по этому пункту повестки дня пока всё

 

====================

далее:

 

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

 

пересоздал базу, залил бэкап

 

что обнаружил:

изменился размер таблицы ibf_posts, число записей 74 195

было 99,8 мегабайт

стало 109,7 мегабайт

 

вопрос - почему размер вырос ? может быть, некое сжатие прежнего файла с таблицей ibf_posts тоже причина тормозов ?

 

ночью перезапустил форум на вновь созданной базе, наблюдаю (в надежде вопроизвести прежние тормоза )

 

советы:

1. В админке поставить полнотекстовый поиск (или вообще вырубить поиск)

2. В админке зайти в оптимизацию и поэкспирементировать с настройками.

3. бекапы делать при минимальной нагрузке (как правило она ночью)

 

Стоят какие-нибудь моды?

1. поиск вырубить ? какой же форум без поиска... так, портянка будет, а не форум; стоит "простой поиск" на 4 символа

 

2. это всё делалось и сделано ещё раз вчера

я вот вчера подумал - а не вешается ли какая статистическая форумская задача ? в админке нашёл, что 70% этих задач помечены красненьким, принудительно их выполнил (хотя, может быть они покраснели из-за двухсуточной блокировки форума? типа "мы не выполнились")

 

...кеши все перегенерил, скины отрефрешил - всё что в админке нашёл, то и отрефрешил

 

... в "защите сервера от перегрузки" стоит cpu=3... имхо, не работает ?? коль root-юзера форумской mysql автоблокировало за перегруз сервера (так сказал хостер)... но в mysql-логах нет записи, по которой автоблок произошёл...

 

3. ну это точно

 

моды не стоят - форум "из коробки" 100%

[Valera]

================

рассуждения:

в логах нет USE

запрос исполнился

значит, USE был? хотя и не был указан явно перед запросом select *

тогда вопрос КОГДА БЫЛ USE?

если USE нет в логе, значит USE добыт из кеша?

================

Вам бы умную книгу по mysql почитать, за чашечкой кофе.

Еще раз повторяю, глюка в mysql драйвере нету, то чем вы пишите это ваши неправильные догадки существующие только у вас в голове.

(USE нигде не добывается, тем более из кеша)

[профф]

Вчера мой выделенный сервер был практически мертв из-за перегруза. Как, выяснилось, какой-то мудак качал форум через Wget. Причем с двух ip адресов. Cудя по скорости закачки (накачал 1Гб за где-то часов 15), у него не диалап. Значит какой смысл качать? Лично я думаю это был такой вариант DDOS атаки

 

P.S. просто один из вариантов почему форум может быть тяжелым

[Valera]

Вчера мой выделенный сервер был практически мертв из-за перегруза. Как, выяснилось, какой-то мудак качал форум через Wget.

 

Это обычная практика, если форум имеет хоть какую-то ценность его периодически скачивают полностью. Бывают случаи когда и поисковики параллельно шерстят...

 

 

-------------------

Cудя по скорости закачки (накачал 1Гб за где-то часов 15), у него не диалап.

-------------------

Надо апгрейдить сервер, так как он не выдерживает всего лишь 1гб траффа форума за 15 часов... :)

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