Congestión Servicio Mysql

[JerS]

Empezado por JerS

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

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

[[AzidRain]]

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.

[JerS]

Empezado por AzidRain

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

[[AzidRain]]

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.