Interesting... That's actually easy to do in SOME situations, namely those that do copy-on-write on a fork() call. The fork()ed child gets a copy of memory as of the fork() call and can happily do what it wants with it - subsequent updates won't impact it.
I haven't done a lot of testing, but give the enclosed patch (vs. 3.0) a try. Unfortunately that won't run in all OSes. For the others, I guess the question is, can you live with the RRDs being out of time-sync? -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Kouprie, Robbert > Sent: Thursday, June 10, 2004 7:50 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [Ntop-dev] Spreading ntop's RRD dumps to spread system load > > > Hi Luca, ntop-dev, > > (Luca, we talked a little bit about this already - so this just > serves as a reminder and to inform ntop-dev). > > Just an idea for something I stumbled upon with the RRD dump > option in ntop. When RRDdumping to a large number of different > RRDs the system load gets a big spike. For example, when enabling > host RRD dumps in our setup (on a /16 net with about 25k active > hosts) it has to update *a lot* of rrds. Although I use a RAID10 > setup on SCSI disks, still the system gets a high load spike when > it's dumping time. > > Maybe it is an idea to spead the total disk I/O (i.e. the RRD > dumps) within the interval that is set to do the dumps. (So very > simply put: why do 25000 RRD updates once in 5 minutes, instead > of 5000 each minute in this 5 minute interval?). > > Regards, > Robbert >
BMS0500-forkrrd.patch
Description: Binary data
_______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
