Добрый день!

В последнее время начались проблемы с MySQL из-за высокой нагрузки. Периодически играюсь с настройками my.cnf.

Особенно достают очень медленные запросы по 7-10 сек, все из таблицы ibf_posts. За час их набегает очень много. В табличке ibf_posts >1 млн. записей. ОЗУ на серваке 16 ГБайт, проц I7 2600. Версия 3.3.4, обновляемая с 1.3 (с 2003 года). БД никогда не чистилась на предмет лишних таблиц и т.д.

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

Данные 786.2 МБ

Индекс 570.8 МБ

Т.е. размер индекса не намного меньше самих данных. Из-за чего только под параметр key_buffer_size пришлось выделить 1 Гиг ОЗУ.

Скриншот прилагаю.

Просьба кому нетрудно выложить скриншот своего рабочего форума, чтобы сравнить индексы. Желательно 3.3.4 версии

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

 

Т.е. размер индекса не намного меньше самих данных. Из-за чего только под параметр key_buffer_size пришлось выделить 1 Гиг ОЗУ.

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

Запросы все такие:

# Time: 130214 11:12:00
# User@Host: bd_ipb[bd_ipb] @ localhost []
# Query_time: 5.541179  Lock_time: 0.000194 Rows_sent: 20  Rows_examined: 4602202
SET timestamp=1360825920;
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_other
s,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=0 )
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=8592 AND  p.queued=0  ORDER BY p.pid asc LIMIT 9860,20;

 

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

Ну это да, поэтому и загрузил все в память, т.к. форум до этого ужасно тормозил. А памяти 16 Гб на серваке. Правда апач много сжирает (хотя и работает бэкэндом на динамику), при следующем переезде поставлю nginx и php-fpm.

Похоже что один и тот же случай http://ipbskins.ru/forum/topic11408.html#entry74433

 

ORDER BY p.pid asc LIMIT 9860,20;

Это же сколько страниц в этой теме?..

Конкретно в этой теме: 9892 ответов в теме и 495 страниц :) Но вообще таких тем много на форуме, где за 10 тыс. ответов.

Спасибо за линк, буду изучать