Is there a limit on number of entries in a graph tree?

[waytac]

Hi...

We're running a ton of cacti servers, but the one in question is 0.8.6j under FreeBSD, MySQL 5.1.11-beta. It appears I've hit a limit where graph trees start getting quite funky in terms of display either in the graph-trees display or console graph-trees edit.

The graph tree which was under active edit was pretty densely packed, I admit. We had probably 20 hosts, each with their own header section, and each of THOSE header sections with the host display, coresiding with about six other header sections with about 7-graph subsets of the host graphs. So, we're intented about four levels, but the absolute number of items in this total section is quite sizeable.

To the point, what would happen after a while is that newly added graph trees stopped showing up in the display. In some cases, "prior" trees disappeared as well. In one case, a tree that fully showed up in the graphs display looked in the console-edit mode like it wasn't there at all. I tried a few things--such as segmenting those 20 top level hosts into sections of five hosts each, and at one point, everything across all graph trees disappeared in the graphs display except for the an empty representation of the tree I was editing.

This is when I got a bit spooked and started looking for guidance in the forum. I tried running some of the MySQL DB repair tools, and they were showing up as valid across all tables. A bit of SQL navigation around the graph tree and graph tree item tables looked valid.

I have to get this available for folks so I (groan) completely removed the tree in question and I'm going to just rebuild it manually tonight (didn't have time to wait for a response from any kind soul here as to how to recover this). The question I have is--am I hitting up against a known or operationally recognized limit in individual tree/tree node/etc. sizes? We're planning to roll this out to a much more sizeable device population, and I can't risk something like this happening again when our data size is of that density.

Note that nothing else funky appears to be happening in cacti--notably (whew) the graphs and data sources appear to be functioning normally and poll-populated reliably so near as I've been able to sample.

Thanks!
Wayne

[waytac]

Sorry, somehow this posted in the Windows specific forum (coulda sworn I posted this in "general" and in fact got an initial SQL error on post), so I'll repost this over there.

[BSOD2600]

I've never heard of this limitation before. There are plenty of users who monitor thousands of devices, so I'd think someone would've ran into it by now... a WAG would be it's due to your mysql version.

[waytac]

I will try an upgrade to 5.1.23 (I'm guessing that the version I have was in the FreeBSD ports area somehow, but I'll do an explicit upgrade). As I said, cursory and automated looks at the tables in question had them looking fine, but I can't account for how what queries the cacti PHP issues are handled and whether it could be botched at the query response processing by a specific version of mySQL.

Let me know, anybody, if you've had adverse experiences w/mySQL 5.1.23 on FreeBSD.

Just to be clear--I know that cacti manages bezillions of devices (or to be accurate, as many as can be polled in a 5 minute window typically). This is specifically about graph trees. A little back of the envelope math--because of the way we set up our hierarchy of specific graphs (not just hosts, but the graphs we call out), if you were to expand out the graph tree in question completely and totally, you'd have 750 items. Now, users don't expand that out that far, but that's what you'd see in, for example, the tree-edit console display with full expansion. I wasn't sure if that was pushing an envelope for that particular function.

Regards,
Wayne

[ispeed]

Any solution to this yet? I have the same problem, so do a couple other users.