Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
But let me be curious and ask you why would you do such thing?
Usually, when your os is swapping, this is bad.
So I don't even imagin with 30G of SWAP. Unless you really want to kill the performances of your machine.
But if you got the choice, add some RAM... Really.
I say => DO NOT SWAP (At least I wouldn't do.)
Limit your squid cache size, but do not swap.
I can't tell whether that advise is based on what you might know about squid (which I will assume is more than I know) or based on what you think you know about swapping (which I'm quite confident is more than you actually know).
Servers using swap space is not generally a bad thing. Even major use of swap space in not necessarily a performance problem. Limiting swap space or swappiness to less than your system should have, can significantly reduce performance.
I have quite a lot of swap space configured, and in some cases used, on the Linux systems for which I make those decisions. My decisions in those cases are quite well supported by evidence, unlike the common bias against swapping seen in this forum. I would not extrapolate from my experience to a server on which the major memory usage is squid, because I don't know enough. So I won't claim to know you are wrong. I just think the OP should be warned that you sound like you are repeating commonly held incorrect views.
Thank you for your well formulated contribution to this answer.
Few years back I did experience this issue as well, and I notice that squid swapping was making the IO going up as hell.
After tuning up squid on "what should be cached" and what should not, I reduce the cache size.
Doing so, I've seen a significant performance improvement.
Tuning squid cache is not easy but you'll get much better performances at the end.
But you are right with one point here, I do not have enough information to say that hack back shouldn't use SWAP. Maybe he got some SSD, in that case it might not heart too much (although I never tried this configuration).
But at the end of the day (in my opinion "and by experience", and it seems that by the squid team as well) SWAP usage should be use with caution as performances WILL suffer. (see my quote below)
Quote:
If you have a low memory server, and a large disk, then you will not necessarily be able to use all the disk space, since as the cache fills the memory available will be insufficient, forcing Squid to swap out memory and affecting performance. A very large cache_dir total and insufficient physical RAM + Swap could cause Squid to stop functioning completely. The solution for larger caches is to get more physical RAM; allocating more to Squid via cache_mem will not help.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.