История такова 18 дек побилась таблица сообщений в БД, была восстановлена по средствам phpmyadmin, 19 дек были увеличены ресурсы VDS до 4х2000CPU и 3Г RAM до этого было 2х2000CPU и 1.5гRAM не хватало часто бились таблицы в пиках. Всё вроде заработало нормально, но уже 21дек количество файловых дескрипторов выросло до 50% или по другому 2000шт до этого на меньшем VDS дескрипторы не превышали 25%. Попытки выявить из за чего привели к БД форума, именно она создает такое количество дескрипторов т.к если остановить mysql то их становится 400шт, в переписке с хостерами не чем помочь не могли сказали что не чего критичного на vds они не видят и что это только 50% из доступных типа беспокоится не стоит. Ну как бы ладно 50 дак 50, но у форума увеличилось время генерации страниц в больших темах то есть тема на 1-2 страницы генерируется за 0.1сек а тема на 130 страниц за 5-9сек что естественно сказывается на посетителях им не по приколу ждать загрузки страниц таких тем по 9 секунд.

Проверил базу на индексы по средствам SSH и через админку форума все нормально. В это время не память, не проц, не превышают 15% по нагрузке

Что может быть куда копать???

Как минимум включить лог запросов.

 

В секции [mysqld]

 

Логирование медленых запросов:

 

slow_query_log = On

long_query_time = 2

slow_query_log_file = /path_to_logs/mysql-slow-query.log

 

Логирование всех запросов:

 

general_log = on

general_log_file = /path_to_logs/mysql-query.log

Включил туда посыпались такие запросы

# Time: 130203 23:03:49
# User@Host: *** @ localhost []
# Query_time: 4.423263  Lock_time: 0.000179 Rows_sent: 20  Rows_examined: 1051339
use ***;
SET timestamp=1359918229;
SELECT p.*,m.member_id as mid,m.name,m.member_group_id,m.email,m.joined,m.posts, m.last_visit, m.last_activity,m.login_anonymous,m.title as member_title, m.warn_level, m.warn_lastwarn, m.members_display_name, m.members_seo_name, m.member_banned, m.has_gallery, m.has_blog, m.members_bitoptions,m.mgroup_others,pp.*,w.wl_id,pc.*,rep_index.rep_rating as has_given_rep,rep_cache.rep_points, rep_cache.rep_like_cache,cca.*,ccb.cache_content as cache_content_sig, ccb.cache_updated as cache_updated_sig FROM ibf_posts p  LEFT JOIN ibf_members m ON ( m.member_id=p.author_id ) 
LEFT JOIN ibf_profile_portal pp ON ( m.member_id=pp.pp_member_id ) 
LEFT JOIN ibf_members_warn_logs w ON ( w.wl_content_app='forums' and w.wl_content_id1=p.pid ) 
LEFT JOIN ibf_pfields_content pc ON ( pc.member_id=p.author_id ) 
LEFT JOIN ibf_reputation_index rep_index ON ( rep_index.app='forums' AND 
					             rep_index.type='pid' AND 
					             rep_index.type_id=p.pid AND 
					             rep_index.member_id=2 ) 
LEFT JOIN ibf_reputation_cache rep_cache ON ( rep_cache.app='forums' AND rep_cache.type='pid' AND rep_cache.type_id=p.pid ) 
LEFT JOIN ibf_content_cache_posts cca ON ( cca.cache_content_id=p.pid ) 
LEFT JOIN ibf_content_cache_sigs ccb ON ( ccb.cache_content_id=m.member_id )   WHERE p.topic_id=20586 AND  p.queued IN (0,1,2)  ORDER BY p.pid asc LIMIT 2560,20;
# Time: 130203 23:03:57
# User@Host: *** @ localhost []
# Query_time: 4.228205  Lock_time: 0.000287 Rows_sent: 20  Rows_examined: 1051339
SET timestamp=1359918237;
SELECT p.*,m.member_id as mid,m.name,m.member_group_id,m.email,m.joined,m.posts, m.last_visit, m.last_activity,m.login_anonymous,m.title as member_title, m.warn_level, m.warn_lastwarn, m.members_display_name, m.members_seo_name, m.member_banned, m.has_gallery, m.has_blog, m.members_bitoptions,m.mgroup_others,pp.*,w.wl_id,pc.*,rep_index.rep_rating as has_given_rep,rep_cache.rep_points, rep_cache.rep_like_cache,cca.*,ccb.cache_content as cache_content_sig, ccb.cache_updated as cache_updated_sig FROM ibf_posts p  LEFT JOIN ibf_members m ON ( m.member_id=p.author_id ) 
LEFT JOIN ibf_profile_portal pp ON ( m.member_id=pp.pp_member_id ) 
LEFT JOIN ibf_members_warn_logs w ON ( w.wl_content_app='forums' and w.wl_content_id1=p.pid ) 
LEFT JOIN ibf_pfields_content pc ON ( pc.member_id=p.author_id ) 
LEFT JOIN ibf_reputation_index rep_index ON ( rep_index.app='forums' AND 
					             rep_index.type='pid' AND 
					             rep_index.type_id=p.pid AND 
					             rep_index.member_id=2 ) 
