Carga del servidor

[fburria]

Buenas,

Hace ya bastante tiempo que tengo Pandora instalado, la versión 1.3, y siempre tengo que ejecutar el script de pandora_db cada cierto tiempo para liberar carga del Pandora_Data, ya que siempre llega a un punto en que se satura y los agentes empiezan a fallar, entiendo que es debido a que Pandora deja de poder procesar los datos que le llegan.

He revisado temas de carga, tanto del sistema como del mysql y parece bastante normal.

No tengo ni 20 agentes configurados en el Pandora, por lo que la máquina donde está instalado es una máquina normalita.

No sé muy bien por donde tirar, no sé si es problema del servidor, del Pandora, de la versión del Pandora. Referente a esto último, he probado varias veces de migrar y siempre he tenido problemas para la migración.

Bueno, ya me comentaréis posibles soluciones o que puedo mirar para trazar el problema.

Gracias

[Sancho Lerena]

El script pandora_db deberias correrlo diariamente.

Con la version 1.3.1 tenemos referencias de gente utilizandolo para mas de 100 agentes sin problemas. Para la 2.1 ahora la empresa que mas agentes tiene funcionando son 1020 agentes y para la 3.0-dev tenemos una planificación para 6000 agentes.

Está claro que tienes un problema en algun sitio ¿has dimensionado correctamente los buffers de memoria para MySQL?. ¿Que caracteristicas tiene tu servidor (CPU, Memoria). En cualquier caso si quieres actualizarte y tienes problemas y pocas maquinas yo casi me esperaba a pasarte a la 3.0 y reconfigurar todo de nuevo. Piensa que los agentes ya los tienes instalados y enviando informacion asi que un pandora reinstalado de 0 cogeria toda esa informacion y solo te faltaria definir informes y alertas de nuevo.

Si quieres migrar a la 3.0 primero tendras uqe hacerlo a la 2.0 y de ahi a la 3, será mas complicado.

[fburria]

El script pandora_db se supone que se ejecuta cada día, o así me lo reflejan los mails que llegan al root de las tarejas ejecutadas por el cron.

El tema de los bufferes de memoria no lo he modificado, suponía que para tan pocos agentes, con la configuración por defecto de MySQL bastaría.

Tengo 19 agentes configurados.

# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 7
model name      : Intel(R) Xeon(R) CPU           E5450  @ 3.00GHz
stepping        : 10
cpu MHz         : 2991.572
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss nx pni
bogomips        : 5990.55

# free -m
total       used       free     shared    buffers     cached
Mem:           503        489         14          0         40        239
-/+ buffers/cache:        208        294
Swap:         1023        103        920

¿Cuándo hablas de un Pandora desde 0, te refieres a realizar una instalación de Pandora 3.0 desde 0 y usar los agentes de la 1.3.1 o también debería actualizar los agentes y tentacle?

Gracias por la respuesta.

[Sancho Lerena]

19 agentes y te va lento ?!?!. Algo hay tremendamente mal para que vaya tan mal. Si miras la demo de pandora actual:

farscape.artica.es/pandora_console

Ahora mismo hay 1050 agentes y casi 5000 modulos. Vale que es la 3.0 pero el hardware es muy parecido al que estás usando tu ahora mismo.

Entra en la bbdd y dime el resultado de estas queries

SELECT COUNT(*) FROM tagente_modulo;
SELECT COUNT(*) FROM tagente_estado;
SELECT COUNT(*) FROM tagente_datos;
SELECT COUNT(*) FROM tagente_datos_string;
SELECT COUNT(*) FROM tagent_access;

Vamos a ver si encontramos el origen del problema.

[fburria]

Aquí te pongo los resultados de las queries:

mysql> SELECT COUNT(*) FROM tagente_modulo;
+----------+
| COUNT(*) |
+----------+
|      556 |
+----------+
1 row in set (0.00 sec)

mysql> SELECT COUNT(*) FROM tagente_estado;
+----------+
| COUNT(*) |
+----------+
|      556 |
+----------+
1 row in set (0.00 sec)

mysql> SELECT COUNT(*) FROM tagente_datos;
+----------+
| COUNT(*) |
+----------+
|   487369 |
+----------+
1 row in set (0.54 sec)

mysql> SELECT COUNT(*) FROM tagente_datos_string;
+----------+
| COUNT(*) |
+----------+
|      835 |
+----------+
1 row in set (0.03 sec)

mysql> SELECT COUNT(*) FROM tagent_access;
+----------+
| COUNT(*) |
+----------+
|    12340 |
+----------+
1 row in set (0.00 sec)

Te pongo esta otra también:

mysql> SELECT COUNT(*) FROM tagente;
+----------+
| COUNT(*) |
+----------+
|       38 |
+----------+
1 row in set (0.00 sec)

Aparecen 38, pero activos, ahora mismo, solamente hay 21, que he añadido dos más estos días.

[Sancho Lerena]

Esto no es nada, deberia ser instantáneo ¿?¿?.

[chejov suzdal voshkov]

