[tip]How i made my cacti render faster

[mxxcon]

For a while now i had a problem with my cacti generating graphs very slow, ~3-5sec per graph. It wasn't polling or reading but actually generating "pictures".

so Googling around i found a tip that suggested regenerating fonts cache.
So i ran this command on my Centos 5.4:

Code: Select all

sudo fc-cache -s -v

and now my cacti generates 40-graph page in less than 4 seconds
Give it a try on your system and see if that makes any improvements.

[bmote]

I applied that change. I hope it helps. Mine always seemed slow displaying the web pages.

[mxxcon]

I applied that change. I hope it helps. Mine always seemed slow displaying the web pages.

did you notice any improvements after you've done this?

[bmote]

Yes, very much so. My Cacti installation is running on a severely overburdened VM farm. The pages definitely render more quickly.

[gandalf]

This should not change anything when using rrdtool <= 1.2.x
On higher versions, I was under the assumption that fc caching happens automatically (as we always have an open pipe to rrdtool).
R.

[mxxcon]

This should not change anything when using rrdtool <= 1.2.x
On higher versions, I was under the assumption that fc caching happens automatically (as we always have an open pipe to rrdtool).
R.

Could it be a regression in 8.7g?
I distinctly remember older versions being at least as fast as after i ran fc-cache command..

[gandalf]

I don't think so. We simply pass the same rrdtool command to the rrdtool pipe. The time consumed is mostly rrdtool execution time.
To be most certain, this will require access to a system showing this behaviour.
If I'm correct, the effect will scale with the amount of fonts installed.
Unfortunately, you did not answer to my assumption above, so it's all guesswork ...
R.

[TheWitness]

Yea, something like an strace of an rrdtool pid would be beneficial.

One correction for the new 'master' though. I don't believe that graphing uses a pipe as each graph request is a separate backend call. Since they are asynchronous, RRDtool is forked for each graph.

We could possibly fix this with a simple enhancement to the boost server of course.

TheWitness

[mxxcon]

Yea, something like an strace of an rrdtool pid would be beneficial.

One correction for the new 'master' though. I don't believe that graphing uses a pipe as each graph request is a separate backend call. Since they are asynchronous, RRDtool is forked for each graph.

We could possibly fix this with a simple enhancement to the boost server of course.

TheWitness

this guy was experiencing similar problem and solution was fc-cache. he also posted strace results
http://www.smert.net/2009/11/07/poor-pe ... ng-graphs/

[TheWitness]

Yes, it's a permissions issue that slows things down. The strace almost looks like Windows when it tries to open a single file (sorry, not meaning to insult).

I'm glad to have seen someone get to the bottom of this. I thought it was just slow...

TheWitness

[mxxcon]

so can something be done in cacti to resolve this problem or to notify a user to correct this permission problem?
people might have such 'misconfiguration' and don't even realize it and think that cacti is slow.

[TheWitness]

Announcement. It's a permissions problem. Should be done by the Linux distrib maintainer. However, in the mean time, we should publish an Announcement.

I'm not to familiar with this. Gandalf is best.

TheWitness

[gandalf]

I don't believe that graphing uses a pipe as each graph request is a separate backend call. Since they are asynchronous, RRDtool is forked for each graph.

This indeed explains bad graphing times. RRDTool will (as I've deduced from a mailing to rrdtoll-users, so it's not my own knowledge) scan the font dir(s) on a first call. It will/shall cache the data and be faster on subsequent calls.
But if there is no subsequent call as suggested by Larry, we will always face this time lag for rrdtool 1.3.x and up.
R.

[TheWitness]

More reason to allow either the boost server to do this, or support the new cache daemon, or have some other inittab/init.d process handle this.

TheWitness

[gandalf]

More reason to allow either the boost server to do this, or support the new cache daemon, or have some other inittab/init.d process handle this.

TheWitness

I was going the cache daemon way. But unfortunately, it does not support specific options required for us. I posted a request to the mailing list to no avail. And my C knowledge is not good enough to do it on my own.
I still suppose that this is the way to go.
R.