¿Qué valor de thread_cache_size debo usar?

Estoy usando Asp.Net junto con MySQL. En la cadena de conexión .Net, configuré Max Pool Size en 150.

Si ejecuto lo siguiente, obtengo estos valores:

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

Lo que da Threads_created / Connections = 0,1392.

Entonces, parece que necesito aumentar thread_cache_size.

Pero si corro SHOW PROCESSLISTsiempre veo que tengo muchas conexiones abiertas (la mayoría de ellas inactivas) debido al grupo creado por .Net. ¿Debo seguir configurando thread_cache_sizeya que seguiré reutilizando las conexiones del grupo de conexiones? Si el tamaño de la agrupación es 150, ¿cree que un buen valor sería establecer thread_cache_size150+? ¿Esto afectaría mucho la CPU y la memoria?

Según la información en la documentación de MySQL, debe hacer lo siguiente: averiguar cuál es el mayor número de conexiones simultáneas que mysqld ha tenido al usar Connections , Threads_created y Max_used_ connections ,

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

Intenta calcular lo siguiente

Threads_created / Connections: Si esto es superior a 0.01, entonces aumente thread_cache_size. Por lo menos, thread_cache_sizedebe ser mayor que Max_used_connections.

De acuerdo con los documentos de MySQL, debe configurar thread_cache_sizepara que la mayoría de las conexiones nuevas usen hilos del caché en lugar de hilos recién creados. Esto ahorra algunos gastos generales de creación de subprocesos, aunque normalmente no crea una mejora significativa del rendimiento:

Las solicitudes de subprocesos se satisfacen reutilizando los subprocesos tomados del caché si es posible, y solo cuando el caché está vacío se crea un nuevo subproceso. Esta variable se puede aumentar para mejorar el rendimiento si tiene muchas conexiones nuevas. Normalmente, esto no proporciona una mejora notable en el rendimiento si tiene una buena implementación de subprocesos. Sin embargo, si su servidor ve cientos de conexiones por segundo, normalmente debería establecer thread_cache_size lo suficientemente alto como para que la mayoría de las conexiones nuevas usen hilos en caché . (fuente)

Esto significaría que debe configurar su thread_cache_sizemodo para que Threads_created / Connections(el% de conexiones que conducen a la creación de nuevos hilos) sea bastante bajo. Si toma los documentos de MySQL literalmente ("la mayoría"), el valor debe ser <50%. La respuesta de RolandoMySQLDBA dice <1%. No sé quién está más cerca de la verdad.

Usted debe no establecer thread_cache_sizemás alto que Max_used_connections. La oración final en la respuesta de RolandoMySQLDBA ("Como mínimo, thread_cache_size debería ser mayor que Max_used_ connections") no parece sensata porque dice que debe mantener más hilos en la memoria caché de los que utiliza su servidor . MySQL nunca colocará tantos subprocesos en el caché de todos modos, no coloca subprocesos preventivamente en el caché, solo los coloca allí después de que un cliente crea un subproceso y se desconecta. Si nunca tiene clientes X conectados al mismo tiempo, nunca tendrá hilos X en el caché:

Cuando un cliente se desconecta, los hilos del cliente se colocan en la memoria caché si hay menos hilos de thread_cache_size allí. (fuente)

Ver también esta respuesta de Michael:

Establecer thread_cache_size en un valor mayor que max_ connections parece un consejo tremendamente inútil ... el caché no puede crecer más que max_ connections e incluso un caché en cualquier lugar cercano a ese tamaño solo podría tener sentido si tiene una gran cantidad de rotación en sus hilos ... lo cual, en una aplicación con buen comportamiento, no será el caso.

/dba//a/28701

En el día laboral común, ¿necesitaría una 'nueva contratación' una conexión? La mayoría de los magos no sabrán cuántas personas podrían ser contratadas en los próximos días. V 8 de MySQL sugiere CAP thread_cache_size a 100 para evitar la sobrecarga, independientemente de max_used_ connections. Para mí, 100 es un buen CAP.

Vea este enlace, por favor.

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