Яке значення thread_cache_size я повинен використовувати?

Я використовую Asp.Net разом з MySQL. У рядку підключення .Net я встановив максимальний розмір пулу на 150.

Якщо я запускаю наступне, я отримую ці значення:

SHOW GLOBAL STATUS LIKE 'max_used_connections'; gives 66
SHOW GLOBAL STATUS LIKE 'Threads_created'; gives 66
SHOW GLOBAL STATUS LIKE 'connections'; gives 474

Що дає Threads_create / Connections = 0,1392.

Тож від цього здається, що мені потрібно збільшити thread_cache_size.

Але якщо я біжу, SHOW PROCESSLISTя завжди бачу, що у мене відкрито багато зв’язків (більшість з них сплять) через пул, створений .Net. Мені все-таки потрібно встановити, thread_cache_sizeяк я все одно повторно використовуватиму з'єднання з пулу з'єднань? Якщо розмір басейну становить 150, чи вважаєте ви, що хорошим значенням було б встановити thread_cache_size150+? Чи багато це вплине на процесор і пам'ять?

Виходячи з інформації в MySQL Документації, ви повинні зробити наступне: Дізнайтеся, яка найбільша кількість одночасних з'єднань mysqld мала за допомогою Connections , Threads_create та Max_used_connections ,

• SHOW GLOBAL STATUS LIKE 'Connections';
• SHOW GLOBAL STATUS LIKE 'Threads_created';
• SHOW GLOBAL STATUS LIKE 'Max_used_connections';

Спробуйте обчислити наступне

Threads_created / Connections: Якщо це більше 0,01, то збільште thread_cache_size. Як мінімум, thread_cache_sizeмає бути більше, ніж Max_used_connections.

Згідно з документами MySQL, ви повинні встановити thread_cache_sizeтак, що більшість нових з'єднань використовують потоки з кеша, а не новостворені потоки. Це економить деякі накладні витрати на створення потоку, хоча зазвичай не створює значного покращення продуктивності:

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

Це означає, що ви повинні встановити thread_cache_sizeтак, що Threads_created / Connections(% з'єднань, що призводять до створення нових потоків), є досить низьким. Якщо ви приймете документи MySQL буквально ("більшість"), значення повинно бути <50%. Відповідь RolandoMySQLDBA говорить <1%. Я не знаю, хто ближче до істини.

Ви не повинні встановлювати thread_cache_sizeвище, ніж Max_used_connections. Заключне речення у відповіді RolandoMySQLDBA ("Принаймні, розмір теми_cache_size повинен бути більшим, ніж Max_used_connections") не здається розумним, оскільки в ньому йдеться про те, що ви повинні зберігати більше тем у кеші, ніж коли-небудь використовує ваш сервер . MySQL ніколи не поміщає стільки потоків у кеш-пам'ять - він попередньо не ставить потоки в кеш - він розміщує їх туди лише після того, як клієнт створить потік і відключиться. Якщо у вас ніколи не підключаються одночасно X-клієнти, ви ніколи не матимете потоків X у кеші:

Коли клієнт відключається, потоки клієнта поміщаються в кеш-пам'ять, якщо там менше ниток thread_cache_size. (джерело)

Дивіться також цю відповідь Майкла:

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

/dba//a/28701

Чи, можливо, потрібен «новий прокат» підключення? Більшість магів не дізнається, скільки людей можуть бути найняті в найближчі кілька днів. V 8 MySQL пропонує CAP thread_cache_size у 100 для запобігання перевантаження незалежно від max_used_connections. Для мене 100 - це хороша CAP.

Дивіться це посилання, будь ласка.

https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_thread_cache_size