mysql> SELECT COUNT(*) FROM tagente_datos;
+----------+
| COUNT(*) |
+----------+
|   487369 |
+----------+
1 row in set (0.54 sec)

no son muchos datos para 38 / 21 agentes ?¿

yo tengo 294 agentes y 306246 en tagente_datos

ya se ejecutan bien los cron de pandora ?

cada cuanto tienes configurado el compact y el purge de la base de datos?
sale justo al principio de la ejecución del cron, en todo caso desde el console/pandora setup/ se pueden ver, por defecto yo pondría 15 para el compact y 90 si quieres conservar los datos por 3 meses (más q suficiente), pero si quieres ir fino, pon 30 para el purge.

cambia el verbosity a 5 o a 10 en /etc/pandora/pandora_server.conf

y prueba a pasarlo un par de veces el cron /etc/cron.daily/pandora_db

pon el resultado de los logs.

[Sancho Lerena]

Cuelga aqui el .conf del server, me da que puedes tener el server_threshold muy alto.

[fburria]

Ya he encontrado lo que comentabas, suzdal, ahora mismo está configurado:

Máx. días antes de comprimir datos   15
Máx. días antes de eliminar datos 60

[Sancho Lerena]

server_threshold 15 es muy alto, prueba a poner:
server_threshold 1, deberias notar la mejora rapidamente.

Por otro lado tienes los timeouts y los reintentos bastante altos.

Has mirado el tamaño de los logs en /var/log/pandora ?, si son muy altos tb afecta al rendimiento.

Concretamente, lo que te va lento es el network o el data server ?

prueba a usar icmp_checks 1

[fburria]

Ya he modificado el server_threshold a 1 y no he notado cambio alguno a primera vista, internamente no sé si habrá mejorado.

Por otro lado, los timeouts y checks están con esos valores dado que son los que venían en la configuración por defecto. No recuerdo haber leído nada acerca de estos parámetros en el manual y como "tunear" pandora.

Lo que funciona mal es el data, que cada X días se "peta" y los agentes aparecen con el "Out of limits" y tengo que purgar la BBDD a mano y reiniciar posteriormente el pandora para que vuelva a recoger información de los agentes y tentacle.

[chejov suzdal voshkov]

Pregunta del millón, aunque suene a raro...

¿Desde la instalación se ha cambiado el nombre, la ip o la codificación de los caracteres y fecha de la maquina?

es posible que tengas en la tabla del data, registros obsoletos o con datos que no se procesan correctamente, prueba a revisarlos a mano, y borra los que tengan un timestamp posterior a 30 días o 60.. tu mismo ha de tener esta forma (sin comillas) "2009-07-10 12:19:50" y el utimestamp "1247221190"

por cierto.. .
tanto los clientes cómo el servidor han de correr con la misma fecha y hora y la codificación, de lo contrarío pueden pasar que el xml que se envíe al server no sea procesado y salga el Out of Limits para ese agente y que se pare el servicio.

otra cosa, si no te es un gran inconveniente, haz un backup de la bdd, borra el contenido de las tablas tagente* y prueba un tiempo, a ver que pasa.

[Sancho Lerena]

Buenos consejos, la verdad que no se me ocurre nada más que aportar !

[fburria]

Pregunta del millón, aunque suene a raro...

¿Desde la instalación se ha cambiado el nombre, la ip o la codificación de los caracteres y fecha de la maquina?

Lo único que puedo haber cambiado es la fecha de la máquina y cuando digo cambiado es configurado el NTP, el resto sigue igual que desde el primer día.

es posible que tengas en la tabla del data, registros obsoletos o con datos que no se procesan correctamente, prueba a revisarlos a mano, y borra los que tengan un timestamp posterior a 30 días o 60.. tu mismo ha de tener esta forma (sin comillas) "2009-07-10 12:19:50" y el utimestamp "1247221190"

He buscado y solamente he encontrado 29 registros anteriores a ese timestamp. Me parecen muy pocos cuando la tabla tagente_datos tiene más de medio millón de registros.

Sobre esto he visto una cosa curiosa, que igual es normal. Me he fijado que la tabla tagente_datos crece y decrece por segundos.

por cierto.. .
tanto los clientes cómo el servidor han de correr con la misma fecha y hora y la codificación, de lo contrarío pueden pasar que el xml que se envíe al server no sea procesado y salga el Out of Limits para ese agente y que se pare el servicio.

En principio todos tienen lo mismo, tanto fecha como la codificación. El Out of limits, como dije antes, se produce al cabo de unos días en los que el data, parece saturarse y deja de procesar los datos que le llegan desde los agentes.

otra cosa, si no te es un gran inconveniente, haz un backup de la bdd, borra el contenido de las tablas tagente* y prueba un tiempo, a ver que pasa.

Esto es complicado, la verdad, si fuese un servidor de pruebas no tendría problemas, pero no es el caso.

Gracias por las respuestas.

[chejov suzdal voshkov]

te sería complicado enviar una copia de la bdd, del pandora.conf y pandora_agent.conf?

lo digo por que así podríamos mirar el contenido de la las tablas y analizar en profundidad la causa de los problemas.