-
Carga del servidor
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
-
21 Replies
-
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.
-
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.
-
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.
-
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.
-
-
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.
-
-
-
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
-
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.
-
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.
-
-
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.
-
-
Hombre, los ficheros de configuraciĆ³n no tengo problema en subirlos, pero la base de datos, mejor que no.
Subo el pandora_server.conf y uno de los pandora_agent.conf que tengo en una de las mĆ”quinas, salvo el tema de mĆ³dulos, todos tienen la misma informaciĆ³n.
Por cierto, revisando el servidor de pandora, voy viendo que el pandora_server consume de mĆnimo un 40% de la CPU y lo he llegado a ver a mĆ”s del 60%. Definitivamente hay algo mal, pero no sĆ© el que.
ĀæSi hay registros errĆ³neos en la BBDD puede generar este elevado consumo de CPU por parte del pandora_server?
-
Te diria los consejos que digo siempre:
a. Optimiza el MySQL. Si ahora mismo no esta consumiendo al menos el 50% de la ram total de tu sistema, esque lo puedes mejorar. Consulta la doc que hay en http://openideas.info/wiki para ver como mejorar el setup de MySQL.
b. Mira el tamaƱo de los logs de pandora en /var/log/pandora, deberian ser siempre pequeƱos, cuando son grandes o enormes, se nota en el rendimiento.
c. AsegĆŗrate de que todos los sistemas estan bien sincronizados de hora.
d. 30 agentes son “de risa” para lo que puede tragar pandora, incluso en la 1.3, me extraƱa mucho este problema la verdad.
Puedes enviarnos la salida de un “ps aux” y de un “uptime” de tu sistema, ya de paso envianos un “cat /proc/cpu” y un “cat /proc/meminfo”. En la version 3 estamos metiendo unos scripts que hacen esto y generan un .txt para que sea mas facil echar una mano a la gente con problemas como el tuyo, con el tiempo vamos aprendiendo de nuestros errores š
Sobre la migracion, la verdad si no tienes muchos datos, yo me instararĆa una 3.0 desde 0, vas a notar muchos cambios (a mejor), te lo aseguro. Si quieres te podemos pasar una imagen vmware con la 3.0 preinstalada, todavia no esta cerrada del todo, pero ya va muy muy bien.
-
Bueno, contesto por puntos.
a. He estado modificando el my.cnf del Mysql y ahora mirando el consumo de memoria, estĆ” al 49,4%, asĆ que creo que no voy a tocarlo mĆ”s.
b. He borrado los logs, he bajado el verbosity de 2 a 0, y ahora parece que no son muy grandes.
c. Eso ya lo mirĆ© el otro dĆa, este punto es correcto.
Subo las salidas de los comandos.
Me plantearĆ© lo de la migraciĆ³n, lo Ćŗnico que me tira para atrĆ”s es el tema de actualizar los agentes y que empiece a fallar ahora que tengo la 1.3.1 mĆ”s o menos configurada, salvo este problema de estabilidad.
-
Para mi, la Ćŗnica diferencia asĆ clara es el consumo del mysql y del pandora_server
realmente hay algo mal.te pongo mi ejemplo.
mysqlĀ Ā Ā 2375 38.8Ā 8.7 1232616 179528 ?Ā Ā Ā SlĀ Ā 10:45Ā 22:28 /usr/sbin/mysqld –basedir=/usr –datadir=/var/lib/mysql –user=mysql –pid-file=/var/run/mysqld/mysqld.pid –skip-external-locking –port=3306 –socket=/var/run/mysqld/mysqld.sock
rootĀ Ā Ā 4717 12.8Ā 2.1Ā 97724 44416 ?Ā Ā Ā Ā SslĀ 10:45Ā Ā 7:21 /usr/bin/perl /usr/local/bin/pandora_server /etc/pandora/pandora_server.conf -D
skynet_p2_Data 3886 of 5055 6:30 minutes / 619
skynet_p2_Net 580 of 5055 6:18 minutes / 523
skynet_p2_WMI 481 of 5055 1:29 minutes / 160en mi caso ese lag de 6 min varia entre 3 y 6 segĆŗn la actividad, pero claro mira la cantidad que procesa, y eso que corre en una imagen del vmware.
piensate la migraciĆ³n, aunque sea parcial y progresiva, el pandora_agent.conf no hace falta cambiarlo y la ejecuciĆ³n del instalable siempre lo puedes hacer silencioso en el login.bat de los usuarios (yo lo tengo asĆ), luego copias de nuevo el pandora.conf con el aƱadido del master y secondary server, asi pueden seguir enviando datos al 1.3 y al 2.
-
Pues no consigo encontrar que es eso que va mal, porque es que tampoco hay muchos sitios donde mirar.
Pues si el pandora_agent.conf se puede reutilizar, sin problemas, desinstalar e instalar el nuevo.
Cuando salga la 3.0 empezarƩ desde 0 a ver como va la cosa, aunque es una movida porque tendrƩ que reconfigurarlo todo desde 0 pero bueno.
Pero me da mucha rabia no encontrar que estĆ” pasando, sobretodo cuando tengo tan pocos agentes enviando datos al pandora :-/
-
