[Вопрос]

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

# Time: 121206  8:49:58
# User@Host: 
# Query_time: 1793.850997  Lock_time: 0.000024 Rows_sent: 0  Rows_examined: 6280058708
SET timestamp=1354780198;
SELECT pmtext.pmtextid
	FROM pmtext AS pmtext
	LEFT JOIN pm AS pm USING(pmtextid)
	WHERE pm.pmid IS NULL;
# Time: 121206  9:49:22
# User@Host:
# Query_time: 1747.685036  Lock_time: 0.000026 Rows_sent: 1  Rows_examined: 6281055549
SET timestamp=1354783762;
SELECT pmtext.pmtextid
	FROM pmtext AS pmtext
	LEFT JOIN pm AS pm USING(pmtextid)
	WHERE pm.pmid IS NULL;
# Time: 121206 10:49:41
# User@Host: 
# Query_time: 1771.975106  Lock_time: 0.000026 Rows_sent: 0  Rows_examined: 6281180161
SET timestamp=1354787381;
SELECT pmtext.pmtextid
	FROM pmtext AS pmtext
	LEFT JOIN pm AS pm USING(pmtextid)
	WHERE pm.pmid IS NULL;

Время запуска запроса с периодом запуска ровно раз в час не наводит на мысли? Это периодическая задача очистки "потерявшихся" личных сообщений из cron.
Если мешает, ее можно вынести в отдельный файл и пореже запускать

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

Получается запрос работает ~ 1800 секунд, то есть каждый на полчаса. Это уже проблема.

Сам объем таблице около 50 мегабайт, может стоит почистить её?

А пользователям что скажешь? это же личные сообщения.

Думаю, можно отредактировать эту задачу в файле includes/cleanup2.php. и пусть себе теряются сообщения. Это не должно мешать работе форума и настолько редкий случай, что можно хоть раз в месяц делать проверку.
Логика разработчиков была в том, чтобы если во время процессов отправки/удаления внезапно остановился скрипт, то база сохраняла логичные связи и не имела лишних.
Сам запрос LEFT JOIN .. WHERE id IS NULL это поиск не связанных "что есть в одном множестве, чего нет в другом". Его практически никак не ускорить. Можно только разбить на итерации.

Вообще, что вы там такого шлете? Медленный сервер должен был уже давно ограничить вас по другим параметрам. Может какие-то хаки для личных сообщений особенные стоят?

да ничего не стоит. сервер с 24 гб оперативы и i7 970 проц на один форум.
была проблема с тем что слетела таблица user, пришлось залить её отдельно с двух недельной давности бекапа, возможно из за этого, что-то нарушилось.
а если чистить, какие таблицы связаны с пм?

в top которые нижние значения, загрузка mysql стоит 100%, бывает и больше. хотя сверху cpu 0,6%
видимо какие-то ядра загружает.

Личные сообщения хранятся в нескольких таблицах. Там все имена таблиц начинаются с pm. pm и pmtext основные.
50 мб это какая из? Объем-то небольшой для неплохого сервера. Просто нетипично, чтобы личные сообщения оказывали заметный эффект на работу. Гораздо раньше влиять начинают другие компоненты форума.

pm=3.7 МБ
pmreceipt=118.6 КБ
pmtext=50.2 МБ

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

закоментировал в cleanup2 очистку, нагрузка на проц от мускула пропала, теперь нормально работает.

апну тему - только что довелось решать точно такую же проблему: запуск по крону очистки утерянных PM стабильно валил сервак
не только симптомы, но и история схожая: проблема возникла после восстановления из бэкапа

Диагностика:
отправляемся в ПМА, открываем таблицы pm и pmtext - структура, и смотрим внизу, где индексы, в пункте "комментарий" - а не указано ли там disabled?
если да (выключены/заблокированы индексы) -
решение: выполняем запрос
ALTER TABLE 'имя_таблицы' ENABLE KEYS
и, кстати, проверяем остальные таблицы, что там?
после разблокирования индексов проблема исчезнет