johnrembo wrote:
1st - you should check poller cache and try running single qos or car query from the console. You can use unix "time" command to measure how long it takes:
#time /usr/bin/php /opt/cacti/scripts/cisco-qos-64.php 10.10.10.10 .....
time /opt/csw/php5/bin/php /opt/cacti-0.8.7b/scripts/cisco-qos-64.php PE_XXX_1 "3::::XXXX::YYYYY::MD5::::[None]::::161::500" query class
[...]
real 0m9.239s --->seems to me a lot of time, i have 80 different classes configured on the box, but the processor is operating normall.
user 0m2.060s
sys 0m0.760s
PE_ROUTER_1--> show proc cpu
CPU utilization for five seconds: 6%/2%; one minute: 4%; five minutes: 5%
johnrembo wrote:
2nd - when next pooling is to come (you can determine it by using "date" command) - for example 11:59:30 - you could check what scripts prom previous pooler are still hanging there:
#ps ax|grep php
Almost all the processes are finishing on time, I'm polling every five min, but i have had to remove some routers from the cacti db to achieve this, otherwise instead of processing 172 rrds cacti only have time to process about 140 rrds
johnrembo wrote:
3rd - maybe you have thousands of interfaces on a busy cisco box and data-queries are taking far too long (usualy this happens when you press a green circle button which reloads a data-query cache). See my post above on debugging data-query (use "time" command as well).
I'll do this and let you know
johnrembo wrote:
4th - I had an issue with juniper routers and too long ifAlias (or ifDescr) fields. When data-query was reaching too long ifAlias (our engineers define them manually) - it was hanging the connection. See you router's doccumentation (or ask support) if there are such restrictions and fix them.
Maybe this can be the issue, the ifAlias on my interfaces is too long, ie:
int Serial1/2/7:0
description PEP.RNTE.PE_YYY_1.GALLO-VERDE
johnrembo wrote:
5th - OSI Layer-8 problems?
maybe a problem between the chair and the keyboard