Чи варто взагалі витрачати накладні витрати частого вимкнення кешу запитів?


22

Зараз я працюю над базою даних MySQL, де ми бачимо велику кількість недійсних даних із кешу запитів, насамперед через велику кількість операторів INSERT, DELETE та UPDATE, які виконуються у багатьох таблицях.

Я намагаюся визначити, чи є взагалі якась користь для того, щоб дозволити використовувати кеш запитів для операторів SELECT, які запускаються проти цих таблиць. Оскільки вони швидко втрачають свою інвалідність, мені здається, найкраще було б просто використовувати SQL_NO_CACHE для операторів SELECT з цими таблицями.

Чи варто взагалі накладати накладні витрати на часті інваліди?

Редагувати: На запит користувача @RolandoMySQLDBA нижче, ось інформація про MyISAM та INNODB.

InnoDB

  • Розмір даних: 177.414 ГБ
  • Розмір індексу: 114,792 ГБ
  • Розмір столу: 292.205 ГБ

MyISAM

  • Розмір даних: 379,762 ГБ
  • Розмір індексу: 80.681 ГБ
  • Розмір столу: 460,443 ГБ

Додаткова інформація:

  • Версія: 5.0.85
  • query_cache_limit: 1048576
  • query_cache_min_res_unit: 4096
  • query_cache_size: 104857600
  • query_cache_type: УВІМКНЕНО
  • query_cache_wlock_invalidate: OFF
  • innodb_buffer_pool_size: 8841592832
  • 24 Гб оперативної пам’яті

2
dom.as/tech/query-cache-tuner підсумовує це досить добре
Laurynas Biveinis

Хе-хе, дуже проникливий.
Крейг Сефтон

Відповіді:


16

Вам слід просто відключити кеш запитів за допомогою

[mysqld]
query_cache_size = 0

а потім перезапустіть mysql. Чому я б запропонував це ???

Кеш запитів завжди буде стикувати голови з InnoDB. Було б непогано, якби MVCC InnoDB дозволив обслуговувати запити з кешу запитів, якщо зміни не впливають на повторювані читання для інших транзакцій. На жаль, InnoDB просто не робить цього. Мабуть, у вас багато запитів, які доволі швидко втрачаються, і, ймовірно, не використовуються повторно.

Для InnoDB під MySQL 4.0 кеш запитів вимкнено для транзакцій. Для MySQL 4.1+ InnoDB відтворює коп трафіку, коли надає доступ до кешу запитів на основі таблиці.

З точки зору вашого питання, я б сказав, що виправданням видалення кешу запитів є не стільки накладні витрати, скільки те, як InnoDB управляє ним.

Для отримання додаткової інформації про те, як InnoDB взаємодіє з кешем запитів, будь ласка, прочитайте сторінки 213-215 книги "Високопродуктивний MySQL (друге видання)" .

Якщо всі або більшість ваших даних - це MyISAM, ви можете піти з початковою ідеєю використання SQL_NO_CACHE.

Якщо у вас суміш InnoDB і MyISAM, вам доведеться знайти правильний баланс для вашої програми, виходячи з того, наскільки високі ваші пропуски кешу. Насправді на сторінках 209-210 цієї ж книги вказуються причини помилок кешу:

  • Запит не підлягає кешуванню або тому, що він містить недетерміновану конструкцію (наприклад, CURRENT_DATE), або тому, що її набір результатів занадто великий для зберігання.
  • Сервер ніколи раніше не бачив запит, тому у нього ніколи не було можливості кешувати його результат.
  • Результат запиту раніше був кешований, але сервер його видалив. Це може статися тому, що не вистачало пам'яті, щоб зберегти його, тому що хтось доручив серверу видалити його або тому, що він був визнаний недійсним

і першопричинами помилок у високому кеші з кількома запитами, які не підлягають керуванню, можуть бути:

  • Кеш запитів ще не нагрітий. Тобто сервер не мав шансу заповнити кеш наборами результатів.
  • Сервер бачить запити, яких раніше не бачив. Якщо у вас немає багато повторних запитів, це може статися навіть після прогрівання кеша.
  • Існує дуже багато виправлень кешу.

ОНОВЛЕННЯ 2012-09-06 10:10 EDT

Переглядаючи останню оновлену інформацію, ви query_cache_limitвстановили 1048576 (1М). Це обмежує будь-який результат, встановлений на 1М. Якщо ви отримаєте щось більше, воно просто не буде кешоване. Хоча ви query_cache_sizeвстановили 104857600 (100 М), це дозволяє лише 100 кешованих результатів, встановлених у ідеальному світі. Якщо ви виконаєте сотні запитів, фрагментація з’явиться досить швидко. Ви також маєте 4096 (4K) як набір результатів мінімального розміру. На жаль, у mysql немає внутрішнього механізму дефрагментації кешу запитів.

Якщо у вас повинен бути кеш запитів і у вас стільки оперативної пам’яті, ви можете виконати наступне:

SET GLOBAL query_cache_size = 0;
SELECT SLEEP(60);
SET GLOBAL query_cache_size = 1024 * 1024 * 1024;

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

