Escribiendo 400.000 reg en proceso servidor Cae vserver


([N4] info) #1

Siguiendo con mis pruebas intento importar 400.000 registros de un fichero de texto con el siguiente lamentable resultado:

Tabla Artículos:

Campos: Código 3 dg Num / Descripción 59 Dg Alfa128 / RefPpal 16 Dg Alfa128 / Refsec 16 Dg Alfa 128 / Tipo 20 dg Alfa 256

Indices: Codigo / Descripción 29 dg / Palabras / TRozos / Refppal completo / Refsec Completo

En el proceso guardo en una tabla auxiliar la hora en que se van escribiendo cad 25000 registros para ver lo que tarda.

Ejecuto proceso:

en 1er plano OK

en 2do plano OK

En el servidor 3er plano sincrono, aquí empiezan los problemas.

escribe aprox. 75000 registro y se cae el servicio. Al entrar de nuevo no tiene acceso a los datos de la tabla si ha escrito porque el fichero dat ttien varios megas. reinicio aplicación, datos etc... pero no se puede acceder alos datos.

Solución:

Paro servicio / Borro tablas del disco /reinicio servicio / ejecuto de nuevo vclient / me vuelve a pasar lo mismo 4 veces.

veo el siguiente mensaje que al poco desaparece:

error de comunicaicón con vatp://localhost:6900 Operación: ServerRunProcesoSinOrigen

Le quito los dos ultimos indices, tengo más suerte leo 150.000 reg aprox. pero me pasa lo mismo el servicio crash.

me quedo solo con el indice codigo mas suerte consigo ler 250.000 repito y mas de lo mismo.

Una sola vez el servcico no se cae solo lee 150000 pero el ordena va lentisimo administradr de tareas el USO DE CPU VSERVER 99%.

xp sp2 1gb corel 2 duo 2.2

O estoy haciendo algo mal o me acojo.....

Un saludo

Miguel

Adjunto jpg del proceso

[attachment=4809,496]


([N4] eic) #2

Hola, Miguel.

Si miras en:

http://velneo.es/info/v7_71_es/tutorial_avanzado/uso_avanzado_de_procesos/

en el apartado "Comandos de ficha y campos de V7", verás que para dar altas, no hace falta usar el comando [Procesar ficha en memoria] que tienes. Primero, se lanza el [Crear nueva ficha en memoria] y después, directamente, el [Alta de ficha]. 

No sé si eso tiene que ver algo en que no sea capaz de liberar la memoria que utiliza. En realidad, está creando las fichas en memoria y luego las pasa al disco, pero no sé de qué manera gestiona esa memoria. 

Al menos, puedes probar con esto.

Saludos,

Fran Varona

 


([N4] info) #3

Gracias Fran lo probaré y comentare el resultado y de paso los una tabla con los tiempos que ha tardado en escribir los registros en los distintos modos.

Un Saludo

Miguel Benjumea

 


(heber.microsipdf) #4

Cada que se da de alta un registro vServer y su uso de memoria inteligente, o algo así me comentaron, va guardando todas esas fichas en el caché, ya sea en la memoria del servidor o en la memoria del cliente (RAM). Imagino que con tantos registros el proceso Server debe ocupar toda la memoria RAM, razón por la cual todo va muy lento.

Yo también noté que el proceso Server usaba todo el CPU en importaciones de texto.


([N1] juan_figueroa.telefonica) #5

No sé si las cifras que das son exactas o aproximadas. Si son exactas y rompe con cifras múltimo de 25.000, es probable que algo tenga que ver el subproceso contador de bloques.

Hay que tener encuenta que cada vez que importa una línea y genera un nuevo registro se reindexa por todos los índices declarados toda la tabla y cuantos más registros vaya teneniendo, lógicamente, más tiempo invierte en reindexar.

En V6, en la importación mediante bases de datos externas, en lo tubos de importación excepcionalmente se podía suspender la indexación además del valor inicial de los campos y las actualizaciones, asumiendo el riesgo de la inadecuación de los datos importados con respecto a la duplicidad de las claves únicas. Si se importa vía ODBC u otro métodos como mediante lectura de ficheros esto no es posible

