perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Whillers <mod_p...@whohasit.com>
Subject Re: Semaphores
Date Sun, 19 Mar 2006 01:22:10 GMT
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

Mime
View raw message