Boost quits when I'm looking at graphs

[GlueGuy]

This is a new installation on 64-bit CentOS 5.5.

Everything seems to be going along swimmingly, and I am looking at graphs. Suddenly, the graph display "stalls", in the middle of displaying 1 or a few of the graphs.

I go to the cacti log, and see this:

10/17/2010 08:45:45 AM - BOOST: Poller[0] ERROR: Socket Error. Boost server is down. Contact support immediately!!

I check to see if the boost server is running (it isn't). So I restart it (it's starting via init.d).

Then I check the boost log, and all that's in there is

2010:10:17 08:46:21 - Cacti RRDtool Service Started

Does the boost.log get cleared during each restart? Is there a way to change this behavior? Is there a way to turn up the logging level so I can see what's causing boost server to quit?

Cacti Version - 0.8.7g
Plugin Architecture - 2.9
Poller Type - Cactid v
Server Info - Linux 2.6.18-194.el5
Web Server - Apache/2.2.3 (CentOS)
PHP - 5.1.6
PHP Extensions - libxml, xml, wddx, tokenizer, sysvshm, sysvsem, sysvmsg, standard, SimpleXML, sockets, SPL, shmop, session, Reflection, pspell, posix, mime_magic, iconv, hash, gmp, gettext, ftp, exif, date, curl, ctype, calendar, bz2, zlib, pcre, openssl, apache2handler, dbase, ldap, mysql, mysqli, PDO, pdo_mysql, pdo_sqlite, snmp
MySQL - 5.0.77
RRDTool - 1.4.4
SNMP - 5.3.2.2
Plugins

• Large Site Performance Booster (boost - v4.2)
  Bloom - Cacti Migration Tool (Bloom - v0.6.5)
  Network Discovery (discovery - v1.1)
  docs
  Host Info (hostinfo - v0.2)
  Login Page Mod (loginmod - v1.0)
  Device Tracking (mactrack - v1.1)
  Device Monitoring (monitor - v1.2)
  Realtime Graph Viewer (realtime - v0.43)
  Cacti-ReportIt (reportit - v0.7.2)
  Router Configs (routerconfigs - v0.1)
  Global Plugin Settings (settings - v0.7)
  Network Tools (tools - v0.3)
  Update Checker (update - v0.4)
  WMI Query (wmi - v0.1)

Otherwise, polling looks normal, and this is the typical polling message:

10/17/2010 09:26:32 AM - SYSTEM THOLD STATS: Time:0.0501 Tholds:5 Hosts:0
10/17/2010 09:26:32 AM - SYSTEM STATS: Time:90.1920 Method:spine Processes:1 Threads:3 Hosts:461 HostsPerProcess:461 DataSources:4319 RRDsProcessed:0

Typical boost stats look like this:

10/17/2010 08:46:44 AM - SYSTEM BOOST STATS: Time:8.6100 RRDUpdates:28126

Typical boost status looks like this:

Current Boost Status
Boost On Demand Updating: Idle
Total Data Sources: 4319
Total Boost Records: 9536
Boost Storage Statistics
Database Engine: MEMORY
Current Boost Table Size: 17 MBytes
Avg Bytes/Record: 545 Bytes
Max Record Length: 30 Bytes
Max Allowed Boost Table Size: 123 MBytes
Estimated Maximum Records: 237006 Records
Runtime Statistics
Last Start Time: 2010-10-17 9:16:42
Last Run Duration: 13 seconds (1% of update frequency)
RRD Updates: 24510
Peak Poller Memory: 25.59 MBytes
Detailed Runtime Timers: RRDUpdates:24510 TotalTime:13.1044 range_local_data_id:0.13 rcaston_add:0.1 get_records:0.44 results_cycle:11.27 rrd_path:1.62 rrd_template:2.93 rrd_lastupdate:2.09 rrd_field_names:0.25 rrdupdate:3.61 delete:0.14
Max Poller Memory Allowed: 1024 MBytes
Run Time Configuration
Update Frequency: 30 Minutes
Next Start Time: 2010-10-17 9:46:42
Maximum Records: 1000000 Records
Maximum Allowed Runtime: 20 Minutes
Boost Server Details
Server Config Status: Enabled
Multiprocess Server: Single Process
Update Timeout: 2 Seconds
Server/Port: localhost@9050
Authorized Update Web Servers: 127.0.0.1,192.168.222.116,192.168.222.138,192.168.222.149
RRDtool Binary Used: /usr/bin/rrdtool
Image Caching
Image Cacing Status: Enabled
Cache Directory: /var/www/html/boostcache
Cached Files: 15 Files
Cached Files Size: 240 KBytes

[GlueGuy]

I think I solved this problem by making two changes:

• Turned OFF "Enable On Demand Updating
• Reduced "Maximum Data Sources per Pass" to 2000 (was at 5000)

At least the problem hasn't re-occurred for quite a while now.