mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: "Ananiev, Leonid I" <leonid.i.ananiev@intel.com>
Cc: Linux Kernel Mailing List <Linux-Kernel@vger.kernel.org>
Subject: Re: Postal 56% waits for flock_lock_file_wait
Date: Sat, 30 Sep 2006 11:05:52 -0400	[thread overview]
Message-ID: <1159628752.5425.31.camel@lade.trondhjem.org> (raw)
In-Reply-To: <B41635854730A14CA71C92B36EC22AAC3AD921@mssmsx411>

On Sat, 2006-09-30 at 09:25 +0400, Ananiev, Leonid I wrote:
> A benchmark
>              'postal -p 16 localhost list_of_1000_users'
> 56% of run time waits for flock_lock_file_wait;
> Vmstat reports that 66% cpu is idle and  vmstat bi+bo=3600 (far from
> max).
> Postfix server with FD_SETSIZE=2048 was used.
> Similar results got for sendmail. 
> Wchan is counted by
>             while :; do
>                         ps -o user,wchan=WIDE-WCHAN-COLUMN,comm;
> sleep 1;
>            done | awk '/ postfix /{a[$2]++}END{for (i in a) print
> a[i]"\t"i}'
> If ext2 fs is used the Postal throughput is twice more and bi+bo by 50%
> less while  flock_lock_file_wait 60% still.

On which filesystem were the above results obtained if it was not ext2?

> Is flock_lock_file_wait considered as a performance limiting waiting for
> similar applications in smp?

All the above results are telling you is that your test involves several
processes contending for the same lock, and so all of them barring the
one process that actually holds the lock are idle.

As for the throughput issue, that really depends on the filesystem you
are measuring. For remote filesystems like NFS, locks can _really_ slow
down performance because they are often required to flush all dirty data
to disk prior to releasing the lock (so that it becomes visible to
processes on other clients that might subsequently obtain the lock).

Cheers,
  Trond


  reply	other threads:[~2006-09-30 15:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-30  5:25 Ananiev, Leonid I
2006-09-30 15:05 ` Trond Myklebust [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-10-01 16:53 Ananiev, Leonid I
2006-10-01 17:18 ` Trond Myklebust
2006-10-02 16:57   ` Tim Chen
2006-10-02 17:11     ` Trond Myklebust
2006-10-02 17:51       ` Alan Cox
2006-10-02 17:40         ` Dave Jones
2006-10-02 22:00           ` Alan Cox
2006-10-02 21:40             ` Dave Jones
2006-09-30 17:26 Ananiev, Leonid I
2006-10-01  4:05 ` Trond Myklebust
2006-09-29 15:36 Ananiev, Leonid I

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1159628752.5425.31.camel@lade.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=Linux-Kernel@vger.kernel.org \
    --cc=leonid.i.ananiev@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®