spine appears slower from 0.8.7d to 0.8.7g

[ayinger]

I upgraded my spine and cacti from 0.8.7d to 0.8.7g, and PA to 2.8. I noticed that spine 0.8.7g had slower speeds than spine 0.8.7d. Let me know your thoughts, for now I rolled back my spine to 0.8.7d. I did not see any errors in the logs.

0.8.7g
SYSTEM STATS: Time:58.2413 Method:spine Processes:4 Threads:30 Hosts:135 HostsPerProcess:34 DataSources:1903 RRDsProcessed:1140

0.8.7d
SYSTEM STATS: Time:39.2689 Method:spine Processes:4 Threads:30 Hosts:135 HostsPerProcess:34 DataSources:1903 RRDsProcessed:1140


Technical Info
-----------------------------------
Date Fri, 16 Jul 2010 18:43:04 -0400
Cacti Version 0.8.7g
Cacti OS unix
SNMP Version NET-SNMP version: 5.3.2.2
RRDTool Version RRDTool 1.2.x
Hosts 154
Graphs 1048
Data Sources Script/Command: 115
SNMP: 616
SNMP Query: 735
Script Query: 5
Script - Script Server (PHP): 5
Script Query - Script Server: 60
Total: 1536
Poller Information
Interval 60
Type spine
Items Action[0]: 1942
Action[1]: 113
Action[2]: 107
Total: 2162
Concurrent Processes 4
Max Threads 30
PHP Servers 2
Script Timeout 45
Max OID 1
Last Run Statistics Time:39.2843 Method:spine Processes:4 Threads:30 Hosts:135 HostsPerProcess:34 DataSources:1902 RRDsProcessed:1138
PHP Information
PHP Version 5.1.6
PHP OS Linux
PHP uname Linux 2.6.18-194.3.1.el5 #1 SMP Sun May 2 04:17:42 EDT 2010 x86_64
PHP SNMP Installed
max_execution_time 30
memory_limit 128M

[ayinger]

this next question was moved to a separate post.

[bfek-18]

Hallo,

have the same observation, go back to spine-0.8.7e.

bye

[TheWitness]

The current svn is mighty fast. However, prior to releasing a patch, I am awaiting a report from a user who was receiving problems with the POPEN code. If you are not using scripts, the SVN is pretty stable. If you are using the script server, you will also be fine.

TheWitness

[dmilholen]

This is my first post on here to let everyone know what I found and what helped me.

I have a 1000 devices I monitor with special scripts and other RRDs.
In All there are about 2500 data sources.

I am running centos 5.5 x64 with 2 dual core 2.8G zeons.

When I upgraded to cacti 8.7G and Spine to the latest.

Everything broke that I mentioned above.

I tried all different methods that were polluted across the internet and the forums. That even dated back to 2005.

All I had to do was do a >yum update

And all is good All data sources graphs and devices are good and completed in 45s during a poll.

I have 1 process,15 threads, 3 scripts servers, 10 seconds for each script, 5oid request seems to do the trick.

[TheWitness]

Do me a favor, run the output of the following:

rpm -qa | grep -i cacti

Also, whose repo's are you using?

Thanks,

TheWitness

[dmilholen]

This returned no results because I did a manual install of cacti.

rpm -qa | grep -i cacti

Here is a list o my repos..

yum.repos.d]# ls
C5-testing.repo CentOS-Media.repo rpmforge-testing.repo
CentOS-Base.repo mirrors-rpmforge
CentOS-Base.repo.rpmnew rpmforge.repo

Let me know if there is more info you need.
I spent alot of time figuring this out on my own. If I can help some else it will make my efforts worth it.
I believe it had to do with the Glib libraries.

Still looking into it.

[TheWitness]

Ok, cool. I see. PM me the following:

rpm -qa > file_for_larry.txt

TheWitness

[TheWitness]

Ok, so here is what we know. First of all, you are running a testing version of CentOS 5.5. Here is my Repo List;

Code: Select all

[root@localhost yum.repos.d]# ls
CentOS-Base.repo  CentOS-Media.repo

My version of PHP is:

Code: Select all

PHP 5.1.6 (cli) (built: Mar 31 2010 02:39:17) 
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

Yours is 5.2.10. It's a big difference. Lot's of issues were in 5.2.x. Mostly cleaned up now, as you demonstrated.

TheWitness