LEFT JOIN ibf_reputation_cache rep_cache ON ( rep_cache.app='forums' AND rep_cache.type='pid' AND rep_cache.type_id=p.pid ) 
LEFT JOIN ibf_content_cache_posts cca ON ( cca.cache_content_id=p.pid ) 
LEFT JOIN ibf_content_cache_sigs ccb ON ( ccb.cache_content_id=m.member_id )   WHERE p.topic_id=20586 AND  p.queued IN (0,1,2)  ORDER BY p.pid asc LIMIT 2560,20;
# Time: 130203 23:04:04
# User@Host: **** @ localhost []
# Query_time: 5.595800  Lock_time: 0.000207 Rows_sent: 20  Rows_examined: 1183964
SET timestamp=1359918244;
SELECT p.*,m.member_id as mid,m.name,m.member_group_id,m.email,m.joined,m.posts, m.last_visit, m.last_activity,m.login_anonymous,m.title as member_title, m.warn_level, m.warn_lastwarn, m.members_display_name, m.members_seo_name, m.member_banned, m.has_gallery, m.has_blog, m.members_bitoptions,m.mgroup_others,pp.*,w.wl_id,pc.*,rep_index.rep_rating as has_given_rep,rep_cache.rep_points, rep_cache.rep_like_cache,cca.*,ccb.cache_content as cache_content_sig, ccb.cache_updated as cache_updated_sig FROM ibf_posts p  LEFT JOIN ibf_members m ON ( m.member_id=p.author_id ) 
LEFT JOIN ibf_profile_portal pp ON ( m.member_id=pp.pp_member_id ) 
LEFT JOIN ibf_members_warn_logs w ON ( w.wl_content_app='forums' and w.wl_content_id1=p.pid ) 
LEFT JOIN ibf_pfields_content pc ON ( pc.member_id=p.author_id ) 
LEFT JOIN ibf_reputation_index rep_index ON ( rep_index.app='forums' AND 
					             rep_index.type='pid' AND 
					             rep_index.type_id=p.pid AND 
					             rep_index.member_id=1024 ) 
LEFT JOIN ibf_reputation_cache rep_cache ON ( rep_cache.app='forums' AND rep_cache.type='pid' AND rep_cache.type_id=p.pid ) 
LEFT JOIN ibf_content_cache_posts cca ON ( cca.cache_content_id=p.pid ) 
LEFT JOIN ibf_content_cache_sigs ccb ON ( ccb.cache_content_id=m.member_id )   WHERE p.topic_id=35014 AND  p.queued=0  ORDER BY p.pid asc LIMIT 5560,20;

 

Что тут к чему???

Rows_examined: 1183964

Мускул пишет, что было обработано 1183964 строк. Проверьте все же еще раз индексы на таблице постов, даже учитывая что используется ORDER BY, он должен перебирать только записи конкретной темы.

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

 

выполнять желательно из ssh

 

ALTER TABLE ibf_posts ENABLE KEYS

 

В вашем случае есть смысл перейти на два запроса

1 - Выбираем все pid-ы по условию WHERE из основного запроса

2 - Делаем основной запрос с условием WHERE pid IN (pids)

 

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

Через phpmyadmin запрос выполнился мгновенно за 0.6 сек только что то не понял как обрабатывалось столько строк если в таблице ibf_posts их всего 496248

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

Вот скрин структуры таблицы

http://img-fotki.yandex.ru/get/4118/18069569.2/0_8ee29_18f266c3_XXXL.jpg

Через phpmyadmin запрос выполнился мгновенно за 0.6 сек

Значит индексы включены.

 

Вот скрин структуры таблицы

Покажите результат запроса

 

EXPLAIN SELECT p.*,m.member_id as mid,m.name,m.member_group_id,m.email,m.joined,m.posts, m.last_visit, m.last_activity,m.login_anonymous,m.title as member_title, m.warn_level, m.warn_lastwarn, m.members_display_name, m.members_seo_name, m.member_banned, m.has_gallery, m.has_blog, m.members_bitoptions,m.mgroup_others,pp.*,w.wl_id,pc.*,rep_index.rep_rating as has_given_rep,rep_cache.rep_points, rep_cache.rep_like_cache,cca.*,ccb.cache_content as cache_content_sig, ccb.cache_updated as cache_updated_sig FROM ibf_posts p  LEFT JOIN ibf_members m ON ( m.member_id=p.author_id ) 
LEFT JOIN ibf_profile_portal pp ON ( m.member_id=pp.pp_member_id ) 
LEFT JOIN ibf_members_warn_logs w ON ( w.wl_content_app='forums' and w.wl_content_id1=p.pid ) 
LEFT JOIN ibf_pfields_content pc ON ( pc.member_id=p.author_id ) 
LEFT JOIN ibf_reputation_index rep_index ON ( rep_index.app='forums' AND 
                                    rep_index.type='pid' AND 
                                    rep_index.type_id=p.pid AND 
                                    rep_index.member_id=2 ) 
