New answers tagged

1

While that factor of 8 is not that great, I'm not so surprised: your benchmark first allocates memory, and then accesses it. There's no file-system logic going on here, sure, you will need page faults to actually map that memory, but sysbench uses hugetlb to minimize the overhead of that and so on: Writing to ramfs is really not a benchmark of your memory, ...


0

Wow!! That is a scary load. Out of curiousity, what hardware are you running on? In any case, it seems like you are are currently experiencing some issues. If this helps, you do actually have memory available for use but your cache is holding it. As you are running VZ containers, you should be relatively safe clearing the cache to release the memory to the ...


0

There are lots of words and numbers here. The only significant thing is this: > Swap: 31G 25G 6.1G This box is heavily into its swap - it does not have enough memory to support the tasks as they are currently configured. If you can't reduce the memory consumption then buy more RAM (or better yet move some of the load onto a ...


0

The version of the kernel you're running has changed - it's solely responsible for swapping. RHEL 7 uses kernel 3.10, RHEL 8 uses 4.18 - there's a ton of changes between them. If you never run out of RAM, you could as well disable SWAP'ing altogether. I've been doing it for over a decade now because SWAP'ping leads to a very unpredictable behavior and ...


Top 50 recent answers are included