On 2016-05-27 05:43:00 +0530, Amit Kapila wrote:
> On Thu, May 26, 2016 at 11:03 AM, å¾·å¥ <digoal@126.com> wrote:
>
> > This is worker process's stack, when i test the hign parallel degree.
> >
> > [<ffffffffa00b8ff0>] ext4_llseek+0x60/0x110 [ext4]
> > [<ffffffff81186eda>] vfs_llseek+0x3a/0x40
> > [<ffffffff81188b96>] sys_lseek+0x66/0x80
> > [<ffffffff8100c072>] system_call_fastpath+0x16/0x1b
> > [<ffffffffffffffff>] 0xffffffffffffffff
> >
> >
>
> Above call stack indicates that the file seek cost has increased on
> employing high number of workers. I think the reason is that employing
> more number of workers to perform parallel scan of same file doesn't work
> very well read-ahead mechanism of OS.
I don't think that's the correct conclusion. That report and profiles
rather seems to suggest we're hitting lock contention, rather than IO
related cost.
The kernel used here is quite old (heavily patched 2.6.32 IIRC). The
kernel guys have since made lseek not take locks in the common case. I
suspect that upgrading to a newer kernel will change the profile
significantly.
Greetings,
Andres Freund