Re: Swap DIsks- but not what you think!

From: squid <squid@dont-contact.us>
Date: Fri, 22 Oct 1999 16:50:31 +0200 (MET DST)

> Is there a way that Squid (& other Linux/UNIX) programs can be convinced that
> they just cannot have more RAM than is available without spitting the dummy such
> that you can use swapoff without fear? If not, would it be possible to build
> something of the kind in future versions of Squid? I'm sure a lot of people
> would love to know the answer to this...
>
>
> Cheers,
> Marc Lucke
>
>

> ...
> On a Mac, I can switch what Apple call "Virtual Memory" (& what every one else
> calls swap disks) off altogether & the Mac goes a lot quicker. Yes, it runs
> out of memory, but you allocate memory manually so if you're running servers
> you don't have a problem!

I'm not sure wether I missed your point, but why don't you limit the
memory use in the config file? Usually squid works fastest if you give
it only real memory - just as you experienced on the Mac. Where is the
problem? Are there any other servers consuming your real memory?

> I know you can use the command "swapoff -a" with Linux, but I have a vague
> memory of there being a problem with that.
> ...

I've run Linux without swap many times, just to see how it changes it's
behaviour, and I had no problems. These experimnets told me to better give
it at least some MBs of swap to make better use of real memory. There is
always some amount of code which won't be used after startup and gets
swapped out soon, freeing some RAM.
On the other side I admit that I never ran a server (a real productive
server) without swap at all for more than a few minutes, just because
I wanted to use all the RAM for my server duties.

--- just my personal limited experience ---
--------------------------------------------------------------------
Andreas Kaeser Schumann Unternehmensberatung AG
Unix- Intranet- und Hermann-Heinrich-Gossen-Str. 3
Internet-Security Berater 50858 Koeln
Andreas.Kaeser@schumann-ag.de Tel: 02234/108-1855 Fax: -1818
--------------------------------------------------------------------
Received on Fri Oct 22 1999 - 09:02:57 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:49:01 MST