Форум пользователей MySQL

Такая же штука.

Постепенно нагрузка увеличивалась и я решил сконвертировать базы в InnoDB. Остался доволен, однако в slow.log начали падать запросы вида: "SHOW TABLE STATUS FROM ***", некоторые даже до 6 секунд доходят, причём это происходит для таблиц InnoDB и MyIsam, а особенно если листать information_schema. Раньше вроде этого не было или я не замечал.

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

Я думаю, нужно задуматься о том, из чего состоит выполнение запроса SHOW TABLE STATUS с точки зрения сервера.

Может, дело в том, что таблицы с дырками, и какая-нибудь операция выполняется медленно?

А база нагружена? Что показывает SHOW FULL PROCESSLIST?

count(*) может медленно работать на Innodb, так как требуется полный скан таблицы

rgbeast написал:

А база нагружена? Что показывает SHOW FULL PROCESSLIST?

count(*) может медленно работать на Innodb, так как требуется полный скан таблицы

Сервер не нагружен, нагрузка процессора до 5%. Раньше было очень много sleep'ов, потом поставил 120 секунд таймаут и процессов доходит где-то до 50, а в среднем и то меньше. Кстати на производительности это никак не сказалось.

Про полный скан знаю, но неужели нет способа уменьшить это время. Плюс в основном count(*) тормозит для information_schema, это вообще не критично, естественно, но проблема имеет место.

paulus написал:

INFORMATION_SCHEMA - все-таки, виртуальная база, она НЕ MyISAM, НЕ MEMORY и НЕ InnoDB.
Запрос тормозит, потому что приходится делать SHOW TABLE STATUS.

Выполните запрос для базы information_schema:

То там будет явно указан тип ENGINE таблиц information_schema. Это просто так?

Отредактированно Kassad (01.10.2008 21:03:29)

Тестировал ночью. Попробовал сегодня запустить сервер с NO_ENGINE_SUBSTITUTION. За день ни одного медленного запроса, хм, совпадение или... Честно говоря не вижу связи.

Дело точно не в том, что я перезагрузил mysql (не сервер). Если нет одназначного ответа, то не будем гадать на кофейной гуще, на самом деле может быть сотня причин, я даже немного удивился, что вы не спросили версию mysql и конфиг, кстати версия mysql 5.0.45. В общем, меня сейчас интересует один вопрос, почему же эта information_schema такая медленная и есть ли варианты исправления? Ну не дело запросы по 0.5-4 секунды выполнять для этой базы. Что касается count(*) и статуса, то я в принципе ими доволен. За 2 последние дня был только 1 медленный зпрос count(*) на таблицу с 200000 записями, который занял 3 секунды, что в глобальных масштабах приемлимо.

Возвращаясь к NO_ENGINE_SUBSTITUTION, у меня на сервере достаточно высокий показатель Created_tmp_tables, может это влияет, да и Created_tmp_disk_tables не 0 (запись временных таблиц на диск), вероятно тут задержки были, да и есть. Плюс кто-то из пользователей мог движок поменять в этот момент, запросы другие и т.д., уже не понять точную картину. Но всё равно как-то шустрей стало.

Это вы опрометчиво. Всё вышеперичленное бага, после долгих поисков и тестов я нашёл ответы на свои вопосы в листе багов на официальном сайте. Обновился до 5.1.28 и всё стало отлично. Увеличение Created_tmp_tables это баг, когда счётчик увеличивается как раз при вызове show table status и некоторых других моментах, честно говоря не вникал особо. Запрсы вида count(*) и show table status стали на порядок лучше работать, хотя ещё скрепя сердце увеличил буфферный пул и некоторые другие настройки, но это как бонус.

NO_ENGINE_SUBSTITUTION был не при чём, просто повезло 2 дня после его прописи. information_schema у меня не тормозит с дефолтным движком myisam и нормальными под него настройками, при InnoDB как тормозила, так и тормозит, ну и фиг с ней. Видимо тоже баг.