Hello, Marius, > > Another thing to try is to use a kernel> 3.2 if possible > > Some of the write locking and scalability issues were solved in kernel 3.2 > >
No, i don't think so. We profiled Linux kernel with Firebird accurately. I have the entire oprofile callgraph handy. The hard bottleneck now is copying of memory from filesystem cache into userspace (do_sync_read -> ... -> copy_user_generic_string) Mutex operations (do_futex, futex_wake and friends) are the second contender, but if left alone would probably limit us at ~40-50 cores given profiling data. Due to massive cache copying operations you cannot effectively utilize > ~16 cores per database without shared cache on OLTP workload. Firebird 3.0 will hopefully solve this problem. The performance measurement of course implies that maximum LockHashSlots value setting of 65521 is used. With default setting LM mutex wait is > 50% and lock manager is the bottleneck. BTW, we completed the work on 64-bit LM, and can publish sources but we are too busy with other issues to actually do the merge now. -- Nikolay Samofatov, MBA Red Soft Corporation +7 495 668 3735 ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
