Rick Romero put forth on 1/4/2010 3:14 PM:
Are you sure the CPU is pegged from CPU and not disk I/O? I used to import 160GB of InnoDB data on a quad core (U320/RAID 10) and after the cache would fill up, only 1 core would show as pegged because the disk I/O wasn't fast enough. Seems like the index on 10k messages might be kinda big. Got more RAM lying around? Just a guess.
I guess I didn't look closely enough before stating that. I saw an imap process eating 99 %CPU and 'assumed' it was one thread, which is usually the case when I see one process listed as 99% in top. Upon further inspection, it would seem it's more than one thread, but the combined CPU usage is being shown in top as 99, which fooled me upon first glance.
top - 23:09:04 up 23 days, 22:49, 1 user, load average: 0.08, 0.02, 0.01 Tasks: 50 total, 2 running, 48 sleeping, 0 stopped, 0 zombie Cpu0 : 59.2%us, 4.9%sy, 0.0%ni, 34.9%id, 1.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 32.1%us, 3.0%sy, 0.0%ni, 64.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 387044k total, 331396k used, 55648k free, 22808k buffers Swap: 995988k total, 428k used, 995560k free, 239544k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9161 stan 20 0 26776 22m 22m R 99 6.1 0:10.77 imap
As we can see from the 1% I/O wait on CPU0 and 0% on CPU1, it's seems pretty clear that the CPUs are being occupied by the dovecot search code, not by disk I/O. Recall that I'm using mbox format, so we're dealing with a single file with 10,600 email messages within, not 10,600 individual files as is the case with maildir. This particular mbox "folder/file" with the 10K+ messages is 46MB in size. There are few users and the host is very lightly loaded at this point. My guess is that this file has been wholly (or very nearly so) cached in the Linux page and/or buffer caches. This would tend to explain the phenomenal body search speed on such low end hardware.
I like Horde (extendability) and Roundcube (speed), and would recommend using imapproxy for either webmail system. It helps speed things up.
I've looked a little at both now and am still reading. One thing I don't like is that I'm seeing requirements a SQL server. That adds unnecessary complexity to the system and I'd rather avoid it if possible. IIRC, one of the reasons I chose Squirrelmail a few years ago was that it's requirements were pretty simple, and that it didn't require a database backend for anything.
-- Stan