On Tue, Jan 23, 2007 at 02:03:42PM +0100, Jonas Thambert wrote:
> The problem is the t/s on the sd1 device where I have the
> email-storage. Have less than 10 accounts and clients on a
> Xeon 3.0 Ghz server with 1 Gb RAM. I have tried to see why I have so
> many t/s on the disk but I can not figure it out. The disks
> are SCSI-disks 15 000 rpm.
OK, so apart from possibly the disk subsystem topping out at 140tps (see
previous response), there's the question of whether it's reasonable to
expect this many tps from just 10 clients. This will be a function of:
(1) the client software (the profile of commands it issues)
(2) the server software (e.g. how well it caches and indexes internally)
(3) the O/S's filesystem (e.g. how well it copes with large numbers of files
in one directory)
These problems can be exacerbated if you have users with thousands of
messages in their mailboxes.
So you can investigate this, by for example capturing the IMAP sessions
between the clients and the server, and discovering what sequences of
commands are being issued. If the client is being stupid, try another client
(e.g. a stupid client, when it opens a mailbox containing 1,000 messages it
has already seen, still issues 1,000 more IMAP commands to open them)
You can capture using tcpdump on port 143, or in the case of courier set
IMAPDEBUGFILE=log.txt in the imapd config file, and all client requests and
responses will be stored in file "log.txt" inside the user's Maildir.
If you know the profile of commands issued by a client, you can try issuing
them manually to a server to see how it handles them in terms of file I/O
operations, e.g. with strace. If it is poor, then try a different server.
Regards,
Brian.
