Hi Timo et al,

On 29 Mar 2007, at 17:52, Mike Brudenell wrote:

But then the ODDNESS starts. I'm still a little hazy how to interpret the output of imaptest, but every now and then one or two processes stall for several seconds. When this happens activity seems to grow quieter in the imaptest output: number of operations per second decreases and the N/N count drops. Eventually it clears somehow and things spring back into life...

Further to my message to the list yesterday I'm still baffled and concerned as to why imaptest10 shows stalls in SELECT occasionally and, when it does so, it looks like all other clients are blocked or something.

When the Maildir mailstore is mounted over NFS from our NetApp filer to the Solaris 10 box Dovecot and imaptest10 are running on the problem shows.

Switch to using local disk for the mailstore and run imaptest10 with the same number of clients and there are no stalls. But increase the number of simulated clients (from 50 to 100) and they come back, but not too badly at that setting.

So it looks like something to do with when the system gets really loaded...

I think the things I'd like to know are:

1.  Are other people on the List running Dovecot with Maildir mailstore
    NFS-mounted from NetApp filers and having it work OK?
    (If you are using Solaris 10, what mount options are you using?)

2. How much real-life user load does running imaptest10 with 50 simulated clients equate to? I assume each simulated user is hammering away at
    its IMAP connection, so should equate to several (how many?) normal
    users in real-life operation?

3.  I'm concerned by the N/M number at the end of the imaptest10 output
    lines plummeting whenever one process goes into this stalled state:
it almost suggests as if the only thing the other processes can do is
    logout?  Are other sessions really being blocked, or is it just
    imaptest10 behaving like this?

As far as I can tell I *think* it's only imaptest10 getting blocked:
    when it is happening for an extended period I can quickly manually
Telnet in to port 143, login as one of the test usernames and SELECT
    INBOX just fine.  So it's probably NOT all of the Dovecot processes
    getting blocked, but imaptest10 that drives them.  Does that sound
    plausible?

Help! (Concerned, and hoping we're not going down the wrong road... can anyone reassure me about the Solaris 10/NFS/NetApp filer setup?)

With thanks,
Mike B-)

--
The Computing Service, University of York, Heslington, York Yo10 5DD, UK
Tel:+44-1904-433811  FAX:+44-1904-433740

* Unsolicited commercial e-mail is NOT welcome at this e-mail address. *


EXAMPLE OUTPUT FROM IMAPTEST10
==============================

  24   13   20   28   25   36   10   14   23   24   48  50/ 50
  32   15   15   28   28   46   18   16   35   32   64  50/ 50
  21   13   14   27   30   32    9    8   21   22   42  50/ 50
- 45. stalled for 16 secs in SELECT
   0    5    2    6    7   27   10   18   26   28   58  21/ 21  <===
  46   22   25   40   38   38    8   12   21   17   34  50/ 50
  28   11   13   24   22   32    9    6   24   28   56  50/ 50
  20   10   15   24   27   38   13   10   24   20   40  50/ 50
  29    9   11   25   21   33   13   14   28   29   58  50/ 50
  28   17   12   32   37   43   17   15   27   28   56  50/ 50

and

  34   15   13   28   27   47   16   20   34   34   68  50/ 50
  18   13   16   27   25   23    9   13   17   18   36  50/ 50
  21    9    8   22   25   36   17   13   23   22   42  50/ 50
- 30. stalled for 16 secs in SELECT
- 37. stalled for 16 secs in SELECT
Logi List Stat Sele Fetc Fet2 Stor Dele Expu Appe Logo
100%  50%  50% 100% 100% 100%  50% 100% 100% 100% 100%
                          30%                  5%
   0    5    2    7    7   28   11   12   28   29   60  20/ 20  <===
  41   16   18   31   26   24    6    4   12   11   22  50/ 50
  29    9   15   28   29   42   10   13   27   29   58  50/ 50


Reply via email to