浅谈linux性能优化之二十一:分析邮件系统

发布时间：2014-09-05 13:45:17作者：知识屋

浅谈linux性能调优之二十:模块管理与内核编译

http://www.zhishiwu.com/os/201308/235094.html

邮件应用服务可以允许延迟，没有像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队列管理器也类似

搭建过邮件服务器的管理员应该知道，一般是自己在服务器创建虚拟域，像XXXXXX@example.com,然后对应到本地一个普通用户的一个家目录的，以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服务器，数据库服务器这些，对服务本身分析也很重要，对于服务工作方式，资源占用，还用安全防范等多个方面考虑调优，效果可能更好！

（免责声明：文章内容如涉及作品内容、版权和其它问题，请及时与我们联系，我们将在第一时间删除内容，文章内容仅供参考）