Thanks - It'd be great to share this memory, but I'm suspecting start/stop could cause other problems -- i.e. dropping current connections. Also, we'd still need to know when to start/stop the given machine's service.
As for touching, instead of using the physical disk, we could use an extra column in a database row that always gets loaded to do the check if that ultimately matters. If the semaphore is missing (machine/process), it can be reloaded. I'm interested to hear what others are doing to acheive the same results. On Saturday 18 March 2006 16:55, Jonathan Vanasco wrote: > i asked something like that once before (though not in terms of > mod_perl) , and was told this: > > if the disk doesn't have a lot of read/writes already, the the OS > should optimize a bunch of the filechecking into memory and won't > touch the disk > if it does have a lot of use ( uploads/ shred use as email/imap/ > etc ) then use either memcached or another in-memory system / > daemon / socket connection that never touches the disk > > i know little of how the kernel handles that sort of stuff > > the one thing i'd note about your plan is this: > if you're updating a large hash, then on update that hash will be > copied into each child -- it won't be shared among the apache > children. i'm not sure how the memory mapping works - will all of > the hash be replaced with per-child memory, will only parts. someone > w/more knowledge of the internals would be better off answering > that. but the point is that you end up losing a lot of shared > memory space, which (i think) defeats the point of having a large > hash of data in the first place. > personally, i do a stop/start whenever i need to handle a data change
