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' s...@broadviewsoftware.com [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 ------------------------------------ ------------------------------------ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ------------------------------------ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) <*> To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/