LEFT JOIN ibf_reputation_cache rep_cache ON ( rep_cache.app='forums' AND rep_cache.type='pid' AND rep_cache.type_id=p.pid ) 
LEFT JOIN ibf_content_cache_posts cca ON ( cca.cache_content_id=p.pid ) 
LEFT JOIN ibf_content_cache_sigs ccb ON ( ccb.cache_content_id=m.member_id )   WHERE p.topic_id=20586 AND  p.queued IN (0,1,2)  ORDER BY p.pid asc LIMIT 2560,20;

Вот результат

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

Выполните запросы

 

ALTER TABLE ibf_members ENABLE KEYS;
ALTER TABLE ibf_profile_portal ENABLE KEYS;
ALTER TABLE ibf_members_warn_logs ENABLE KEYS;
ALTER TABLE ibf_pfields_content ENABLE KEYS;
ALTER TABLE ibf_reputation_index ENABLE KEYS;
ALTER TABLE ibf_reputation_cache ENABLE KEYS;
ALTER TABLE ibf_content_cache_posts ENABLE KEYS;
ALTER TABLE ibf_content_cache_sigs ENABLE KEYS;

 

Потом проверьте запрос выше без EXPLAIN, за какое время он выполнится.

 

И рекомендую все таки поправить http://community.invisionpower.com/resources/bugs.html/_/ip-board/big-topics-i-mean-big-topics-r36577

Они исправили запрос и сделали подзапросом - FROM ( SELECT pid FROM ibf_posts WHERE topic_id=4754 AND queued IN (0,1,2) ORDER BY pid asc LIMIT 1020,20 ) z

Выполнил запросы все прошли довольно быстро

ну а этот запрос дал такой результат

Отображает строки 2560 - 2579 ( 20 всего, Запрос занял 5.2985 сек.) [pid: 842224 - 843465]

 

И рекомендую все таки поправить http://community.inv...g-topics-r36577

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

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

В комментариях смотрите.

Кстати да, а выполните такой запрос

 

SELECT p.*,m.member_id as mid,m.name,m.member_group_id,m.email,m.joined,m.posts, m.last_visit, m.last_activity,m.login_anonymous,m.title as member_title, m.warn_level, m.warn_lastwarn, m.members_display_name, m.members_seo_name, m.member_banned, m.has_gallery, m.has_blog, m.members_bitoptions,m.mgroup_others,pp.*,w.wl_id,pc.*,rep_index.rep_rating as has_given_rep,rep_cache.rep_points, rep_cache.rep_like_cache,ccb.cache_content as cache_content_sig, ccb.cache_updated as cache_updated_sig 
FROM ( SELECT pid FROM ibf_posts WHERE topic_id=4754 AND queued IN (0,1,2) ORDER BY pid asc LIMIT 1020,20 ) z 
LEFT JOIN ibf_posts p ON ( p.pid=z.pid ) 
LEFT JOIN ibf_members m ON ( m.member_id=p.author_id ) 
LEFT JOIN ibf_profile_portal pp ON ( m.member_id=pp.pp_member_id ) 
LEFT JOIN ibf_members_warn_logs w ON ( w.wl_content_app='forums' and w.wl_content_id1=p.pid ) 
LEFT JOIN ibf_pfields_content pc ON ( pc.member_id=p.author_id ) 
LEFT JOIN ibf_reputation_index rep_index ON ( rep_index.app='forums' AND rep_index.type='pid' AND rep_index.type_id=p.pid AND rep_index.member_id=98 ) 
LEFT JOIN ibf_reputation_cache rep_cache ON ( rep_cache.app='forums' AND rep_cache.type='pid' AND rep_cache.type_id=p.pid )
LEFT JOIN ibf_content_cache_sigs ccb ON ( ccb.cache_content_id=m.member_id )

MySQL вернула пустой результат (т.е. ноль строк). ( Запрос занял 0.0047 сек. )

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

72ст - 5с

50ст - 3.5с

25ст - 1.5с

1ст - 0.1с

Значит это баг из комментариев как то не охото править в планах было обновится до 3.4.2 но что то не дождаться от IBR локализации.

Да и смущает очень откуда взялось такое большое количество файловых дескрипторов из за mysql?

MySQL вернула пустой результат (т.е. ноль строк). ( Запрос занял 0.0047 сек. )

topic_id=4754 замените на topic_id=20586

topic_id=4754 замените на topic_id=20586

Отображает строки 0 - 19 ( 20 всего, Запрос занял 0.0381 сек.)

( 20 всего, Запрос занял 0.0381 сек.)

Что и требовалось доказать. Либо обновляйтесь, либо исправьте запрос, и будет вам профит.

Столкнулся с такой же проблемой на 3.3.4. Обновляться на 3.4.2 пока что не хочется, смотрю там еще глюков много.

По этой теме пытался сделать фикс запрос (см. сообщение от Mark Sep 10 2012 06:20 PM)

Но только вношу первую правку и при просмотре любой темы получаю сообщение об ошибке БД. Запрос пересмотрел, вроде editor ничего не напортачил при вставке. Видимо дело в самих полях запроса. Кто-нибудь разобрался что к чему там?