jueves, noviembre 11, 2010

MySQL y los pools de Threads

jueves, noviembre 11, 2010 por Martín

Estaba repasando algunas entradas en la red sobre MySQL y me he encontrado sobre este artículo que habla del problema que tiene MySQL con la gestión de Threads y en particular con la plataforma Java.

Básicamente el problema es que MySQL se ejecuta como un único proceso. Este proceso crea un Thread para cada una de las conexiones que recibe. En MySQL lo implementaron de este modo porque parece que era realmente rápido. Pero entonces se encontraron con esas plataformas que, como Java, están llenas de pools de conexiones.

Para los que no estéis familiarizados con este concepto, la idea de un pool de conexiones consiste en reservar de antemano las conexiones a recursos externos como son las bases de datos. El conectarse a un recurso externo suele ser una tarea costosa en cuanto a tiempo, y por lo tanto el mantener una estructura de memoria donde se guarden conexiones abiertas que se puedan reutilizar cada vez que nuestro programa accede a ese recurso, parece una buena idea. Cualquier servidor de aplicaciones Java que utilicéis funciona de este modo, Tomcat, Glassfish, WebSphere, WebLogic, el que sea. En otros lenguajes como .NET o Rails también es algo típico.

Y ese es básicamente el problema. La persona que administra el servidor de aplicaciones puede decidir el crear un pool grande: "Voy a reservar 500 conexiones porque vamos a tener muchos usuarios concurrentes". Lo que hará el servidor de aplicaciones es abrir 500 conexiones y mantenerlas abiertas de por vida, aunque no se utilicen. Como consecuencia en MySQL se abren 500 threads, aunque no se utilicen.

Lo ideal sería que MySQL tuviese también un pool de conexiones, pero por ahora va a ser que no. Parece que MySQL 6.0 sí lo va a tener aunque están resolviendo algunos problemillas.

Por cierto si utilizáis MySQL, el blog de Percona tiene dos artículos bastante interesantes:

1 - MySQL utilizado como base de datos NoSQL en memoria SSD
2 - Percona como alternativa a Oracle tras el lio de los precios con InnoDB

comments

3 Respuestas a "MySQL y los pools de Threads"
jcesarperez dijo...
11:51

Hombre, configurar un pool con 500 conexiones permanentes me parece más un error de configuración del pool que de diseño de mysql. No por el 500, sino porque sean permanentes! Lo más inteligente es ir matando las conexiones inactivas cada cierto tiempo. Así, además de optimizar recursos, evitas que los firewalls te jueguen malas pasadas, matando las conexiones ellos mismos y sin avisar a nadie.


Martín dijo...
12:02

Julio, todo es tan relativo. Hay casos en los que quieres un pool grande. Por ejemplo, en trading soliamos trabajar con pools grandes porque había el peligro de picos de gente que quiera vender y no les haría gracia esperar a que se reserve una conexión.

Pero ahí ya entramos en temas de gestión de pools. Muy importante como comentas. Cada cuanto se renuevan las conexiones, cuanto espacio de conexiones libres permitimos, se duplican las conexiones cuando el pool esté a punto de llenarse?... hay tantas cosas :)

Por cierto que has dejado muerto el blog en el 2010!!!


jcesarperez dijo...
18:50

Muy a mi pesar, pero sí, lo tengo totalmente abandonado. No tengo tiempo libre casi para nada, ni siquiera para acercarme a las conferencias agiles o al spring i/o.

De hecho, he borrado muchos de mis feeds, aunque conservo el tuyo y me alegro mucho de que hayas vuelto!

A ver si un día te animas y nos cuentas un poco sobre la solución de rendimiento y escalabilidad que usais en jobsket. Sin duda vuela!

Un saludo,
Julio.