邮件应用服务可以允许延迟，没有像web,数据库那样实时性要求强，响应快。对于这种应用在设计上就比较特别，我给出postfix的进程信息：
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - n - - smtpd
#628 inet n - n - - qmqpd
pickup fifo n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
#qmgr fifo n - n 300 1 oqmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp
可以看出pickup进程会周期的被唤醒来检查新收到的邮件，然后交给cleanup做处理，这些信息管理员可以手动调节，qmgr队列管理器也类似
搭建过邮件服务器的管理员应该知道，一般是自己在服务器创建虚拟域，像[email protected],然后对应到本地一个普通用户的一个家目录的，以XXXXXX为名的目录里不同的文件便是XXXXXX用户的信件，很多的小文件（一般使用maildir形式存储信件，mailbox存在文件锁的问题）这里可以明文的哦。这里要注意的是linux下邮件服务器若是采用ext3,ext4文件系统，就可能出现inode耗尽的情况，具体可以参考我之前写过的“文件系统格式化的考虑”，当然若使用gfs这样的集群文件系统，就不必考虑这样的问题了
磁盘:
邮件系统的一个最大的问题是：不是很多大文件的读写，而是很多小文件的读写,而且这些读写请求是来自同一时间的多个进程或者线程：假设一个信件由服务器postfix收到，先是pickup发现并读出，再交给cleanup,可能调用rewrite对地址进行改写，最后在进入incoming队列，由smtp处理
对很多小文件的应用服务，推荐使用deadline算法进行I/O调度
内存:
对于postfix而言，它的每一个进程不会消耗太多的内存，我们期望的是大量的内存被自动使用到磁盘缓存中来提高磁盘I/O速率，当然这个我们不需要操作，linux帮我们完成了！Linux虚拟内存管理默认将所有空闲内存空间都作为硬盘缓存。因此在拥有数GB内存的生产性Linux系统中，经常可以看到可用的内存只有20MB。
处理器:
对于邮件系统，不管是smtp,imap对CPU的占用都不是很大
网络:
尽管对于邮件系统而言，会频繁的使用网络子系统，但是邮件系统的瓶颈还是磁盘的吞吐而不是网络的吞吐，对应这种应用不要求交互，延迟是允许！当然对于一些常用的网络内核参数还是有必要调节的！
这些只是在系统级别简单分析一下，对于应用服务:邮件服务器，Web服务器，数据库服务器这些，对服务本身分析也很重要，对于服务工作方式，资源占用，还用安全防范等多个方面考虑调优，效果可能更好！
西邮-小宋