Hi Andreas,

I think the main thing is

* blockdev -setfra 32768 <datadevice> - this has nothing to do with
firebird but speeds up reads in the RAID array quite a bit. Thanks
to wltjr on IRC.

and, probably, backup/restore.

In 2.5 the bad effect of autosweep is almost eliminated on the systems
with low and moderate writes.

Regards,
Alexey Kovyazin

> Hi guys,
>
> I'm just responding one more time because I want to mark this as solved
> for me:
>
> Several things did the trick:
>
> * Upgrade Firebird to 2.5.7 (apparently there was a subquery bug in
> 2.5.4 which wasn't fixed in the debian package) - thanks to LiENUS
> on IRC.
> * blockdev -setfra 32768 <datadevice> - this has nothing to do with
> firebird but speeds up reads in the RAID array quite a bit. Thanks
> to wltjr on IRC.
> * switching to manual sweeping over automatic and transaction-based
> * doing a complete gbak backup/restore one more time to re-index
> * tweaking xinetd (flags = REUSE NODELAY)
>
> Tweaking a system for firebird is a little bit different from tweaking
> it for other databases, because firebird uses one huge file and not
> several of them scattered all over the filesystem. Not judging, just
> saying it's a different approach :)
>
> Maybe I'll write something up on our blog for this so people can more
> easily find the bottlenecks. This took me two weeks of research and a
> lot of asking around. One simple best-practice howto would have saved me :)
>
> If anyone cares, I will write this down as an optimized firebird linux
> setup from start to finish and run this by you guys. Most of the howtos
> and optimization resources I could find focus on Windows (CPUAffinity
> tweaks, etc.) - and I'd like to help people out who want to skip the
> windows section :)
>
> Thanks again.
>
> Andreas
>
>
>
>
> On 28.02.2017 00:33, 'Leyne, Sean' Sean@...
> [firebird-support] wrote:
>>
>>
>> Andreas,
>>
>>
>>
>>
>>
>> this is the one thing I am getting when I am connecting to the
>> database. I am not the one working productively on the system, so I
>> can't really tell wether this has become faster or is still the same.
>>
>> LOCK_HEADER BLOCK
>> Version: 145, Active owner: 0, Length: 7048576, Used: 540536
>> Flags: 0x0001
>> Enqs: 5031, Converts: 113, Rejects: 8, Blocks: 11
>> Deadlock scans: 0, Deadlocks: 0, Scan interval: 10
>> Acquires: 7695, Acquire blocks: 3, Spin count: 0
>> Mutex wait: 0.0%
>> Hash slots: 30011, Hash lengths (min/avg/max): 0/ 0/ 4
>> Remove node: 0, Insert queue: 0, Insert prior: 0
>> Owners (3): forward: 252920, backward: 490968
>> Free owners: *empty*
>> Free locks (5): forward: 254960, backward: 519480
>> Free requests (6): forward: 540344, backward: 403464
>> Lock Ordering: Enabled
>>
>> This is what the fb_lock_print output looks like.
>>
>> <SL> Those numbers look to be very good.
>>
>> <SL> Q: Why are you running Classic server? How many
>> users/connections are there usually to the database?
>>
>> <SL> Perhaps SuperServer provide better performance – it would allow
>> you to “blow up” the page cache size.
>>
>>
>>
>>