Indy TCP Server: Uso de CPU 100% tras 5 min

[JARivera]

Tengo un servidor de TCP usando Indy que en general funciona bien. Sin embargo, por alguna razón, después de 5 minutos aprox. el uso de CPU se me dispara a 100%. Todo sigue funcionando, pero la maquina corre mas lento, y eso es un gran problema. Es una aplicacion bastante intensiva, asi que a los 5 minutos tengo aprox. 40 conexiones, aunque recibo solamente unos 10 paquetes por minuto en total. En la misma aplicación recibo también paquetes UDP, y alli recibo hasta 300 paquetes por minuto, sin problema. Es mas, si desactivo el componente de TCP, el uso de CPU se mantiene entre 8 y 15%, asi que ya no me queda otra mas que echarle la culpa a algo en el servidor de TCP. Sin embargo, tras semanas de romperme la cabeza con eso, no le atino a cual pueda ser la causa. Alguien tiene alguna sugerencia? Mil gracias!

[jachguate]

Es probable que se trate de un bug en las propias INDY. ¿que versión estas usando? ¿has actualizado a la última disponible en el sitio del proyecto indy

Saludos.

[[cHackAll]]

No necesariamente sea un BUG... la unica solucion en ese tipo de casos es ir deshabilitando las funcionalidades de tu sistema e irlas habilitando segun funcionen a la perfeccion...

Tambien habría que ver si estas cerrando todos los Handles y liberando la memoria asignada temporalmente para descartar problemas causados por programación.

Suerte

[jachguate]

Empezado por cHackAll

No necesariamente sea un BUG

Me cito a mi mismo:

Empezado por jachguate

Es probable que se trate de un bug

Empezado por cHackAll

la unica solucion en ese tipo de casos es ir deshabilitando las funcionalidades de tu sistema e irlas habilitando segun funcionen a la perfeccion...

En esto no estoy de acuerdo. Particularmente con las INDY que venían con Delphi 7, que era INDY 9, tuve algunos problemas extraños que se corrigieron con una actualización de las mismas. Claro que no digo que sea lo único, pues sin conocer el código de la aplicación... imposible decirlo, pero si que es probable. Ante la falta de información de versiones.. he preferido dejar el dato.

Hasta luego.

[JARivera]

La verdad, tengo una version algo viejita, porque estoy usando Delphi 6 (y, la verdad, no tengo una buena razón para cambiarlo...). En este momento, la funcionalidad dentro del server de TCP es la mínima indispensable: leo el paquete, lo parseo y lo inserto en la base de datos. Tengo una bitacora en un archivo de texto, para fines de depuracion, y lo mas curioso es que no hay nada de distinto en el patron entre los primeros minutos y el momento en que se satura el uso de CPU. De hecho, deshabilite todas las demas funciones, como cerrar sesiones que no han tenido actividad en cierto tiempo.

[jachguate]

Empezado por JARivera

La verdad, tengo una version algo viejita, porque estoy usando Delphi 6 (y, la verdad, no tengo una buena razón para cambiarlo...).

Supongo que se trata de Indy 9, aunque el único que puede saberlo sos vos...

Debiera estar la última revisión de dicha versión en el sitio que ya he apuntado antes. Nada perdés con realizar la actualización... hasta donde recuerdo, funciona de delphi 5 para arriba

Hasta luego.

[JARivera]

Juan Antonio,

que casualidad que ambos estemos en Guate! Por cierto, trate de ver tu perfil en Hi5 pero me dio un error. Alguna otra forma de contactarte?
En todo caso, voy a probar bajar la actualizacion de Indy y te cuento. Mil gracias,

Arturo

[jachguate]

Siempre contanos cómo te va después de actualizar.

Te he enviado ya información de contacto.

Hasta luego.

[JARivera]

Bueno, solo para comentarles, el problema sigue alli, despues de actualizar a Indy9 (D6 venia con Indy 8... tuve que hacer bastantes cambios para actualizar). De paso, cai en la cuenta de un problema con los threads, que ya solucione, pero lo del 100% de CPU se resiste a desaparecer. A veces son mas de 5 minutos, pero no veo un patron.
Dentro de la misma aplicacion tengo otro servidor TCP, en otro puerto, aunque alli suele haber una o dos conexiones, y ese no me causa problemas.
A continuacion una version simplificada del codigo OnExecute del servidor TCP:

