MySQL table_cache та Openned_tables

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

Якщо порівняння Open_tables з Open_tables не вірно, чи є інший спосіб отримати вимірювані дані для цього?

Це є на MySQL 5.0, але відмінності між версіями теж вітаються.

Найбільша причина мати великий table_cache - це те, що LOCK_open mutex не є гарячим. У MySQL до 5.5 є багато суперечок, коли ви намагаєтесь відкривати / закривати таблиці, тому ви хочете максимально обмежити це, тобто мати великий кеш таблиці.

Тож вам не байдуже якесь співвідношення звернень до промахів (у випадку, коли ви повинні взагалі ігнорувати коефіцієнти - цей пост у блозі пояснює, чому ). Те, що вас хвилює, - це показник пропуску , оскільки чим більше разів це відбувається за секунду, тим більше шансів на те, що у вас виникнуть суперечки (один потік повинен чекати, коли інший потік звільнить замок.)

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

Примітка. Я дуже конкретно не рекомендую порівнювати їх із тривалістю роботи.

Спочатку розглянемо ці змінні стану:

Відкриті таблиці : Кількість відкритих таблиць.

Opened_tables : Кількість відкритих таблиць. Якщо Opened_tables великий, значення table_open_cache, ймовірно, занадто мало.

Дивно, але відповідь на ваше запитання лежить у самому питанні.

Дві змінні матимуть більше сенсу, лише якщо ви кинете ще одну змінну стану у суміш: Uptime (або Uptime_since_flush статус для свіжих середніх значень після STALUS FLUSH STATUS ).

Ви повинні порівнювати Open_tables agsinst (Opened_tables / Uptime) . Якщо Open_tables піднімається нагорі (Opened_tables / Uptime) , тепер у вас є привід для занепокоєння, і вам слід тримати огляд відкритим для таких речей:

• netstat
• іостат
• завантаження сервера
• Кількість з'єднань (у міру наближення до max_connections )
• Аборти клієнтів
• Аборт підключається
• Повільні запити

ОНОВЛЕННЯ 2011-08-31 12:18 EDT

Зверніть увагу, чому я також запропонував використовувати Uptime_since_flush_status замість Uptime, щоб отримати виправлену схему зростання Open_tables за даний період.

Наприклад, якщо ви працюєте FLUSH STATUS;щопонеділка опівночі, ви можете створити OpenTableFactor:

SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM
(SELECT variable_value Uptime FROM information_schema.global_status
WHERE variable_name = 'Uptime_since_flush_status') up,
(SELECT variable_value Open_tables FROM information_schema.global_status
WHERE variable_name = 'Open_tables') opn,
(SELECT IF(variable_value=0,1,variable_value) Opened_tables
FROM information_schema.global_status
WHERE variable_name = 'Opened_tables') opnd;

Цей коефіцієнт відкритої таблиці становить число, яке представляє кількість відкритих таблиць у будь-який момент часу проти середньої кількості відкритих таблиць за даний період. З FLUSH HOSTS;кожного тижня / день / хоста, що в середньому становить від тижня / день / год.

Ось зразок одного з клієнтів мого роботодавця:

mysql> SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM     (SELECT variable_value Uptime FROM information_sc    hema.global_status     WHERE variable_name = 'Uptime_since_flush_status') up,     (SELECT variable_value Open_tables FROM informat    ion_schema.global_status     WHERE variable_name = 'Open_tables') opn,     (SELECT IF(variable_value=0,1,variable_value) Opened_ta    bles     FROM information_schema.global_status     WHERE variable_name = 'Opened_tables') opnd;
+----------+-------------+---------------+-------------------+
| Uptime   | Open_tables | Opened_tables | OpenTableFactor   |
+----------+-------------+---------------+-------------------+
| 14385123 | 16326       | 30429078      | 7717.996519579068 |
+----------+-------------+---------------+-------------------+
1 row in set (0.00 sec)

Цей клієнт зазвичай підтримує близько 7745 OpenTableFactor на макс. Якщо OpenTableFactor впаде раптово (навіть якщо трохи), це може вказувати на менші шаблони трафіку, високі перервані конекції тощо. Якщо OpenTableFactor ніколи не змінюється (навіть якщо трохи), він може запропонувати вам змінити ці налаштування:

• open_files_limit
• innodb_open_files
• table_open_cache

Після налаштування OpenTableFactor може постійно змінюватися або потрапляти на інший стелю або плато. Таким чином, використання різних одиниць всередині змінних статусу стає життєво важливим для цієї настройки.

ОНОВЛЕННЯ 2011-08-31 12:42 EDT

Запит SQL, який я запускав для OpenTableFactor, не працює для MySQL 5.0 і назад. Якщо ви використовуєте MySQL Administrator або MONyog , ви можете налаштувати графік, використовуючи формулу в запиті та моніторі. MONyog збирає історію за допомогою SQLLite для подальшого історичного графіку. Це можна зробити для будь-якої версії MySQL.

З одного з коментарів користувачів на сторінці документації table_cache :

Opened_tables - це змінна стан, яка підтримує облік кількості додаткових дескрипторів файлів, які були призначені для відкриття таблиць у часи, коли доступні дескриптори файлів у table_cache були вичерпані. ...

Це означає, що вона збільшується при переході вашої table_cacheвартості. Так як я зазвичай перевірити це порівняти opened_tablesз uptime, але ключ тут , щоб прийняти його в протягом заданого інтервалу (один раз на хвилину в протягом десяти хвилин, наприклад). Якщо він збільшується, це може бути ознакою, що вам потрібно збільшити свою table_cache.

Пара застережень, щоб згадати:

• Ще один коментар до цієї документації вище: "Змінна стану" Відкриті_таблиці "також буде збільшуватися на 2 щоразу, коли ви створюєте тимчасову таблицю." Отже, якщо ваші запити потребують багатьох тимчасових таблиць, це може бути причиною швидкого збільшення opened_tables. Ви можете побачити своє тимчасове використання таблиці за допомогою наступного запиту:

  SHOW GLOBAL STATUS LIKE '%tmp%';

• Не збільшуйте надто високий стіл кеша

  Причина такої поведінки полягає в тому, що якщо у вас великих немає. таблиць зі складними запитами, що поєднують декілька таблиць і декілька з'єднань, які виконують ці складні запити, ви можете в кінцевому рахунку використовувати весь кеш дескрипторів файлів (table_cache). У цьому випадку MySQL використовує алгоритм для пошуку найменш використовуваного дескриптора, закриває його та замінює це з новим дескриптором.