Quoting Javier de Miguel RodrÃguez javierdemiguel@us.es:
- I understand that indexes should go to the fastest storage Iown. Somebody talked about storing them in a ramdisk and then backup
them to disk on shutdown. I have several questions about that:- In my setup I have 25.000+ users, almost 7.000.000messages in my maildir. How much memory should I
need in a ramdisk to hold that?
Are you using dovecot with them now? If so, then you can figure out who much they are currently using. Otherwise, well, who knows? It will depend on the clients used (for dovecot.index.cache), as well as how often they are accessed (for transaction log), and so on.
Maybe Timo or someone more into the inner workings can give more details.
- What happens if something fails? I think that ifI lose the indexes (ej: kernel crash) the next time I
boot the system the ramdisk will be empty, so the indexes should be
recreated. Am I right?
Yes. If the ramdisk is full, it will switch to INDEX=MEMORY automatically for all new sessions until space frees up. And if you crash without saving the indexes, it will rebuild them when the users reconnect.
- If I buy a SSD system and export that little andfast storage via iSCSI, does zlib compression
applies to indexes?
I don't think so, but maybe Timo can say for sure.
- Any additional filesystem info? I am using ext3 on RHEL 5.5,in RHEL 5.6 ext4 will be supported. Any performance hint/tuning (I
already use noatime, 4k blocksize)?
Only the ext3 commit interval (raising it might lower your I/O on the SAN) I mentioned earlier... But of course, it raises your chances of losing data in a crash (i.e. you could lose more data, since it flushes less often). But it is a good trade off sometimes (I always raise it on my laptops in order to cut down on battery usage).
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!