Con esto quería decir que, tanto en V7 como en V6, debería permitirse obviar las indexaciones reiteradas en estos procesos controlados de importación cuando són masivo y esporádicos, p.e. para migrar datos. Luego de realizada toda la importación simplemente se reindexaría y se buscarían las claves duplicadas produciendo una rejilla con las incidencias.

 

 


([N4] info) #6

Hola Juan. Las cifras multiplos de 25000 son aproximadas, yo grabo un registro en una tabla auxiliar cuando se han producido 25000 escrituras (este fichero afortunadamente no se me escojo..., lo quería utilizar inicialmente para ver los tiempos que tardaba entre escrituras segun iba creciendo la base de datos ) . Lo unico que se, es que en el tramo 25000*X y 25000*(X+1) (no se exactamente donde) se cae el servicio Y DEPENDE del número de indices que tenga la tabla, como indico según  quito indices escribe más registros y aunque reinicies la instancia de datos, no se puede acceder a los mismos, solo en una ocasión pude acceder a ellos, el fichero DAT en disco llega a tener unos 20 Mb. Si vuelvo a poner más indices vuelve a escribir menos registros hasta el crash. Si cojo un fichero de texto e importo sólo 70000 reg. el proceso acaba normal y puedes acceder a los datos. Pero como he comentado en 1er y 2do plano no hay problema.

Como dices puede ser un problema de la reindexación, pero sí fuera por esto debería yo creo acentuarse todavia más en 1er y 2do plano. En cualquier caso el problema me parece bastante serio.

Haber Si alguien ha importado una gran cantidad de datos en 3er plano y no le ha dado problemas y puede comentar como lo ha hecho.

Un Saludo

Miguel Benjumea


([N4] info) #7

Atendiendo lo que me comento Fran Varona, he cambiado el proceso para dar directamente alta de ficha sin procesar ficha en memoria, el resultado es el mismo con los indices que tiene ahora el servicio se cae entre al escribir entre 150000 y 175000 registros.

Espero que velneo me diga algo.

Un Saludo

Miguel


([N4] info) #8

Escribi este Tema el día 26/06/09 todavía a ando esperando que alguien de velneo me diga si es normal, si estoy haciendo algo mal o que puede pasar, o si simplemente la ejecución del proceso en 3er plano tadavia no funciona correctamente.

Un Saludo

Miguel


([N4] fgutierrez.velneo) #9

Perdona pero no nos habíamos percatado de tu post.

Hemos pasado a desarrollo las indicaciones que nos comentas para tratar de reproducir el problema.

En resumen: un proceso (que no transacciona) llama a otro en tercer plano (que transacciona) que es el que realiza las operaciones. Al cabo de un tiempo, muestra el error Operación: ServerRunProcesoSinOrigen.

Confírmanos por favor que el proceso realiza operaciones durante todo el tiempo que se ejecuta el proceso. Para ello accede al panel de transacciones de Velneo vAdmin V7 y activa el refresco. Puedes hacer doble clic sobre la transacción en curso para conocer más información al respecto.

El proceso llamado en tercer plano no tiene origen ¿es así? La línea de proceso desde que se ejecuta el proceso llamado, ¿tiene origen?

Gracias por tu colaboración y un saludo.


([N4] info) #10

Buenas de nuevo, gracias por tu contestación fgutierrez. te comento todo el proceso que según tus indicaciones he realizado de nuevo.

Desde Menu lanzo una acción a un proceso sin origen

Desde este ejecuto proceso (sin origen) en 1er 2do y 3er plano.

Comenzando.

(1) paro servicio -> (2) Borro ficheros articulos.dat e idx en disco -> (3) Inicio Servicio -> (4) cargo vAdmin -> (5) Voy a panel de transacciones -> (6) Pongo autorefrescar en rápido -> (7) vClient -> (8) ejecuto aplicación en 1er y 2do plano, voy a vAdmin veo las transacciones las va realizando e incorpora 400000 reg normal, se puede acceder a ellos.

Vuelvo a realizar todo el proceso, pero ahora en tercer plano. voy a vAdmin -> panel Transaciones -> comienza a dsiplayar las transaciones cuando llega en la primera ocasión a 193422 reg . aparece un nueva transación os envio imagen y deja de funcionar todo por (por supuesto al entrar de nuevo no se puede acceder a la tabla). y ya no hay nada que hacer. vuelvo a hacer todo en esta ocasión llega a 194336 y adios. Vuelvo en esta ocasión 188792 pero no genera una segunda transacción el servicio no parece funcionar intento detenerlo y obtengo el error que os envio en jpg.

