vm.swappiness to 0

abdelilah

Member

Reaction score: 6
Messages: 94

Hello everyone,

Is there an option under FreeBSD that enables us to use swap under this exact circumstances (retrieved from a general OS forum) :

Code:
* vm.swappiness = 0    The kernel will swap only to avoid an out of memory condition, when free memory will be below vm.min_free_kbytes limit.

Thanks.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 13,147
Messages: 39,756

As far as I know FreeBSD will not actively swap out idle pages unless it has to. So this option is really not necessary. Why do you think you need it?
 
OP
abdelilah

abdelilah

Member

Reaction score: 6
Messages: 94

As far as I know FreeBSD will not actively swap out idle pages unless it has to. So this option is really not necessary. Why do you think you need it?
Thanks for your answer, we have some MariaDB servers with 64 gb of RAM, yet they swap like crazy slowing down the whole server in the process, also we do have a lot of Inactive memory :

SWAP.PNG


I just don't understand this thing, 23 Gb of inactive memory yet it swaps to this extent.
 

Crivens

Moderator
Staff member
Moderator

Reaction score: 1,748
Messages: 2,589

Inactive is not free. That is cached data you see there.
 

ekingston

Active Member

Reaction score: 66
Messages: 230

So what can I do to avoid such swapping ?

If I were you, I would look more closely at the MariaDB and the queries that are being run on it. Certain queries can use significant amounts of RAM. This may lead to brief bursts of swap usage.

If you are using tmpfs (as opposed to a dedicated disk slice) for your /tmp filesystem, you might look at what /tmp is being used for as well. Tmpfs uses RAM for the /tmp filesystem. If something is using significant amounts of space in /tmp it may result in swap as well.

Have you figured out which applications are using the most RAM during your slowdown issues?
 
OP
abdelilah

abdelilah

Member

Reaction score: 6
Messages: 94

If I were you, I would look more closely at the MariaDB and the queries that are being run on it. Certain queries can use significant amounts of RAM. This may lead to brief bursts of swap usage.

If you are using tmpfs (as opposed to a dedicated disk slice) for your /tmp filesystem, you might look at what /tmp is being used for as well. Tmpfs uses RAM for the /tmp filesystem. If something is using significant amounts of space in /tmp it may result in swap as well.

Have you figured out which applications are using the most RAM during your slowdown issues?
Didn't recheck yet but mainly from MariaDB usage, we do have a big traffic on this server with a lot of slow queries some of them taking up to 37 seconds to complete, plus this is a slave so it has to work more.
I'll check tomorrow once at the office.
Thank.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 13,147
Messages: 39,756

we have some MariaDB servers with 64 gb of RAM, yet they swap like crazy slowing down the whole server in the process
Review MariaDB's tuning. It sounds like it's not tuned properly.

we do have a big traffic on this server with a lot of slow queries some of them taking up to 37 seconds to complete
Fix those queries. Add indexes etc.
 

Grell

Active Member

Reaction score: 63
Messages: 166

Okay, I am having some problems where my system is using too much swap when there is plenty of actual memory available, and it is starting to slow the system the system down significantly. Here is my fstab entry:


Code:
# Device                Mountpoint      FStype  Options         Dump    Pass#
#/dev/ada0p2.eli                none    swap    sw              0       0
md99    none    swap    sw,file=/usr/local/swap0,late   0       0

Here is a copy of the head of my topcommand:
Code:
last pid:  6395;  load averages:  1.03,  0.63,  0.41  up 1+07:47:08    20:23:35
95 processes:  1 running, 94 sleeping

Mem: 1429M Active, 156M Inact, 2231M Laundry, 11G Wired, 341M Free
ARC: 9439M Total, 2650M MFU, 6165M MRU, 1036K Anon, 107M Header, 517M Other
     8096M Compressed, 14G Uncompressed, 1.81:1 Ratio
Swap: 8192M Total, 523M Used, 7669M Free, 6% Inuse
Any help would be appreciated, thanks.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 13,147
Messages: 39,756

Swap usage in and of itself is not a problem. It's excessive swapping that's a problem. And I see no indication of that.
 

Grell

Active Member

Reaction score: 63
Messages: 166

Perhaps I am missing something but I don't know how to fix this excessive swapping problem.
 

bds

Member

Reaction score: 9
Messages: 53

You could tune down the size of the ARC if you're not happy with the kernel swapping out LRU pages in preference to cached filesystem data - try adding vfs.zfs.arc_max="8589934592" to /boot/loader.conf and rebooting. You may need to adjust this if your memory usage profile changes though, so not always ideal.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 13,147
Messages: 39,756

Perhaps I am missing something but I don't know how to fix this excessive swapping problem.
You don't have excessive swapping, you have some swap in use, that's all. Excessive swapping means the system is continuously swapping pages in and out, and that's not happening here.

What has happened is that some idle processes have been swapped out in order to provide more memory to the active processes. That's nothing to worry about.
 