Código Delphi [-]
 
procedure TfrmMyServer.ServerTCPExecute(AThread: TIdPeerThread);
var
  Data    :string;
  MyThread:TMyThread;
  Client  :TMyClient;
begin
     if AThread is TMyThread then
        MyThread:=TMyThread(AThread)
     else
         MyThread:=nil;
     with AThread.Connection do
     begin
         //espera la transmisión del cliente
         try
            Data:=readln('',TCPReadlnTimeout);
         except on E:Exception do
            begin
                 Data:='';
            end;
         end;
         if not(AThread.Connection.Connected) or not(ServerTCP.Active) or (AThread.Terminated) then
            exit;
         if shuttingdown then
                exit;
         if(Data <> '') then
         begin
              
              if MyThread<>nil then
              begin
                   Client := MyThread.Client;
                   if Client<>nil then
                   begin
                        //todo se asigna para ser manejado por el thread
                        Client.Data:=GetReport;
                        Client.PeerIPTCP := athread.Connection.Socket.Binding.PeerIP;
                        Client.portTCP := athread.Connection.Socket.Binding.PeerPort;
                        AThread.Synchronize(TMyThread.ProcessTCP);
                   end;
              end;
         end;
     end;//Athread.Connection
end;
 
//y el codigo simplificado de TMyThread.ProcessTCP es:  
 
procedure TMyThread.ProcessTCP;
var
   data:string;
   IpAddr:string;
   IpPort,ID:Integer;
begin
     data:=Client.Data;
     ipAddr:=Client.PeerIPTCP;
     ipPort:=Client.portTCP;
     ProcessPackage(data,ipAddr,ipPort,ID,PROTO_TCP);
     Client.ID:=ID;
end;

donde ProcessPackage es una rutina que parsea la data y actualiza la base de datos usando ADO, y devuelve un ID.

Sin embargo, aun si pongo entre comentarios esa llamada, es decir, no hago nada en la base de datos, de todas formas sigue disparandose el uso de CPU. Alguna idea?

[[fer21unmsm]]

Hola si pudieras colgar el código, te podríamos ayudar a hacer un seguimiento de este, a menos que sea privado.

saludos cordiales.

[JXJ]

usa eurekalog

casi siempre logran mostrarte los errores, mas comunes
que se ocultan,
te podrian decir, que linea de codigo causa el problema o como
se incia

[jachguate]

Que tal Arturo.

Comento que edité tu post para añadir la etiqueta [ delphi ] [ /delphi ], que es la razón por la que ahora el código aparece indentado y resaltado. Te recomiendo que aprendas a usarla. Podes dar una mirada rápida editando el mensaje.

Así mismo, te invito a leer la guia de estilo.

Hasta luego.

[tefots]

Empezado por JARivera

donde ProcessPackage es una rutina que parsea la data y actualiza la base de datos usando ADO, y devuelve un ID.

Sin embargo, aun si pongo entre comentarios esa llamada, es decir, no hago nada en la base de datos, de todas formas sigue disparandose el uso de CPU. Alguna idea?

yo el codigo no lo hubiera hecho tal como lo pones ahi.
ademas en el except , deberias detectar si la excepcion es por timeout , o por un error del socket , para asi forzar a desconectar al cliente , lo cual indirectamente creo que es lo que te está provocando el problema.

respuesta corta : pon un sleep(1) , despues del readln , tal como está el código solucionará el problema.

respuesta larga :
al hacer un readln , cuando el cliente se desconecta o se corta el socket , y como en el try excep no controlas el tipo de excepcion , haces que el readln salte enseguida (independientemente del valor que tenga TCPReadlnTimeout) , y como estas dentro del execute de un thread , se está ejecutando el readln y dando excepción constantemente , con lo que el procesador lo saturas (es como tener un bucle infinito dentro de un thread ). por eso , simplemente al poner un sleep(1) ya no consumes nada de procesador.

ademas , lo normal es hacerlo todo lo que haces dentro del try (y no despues del except) , y en el except controlar si la excepcion es idreadtimeout no hacer nada , y si es culquier otra hacer un athread.connection.disconnect


saludos.