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

 

core_item_markers

Форум 3.1.2

 

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

| 1032988 | baza_db | localhost | baza | Query | 0 | Locked | INSERT INTO ibf_core_item_markers (`item_app_key_1`,`item_last_update`,`item_global_reset`,`item_unr |
| 1033006 | baza_db | localhost | baza | Query | 39 | Locked | INSERT INTO ibf_core_item_markers (`item_app_key_1`,`item_last_update`,`item_global_reset`,`item_unr |
| 1033008 | baza_db | localhost | baza | Query | 39 | Locked | INSERT INTO ibf_core_item_markers (`item_app_key_1`,`item_last_update`,`item_global_reset`,`item_unr |
| 1033010 | baza_db | localhost | baza | Query | 1 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033014 | baza_db | localhost | baza | Query | 3 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033015 | baza_db | localhost | baza | Query | 0 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033018 | baza_db | localhost | baza | Query | 38 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033019 | baza_db | localhost | baza | Query | 13 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033021 | baza_db | localhost | baza | Query | 39 | Locked | INSERT INTO ibf_core_item_markers (`item_app_key_1`,`item_last_update`,`item_global_reset`,`item_unr |
| 1033024 | baza_db | localhost | baza | Query | 0 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033025 | baza_db | localhost | baza | Query | 3 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033026 | baza_db | localhost | baza | Query | 39 | Locked | INSERT INTO ibf_core_item_markers (`item_app_key_1`,`item_last_update`,`item_global_reset`,`item_unr |
| 1033028 | baza_db | localhost | baza | Query | 3 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033029 | baza_db | localhost | baza | Query | 0 | cleaning up | INSERT INTO ibf_core_item_markers (`item_app_key_1`,`item_last_update`,`item_global_reset`,`item_unr |
| 1033030 | baza_db | localhost | baza | Query | 39 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033032 | baza_db | localhost | baza | Query | 0 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033034 | baza_db | localhost | baza | Sleep | 12 | | |
| 1033035 | baza_db | localhost | baza | Query | 39 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033036 | baza_db | localhost | baza | Query | 3 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033038 | baza_db | localhost | baza | Query | 38 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033039 | baza_db | localhost | baza | Query | 3 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033041 | baza_db | localhost | baza | Query | 38 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033042 | baza_db | localhost | baza | Query | 12 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033045 | baza_db | localhost | baza | Query | 38 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033046 | baza_db | localhost | baza | Query | 3 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |
| 1033047 | baza_db | localhost | baza | Query | 13 | Locked | INSERT INTO ibf_core_item_markers (`item_key`,`item_member_id`,`item_app`,`item_last_update`,`item_l |

В итоге процессы apache корректно не отрабатывают, а висят и ждут возможности подключения к mysql, при этом забивая собой всю доступную память. Затем идет свопинг винта и все проседает.

 

Не когда не смотрел таблицу - core_item_markers

Сегодня посмотрел :)

1,030,128 записей 188.1 МБ

Данные	140.3	МБ
Индекс	48,674.0	КБ
Фрагментировано	 60	Байт
Эффективность	187.8	МБ
Всего	187.8	МБ

 

На аналогичном форуме (по нагрузке) но там 3.2.3

74,284 записей 45.6 МБ

Данные 	42,281.5 	КБ
Индекс 	4,401.0 	КБ
Фрагментировано 	699.5 	КБ
Эффективность 	45,983.0 	КБ
Всего 	46,682.5 	КБ

@Ph-A, таблица MyISAM или InnoDB?

Полный лог запроса есть?

таблица MyISAM или InnoDB?

Пока в MyISAM. Планирую переезд на новый сервер и тогда можно включать InnoDB

 

Полный лог запроса есть?

Неа, надо в логи лезть.

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

1 млн записей это конечно много, особенно если учесть что эта таблица дергается постоянно.

1 млн записей это конечно много

у меня большое сомнение, что они все реальные и нужные. Думаю не почистить таблицу :)

 

особенно если учесть что эта таблица дергается постоянно.

Но падает раз в день-два-три и то не всегда. Причем не при самых сильных загрузках.

И что не понятно, не помогает перезагрузка. Можно час - два не дергатся :)

 

А на 3.2.3 есть полезная настройка

Частота сохранения статуса прочитанности?

Статусы прочитанности тем хранятся в базе данных, их обновление достаточно ресурсоемкая операция. Потому IP.Board на время работы пользователя с форумом сохраняет статусы в сессии пользователя. Данная опция позволяет настроить время через которое статусы из сессии будут добавляться в базу. Чем больше время тем меньше нагрузка, но больше риск потери статусов, чем меньше время, тем меньше риск потери, но выше нагрузка.

 

А если включить логи медленных запросов?

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

Первый выскочил сразу

 

# Time: 130206 23:12:45
# User@Host: nikon_db[nikon_db] @ localhost []
# Query_time: 20  Lock_time: 1  Rows_sent: 0  Rows_examined: 0
use nikon;
DELETE FROM ibf_core_item_markers_storage WHERE item_member_id IN (36329,26205,28435,30814,36367,19065,31479,29566,22621,8882,37635,36627,16749,31478,37995,26533,31118,12709,31346,22379,7401,38529,28482,23452,25491,12542,35284,28888,14918,22829,38036,37024,13843,35519,9376,16605,25586,24389,8456,28357,16075,34898,38043,21140,32451,21843,38848,38643,10202,36830);
# Time: 130206 23:21:42
# User@Host: _db[_db] @ localhost []
# Query_time: 103  Lock_time: 4  Rows_sent: 1  Rows_examined: 0
SELECT m.*, m.member_id as my_member_id,p.*,pp.*,g.*,im.*,ccb.cache_content FROM ibf_members m  LEFT JOIN ibf_pfields_content p ON ( p.member_id=m.member_id ) 
LEFT JOIN ibf_profile_portal pp ON ( pp.pp_member_id=m.member_id ) 
LEFT JOIN ibf_groups g ON ( g.g_id=m.member_group_id ) 
LEFT JOIN ibf_core_item_markers_storage im ON ( im.item_member_id=m.member_id ) 
LEFT JOIN ibf_content_cache_sigs ccb ON ( ccb.cache_content_id=m.member_id )   WHERE m.member_id=1;

Имхо, чистить надо. Даже небольшой delete выполняется по 20 сек

Имхо, чистить надо

Аналогично

 

Даже небольшой delete выполняется по 20 сек

Подозрение, что система чем-то еще занята.

 

Глюки странные. Две - три ночи вылетают, потом неделю без тормозов работают.