Consulta MySQL - volver a ejecutar - Aumenta uso Memoria

[José]

Hola a todos,

De antemano gracias por sus respuestas, y gracias porque estos foros sirven mucho.

La pregunta es que está mal en este código, o que falta (ejemplo preparado para el foro) que el uso de memoria aumenta entre 5 y 10 MB por cada ciclo en que vuelvo a ejecutar la consulta, que trae unos 20.000 registros. Si quito columnas o limito las filas, aunque el consumo es menor, el error persiste.

Code: Select all  Expand view  RUN

oDbProdu := Nil

cSelect  := 'Produ.CRAYON1, ' + ;
            'Produ.COD_UNIF, ' + ;
            'Produ.CODIGO, ' + ;
            'Produ.NOMBRE, ' + ;
            'Produ.PRESENT, ' + ;
            'Produ.CONTEN, ' + ;
            'Produ.UNIMEDI, ' + ;
            if( cGlbTabIteCol9 = 'F', 'Produ.REFERPRO, ', 'Prove.FANTASIA, ' ) + ;
            'Produ.CODUNIVER, ' + ;
            'Produ.CODICOMU '

c:= "select" + cSelect + " from TABLAITE as Produ left join PROVEDOR as Prove on Prove.RUT = Produ.RUTPROV"

for n = 1 to 10                       // ciclo para demostrar el hecho
  if valtype(oDbProdu) = 'O'
    release oDbProdu             // probé oDbProdu:end() y tampoco libera
  endif
  oDbProdu:= oMyCon:Rowset(c, oMyCon)
  msginfo( 'espero... y presiono enter')
next

Lo he probado en dos ddbb diferentes, MySQL y MaríaDB de 2 servidores diferentes, y es lo mismo.

Y además, si luego paso la consulta un oBrw (XBrowse) y la navego... los desplazamientos en el oBrw también, aunque menos, aumentan constantemente el consumo de memoria.

Esto es con HB 3.2 + FWH 21.06

Gracias

[carlos vargas]

Ummm, para empezar un query en un ciclo, no se me hace cómodo.
El caso es que para que la consulta finalize, debes hacer un oDbProduct:end() y a continuación un oDbProduct:=nil, para que entre el recolector de basura, pero insisto, ese query en el for...next, no es lo ideal, lo que deberíamos as buscar es hacer un solo query que obtenga todo de una sola vez, esto lo digo en el desconocimiento de que datos y que hacer con ellos.

[carlos vargas]

Me parece que en el ciclo no le da tiempo al recolector de basura de harbour entrar en acción, en MySQL el hacer constante consultas similares hace que el Sever haga uso se su caché, y es lo buenos de los servidores de bases de datos..., La primera vez toma.su tiempo, las siguientes al ser bastante similares es más rápido...

[José]

Carlos Vargas

Hola, muchas gracias por tu respuesta!

Tienes razón, el ciclo fue solo para la demo, para probar; lo uso un poco más parecido a como tú recomiendas.

Basado en lo que indicaste, usé

Code: Select all  Expand view  RUN

oDbProdu:end() ; oDbProdu:=nil
SysRefresh() ; hb_gcAll(.t.)
 

Justo antes de volver a ejecutar la consulta.

Y funciona, efectivamente ya no se eleva el consumo de memoria cuando se carga nuevamente, sea porque cambian los filtros o por otra razón que el usuario requiera.

Tu comentario sobre el "recolector de basura de harbour" me llevó a encontrar hb_gcAll.

Nota. Ahora me queda ver porqué cuando ejecuto ciertas acciones sobre la consulta o registros de esta (onchange u otros), el consumo de RAM también aumenta, aunque de 100 a 300 KB cada vez. Imagino que es mal manejo de mi parte, de variables, procesos u otros que deberé revisar.

De nuevo, muchas gracias!!! y atento si alguien tiene más información.

[artu01]

Haz intentado con crear indices en el sql, quizas mejore la velocidad.

[carlos vargas]

Me parece que la llamada manual de sysrefresh y el recolector no es necesario, dado que internamente al asignar NIL a la variable contenedora de un objeto query esto hace que se dispare una función de MySQL en C que cierra la consulta y llama al colector de basura, nuevamente me pare que el ejemplo del ciclo no es lo más adecuado ya que no si da tiempo al recolector de ejecutarse, tal vez alguien con conocimiento del tema nos ilustre.