|
Задавайте вопросы, мы ответим
Вы не зашли.
Mysql по умолчанию пишет всё в кеш.
В большинстве случаев существует есть ряд причин когда запись в кеш абсолютно не эффективна.
1) Таблицы с часто изменяющимися данными.
2) Запросы возможно и частые, но мало повторяющиеся.
3) Просто очень быстрые запросы.
Так же есть тяжёлые запросы, которых кеширование просто спасает.
Получается что неэффективный кеш может засорять память, таким образом не будет достаточно место для сохранения кеша тяжёлых запросов ?
Не является ли правильным, всегда работать в режиме QUERY_CACHE_TYPE=DEMAND ?
То есть всю память наполнять самым эффективным кешам ?
Неактивен
Добавлю еще один аргумент - из-за используемой глобальной блокировки, кэш будет приводить к снижению производительности на многоядерных системах (конечно, при условии, что запросы быстрые). См. доклад Константина Осипова, Масштабирование СУБД MySQL на системах с многоядерной архитектурой.
Использование QUERY_CACHE_TYPE=DEMAND, конечно, даст прирост производительности (во многих случаях очень существенный). Недостаток только в том, что нужно добавить SQL_CACHE ко всем запросам, подлежащим кэшированию. Возможен альтернативный подход - добавить SQL_NO_CACHE к быстрым/неповторяющимся запросам и к тем, которые стоят непосредственно перед UPDATE. Все это выйгрыш производительности за счет дополнительных трудозатрат - если производительность приоритетна, то конечно правильным будет использовать эту возможность.
Неактивен
Подскажите как лудьше отслеживать конкретные ситуации ?
1) Таблицы с часто изменяющимися данными.
С помощью Maatkit парсить general log, искать таблицы где часто используются инсерты и апдэйты ?
Есть более простой способ ?
2) Запросы возможно и частые, но мало повторяющиеся.
Возможно тоже можно с помощью Maatkit, но не знаю как ... :-(
То есть нужно найти таблицы, в которых маленький процент часто повторяющихся запросов.
Не подскажите как это сделать ?
Неактивен
1. Посмотреть сколько SELECT-ов приходится в среднем на один UPDATE/INSERT. Проще всего это понять из логики работы приложения. И, конечно, избавиться от лишних апдейтов к информационным таблицам - вынести все каунтеры просмотров, кликов и.т.д. в отдельную таблицу.
2. Должно также следовать из логики приложения. Если не следует, то я бы grep-ом выделил спорные запросы из лога и посмотрел бы, повторяются или нет. Лучше всего использовать логику, так как в будущем возможен slashdot-эффект (наплыв посетителей на одну страницу), которого обычно в логах нет.
Неактивен
rgbeast написал:
1. Посмотреть сколько SELECT-ов приходится в среднем на один UPDATE/INSERT. Проще всего это понять из логики работы приложения. И, конечно, избавиться от лишних апдейтов к информационным таблицам - вынести все каунтеры просмотров, кликов и.т.д. в отдельную таблицу.
2. Должно также следовать из логики приложения. Если не следует, то я бы grep-ом выделил спорные запросы из лога и посмотрел бы, повторяются или нет. Лучше всего использовать логику, так как в будущем возможен slashdot-эффект (наплыв посетителей на одну страницу), которого обычно в логах нет.
То что вы говорите это всё понятно ... Речь идёт не о разработке приложения, а о оптимизации БД, уже существующих систем ...
То есть логика работы приложения неизвестна ... Есть приложение с умирающим Mysql-ам, которого нужно оптимизировать за максимально короткие сроки.
Вот и приходится искать максимально практичные действующие решения. Быстрый подбор индексов,настройка оптимального кеширования, настройка конфига, переписывание кривых запросов.
Неактивен
evgeny написал:
То что вы говорите это всё понятно ... Речь идёт не о разработке приложения, а о оптимизации БД, уже существующих систем ...
То есть логика работы приложения неизвестна ... Есть приложение с умирающим Mysql-ам, которого нужно оптимизировать за максимально короткие сроки.
Вот и приходится искать максимально практичные действующие решения. Быстрый подбор индексов,настройка оптимального кеширования, настройка конфига, переписывание кривых запросов.
В таких условиях ни разу не делали DEMAND. Оправдано бывает только указать SQL_NO_CACHE для нескольких наиболее частых быстрых или очевидно неповторяющихся запросов. В рунете в 95% случаев сервер тормозит из-за медленных, а не из-за быстрых запросов. Если важны быстрые запросы, то это уже нагрузки другого порядка и в таких случаях бывает без серьезного проектирования не обойтись и быстро не сделать.
Неактивен
