Scott Carey wrote:
222 / 8 cores = ridiculous 27 processes per core, while the OP has 239
That's not rediculous at all. Modern OS's handle thousands of idle
processes just fine.
I meant that 27 was a ridiculously small number.
Or you can control the behavior with the following kenrnel params:
vm.swappiness
vm.dirty_ratio
vm.dirty_background ratio
Thanks for pointing that out!
Actually, no. When a process wakes up only the pages that are needed are
accessed. For most idle processes that wake up from time to time, a small
bit of work is done, then they go back to sleep. This initial allocation
does NOT come from the page cache, but from the "buffers" line in top. The
os tries to keep some ammount of free buffers not allocated to processes or
pages available, so that allocation demands can be met without having to
synchronously decide which buffers from page cache to eject.
Wait a second, I'm trying to understand that :-)
Did you mean that FS cache pages are first allocated from the buffer
pages or that process memory being paged out to swap is first written to
buffers? Could you clarify please?
If queries are intermittently causing problems, it might be due to
checkpoints. Make sure that the kernel parameters for
dirty_background_ratio is 5 or less, and dirty_ratio is 10 or less.
Scott, isn't dirty_ratio supposed to be less than
dirty_background_ratio? I've heard that system would automatically set
dirty_ratio = dirty_background_ratio / 2 if that's not the case. Also,
how dirty_ratio could be less than 5 if 5 is the minimal value?
Regards,
Mike
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