vserver utiliza el 99% de la cpu tengo que matar la tarea.

Nota al pinchar sobre la transacción cuando parace que no sigue funcionando aparece la pantalla que os envio si intento ir viendo lo que realizó la transacción se tuesta, debe ser porque hay muchisimas líneas, pero esto no debiera ser así.

Un Saludo

Miguel


([N4] davidgu) #11

Estimado Miguel

Lo mejor es que nos envías los registros ha importar y el proyecto que estas usando a soporte, para que lo veamos, este tipo de operaciones son normales en las baterías de pruebas y no tenemos constancia de un error similar. Como bien dices en primer y segundo plano funciona perfectamente, con lo que seguro que es algo particular al lanzar el proceso en tercer plano.

Nos gustaría ver tu aplicación y los procesos importados, quizá tenga algún detalle la aplicación o algún funcionamiento particular que nos gustaría estudiar.

Respecto al vAdmin, recuerda que te esta mostrando una transacción de más de 1.200.000 operaciones, con lo que las aplicaciones realizarán uso intensivo de la CPU y memoria de tu máquina.

Esperemos que el resultado sea algo tan sencillo como en el post "http://velneo.es/foros/topic/v7-casi-3-veces-mas-lento-que-v6"

Muchas gracias por tus comentarios.

Saludos


([N4] info) #12

<div class="post">

Quiero comentar de nuevo que Atendiendo lo que comento Fran Varona, he cambiado el proceso para dar directamente alta de ficha, **sin** procesar ficha en memoria (Antes no se ya si lo habia hecho o no, **estoy en duda**), el caso es que el resultado es el mismo pero escribe casi el doble de registros 300000 y 350000 registros.

Un Saludo

Miguel

</div>


([N4] velavisual) #13

Buenas y calores tardes,

 

Simplemente dejar constancia de que lo que comenta Miguel en este post, a mí me ha ocurrido también. Leí el post y puse todos los elementos necesarios para poder realizar lo mismo esta mañana.

 

1.- Hice un proceso en las nubes con su correspondiente acción, la cual importaba ficheros ascii a una tabla.

2.- Instalo el vAdmin, vClient en un Quad con 4 gigas de ram.

3.- La aplicación correpondiente me la descargo de la nube y la instalo en la carpeta de cajas.

4.- Inicio servicio, vadmin, creo instancias y todo lo neceario. Ejecuto vclient

5.- Importo un archivo con 83038 registros (de 700 bytes/reg.)y todo ok y en una sola transaccion. Todo en 3P.

6.- Importo otro arhivo con 433571 registros (de 700 byte/reg.) y cuando llega a unos 110000 (+ o -) se presenta otra transacción. A partir de ahí los problemas

Los las tareas tienen recursos de memoria suficientes, de echo no superan el 53%

A veces el vAdmin aparece activo y al rato inactivo

El ordenador no deja realizar otras tareas, aunque a veces si y dependiendo de los recursos de memoria libre en cada momento.

No deja acceder a los datos, aunque tengo que cerrar antes todas las aplicaciones para poder usar el vclient, ya que el vadmin sólo admite una conexión si no se dispone de licencias. Como es este caso.

También indicar que me genera muchos más registros de los que debiera, es como si volviese a realizar la transacción en ejecución o la que no se llegó a realizar correctamente.

La tabla tiene 3 indices (por nombre, palabras y trozos)

Si lo realizo en primer plano todo ok, pero si cambio el plano de ejecución en el proceso a 3P, pasa todo esto.

Son un total de 516609 registros. Pues con lo mencionado, me genera hasta un total de 830000 registros, y por que lo corté y no dejé que terminase.

Indicar  que no observé ningún mensage de error.

 

 

 

 


([N4] velavisual) #14

.... adjunto proceso.....

[attachment=5023,531]


([N4] info) #15

Gracias por tu prueba velavisual, lo que lamento es que tambien te haya pasado lo mismo, hubiera preferido equivocarme.

Un Saludo

Miguel