Hangi thread_cache_size değerini kullanmalıyım?

Asp.Net'i MySQL ile birlikte kullanıyorum. Net bağlantı dizesinde, Max Pool Size değerini 150'ye ayarladım.

Aşağıdakileri çalıştırırsam şu değerleri alırım:

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

Bu, Threads_created / Connections öğesini verir = 0,1392.

Böylece, artmaya ihtiyacım var gibi görünüyor thread_cache_size.

Ama kaçarsam, SHOW PROCESSLISTher zaman .Net tarafından oluşturulan havuz nedeniyle açık (çoğu uyku) bağlantıların çok açık olduğunu görüyorum. Hala thread_cache_sizebağlantı havuzundaki bağlantıları tekrar kullanacağım gibi ayarlamam gerekiyor mu? Havuz Boyutu 150 ise, iyi bir değerin thread_cache_size150+ olarak ayarlandığını düşünüyor musunuz? Bu CPU ve belleği çok etkiler mi?

MySQL Dokümantasyonundaki bilgilere dayanarak aşağıdakileri yapmanız gerekir: mysqld'ün Connections , Threads_created ve Max_used_connections kullanıyorken en fazla eşzamanlı bağlantı sayısına sahip olduğunu öğrenin .

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

Aşağıdakileri hesaplamayı deneyin

Threads_created / Connections: Bu 0,01'in üzerindeyse, artırın thread_cache_size. En azından, thread_cache_sizedaha büyük olmalıdır Max_used_connections.

MySQL belgelerine göre, thread_cache_sizeyeni bağlantıların çoğunun yeni oluşturulan iş parçacıkları yerine önbellekteki iş parçacıklarını kullanacak şekilde ayarlamanız gerekir . Bu, iş parçacığı oluşturma ek yükünü azaltır, ancak normalde önemli bir performans artışı sağlamaz:

İş parçacığı istekleri, mümkünse önbellekten alınan iş parçacıkları yeniden kullanılarak gerçekleştirilir ve yalnızca önbellek boşken oluşturulan yeni bir iş parçacığıdır. Çok sayıda yeni bağlantınız varsa, bu değişken performansı artırmak için artırılabilir. Normal olarak, bu iyi bir iş parçacığı uygulamanız varsa , dikkate değer bir performans artışı sağlamaz . Ancak, sunucunuz saniyede yüzlerce bağlantı görüyorsa, normalde thread_cache_size değerini yeterince yüksek ayarlamalısınız ki yeni bağlantıların çoğu önbelleklenmiş iplikler kullanmalıdır . (kaynak)

Bu thread_cache_size, Threads_created / Connections(yeni iş parçacıklarının oluşturulmasına yol açan bağlantıların yüzdesi) oldukça düşük olacak şekilde ayarlamanız gerektiği anlamına gelir . MySQL dokümanlarını kelimenin tam anlamıyla ("çoğu") alırsanız, değer <% 50 olmalıdır. RolandoMySQLDBA'nın cevabı <% 1 diyor. Kimin gerçeğe daha yakın olduğunu bilmiyorum.

Sen gerektiğini değil set thread_cache_sizedaha yüksek Max_used_connections. O size sunucudan daha önbelleğinde fazla konuları tutmak gerektiğini söylüyor çünkü RolandoMySQLDBA yanıtında son cümle mantıklı görünmüyor ( "En azından, thread_cache_size Max_used_connections daha fazla olmalıdır") hiç kullanımları. MySQL hiçbir zaman önbellekteki birçok iş parçacığı koyamaz - önleyici olarak önbellekte iş parçacığı koyamaz - yalnızca bir istemci iş parçacığı oluşturup bağlantısını kestikten sonra bunları oraya koyar . Hiçbir zaman aynı anda bağlanan X istemciniz yoksa, önbellekte hiçbir zaman X diziniz olmaz:

Bir istemci bağlantısı kesildiğinde, orada thread_cache_size evrelemesinden daha az sayıda varsa, müşterinin evlatları önbelleğe alınır. (kaynak)

Ayrıca Michael'ın bu cevabına bakınız :

Thread_cache_size değerini max_connections değerinden daha büyük bir değere ayarlamak inanılmaz derecede yararsızdır bir öneri gibi görünüyor ... önbellek muhtemelen max_connections öğesinden daha büyük büyüyemez ve bu boyuta yakın herhangi bir yerdeki bir önbellek, yalnızca iş parçanızda çok fazla miktarda kayıp varsa bile mantıklı olabilir ... iyi niyetli bir uygulamada durum böyle olmaz.

/dba//a/28701

Ortak çalışma gününde, 'yeni bir işe alma' muhtemelen bir bağlantıya ihtiyaç duyar mı? Sihirbazların çoğu, önümüzdeki birkaç gün içinde kaç kişinin işe alınabileceğini bilmeyecek. MySQL'in V 8'i, max_used_connections ne olursa olsun aşırı yüklenmeyi önlemek için 100'de CAP thread_cache_size'yi önerir. Benim için 100 iyi bir CAP.

Lütfen bu bağlantıya bakınız.

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