Jakiej wartości thread_cache_size powinienem użyć?

Używam Asp.Net razem z MySQL. W ciągu połączenia .Net ustawiłem Maksymalny rozmiar puli na 150.

Jeśli uruchomię następujące, otrzymam te wartości:

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

Co daje Threads_created / Connections = 0,1392.

Z tego wynika, że ​​muszę zwiększyć thread_cache_size.

Ale jeśli uruchomię SHOW PROCESSLIST, zawsze widzę, że mam wiele otwartych połączeń (większość z nich śpi) z powodu puli utworzonej przez .Net. Czy nadal muszę ustawić, thread_cache_sizeponieważ nadal będę ponownie używać połączeń z puli połączeń? Jeśli rozmiar puli wynosi 150, czy uważasz, że dobrą wartością byłoby ustawienie thread_cache_size150+? Czy miałoby to duży wpływ na procesor i pamięć?

Na podstawie informacji zawartych w dokumentacji MySQL powinieneś wykonać następujące czynności: Dowiedz się, jaka była najwyższa liczba jednoczesnych połączeń, jakie mysqld uzyskał przy użyciu Connections , Threads_created i Max_used_connections ,

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

Spróbuj obliczyć następujące

Threads_created / Connections: Jeśli jest to ponad 0,01, zwiększ thread_cache_size. Przynajmniej thread_cache_sizepowinien być większy niż Max_used_connections.

Zgodnie z dokumentacją MySQL należy ustawić thread_cache_sizetak, aby większość nowych połączeń używała wątków z pamięci podręcznej, a nie nowo tworzonych wątków. Oszczędza to trochę narzutów związanych z tworzeniem wątków, choć zwykle nie powoduje znaczącej poprawy wydajności:

Żądania dotyczące wątków są spełnione przez ponowne użycie wątków pobranych z pamięci podręcznej, jeśli to możliwe, i tylko wtedy, gdy pamięć podręczna jest pusta, tworzony jest nowy wątek. Zmienną tę można zwiększyć, aby poprawić wydajność, jeśli masz wiele nowych połączeń. Zwykle nie zapewnia to zauważalnej poprawy wydajności, jeśli masz dobrą implementację wątku. Jeśli jednak twój serwer widzi setki połączeń na sekundę, powinieneś normalnie ustawić wystarczająco wartość thread_cache_size, aby większość nowych połączeń używała buforowanych wątków . (źródło)

Oznaczałoby to, że należy ustawić thread_cache_sizetak, aby Threads_created / Connections(% połączeń, które prowadzą do tworzenia nowych wątków) był raczej niski. Jeśli weźmiesz dokumenty MySQL dosłownie („większość”), wartość powinna wynosić <50%. Odpowiedź RolandoMySQLDBA mówi <1%. Nie wiem, kto jest bliżej prawdy.

Należy nie ustawić thread_cache_sizewyższy niż Max_used_connections. Ostatnie zdanie w odpowiedzi RolandoMySQLDBA („Przynajmniej rozmiar_waga_cache powinien być większy niż Max_used_connections”) nie wydaje się sensowne, ponieważ mówi, że należy przechowywać więcej wątków w pamięci podręcznej, niż kiedykolwiek serwer używa. MySQL nigdy nie umieści tak wielu wątków w pamięci podręcznej - nie wyprzedza wątków w pamięci podręcznej - umieszcza je tylko wtedy, gdy klient utworzy wątek i rozłączy się. Jeśli nigdy nie masz X klientów łączących się w tym samym czasie, nigdy nie będziesz mieć X wątków w buforze:

Gdy klient się rozłącza, wątki klienta są umieszczane w pamięci podręcznej, jeśli jest tam mniej niż wątków wątku rozmiar_pamięci_podręcznej. (źródło)

Zobacz także tę odpowiedź Michaela:

Ustawienie wartości thread_cache_size na wartość większą niż max_connections wydaje się być ogromnie nieprzydatną radą ... pamięć podręczna nie może wzrosnąć więcej niż max_connections, a nawet pamięć podręczna w pobliżu tego rozmiaru może mieć sens tylko wtedy, gdy masz ogromną ilość rezygnacji z wątków ... co w dobrze zachowującej się aplikacji nie będzie miało miejsca.

/dba//a/28701

Czy we wspólnym dniu roboczym „nowy wynajem” może być potrzebny? Większość magów nie będzie wiedziała, ile osób można zatrudnić w ciągu najbliższych kilku dni. Wersja 8 MySQL sugeruje rozmiar CAP_wątek_pamięci_cache na 100, aby zapobiec przeciążeniu bez względu na max_used_connections. Dla mnie 100 to dobra WPR.

Proszę zobaczyć ten link.

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