[Dovecot] Re: extremely slow delete/move operations?
On Jan 30, 2006, at 11:12 AM, Gregory K. Ruiz-Ade wrote:
Message: 10 The thing is, these mail servers _are_ the local storage for the
mail spools and home directories. There is no network involved when dovecot is accessing the INBOX or saved mail folders. Yes, they're "NFS"
mounted, but this is RHEL4 (linux 2.6.x), and when an NFS share is mounted from
the local host, it's done as a bind mount, which means local disk access.
I don't understand this at all. Mounting anything via NFS should
only be done from a remote server, where when you type "mount" at a
commandline you see something like:
10.10.10.2:/data on /var/mail type nfs (rw,nfsvers=3,addr=10.10.10.2)
If your /etc/fstab or your automounts on your RHEL4 box are mouting
LOCAL disks as type NFS, you have set up something very very wrong.
Local disks should be mounted at boot like so:
/dev/sda3 on / type ext3 (rw)
Let's be certain we're clear about this. The disks where dovecot
reads and writes your mboxes are local to the RHEL4 machine? If so,
you're not using NFS at all.
Roger Weeks
First, I regret saying anything about NFS being involved, since it seems to have clouded the issue. None of the current users on the system are mounted with NFS home directories, so, the performance issues seem to be wholly contained in the local system. That said, the local filesystems are exported by NFS for other systems (clients NOT running dovecot) to mount.
Dovecot is running on the server where the disks and filesystems are.
To remove a number of variables, I copied my own mail files to my personal workstation (no NFS, only one user, dovecot 0.99.11) and had the exact same performance for moving messages from one mailbox to another as I did on the server. I have not yet had a chance to test 1.0 beta2.
Roger Weeks wrote:
I don't understand this at all. Mounting anything via NFS should only be done from a remote server, where when you type "mount" at a
commandline you see something like:
The following is what I've seen from my own experiences as a Unix admin, both in Solaris and Linux environments where a large number of systems need to have similar or identical environments. My first experiences with this setup were with Solaris environments; in fact, the default Solaris install puts homes in /export/home and automounts them into /home, even if you don't turn on NFS services.
This is a rather long-winded response, and isn't strictly related to dovecot, but I'm attempting to explain my rationale for excluding NFS from the equation in these dovecot performance issues I'm having.
Forgive me if I'm explaining things people here already know. :)
In large NFS environments, where people can either log on to the server or any number of workstations, common things like home directories are mounted, on the server, under /export:
/dev/mapper/vg00-homes1 on /export/homes1 type ext3 (rw,nosuid,nodev,usrquota) /dev/mapper/vg00-mail on /export/mail type ext3 (rw,nosuid,nodev,usrquota)
everything is set up in NIS to provide consitency across systems:
gruizade@csefast(pts/19):~ 23 > ypmatch gruizade passwd gruizade:x:XXX:YYY:Gregory Ruiz-Ade:/home/gruizade:/bin/tcsh gruizade@csefast(pts/19):~ 24 > ypmatch -k gruizade auto.home gruizade csefast:/export/homes1/&
and automounter (autofs) is used to put things where they're supposed to be when a user (or a user's process) needs access:
gruizade@csefast(pts/19):~ 26 > mount | grep auto automount(pid2449) on /home type autofs (rw,fd=5,pgrp=2449,minproto=2,maxproto=4)
the automounter on Linux is apparently smart enough to realize when you're telling it to mount a local filesystem over NFS, and simply bypasses NFS by using a bind mount. So, when I log in to the NFS server, instead of doign an NFS mount, it does a bind mount:
gruizade@csefast(pts/19):~ 27 > mount | grep gruizade /export/homes1/gruizade on /home/gruizade type none (rw,bind)
So, yes, while the filesystem is exported via NFS, and other systems are accessing the filesystems via NFS, the only thing touching the mail files should be sendmail, procmail, or dovecot running on the server itself.
Gregory
-- Gregory K. Ruiz-Ade Sr. Systems Administrator Computer Science and Engineering University of California, San Diego Office: EBU3b 1216 Phone: (858) 822-2625 E-mail: gkra@ucsd.edu
participants (2)
-
Gregory K. Ruiz-Ade
-
Roger Weeks