Re: random slow query

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