On Sat, Oct 04, 2003 at 11:12:27AM +0100, Philip Hazel wrote: > > To work around file locking contention against the filesystem-based db.
> > This is a big problem on high-throughput relays.
>
> (1) If messages are not being delayed, there are only read accesses to
> the hints databases. These do not hold up other processes, because they
> use shared locks. One way to make use of this fact is to use fallback
> hosts, so that delayed messages are not kept on the high-throughput
> relays, but on some backup relays. If you do that, there will never be
> any writes to the hints databases on the high-throughput relays. And
> what's more, searching an empty hints file will be pretty quick. :-)
Good point and very correct :)
> (2) As has been said already, you should optimize disk hardware
> performance (e.g. by putting hints on RAM disk, etc.)
This helps to a point, yes :)
> (3) I can't see how using SQL can be *that* much better, in that it too
> must use some kind of locking feature in order to handle simultaneous
> accesses. Can it really do this in a more efficient way than the
> system's file locking? There also has to be a process switch (as far as
> I know) in order to interact with an SQL database.
The advantage I can think of is not having to lock the entire db to do a
write.
Also, the current db is a straight hash iirc. Would a b-tree be more
efficient for this? I'm jsut thinking about ways to squeeze that little
extra performance out of Exim :-)
The locking problem is something I have run in to and have to work with
regularly :-/
> I'm just skeptical, but I'm not an expert in this stuff, so I accept
> that I may be wrong...
I can't think of an obvious way to test this, other than just trying it.
