Congestión Servicio Mysql
 

Muy Buenas amigos, Tengo un problema, tengo una base de datos en Mysql 4.1 montada en un muy buen servidor al cual se conectan por medio de VPN aproximadamente 10 maquinas para hacer consultas e inserciones a las tablas de esta base de datos, me ha pasado que si en alguna de las maquinas en las horas pico se intenta sacar un reporte que contenga mucha información el servicio de mysql colapsa! me gustaría saber si me pueden ayudar a configurar las variables de mysql para este flujo de datos , ya que he dejado las variables por defecto que trae mysql y debería de tunearlas, pero no consigo a nadie que me eche una mano con eso!!

Gracias de antemano!!!

Una simple búsqueda en google, yahoo o donde más te guste, te devolverá multitud de enlaces para configurar mysql... pero, la pregunta que se me ocurre es: ¿con sólo 10 conexiones se satura mysql?, no creo que eso pueda ocurrir salvo que las consultas que se hacen sean extremadamente complejas, que la base de datos sea extraordinariamente enorme, que tengas un problema con el servidor o las conexiones, etc.
¿El problema no será que la línea está saturada?, si es una conexión por internet, por vpn, necesitarás un buen ancho de banda, ¿puede ser ese el problema?.
¿Has usando algún tipo de monitoreo del servidor para comprobar qué está haciendo cuando se satura?, puede que no sea el servidor el problema.

Bueno en realidad he echo las pruebas suficientes y he ido descartando y necesito es ampliar las variables de los buffer de mysql, yo pense que por aqui me podia ayudar ya que el foro es de Mysql en especifico, pero bueno sino buscare por google o yahoo

Bien, ahora que sabemos lo que buscas, puedo asegurarte que algunos compañeros de clubdelphi son unos grandes expertos en mysql y podrán ayudarte.
Aunque puede que esto te sirva: http://ferranserafini.blogspot.com/2...del-mysql.html

Muchas gracias de verdad no pongo en duda que aquí están registrados los mejores profesionales de desarrollo en la web! por eso siempre acudo aquí así sea porque mi carro no me prende!

Bueno :rolleyes: si tu carro no prende puede ser por uno de los siguientes motivos:
* No tiene Combustible...;)
* El combustible tiene demasiada suciedad e impuresa...
* El alternador o la batería no sirve, o esta descargada.
* Algun cable no sirve o esta mal conectado
* Una rata dañina mordisquió algun cable principal y lo averió.:D:D.
*Etc,etc....
Espero te sea de utilidad...:):D:D:D.

Excelente dato! yo creo que es una rata dañina mordió el cable!! o que la persona que me le cambio el aceite al carro la ultima vez es un programador Experto y fanático de Visual Basic

Jeee,jeee...:D.

Bueno viendo tu problema sobre MySQL no has considerado trabajar con una versión superior a la 4.1? :confused: Por ejemplo trabajar con la version 5 o superior?.;).

amigos siguiendo el tema original, que variables de mysql me recomiendan que modifique, aparte del buffer. yo consegui esto por la web y es lo que recomiendan que me dicen ustedes:

set-variable = key_buffer=64M
set-variable = max_allowed_packet=256M
set-variable = table_cache=64
set-variable = sort_buffer=512K
set-variable = net_buffer_length=8K
set-variable = myisam_sort_buffer_size=16M
set-variable = max_connections=500
set-variable = interactive_timeout=345600
set-variable = wait_timeout=345600

Pues has llegado al sitio perfecto, da la casualidad de que soy mecánico (titulado y todo) de coches y motos. Así que pasa el coche para adentro y le echamos un vistazo :)

amigos hay alguna variable que tenga un valor fuera de lo normal o que deberia tener otro valor? y falta alguna variable por configurar que haya dejado por fuera??

Me parece que el problema por la manera de hacer las conexiones al servidor ya que comentas que lo haces por medio de vpn. Vpn funciona bien en cualquier aplicación si tienes un ancho de banda decente. Normalmente yo no utilizo este tipo de conexiones en líneas ADSL ya que dada la cantidad de información que pasa por cada tunel, se satura rápidamente el ancho de banda. Yo te sugiero que hagas la conexión directamente vía TCP/IP, es decir, que tu aplicación cliente se conecte al servidor directamente. Yo tengo una instalación por ejemplo, con 15 conexiones simultáneas en 3 ciudades distintas, tirando consultas a tablas de 300 mil registros para arriba y lo más que tarda alguna consulta es 1.5 segundos. Utilizo MySQL 5.1 (originalmente se diseñó sobre 4.1) y nunca he tenido que mover ninguna variable.

Otra cosa puede ser el tipo de consultas que lanzas, vendría bien un ejemplo de las que más utilizas para analizarla y poderte opinar más. Hay por cierto otra situación que pudiera pasar, si utilizas tablas InnoDB que son transaccionales y por algun error abres una transacción y olvidas hacer el commit o rollback llega el momento en el que el servidor simplemente cuelga todo por quedarse esperando a cerrar la transacción.

Como ves pueden ser muchas cosas, vendría bien mas info.

Amigo AzidRain, muy interesante tu comentario, efectivamente el ancho de banda no es muy bueno, y me gustaria saber si me podrias dar mas informacion en como podria conectarme via TCP/IP de la manera en que me comentas que lo haces con tu aplicacion, creo que solucionaria uno de mis problemas, por otro lado revisando mi base de datos observe que mis tablas son de tipo InnoDB

Es relativamente sencillo. En el TZConnection que utilizas para hacer la conexión podrás ver que tiene las propiedades para indicar el host, usuario, passw y base de datos la que se va a conectar. Basta indicar en host la ip o dominio en donde esta corriendo el servidor y con eso puedes acceder de manera remota. UNicamente tienes que abrir el puerto 3306 (si usas el default de MySQL) de tu firewall para que permita tráfico externo. Ojala y pudieras poner un resumen de estas propiedades del TZConnection que utilizas. No entiendo bien como haces el acceso ahorita, realmente que haces con los túneles, utilizas tu programa alojado en el servidor?, o utilizas un cliente en cada terminal que se conecta?

Por otro lado como te mencionaba el problema de los "deadlocks" de las transacciones se dá si explícitamente las estás utilizando en tu programa, este sería un ejemplo correcto:

Código Delphi [-]
 Datos.InitTransaction; //realmente lo que hago es mandarle al servidor un "START TRANSACTION"
    Try
     //Hacemos algo que puede fallar
       Datos.Commit;  //Nuevamente solo mando un "COMMIT" al servidor
    except
      Datos.RollBack; // Si algo falla deshacemos todo
    end;

Y esto nos produciría un deadlock:

Código Delphi [-]
 Datos.InitTransaction; //realmente lo que hago es mandarle al servidor un "START TRANSACTION"
    Try
     //Hacemos algo que puede fallar
      //Olvide hacer el comit!!
    except
      Datos.RollBack; // Si algo falla deshacemos todo
    end;

En el segundo si no hay error el rollback nunca se ejecuta y el servidor se queda indefinidamente esperando a que finalice esa transacción. Normalmente el efecto tarda a veces hasta varias horas en notarse. Lo notas porque el servidor empieza a mandar mensajes de error de que tiene bloqueada la tabla y no permite más acceso prácticamente a ninguna otra. Es decir, se paraliza totalmente hasta en tanto no mates la conexión que generó el deadlock.