Mark Goodge: > I see from the documentation that the current default of > hash_queue_names is only to hash the defer and deferred directories, in > contrast to versions prior to 2.2 where pretty much everything was hash > queued. The documentation has this to say about the reason for the change: > > Claims about improvements in file system technology suggest that > hashing of the incoming and active queues is no longer needed. Fewer > hashed directories speed up the time needed to restart Postfix. > > My question is: if the time taken to restart Postfix is not an issue, > but throughput performance while Postfix is running is a primary > concern, is it still worth hashing the incoming and active queues?
The purpose of "queue hashing" is to limit the number of files per directory. It's not needed normally if the file system can handle order 10K files per directory. The size of the active queue has an upper limit, so you use the lowest amount of "queue hashing" that works. In the case that the incoming queue gets really congested with a million messages, hashing the incoming queue won't help (and changing it will take time). The problem, and its solution, is downstream. If you change the incoming directory into multiple levels of subdirectories then Postfix will be slower under normal conditions. How much depends on file system caching. The defer and deferred directories may contain a large number of files when a downstream site is unreachable. These are hashed to avoid file system meltdown. Deferred mail delivieries are not time critical, so it is not a problem if it takes a little longer on systems with near-empty queues. > If > so, does anyone have any comments to make on the performance trade-offs > involved in either hashing or not hashing the queues? > > Mark > -- > http://mark.goodge.co.uk - my pointless blog > http://www.good-stuff.co.uk - my less pointless stuff > >
