FreeBSD not using 100% of memory, killing processes

[0x46f]

Hello,

i am currently experiencing some problems with FreeBSD on my desktop. It has been my desktop operating system for quite some time but recently various kinds of issues started to appear. When I use htop to check my system resources, it shows a memory usage of ~12G out of 32G. I got approx 10 Firefox Windows open, so this number does not surprise me. However every now and then my entire system get really laggy. My screen starts to freeze, not just Firefox but awesomewm and others do not respond either. (Sometimes my mouse is affected but this is kinda random.) After ~30 seconds my system either recovers completely or FreeBSD kills Firefox. This does not affect VMs running in bhyve.
dmesg shows:
pid 51227 (firefox), jid 0, uid 1001, was killed: out of swap space
pid 87277 (firefox), jid 0, uid 1001, was killed: out of swap space

It does not make a difference to enable/disable swap.


Why does this keep happening and what can I do about it? My memory isnt even half full and I would be happy if the kernel could just assign the remaining GBs to Firefox instead of just killing it.
And why are bhyve VMs not affected by this?

 

[wolffnx]

Hello,

i am currently experiencing some problems with FreeBSD on my desktop. It has been my desktop operating system for quite some time but recently various kinds of issues started to appear. When I use htop to check my system resources, it shows a memory usage of ~12G out of 32G. I got approx 10 Firefox Windows open, so this number does not surprise me. However every now and then my entire system get really laggy. My screen starts to freeze, not just Firefox but awesomewm and others do not respond either. (Sometimes my mouse is affected but this is kinda random.) After ~30 seconds my system either recovers completely or FreeBSD kills Firefox. This does not affect VMs running in bhyve.
dmesg shows:
pid 51227 (firefox), jid 0, uid 1001, was killed: out of swap space
pid 87277 (firefox), jid 0, uid 1001, was killed: out of swap space

It does not make a difference to enable/disable swap.


Why does this keep happening and what can I do about it? My memory isnt even half full and I would be happy if the kernel could just assign the remaining GBs to Firefox instead of just killing it.
And why are bhyve VMs not affected by this?

Hi, i dont know much about bhyve,
but you tried to establish the
value of ZFS ARC?

zfs.arc_max=4G

should be enough for your setup

 

[0x46f]

Hi, i dont know much about bhyve,
but you tried to establish the
value of ZFS ARC?

zfs.arc_max=4G

should be enough for your setup

Thank you for your reply.
My arc_max value is currently set to

vfs.zfs.arc_max: 32311222272

It seems a bit high. Should I limit it to 4G? I don't want to set it to a value which is too small bc there is a 12T raidz1 running on this machine.

 

[PMc]

I don't want to set it to a value which is too small bc there is a 12T raidz1 running on this machine.

Size of the pools is irrelevant (except when using dedup). What's relevant is the size of your active set: that is the amount of data that is repeatedly used and therefore can benefit from a cache. If you have a cache smaller than the active set, then things will be continously replaced, and performance is bad. If the cache is larger than the active set, memory is wasted.
So this is highly dependent on your usage pattern.

I suggest for a beginning You figure how much mem your firefox should use, how much mem your bhyve or whatever should use, etc. etc. Then subtract that from the 32g, and make the arc 3/4 of the remainder.
Then, install the sysutils/zfs-stats and occasionally hava a look at the statistics. Adapt if they are bad.

 

[wolffnx]

Thank you for your reply.
My arc_max value is currently set to

vfs.zfs.arc_max: 32311222272

It seems a bit high. Should I limit it to 4G? I don't want to set it to a value which is too small bc there is a 12T raidz1 running on this machine.

I' think that you are running a single hard disk in a simple desktop...
the answer of PMc is more usefull n your case