Чому потоки MySQL часто показують статус "звільнення елементів", коли кеш запитів вимкнено?

Коли я запускаю SHOW PROCESSLIST, часто є велика кількість INSERT / UPDATE потоків у стані "звільнення елементів".

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

Однак у мене query_cache_sizeвстановлено значення 0, що має взагалі вимкнути кеш запитів.

Які ще причини могли б мати стільки ниток у цьому стані?

У відповідних таблицях використовується механізм зберігання InnoDB.

Перевірте значення innodb_thread_concurrency.

Для моєї системи збільшується значення з 8 до 32 відповідно до вказівок у документації MySql спричинило помітне зменшення кількості потоків, що одночасно повідомляють про стан "звільнення елементів". Крім того, затримані середні строки запиту впали на порядок.

Хоча це значно змінило загальну продуктивність сервера, це була не срібна куля "звільнення предметів". Моя апаратна екосистема спонукає мене до гіпотези, що цей стан в основному спостерігається в системах з "повільними" дисками (2x10k дисками рейд 1), і менш поширений у системах з більш швидким зберіганням (12x15k дискових рейдів 10). Отже, перевірка працездатності диска також може бути гарантованою.

Щасти!

Також:

Варто зазначити, що значення за замовчуванням innodb_thread_concurrency докорінно відрізняється залежно від того, який 5.0-бальний реліз використовується.

Значення за замовчуванням кілька разів змінювалося: 8 перед MySQL 5.0.8, 20 (нескінченно) від 5.0.8 до 5.0.18, 0 (нескінченно) від 5.0.19 до 5.0.20, і 8 (скінченне) з 5.0.21 на. - джерело

Це означає, що, здавалося б, нешкідливе оновлення з 5,0.20 до 5,0,21 змінило типовий стан з нескінченного на 8 і принесло разом із цим і наслідки для продуктивності.

Вивільнення елементів - це етап виконання запитів, де розміщуються тимчасові структури, буфери тощо. На цьому етапі виконується деяка робота з кешування запитів, але це не єдине, що відбувається там. Я б запропонував скористатися SHOW PROFILES, щоб побачити, як довго цей етап триває відносно інших етапів, і якщо витрачений час закінчується проблемою, усунення несправностей з інструментами, такими як профілер і oprofile бідолахи.

З цього питання з'явився звіт про помилки щодо "звільнення елементів" та кешу запитів . Хоча помилка закрита, innodb_thread_concurrency не згадувалося .

Випадково я говорив з Рональдом Бредфордом у Percona Live NYC ще в травні. Я розповів йому про ситуацію, коли я налаштував innodb_thread_concurrency, тому що багаторазовий пул InnoDB Buffer MySQL 5.5 створив тонну блокування потоків, і я підозрював, що кешовані дані, які мені потрібні, швидше за все, поширилися серед кількох пулів буфера.

Він прямо сказав мені, що я ніколи не повинен встановлювати значення проти innodb_thread_concurrency. Нехай це завжди буде значення за замовчуванням, яке зараз дорівнює нулю (0). Тим самим ви дозволяєте сховищу InnoDB вирішувати, скільки innodb_concurrency_tickets самостійно генерувати. Це те, що робить нескінченна паралельність.

"Вивільнення предметів", швидше за все, трапляється частіше, коли ми встановлюємо обмеження на innodb_thread_concurrency. Це завжди має бути нуль (0). Я б ризикнув підняти innodb_concurrency_tickets і побачити, чи допомагає це чи ні.

У нас була проблема з точно такими ж симптомами. Виявилося, що диск із файлами журналу InnoDB заповнився. Варто перевірити.

Ще одна підказка: може бути innodb fsync (). Спробуйте встановити

innodb_flush_log_at_trx_commit = 2

У моєму. Cnf

Потім файл innodb видається на диск кожні 1-2 секунди, а не ob при кожному здійсненні. Незначне покарання цілісності даних, велике збільшення швидкості.