On 3 Dec 2023 14:33 +0800, from jeremy.ard...@gmail.com (jeremy ardley): >> You have swap and it is enabled? > > No Swap. I prefer not on SSD
Why not? You are definitely putting the VM allocator in a much more difficult spot than necessary by not providing any swap space. If I read what you provided in a different message in this thread correctly, over half of your RAM at that particular time was being used for anonymous pages; that is, data which has no backing on other storage, and therefore cannot be evicted from virtual memory. Combine this with the fact that you have no swap, and all that data _must_ be kept in RAM because that's all there is. Combine _that_ with running several rather memory-hungry processes (several web browsers plus LibreOffice) _and_ the Linux default of allowing memory overcommitting, and I'm not all that surprised that you're apparently hitting the OOM killer from time to time. The reason for the system slowing down seems to me to likely be that once the system comes under memory pressure (quite possibly due to an increase in anonymous pages), it must evict something, and only non-anonymous (that is, backed) pages can be evicted safely. So most likely the allocator starts evicting program code, because that can be read back from storage later, or other forms of cache, in order to keep room for the anonymous pages which it cannot evict. The next time that code is needed, it must go all the way to the (horribly slow by comparison) storage, instead of originally just writing out to swap some anonymous pages which haven't been used in comparatively forever, like a tmpfs that someone mentioned, or data for inactive web browser tabs or documents you aren't doing anything active with. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
