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.
PE_ROUTER_1--> show proc cpu
CPU utilization for five seconds: 6%/2%; one minute: 4%; five minutes: 5%
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
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
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:
5th - OSI Layer-8 problems?
maybe a problem between the chair and the keyboard