Hello Arran. Thanks for your explanation concerning filedescriptors.
Compiled in limits are usually to stop people doing stupid things. Stop doing stupid things and the server will work.
I try to.
The detail file reader is considerably faster in v3.0.7 than 2.2.5, you probably don't need 128 detail queues. One would likely be enough, 10 at most.
I can confim it. I have tried 12 and it is really fast an uses the DB connections more efficiently.
Also is there a reason why you're not doing direct inserts into the database? buffered sql was intended primarily for buffering SQL data when the database went offline, not for insertion into the normal request flow. It'll always be slower than blocking inserts.
The idea behind was that writing to a file is cheeper than perform a DB transactions and a delayed (asynchronous) write to DB is not an issue for me. My average row lock time is about 40ms in bussy hour. IMHO writing to a file must be faster or am I wrong?
You can set the MySQL client library timeout sufficiently low that the module will will trash all its connections, and failover to the detail writer before the server starts dropping packets.
What config parameter is it? I am affraid that if I lock the raddact table for 3-5 sec or so because of another transaction the server will start to drop requests before it will have a chance to failover to a file...
Set retry_delay in the sql module pool to something like 60 to stop the server continuously trying to open new connections when a MySQL server does down.
Thanks Ales