Actually, I don't have a problem, I was just pondering the idea. I know
that Solaris versions prior to 2.6 had a vm model where once memory was
used up it wasn't too selective about what got paged out. In 2.6 and 7
they added a parameter you could set in /etc/system that would try to
keep application memory from getting paged out. Of course Solaris 8 has
an all new vm model that also prefers to keep application memory. I
believe that Linux has always worked this way. I suppose mlockall might
be useful if for some reason you happen to have other applications
running on the same box as squid and you don't mind having the other
apps get paged out, but want to keep squid in memory.
Joe Cooper wrote:
>
> You should simply avoid creating a situation where Squid might be
> swapped out.
>
> In other words, Squid getting swapped out is very bad...but part of the
> reason it is so bad is that if there is that much memory pressure on
> your system disk I/O will suffer, crippling Squids performance.
> Actually having the Squid process go into swap memory is even worse--but
> it's just a symptom of other problems (too big a Squid process for the
> amount of memory you have--shrink your Squid or grow your memory).
>
> So it is not /just/ the fact of Squid being swapped out that is so bad
> for performance though it certainly does get ugly if any swapping occurs
> of the Squid process--but /something/ will have to go into swap if you
> have that much memory usage pressure on the system, and so performance
> will suffer generally, regardless of what it is.
>
> That said, it probably wouldn't hurt--but please don't consider it a
> solution to an existing problem.
>
> Just my .02.
>
> Jim Richey wrote:
>
> > Is their any advantage to using mlockall (Linux) or plock (bsd?) to
> > prevent squid, or parts of it, from being swapped out?
>
> --
> Joe Cooper <joe@swelltech.com>
> http://www.swelltech.com
> Web Caching Appliances and Support
-- Jim Richey jrichey@highmark.com Highmark, Inc. http://www.highmark.comReceived on Thu Dec 06 2001 - 10:36:25 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:05:15 MST