Terry_Kennedy

Aspiring Daemon

Reaction score: 351
Messages: 984

Okay, I am having some problems where my system is using too much swap when there is plenty of actual memory available, and it is starting to slow the system the system down significantly. Here is my fstab entry:

Code:
# Device                Mountpoint      FStype  Options         Dump    Pass#
#/dev/ada0p2.eli                none    swap    sw              0       0
md99    none    swap    sw,file=/usr/local/swap0,late   0       0
One of us is confused (quite possibly me), but it looks like you are using a memory disk as a swap device with backing store on a filesystem. I would think (I haven't tested it) that this is suboptimal for 2 reasons:

1) This is using at least some memory (depending on how your md(4) is configured) as swap space to hold things that don't fit in memory. See fstab(5). You see where I'm going with this?

2) Using a filesystem-backed swap means that swap I/O goes through the filesystem, including the buffer cache, etc. This is slower (which will vary between "a lot" and "almost nothing", depending on your hardware) than having the swapper do its thing on a dedicated partition / slice.

I think that feature was originally added to help people who discovered a critical shortage of swap space and needed to do something ASAP, that didn't involve shutting the system down, re-partitioning, etc. I suspect (but have not looked at the sources) that some of this code is shared with the encrypted swap feature.

If my understanding of this is incorrect, someone please enlighten me...
 

Crivens

Moderator
Staff member
Moderator

Reaction score: 1,748
Messages: 2,589

Grell, the memory swapped out is what running processes have changed but not touched in some time. Thus the swapper drops the pages to disc so they are clean and can be reassigned at once. Or they can become disc cache. Your machine has about 2 GB in the laundry, which is that memory currently queued to be synced to swap. IF the machine was swapping, that number would be much closer to 0.

Terry_Kennedy, there is probably no extra code in the kernel for this, since the swapper uses a device interface. Swapping to a file is what needs extra code. But it makes sense. You could swap to a device (file) which is available by NFS. That can come in handy for compute clusters. Oh, and as soon as you use super pages (4 MB or so), adding enough swap space is a really good idea to get 4 KB pages moved out of the way to collapse some address range into one page.
 

Grell

Active Member

Reaction score: 63
Messages: 166

Well, if the swap is not the issue then something else is. After having the computer on for a few hours, or possibly a maximum of a day or so it will just lock up. I cannot move the mouse, I cannot switch back to console, and the light indicating hard disk activity on the computer is completely lit up and not blinking at all. I thought maybe it was too much swap being used and not enough memory but apparently not. Can anyone help me with this other problem? Thanks.
 

Terry_Kennedy

Aspiring Daemon

Reaction score: 351
Messages: 984

Well, if the swap is not the issue then something else is. After having the computer on for a few hours, or possibly a maximum of a day or so it will just lock up. I cannot move the mouse, I cannot switch back to console, and the light indicating hard disk activity on the computer is completely lit up and not blinking at all. I thought maybe it was too much swap being used and not enough memory but apparently not. Can anyone help me with this other problem? Thanks.
Since you say "switch back to console", I assume you're using X Windows or some other graphical user interface? Would it be possible to temporarily run the system without it? I don't know if it is "a server that happens to run X" or your desktop system. If you can run without X, use the first console (the one the boot messages come out on). Use Alt+F2 to make sure you can cycle through the various consoles, then get back to the one with the boot messages, log in, and run top -S and wait for the system to "lock up". Check to see if top(1) is still updating. If it is, that's one useful datapoint - take a picture of what it is showing and post it. If it isn't, that's another useful datapoint - likewise, take a picture and post it. In either case, try Alt+F2 and see if you can switch consoles.

If top(1) is still running, then the scheduler is OK and you likely have either a stuck process or a disk I/O problem. If it isn't running, hopefully it will show some "footprints" of what the system was doing just before it got stuck. If Alt+F2 works, then things are still running at interrupt level, but there's a problem at the scheduler level or deeper in the kernel. If Alt+F2 doesn't work, then things are dead even at interrupt level.

Note that Alt+F2 requires the standard configuration in /etc/gettytab and a kernel that supports them, as well as a console video mode that also supports them. The first 2 are the defaults; I don't know if the "new" console code supports it. That's why I said to try it first.
 

jpierri

Member

Reaction score: 22
Messages: 57

I assume you're using X Windows or some other graphical user interface? Would it be possible to temporarily run the system without it?
If being without X is not doable, for any reason, but you happen to have access to a second computer in the same network, wait until that freeze occurs again and then, from that other computer, try to reach that frozen machine using ping first and then ssh.

I used this method and discovered that a machine which froze only occasionally had a bad connector on its HD.
I couldn't connect to it through ssh but it kept answering to all my pings.
 

Crivens

Moderator
Staff member
Moderator

Reaction score: 1,748
Messages: 2,589

Or keep tty0 in front all the time if possible, otherwise use xconsole. The syslog output might tell you something.
 
Top