-
lentitud en la obtención de gráficas de estadísticas.
Hola buenos días
Llevo bastante tiempo notando lentitud cuando se obtienen gráficas de monitores snmp que muestrean anchos de banda, errores, etc.
En concreto me tarda del orden de 2-3 minutos cada vez que intento obtener una gráfica.He utilizado el script /usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_server.conf para mantener la base de datos y parece que lo hace bien:
Pandora FMS DB Tool 6.0 PS151020 Copyright (c) 2004-2009 Artica ST
This program is Free Software, licensed under the terms of GPL License v2
You can download latest versions and documentation at http://www.pandorafms.orgPandora DB now initialized and running (PURGE=730 days, COMPACT=0 days, STEP=1) .
Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/PandoraFMS/Tools.pm line 595.
Can’t locate PandoraFMS/Enterprise.pm in @INC (@INC contains: /usr/lib/perl5/5.10.0 /usr/lib/perl5 /usr/local/lib/perl5 /usr/local/share/perl5 /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/share/perl5 .) at (eval 12) line 1.- Pandora FMS Enterprise module not available.
Starting at 2017-03-09 09:51:04
09:51:04 [PURGE] No data to purge in tagente_datos.
09:51:04 [PURGE] Deleting old export data from tserver_export_data09:51:04 [PURGE] Deleting old session data from tsessions_php
09:51:04 [PURGE] No data in tagente_datos_log4x.
09:51:04 [PURGE] No data to purge in tagente_datos_string.
09:51:04 [PURGE] Deleting old event data at tevento table (More than 7 days).
09:51:04 [PURGE] Deleting old audit data (More than 15 days).
09:51:04 [PURGE] Deleting old SNMP traps (More than 7 days).
09:51:04 [PURGE] Deleting old GIS data (More than 7 days).
09:51:04 [PURGE] Deleting pending delete modules (data table).
09:51:04 [PURGE] Deleting pending delete modules (status, module table).
09:51:04 [PURGE] Deleting old access data (More than 24hr)
09:51:04 [PURGE] No agent access data to purge.
09:51:04 [PURGE] Delete contents in report that have some deleted modules.
09:51:04 [PURGE] Delete contents in report that have some deleted agents.
09:51:04 [PURGE] Delete empty contents in report (like SLA or Exception).
09:51:04 [PURGE] Deleting old netflow data.
09:51:04 [PURGE] Deleting old log data.
09:51:04 [!] Log data directory does not exist, skipping.
09:51:04 [CHECKDB] Ignoring not-init data.
09:51:04 [CHECKDB] Deleting unknown data (More than 0 days).
09:51:04 [CHECKDB] Checking database consistency (Missing status).
09:51:05 [CHECKDB] Checking database consistency (Missing module).
09:51:06 [INTEGRITY] Cleaning up group stats.
09:51:06 [INTEGRITY] Deleting orphan alerts.
09:51:06 [INTEGRITY] Deleting orphan modules.
Ending at 2017-03-09 09:51:06
[root@localhost util]#Por otro lado, la lentitud solamente la noto cuando obtengo las gráficas, en la navegación normal y uso de la herramienta a través de la interface web no va mal.
Por otro lado el my.cnf lo he modificado según indicaciones en la wiki y el asunto sigue igual,[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Mysql optimizations for Pandora FMS
# Please check the documentation in http://pandorafms.com for better results
table_cache = 64
key_buffer = 400M
max_allowed_packet = 64M
max_connections = 500
query_cache_size = 128M
query_cache_limit = 48M
join_buffer_size = 16M
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
innodb_io_capacity = 140
innodb_buffer_pool_size = 400M
innodb_additional_mem_pool_size = 62M
innodb_lock_wait_timeout = 50
innodb_file_per_table
innodb_thread_concurrency = 0
innodb_flush_log_at_trx_commit = 0
thread_stack = 64K
thread_cache_size = 8
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pidLa verdad es que el tema me tiene bastante despistado y no se a qué puede ser debido.
-
10 Replies
-
Hola Jramongv,
Cuál es el intervalo de los chequeos SNMP que intentas sacar en las gráficas con problemas de lentitud?
Únicamente ocurre con chequeos SNMP? has notado que ocurra con otro tipo de chequeos de red (latencia, disponibilidad de una web o un puerto…) o chequeos locales (reportados por agentes software)?
En la sección Setup -> Visual styles hay un parámetro “Graph resolution”, qué valor muestra?
Podrías adjuntar también los valores configurados en la sección de Setup -> Performance? Son estos los que determinan las opciones de purgado y mantenimiento de la base de datos.
Un saludo,
Antonio. -
Hola buenos días,
Las gráficas con este problema de lentitud son las de monitores snmp con un intervalo de muestreo de 5 minutos.
Fundamentalmente son las gráficas de monitorización snmp de anchos de banda las que tienen este problema, también me he fijado que son aquellas que tienen datos muy elevados de anchos de banda, las que tienen poco no tienen este problema, aunque esto último voy a probarlo un poco mejor. Tengo otros monitores como disponibilidad basadas en un generic boolean con pingcheck que no dan este problema.
El Graph resolution está en 5 (pone alto)
Los datos de prestaciones os lo paso en este link, no se que pasa que no puedo subir adjuntos.
https://drive.google.com/file/d/0B5chXyFerwDbX3gwMGxpRHlaSTA/view?usp=sharing
Gracias.
N
-
Hola Jramongv,
Por la información que me comentas, puedo decirte casi con toda seguridad que el problema se debe a que tienes demasiada información en la base de datos. 730 días son muchísimos para mantener en la base de datos de tiempo real, es una cantidad de información enorme y no es aconsejable emplear valores tan largos.
Nuestra recomendación es no mantener información de más de unos 45 días. Esta recomendación es orientativa, pues el valor exacto puede variar dependiendo del entorno: cantidad de agentes, cantidad de módulos, tipo de los módulos…
Mi recomendación es que utilices aquí un valor inferior, no obstante no es aconsejable reducir drásticamente de un valor tan alto (730) a uno mucho más bajo (45), ya que el script de mantenimiento de la base de datos puede llegar a tardar demasiado, por lo que mi consejo es ir reduciendo este valor progresivamente, por ejemplo puedes bajar en 10 cada hora, esto significa que a las 10 tendrás un valor de 730, se ejecutará el script de mantenimiento, a las 11 un valor de 720, se ejecutará de nuevo… y así sucesivamente durante varios días hasta que observes que el rendimiento de las gráficas es satisfactorio.
Como esto puede llevarte algún tiempo, otra prueba que puedes hacer para intentar acelerar el proceso es, en primer lugar, guardar un backup de tu base de datos, en segundo lugar ir reduciendo el valor en bloques mayores (unos 100) y observar el comportamiento, si ves que el script de mantenimiento no se queda atascado, puedes seguir bajando, y así.
Dada la delicadeza, complejidad y variedad de usos de las bases de datos, no es posible darte información más exacta al respecto, tendrás que ir “jugando” con los valores de purgado hasta alcanzar un rendimiento satisfactorio.
Recuerda siempre hacer un backup de la base de datos antes de trabajar con estos parámetros.
Un saludo,
Antonio. -
-
Si solo te dan problemas las gráficas puedes probar a bajar la resolución en el parámetro “Graph resolution”, prueba a establecerlo al mínimo para ver si el rendimiento mejora.
También es posible montar una base de datos de histórico para guardar información de periodos mayores, pero solo está disponible en la versión Enterprise.
Lo único que se me ocurre además de eso sería ir guardando los informes que necesites de periodos más cortos, por ejemplo mes a mes. Puedes sacarlos por pantalla, en papel o mediante una impresora pdf (los informes en pdf formateados también son de la versión Enterprise).
Un saludo,
Antonio. -
Jramongv,
Hay otra opción que puede quizá pueda ayudarte a mejorar el rendimiento, es el particionado de tablas de MySQL. Tenemos una sección en la documentación donde hablamos de ello:
En todo caso ten en cuenta que la base de datos es el componente más crítico y siempre antes de hacer cualquier modificación guardes los backups necesarios por si algo saliese mal o decidieses volver atrás.
Un saludo,
Antonio. -
Hola buenas
He visto también que existe la posibilidad de crear índices para mejorar el rendimiento de las gráficas
ALTER TABLE `pandora`.`tagente_datos` ADD INDEX `id_agente_modulo_utimestamp` ( `id_agente_modulo` , `utimestamp` );
¿qué opinais sobre esto?. ¿mejoraria la visualización de gráficas?
Gracias
-
Hola Jramongv,
Aunque todas las recomendaciones para ayudar a mejorar el rendimiento de la base de datos vienen siempre bien, es difícil que veas un verdadero cambio en el rendimiento manteniendo un histórico de información tan largo en tu base de datos.
No obstante te animo a que vayas aplicando las diferentes opciones mencionadas y nos comentes los progresos que observes.
Un saludo,
Antonio. -
Hola buenas tardes,
Pues ahora mismo tengo en la base de datos información de 13 meses y la visualización de las gráficas de monitores snmp me ha bajado hasta aproximadamente 1minuto 20 segundos.
Lo que me tiene bastante extrañado es que este tiempo de 1m20s que se tarda en monitorizar es la primera vez que se visualiza la gráfica, si la cerramos y a continuación volvemos a visualizar tarda aproximadamente 20segundos solo.
¿Tiene esto alguna explicación?.
Por otro lado, también estaría bien saber si el crear los índices mejoraría los tiempos de visualización.Gracias.
-
Hola Jramongv,
Nuestra recomendación es no mantener en la base de datos un volumen de información superior a aproximadamente dos meses, como ya te he comentado. La razón de esto es que las bases de datos MySQL en las máquinas convencionales no están preparadas para soportar tanto volumen de datos y mantener un rendimiento aceptable.
Crear los índices, subir recursos a la máquina, reducir la resolución de las gráficas… todo ayuda, pero la base fundamental y más importante se encuentra aquí en la cantidad de información almacenada en la base de datos.
En cuanto a la velocidad de carga de las gráficas, tiene su explicación en la caché. Existen varios tipos de caché tanto en los navegadores como en MySQL, que es la razón por la que la primera vez tardan más las gráficas. También puede ocurrir, por ejemplo, con los informes.
Un saludo,
Antonio.
