Интересное поведение

интересная тема, но для начала - выяснили - какой движек формирует #sql_XXX ? и какого они размера ? просто имейте ввиду - что если временно-формированные таблицы формируются большого размера (я встречал до 16гб!!!) то вы потеряете всю оперативную память, поэтому увлекаться сильно не надо.

mysqltuner - покажет не до конца объективную картину, так как показывает он более менее вменяемые данные спустя 24часа после рестарта.

еще очищается когда логика запросов на обновление делает информацию устаревшей.

т.е. очень простенький запрос на обновление одной ранее активно читаемой таблички может привести к очистке 2 гб кеша и запрос зависнет секунд на 10.

Так что кеш должен быть маленький.

А они не очень то парятся.

Вы смотрите на график объема последовательной записи . Это не так страшно как случайное чтение или настоящая фиксация транзакций.

Графики Disk utilization у вас уменьшились лишь в 2 раза.

Почему, кстати, они разные ? они не в идентичном raid ?

Создаются файлы размером от 50 до 500 MB. А кто именно их создает .... не ясно.... Как кстати посмотреть от каких запросов эти временные таблицы?

---------- Добавлено 06.02.2013 в 13:26 ----------

Кстати тоже это интересно, можт один из драйвов шабашит? Но как бы SMART молчит, все ок!

---------- Добавлено 06.02.2013 в 13:36 ----------

После 7 часов работы:

+-------------------------+------------+

| Variable_name | Value |

+-------------------------+------------+

| Qcache_free_blocks | 3774 |

| Qcache_free_memory | 1008126648 |

| Qcache_hits | 16367635 |

| Qcache_inserts | 4043140 |

| Qcache_lowmem_prunes | 1022268 |

| Qcache_not_cached | 159970 |

| Qcache_queries_in_cache | 61687 |

| Qcache_total_blocks | 153160 |

+-------------------------+------------+

[!!] Total fragmented tables: 34

[!!] Query cache prunes per day: 3,541,660

[!!] Joins performed without indexes: 2083

[!!] Temporary tables created on disk: 29% (77K on disk / 259K total)

Интересно откуда берутся фрагментированные таблицы, после optimize они начали появляться почти что моментально, при перезапуске sql последнем их было всего 2 (предлагает их пересоздать, так как они не могут быть оптимизированы), а сейчас уже 34..... Как часто надо делать optimize и от чего зависит фрагментация в какие моменты она появляется ?

если по простому - то включить лог медленных запросов, типа

log-slow-queries или как его там, и посмотреть долгие запросы с Raws_examinated - скажем ну .... больше чем 100000...

ну или по времени долго выполняющиеся. быстрее всего эти запросы и будут создавать временные файлы .....

да и вообще на самом деле анализ медленного лога много чего покажет и расскажет.

pupseg, насчет анализа лога, понимаю, но расскажет он не совсем мне, а расскажет клиентам что у них где-то нет индексов, а где-то их программист сделал какашку, я так понимаю :D Первоначальная задача оградить сервер от зависаний по желанию mysql ;)))) А уже конечно позже будем анализировать данные вместе с клиентами и их программистами если будет надо.. но пока рано. :)

Спасибо за рекомендации и напутствия, если у кого-то еще есть что сказать - я внимательно выслушаю.

Все болезни от нервов. Просто не смотрите туда.

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

Но с набором патчей percona уже можно включить запись медленных запросов со временем 0 и выбрать те, которые помечены соответствующим образом.

Раз уж вы все равно решили делать tmpfs, это уже не важно.

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

Да да , буду смотреть в этом направлении, винты одинаковые и там soft-mirror , т.е писать должно одинаково....

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

Как видно на графиках, значительно вырос процент cache_hit :) что не может не радовать :)