smf_log_topics можно очищать?

[kak2z]

Ну собственно сабж. smf_log_topics уже 35 мегабайт. Его можно в пхпАдмине почистить?

[Bugo]

Очищайте. Только все темы превратятся в новые (непрочитанные).

[kak2z]

О) Буго, рад видеть) Тогда наверно не буду трогать) А то посетители возмутятся.

[smart]

Так, братья по оружию, помогайте. У нас на joomlaforum.ru указанная таблица уже больше 7 млн. записей, размер ее без индексов за 400мб. В результате операции удаления тем очень медленные. Видел решения на забугорных форумах, которые помечают все темы как прочитанные для пользователей, которые не заходили на форум N-дней. Но я не очень понимаю, чем это может помочь, ибо пометка темы как прочитанной запись из таблицы не уберет же.

Посему появилась мысль, а что если удалить из этой таблицы все записи для пользователей, которые (допустим) больше полугода не ходили на форум. По сути, те кто редко ходят вряд ли как-то испытают серьезный дискомфорт. Ибо сейчас на форуме 26 тыс пользователей и 600 тыс сообщений. Да, форум 1.0.15, на 2-ю версию обновляться пока не решаемся - есть куча изменений, которые быстро не перенести.

Какие еще есть идеи?

[digger®]

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

Уберет.

[smart]

Тогда объясните, почему уберет-то? Я так понимаю данная таблица хранит информацию о том, до какого сообщения в теме пользователь прочитал (по факту там хранится ID последнего сообщения в теме, на момент последнего просмотра темы пользователем). Если мы удаляем из данной таблицы все строки - то все темы на форуме станут непрочитанными - так? Тогда почему при пометке тем прочитанными, количество записей в этой таблице уменьшится?

И еще, смотрю таблицу в phpMyAdmin, в ней 3813821 записей, обновляю через 2 секунды - 4601661, обновляю еще через пару секунд - 4477650. Почему такие существенные изменения? Ну за пару секунд не может по идее быть таких изменений, в этот момент на форуме 100 пользователей всего. Они не могут за 2 секунды так сильно повлиять на кол-во строк. Но ведь гости никак в этой таблице не фиксируются? Или я неправ?

[digger®]

Тогда объясните, почему уберет-то? Я так понимаю данная таблица хранит информацию о том, до какого сообщения в теме пользователь прочитал (по факту там хранится ID последнего сообщения в теме, на момент последнего просмотра темы пользователем). Если мы удаляем из данной таблицы все строки - то все темы на форуме станут непрочитанными - так? Тогда почему при пометке тем прочитанными, количество записей в этой таблице уменьшится?

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

Я даже проверил только что опытным путем:
посмотрел в smf_log_topics, там есть записи для моего id;
зашел в непрочитанные сообщения на форуме и все отметил прочитанным;
все записи в smf_log_topics для моего id удалились.

Все мои умозаключения относятся к SMF2. Возможно что на 1.0 эти механизмы работали как-то иначе.

[smart]

Так, если

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

то почему:

Очищайте. Только все темы превратятся в новые (непрочитанные).

Или если тема прочитана не полностью, то записи в этой таблице, а если прочитана целиком то в какой-то другой?

[digger®]

Так, если
то почему:
Или если тема прочитана не полностью, то записи в этой таблице, а если прочитана целиком то в какой-то другой?

Когда юзер отмечает все прочитанным, из smf_log_topics записи удаляются, а в log_mark_read делается запись о последнем прочитанном сообщении.
Для понимания механизма, можно посмотреть функции MarkRead и MarkBoardsRead в Subs-Boards.php.

Я бы на вашем месте просто удалил из smf_log_topics записи для юзеров которых не было на форуме X дней и все.

[smart]

Я бы на вашем месте просто удалил из smf_log_topics записи для юзеров которых не было на форуме X дней и все.

ну вот я к этому все больше и склоняюсь, я щас посчитал, если удалить записи для всех кого не было год, то это 500 тыс, а по факту можно и полугодовой интервал взять. Спасибо!

[digger®]

ну вот я к этому все больше и склоняюсь, я щас посчитал, если удалить записи для всех кого не было год, то это 500 тыс, а по факту можно и полугодовой интервал взять. Спасибо!

Если в smf_log_topics миллионы записей, может ее пора в innodb перегнать?

[smart]

Она уже лет 5 как InnoDB у нас. Просто удивляет изменение ее размеров за короткие промежутки времени. Она бывает то 7 млн, то 3. Вот сейчас запустил скрипт пометки тем как прочитанных для всех пользователей, которые не были на форуме более 90 дней. В итоге, размер уменьшился сначала до 2.5 млн, потом увеличился до 3.5. Попытка удаления с форума 30 тем приводит к 500 ошибке, у MySQL висят запросы вида:

Код (sql) Выделить Развернуть

DELETE FROM smf_log_topics WHERE ID_TOPIC IN (182182, 178962, 175543, 175466, 175347, 175175, 175027, 174992, 174920, 174425, 174654, 174868, 168533, 174818)

