откуда у людей такая тяга к ORDER BY RAND()? медленнее придумать сложно.

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

то что отвечает хостер бред полнейших потому что ошибка в mysql и логика скрипта (несмотря на всю кривожопость dle) не причем!

показал хостеру сообщение. Его ответ был таков:



Есть мысли у вас. как решить проблему?
Сейчас попробую вырубить модуль на день, посмотрим, каков результат будет. сли дело в нем, то буду долбать разработчика.

как вы думаете зачем мне решать чужие проблемы?

Понял...
Лично я, если бы имел достаточно знаний в этом деле, помог бы человеку...

портал большой? сколько людей ходит в сутки? Как насчет переехать?

помочь советом и сделать чью то работу, согласитесь, это разные вещи. я вам уже помог обозначив три самые вероятные причины они покрывают 80% случаев возникновения этой ошибки. если вы уверены в своем хостере... (я лично очень сомневаюсь) то проблема не имеет тривиального решения и отнимет много времени.

На одном 7к стабильно, на другом (тот что глючит) 2,5-3к в сутки. Так постоянно было, но почему-то глючить начало только недавно и глючит только тот сайт, который меньше.
Хотя в воскресенье я заметил очень большое количество посетителей. Могло ли это создать небольшую нагрузку на сервак, в следствии которой нарушилась таблица и началась ошибка, создающая вообще большую нагрузку...? Может быть такое?

Сообщение отредактировал Axel - 22.12.2010, 10:36

Если не секрет что за хостер ? Возможно у него эта ошибка часто бывает и кто то с ней уже там сталкивался.

Использование ORDER BY RAND не только медленно, но и сильно грузит сервер

Похоже что по этому запросу MySQL выбирает все строки из таблицы dle_post, записывает их во временную таблицу с дополнительным полем, в которое сохранаются результаты работы функции RAND (для каждой строки таблицы вычисляется случайное значение вида 0.00433708355234664), сортирует временную таблицу по добавленному полю и только после этого выбирает из временной таблицы строки, удовлетворяющие условию "WHERE approve='1' AND lenta='1'".

Это не очень долго, если в таблице десятки или сотни записей, а если там сотни тысяч или миллионы записей ?

Допустим что такой запрос выполняется 5 секунд (при достаточном объеме таблицы), тогда даже не нужно DDOS атаки, достаточно одного робота-индексатора.
Если он будет присылать 5 запросов в секунду, то уже к моменту завершения формирования ответа на первый запрос во временном каталоге будет 25 временных таблиц, по объему превышающих ту, к которой выполняется SQL-запрос. Это же так нагрузит сервер, что запрос уже не будет выполняться даже и за те 5 секунд, что нужны для еденичного запроса, что еще больше усугубит ситуацию и просто повесит сервер.

Axel, может у Вас действительно большая таблица dle_post ?

Или в момент проблем была не DDOS атака, а просто что-то похожее на частые запросы одной и той же страницы, на которой вызывается этот SQL-запрос (посмотрите в логах). Я встечал такое у себя в логах: с одного IP в течении десятков минут запрашивается одна страница с периодичностью 5-10 раз в секунду (тогда я посчитал это просто глюком в браузере посетителя).