Я також призначив би таке:

  • query_cache_size = 1G
  • query_cache_limit = 8М

Це залишає 23G оперативної пам’яті. Я хотів би зазначити наступне:

  • innodb_buffer_pool_size = 12G
  • key_buffer_size = 4G

Це залишає 7G. Це повинно бути достатнім для підключень ОС та БД.

Майте на увазі, що буфер ключів кешує лише індексні сторінки MyISAM, тоді як InnoDB Buffer Pool кешує дані та індекси.

Ще одна рекомендація: оновлення до MySQL 5.5, щоб ви могли налаштувати InnoDB для декількох процесорів і декількох потоків для читання / запису вводу / виводу.

Дивіться мої попередні повідомлення про використання MySQL 5.5 спільно з доступом до декількох процесорів для InnoDB

ОНОВЛЕННЯ 2012-09-06 14:56 EDT

Мій метод очищення кешу запитів досить екстремальний, оскільки він збирає кешовані дані та утворює зовсім інший сегмент ОЗУ. Як ви вказували у своєму коментарі FLUSH QUERY CACHE(як ви запропонували) або навіть RESET QUERY CACHEбуло б краще. Для уточнення, коли я сказав «немає внутрішнього механізму», я мав на увазі саме це. Дефрагментація потрібна і повинна бути виконана вручну. Це потрібно було б бути crontab'd .

Якщо ви робите DML (INSERT, UPDATE, DELETE) на InnoDB частіше, ніж на MyISAM, я б сказав, що виймаєте кеш запитів взагалі, про що я говорив на початку.


Дякуємо за відповідь. Я маю цю книгу і широко її використовую; Я добре знаю, з яких причин ви плануєте пропускати кеш, але, як я вже згадував, ми вже визначили недійсність кешу як ключову проблему через сильну кореляцію, яку ми бачимо між Com_select та Qcache_inserts. О, і БД, про яку йдеться, має поєднання INNODB та MyISAM.
Крейг Сефтон

Оновлено додаткову інформацію, яку ви запитували. Спасибі.
Крейг Сефтон

Дякую за відповідь, з нетерпінням чекаю на решту. Однією з речей, які ми визначили, було те, що близько 18% запитів не кешувались, тому обов'язково цінуйте поради щодо налаштувань. На жаль, поле не присвячене, але ваші рекомендації повинні допомогти. Фрагментація, безумовно, також є проблемою. Я все ще дуже стурбований кількістю невідповідностей, які ми бачимо (на відміну від запитів, які взагалі не кешовані), тому все ще невідомо, чи варто цього накладних витрат. Дуже ціную вашу проникливість, дуже дякую.
Крейг Сефтон

Що стосується Вашого коментаря щодо "mysql не має внутрішнього механізму для дефрагментації кешу запитів", ви не можете виконати команду FLUSH QUERY CACHEдля її дефрагментації? Дивіться: dev.mysql.com/doc/refman/5.0/en/flush.html
Крейг Сефтон

Оновлено мою відповідь ...
RolandoMySQLDBA

3

BAD: query_cache_size = 1G

Чому? Через те, скільки часу триватиме промивка. Тобто, коли відбувається записування, весь 1 Гб буде відскановано, щоб знайти будь-які посилання на таблицю, яка була змінена. Чим більше КК, тим повільніше це. Я рекомендую розмір не більше 50 млн, якщо тільки ваші дані рідко змінюються.

КК є накладними і для MyISAM, і для InnoDB. Він виймає глобальний Mutex і виймає його занадто рано. Цей мутекс є однією з причин того, що MySQL не може ефективно використовувати більше ніж близько 8 ядер.

SQL_NO_CACHE НЕ не помітив , поки після того, як м'ютекс заблокований! Про єдине використання цього прапора є тестування.

Часто краще дати оперативну пам’ять якомусь іншому кешу.


2

Я можу придумати ідеальний випадок для цього, і ми ретельно випробували і запустили його у виробництво ... Я це називаю стратегією кластеризації "швидкої смуги" :

Якщо ви робите розділення читання-запису з таким проксі, як MaxScale, або ваша програма здатна, ви можете надіслати частину зчитувань цих рідко недійсних таблиць лише рабам, у яких увімкнено кеш запитів, а решту - іншим невільникам із ним вимкнений.

Ми робимо це і обробляємо 4M дзвінки в хвилину до кластеру під час наших тестів навантаження (не еталон ... реальна угода). Додаток чекає на master_pos_wait () для деяких речей, тому його перетягує нитка реплікації, і хоча ми бачили це зі статусом очікування вимкнення Qcache при дуже високій пропускній здатності, рівень пропускної здатності вище, ніж кластер рівний здатний без Qcache.

Це працює, тому що рідко є щось релевантне в крихітному кеші запитів на цих машинах, щоб визнати недійсними (ці запити стосуються лише нечасто оновлених таблиць). Ці коробки - це наша «швидка смуга». Для решти запитів, які виконує програма, їм не доводиться боротися з Qcache, оскільки вони переходять у вікна без його включення.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.