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ęć?

— Jaskółka oknówka
źródło

Odpowiedzi:

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.

— RolandoMySQLDBA
źródło

Dzięki za świetny komentarz! Trochę zaktualizowałem swoje pytanie.

— Martin

Myślę, że miałeś zamiar mysql> POKAŻ GLOBALNY STAN PODOBNY DO „połączeń”; (napisałeś max_used_connections dwa razy)

— Alekc

Chcę tylko to dodać, odwołując się do tego dev.mysql.com/doc/refman/5.7/en/ ... powinieneś dodać 8 do Max_used_connections dla wartości thread_cache_size (bez przekraczania 100)

— CME64

W rzeczywistości instrukcja sugeruje domyślną wartość (1% mac_used_connections) + 8 .... lub 100 ... w zależności od tego, która wartość jest mniejsza.

— Christopher McGowan,

Dla mnie # to 264/103134, co daje 0,0026, czyli o wiele mniej niż 0,01. Ale moje MaxUsedConnections ma 72, więc ostatnie zdanie jest strasznie sprzeczne

— Boatcoder

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

— Tomasz P. Szynalski
źródło

Chyba tak! po przetestowaniu tej konfiguracji „rozmiar_pamięci_cache powinien być większy niż Max_used_connections”, nie jest to pomocne.

— CK.Nguyen,

-2

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

— Wilson Hauck
źródło