Индекс по ID_TOPIC присутствует. Уже подумываю может быть явно в запросе указать USE INDEX? Ну смешно, 3млн для индекса это ведь не цифра? Я работал с базами по 400 млн записей (правда на Informix), и никогда таких проблем не имел.

[Mavn]

Серег а какие таблицы у тебя вообще в иннодб?
тут посмотрел на одном большом форуме там таблица содержит вообще >15кк записей и проблем нет
списочек выкладываю чего у нас в иннодб на большом форуме

Код Выделить Развернуть


smf_log_mark_read InnoDB
smf_log_notify         InnoDB
smf_log_online         InnoDB
smf_log_search_words    InnoDB
smf_log_topics         InnoDB
smf_members            InnoDB
smf_messages                    InnoDB
smf_personal_messages     InnoDB
smf_pm_recipients     InnoDB
smf_topics            InnoDB


[smart]

Все перечисленные, за исключением smf_messages у меня в InnoDB...

[kak2z]

Если в smf_log_topics миллионы записей, может ее пора в innodb перегнать?

а как перегнать в innodb? у меня уже 13 000 000 записей)

[digger®]

а как перегнать в innodb? у меня уже 13 000 000 записей)

Можно для начала отметить все прочитанным для юзеров, которых с год на форуме не было. Мод Admin Toolbox поможет.

[kak2z]

Admin Toobox

на оффе по старой ссылке вот что говорят "Sorry but no mod was found"

[digger®]

на оффе по старой ссылке вот что говорят "Sorry but no mod was found"

https://github.com/Spuds/SMF-Admin-Toolbox

[kak2z]

https://github.com/Spuds/SMF-Admin-Toolbox

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

[valek0972]

подскажите еще как моды и с гитхаба ставить?)

Перепаковать нужно.

[kak2z]

Перепаковать нужно.

спасибо)) помогло)) а я просто перекинул в том же самом архиве из папки в корень)

[kak2z]

было 13 000 000 после работы Тулбокса, стало 9 000 000
вопрос все таки остается открытым)
можно и нужно ли переводить базу в InnoDB и что это даст и почему?)

А вот так тулбокс работал у меня)) 

[GeorG]

В Гугле есть способы, по ключам если искать - mysql+innodb+перевод

[kak2z]

В Гугле есть способы, по ключам если искать - mysql+innodb+перевод

я искал) даже находил что прямо из пхпадмина можно это делать..
только все грозятся что какие то связи потеряются..
и я по прежнему не могу понять что дает этот переход..
многие пишут что innoDB круче.. но чем круче я так и не понял))
меня именно такие нюансы озадачивают)

[GeorG]

Он круче, с многомиллионными записями в таблице, а так мускул быстрее, но не с миллионами записей (это очень простыми словами, есть кучи нюансов).

[digger®]

можно и нужно ли переводить базу в InnoDB и что это даст и почему?)

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

Таблицы, которые имеет смысл перевести в InnoDB:

Код (sql) Выделить Развернуть

ALTER TABLE smf_attachments ENGINE=InnoDB;
ALTER TABLE smf_collapsed_categories ENGINE=InnoDB;
ALTER TABLE smf_log_actions ENGINE=InnoDB;
ALTER TABLE smf_log_boards ENGINE=InnoDB;
ALTER TABLE smf_log_errors ENGINE=InnoDB;
ALTER TABLE smf_log_karma ENGINE=InnoDB;
ALTER TABLE smf_log_mark_read ENGINE=InnoDB;
ALTER TABLE smf_log_online ENGINE=InnoDB;
ALTER TABLE smf_log_topics ENGINE=InnoDB;
ALTER TABLE smf_members ENGINE=InnoDB;
ALTER TABLE smf_sessions ENGINE=InnoDB;
ALTER TABLE smf_settings ENGINE=InnoDB;
ALTER TABLE smf_topics ENGINE=InnoDB;
ALTER TABLE smf_log_activity ENGINE=InnoDB;
ALTER TABLE smf_pm_recipients ENGINE=InnoDB;
ALTER TABLE smf_pm_rules ENGINE=InnoDB;
ALTER TABLE smf_log_spider_stats ENGINE=InnoDB;

smf_log_floodcontrol лучше перевести в Memory

Код (sql) Выделить Развернуть

DROP TABLE smf_log_floodcontrol;
CREATE TABLE `smf_log_floodcontrol` (
  `ip` char(16) NOT NULL default '',
  `log_time` int(10) unsigned NOT NULL default '0',
  `log_type` varchar(8) NOT NULL default 'post',
  PRIMARY KEY  (`ip`,`log_type`)
) ENGINE=MEMORY;

MySQL желательно тюнить, обязательно поставить:

Код (ini) Выделить Развернуть

innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 2
innodb_buffer_pool_size = 256M

Размер innodb_buffer_pool_size нужно подобрать самостоятельно, исходя из доступной оперативной памяти и размера имеющихся данных в таблицах InnoDB. Скрипт mysqltuner.pl окажет неплохую помощь.