> We had been using Option 1 for a long time & we had
> absolutely no problems
But doesn't it totally wreck your shared memory? For me that would make
it unusable. I usually get a pretty large percentage of memory to be
shared and count on that for getting maximum capacity from each box.
- Per
We had been using Option 1 for a long time & we had
absolutely no problems (with
mod_perl-1.19/Apache-1.3.14/Perl-5.005).
However on upgrading to mod_perl-1.26, we were getting
hell lot of errors. I have tracked this to a bug in
perl_util.c & on fixing this PerlFreshRestart works
w/o any problems.
> upgrades for applications that maintain state - since a user might
> have a session created using a new-code box, then hit an old-code box
> on the next page view. it takes us many minutes to work through
> restarting the entire array.
>
> were you ever concerned about something like that
Geoffrey Young wrote:
> we do that frequently here - 7 servers behind a BigIP. I've always
> wondered, though, whether this approach is foolproof for major
> upgrades for applications that maintain state - since a user might
> have a session created using a new-code box, then hit an old-code box
>
> The best way I've found to deal with this problem is to have multiple
> servers behind a load-balancer and do a "rolling" restart. If you have
> servers A and B, you take A out of the load balancer temporarilly,
> upgrade it, add it back in, take B out, upgrade it, add it back in.
> Using t
Gordon Henriksen wrote:
> I see three options open to me:
>
> 1. static mod_perl w/ PerlFreshRestart
> Reloads %INC.
> downside: Heresay claims historical instablity.
>
> 2. dynamic mod_perl
> Tears down & cleans up Perl interpreter on graceful restart.
> downside: Here
Gordon Henriksen wrote:
>
> I'm looking at how to best avoid downtime during a code upgrade, as we often
> do spot releases of critical code fixes and we're getting to the usage level
> that I don't want to interrupt service to deploy that code. At the same
> time, I want to avoid running 200 sta
I'm looking at how to best avoid downtime during a code upgrade, as we often
do spot releases of critical code fixes and we're getting to the usage level
that I don't want to interrupt service to deploy that code. At the same
time, I want to avoid running 200 stat()'s per request for all of the lo
