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.
>
>
>
>

--

*Andreas Zeller*

Geschäftsleitung
lux-medien.com <https://www.lux-medien.com/>
Carl-Friedrich-Gauss-Str. 56
47475 Kamp-Lintfort

Office: +49 2151 32 66 628
Fax: +49 2151 32 66 721
Mobil: +49 163 27 9 1979