Yu (Irvin) Fan: > Hi Wietse, > > Thanks for the quick answer. Can I say that the postfix performance is > affected by small file read/write speed of the disk?
Many email messages small. Therefore performance is dominated by rotational and seek latencies (absent a large persistent buffer between the kernel and the disk drive). > Anyway, I have another related question. We have an after-queue content > filter written in Perl. The email is fed to the filter using pipe as > suggested in the following example in the documentation. > > smtp inet ...other stuff here, do not change... smtpd > -o content_filter > <http://www.postfix.org/postconf.5.html#content_filter>=filter:dummy > > filter unix - n n - 10 pipe > flags=Rq user=filter argv=/path/to/script -f ${sender} -- ${recipient} > > > We notice that if the disk activities (by other processes in the box) went > up there would be less # of filter scripts running. But at the same time the > smtpd queuing doesn't seem to be affected that much. The smtpd processes load the disk. Therefore, less I/O can be done by the queue manager. Postfix has a limited safety mechanism that works only when the mail load comes from a small number of clients. To reduce disk load, receive less mail. That is, provide less bandwidth to receive mail, or fewer smtpd processes. > So we end up with > backlog building in incoming queue. I want to understand does this happen > naturally because spawning filter would require more system resource > (loading, compiling, etc. even our filter is lightweight) so if the disk is > slow it would be affected the most? You would not have asked this question if you had looked at the CPU load of your machine. > or is there some kind of throttling > control built in postfix (can't find anything about it in documentation > though) by which the postfix qmgr would spawn less filters on purpose in > order to make sure smtpd have enough resource to handle incoming emails > cause we don't want to reject emails? If postfix does have throttling > control what are the deciding factors it's looking at? The queue manager works as fast as it can. > btw, If I turn the filter into a daemon and feed the content through smtp > would that help a lot? It would use less CPU than creating a new process for every message, but it matters only when the disk is fast enough. Which it is not in the present case. Wietse
