достал этот сервер!!!

[kkk]

Скорее всего проблема в том, что в настройки БД никто не лазил с момента установки, а с ростом нагрузки (в смысле количества всяких спамеров, ботов и прочих, ходящих на сервер одновременно) - выделенных ресурсов стало не хватать. Или, опять же из-за дефолтных настроек, вся база перестала помещаться в оперативку целиком, из-за чего начался дикий своп и тормоза. В общем, дело однозначно в базе, я пока потихоньку увеличиваю значения всяких переменных, и смотрю чо происходит

Конкретный вопрос, как вы и просили:

MySQL, после рестарта нивроткасмически быстро начинают расти значения переменных Handler_read_rnd и Handler_read_rnd_next, что, по идее, не совсем правильно. При условии, что индексы перестроены, это какой-то косяк настроек, или же так построены запросы движка форума, что так задумано, и не париться ?

Вот с этим пока непонятно, остальное вроде пока без проблем. Весь сервер ОК, винты физически исправны, тупняк - однозначно из-за базы.

[Kvarz]

Сообщение от kkk

Конкретный вопрос, как вы и просили:

MySQL, после рестарта нивроткасмически быстро начинают расти значения переменных Handler_read_rnd и Handler_read_rnd_next, что, по идее, не совсем правильно. При условии, что индексы перестроены, это какой-то косяк настроек, или же так построены запросы движка форума, что так задумано, и не париться ?

Вот с этим пока непонятно, остальное вроде пока без проблем. Весь сервер ОК, винты физически исправны, тупняк - однозначно из-за базы.

Насколько я понял, эти значения не показатель использования памяти:

Handler_read_rnd = Количество запросов на чтение строки, основанных на фиксированной позиции. Значение будет высоким, если выполняется много запросов, требующих сортировки результатов. Возможно, поступает слишком много запросов, требующих от MySQL полного сканирования таблиц или у вас есть соединения, которые не используют ключи надлежащим образом.
Handler_read_rnd_next = Количество запросов на чтение следующей строки из файла данных. Данное значение будет высоким, если производится много сканирований таблиц. Обычно это означает, что ваши таблицы не проиндексированы надлежащим образом или ваши запросы не используют преимущества индексов. (в основном при использовании OFFSET)
Даже после выполнения
FLUSH STATUS;
SHOW STATUS LIKE 'handler%';
получите handler_write=14 - число запросов на вставку в таблицу (которую вы увидите на экране),
при повторном SHOW STATUS LIKE 'handler%'; - Handler_read_rnd_next=16 (прочитано при предыдущем запросе), handler_write=29
при последующих запросах без выполнения FLUSH STATUS все накапливается.

Если увеличение этих параметров происходит - значит кто-то (может быть вы что-то модифицируете, проверяете), или "что-то" делает запросы к базе. Т е. ничего страшного в этом нет, это не показатели использования памяти.

Отсюда: http://www.sql.ru/forum/652821/mysql...bya-chto-delat

[Solmyr]

Сообщение от kkk

Конкретный вопрос, как вы и просили

задал вопрос знакомому:

знакомый: - большинство форумов написано через жопу и не рассчитано на нагрузки

я: - это да... но следует ли что-то делать с конкретной проблемой Handler_read_rnd и Handler_read_rnd_next, или забить? может на уровне базы можно оптимизировать?

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

я: - а. то есть - уйти с mysql?

знакомый: - оптимально - да
у него херовейший планировщик запросов

я: - А Мемкешед чо делает?

знакомый: - тупо складывает ветки форума в память как есть
и отдаёт из памяти если в ветку не было апдейтов
ну мемкешед вкрутить точно не помешает, его скорее всего нет, а почти все форумы умеющие мускул его умеют