Re: [Firebird-devel] Lock manager memory 2 GB

2012-03-25 Thread marius adrian popa 
On Fri, Mar 23, 2012 at 9:13 AM, Alex Peshkoff peshk...@mail.ru wrote:
  On 03/23/12 00:24, Nikolay Samofatov wrote:
 Hello, All!

 We completed (conditional) implementation of lock manager buffer  2 GB and 
 put it into production.

 The production system tends to be 100% CPU bound now (as there is a few days 
 back-log of work).
 All 24 cores are busy, 450 GB RAM utilized for one database.

 Roughly ~50% of CPU time is spent in Linux kernel

 Interesting, where is the time spent when changing rings is counted -
 user or kernel time?

 on average and lock manager mutex wait hovers
 around 40-50%.


 Afraid it's as expected for 24 cores system.

 Live kernel profiler output of loaded system is as follows (generated with 
 OProfile):

 7073900   3.6298  vmlinux                  vmlinux                  
 copy_user_generic_string
 5554648   2.8502  vmlinux                  vmlinux                  __wake_up
 4695015   2.4091  vmlinux                  vmlinux                  
 prepare_to_wait_exclusive
 4670651   2.3966  vmlinux                  vmlinux                  
 futex_wait_setup
 3988807   2.0468  vmlinux                  vmlinux                  
 futex_wake
 2006843   1.0298  vmlinux                  vmlinux                  
 intel_idle
 1321253   0.6780  vmlinux                  vmlinux                  schedule
 1022927   0.5249  vmlinux                  vmlinux                  put_page
 1001815   0.5141  vmlinux                  vmlinux                  
 finish_wait
 735902    0.3776  vmlinux                  vmlinux                  
 try_to_wake_up
 716559    0.3677  vmlinux                  vmlinux                  
 _atomic_dec_and_lock
 674752    0.3462  vmlinux                  vmlinux                  get_page
 646537    0.3318  vmlinux                  vmlinux                  
 tick_nohz_stop_sched_tick
 628516    0.3225  vmlinux                  vmlinux                  
 task_rq_lock
 594621    0.3051  vmlinux                  vmlinux                  
 update_curr
 583779    0.2996  vmlinux                  vmlinux                  
 native_write_msr_safe
 527673    0.2708  vmlinux                  vmlinux                  
 select_nohz_load_balancer
 504132    0.2587  vmlinux                  vmlinux                  
 get_futex_key
 460908    0.2365  vmlinux                  vmlinux                  
 __audit_syscall_exit
 447328    0.2295  vmlinux                  vmlinux                  
 enqueue_hrtimer
 443841    0.2277  vmlinux                  vmlinux                  
 __wake_up_bit
 429380    0.2203  vmlinux                  vmlinux                  
 thread_return
 401287    0.2059  vmlinux                  vmlinux                  
 __switch_to
 397639    0.2040  vmlinux                  vmlinux                  
 update_cfs_shares
 381845    0.1959  vmlinux                  vmlinux                  
 rb_get_reader_page
 377837    0.1939  vmlinux                  vmlinux                  ktime_get
 371547    0.1907  vmlinux                  vmlinux                  
 native_read_tsc
 369331    0.1895  vmlinux                  vmlinux                  
 radix_tree_lookup_slot


 This demonstrates that to scale effectively past 24-40 cores per node, 
 Firebird needs to implement
 shared buffer cache.

 Luckily it's implemented in trunk.
 And it's superserver - i.e. latches instead locks in lock manager.

 Lock manager mutex operations and copying from file system cache to 
 userspace emerge as hard bottleneck.

 With lock manager change to 64-bit one 24 core node handles ~10 million user 
 transactions daily.

 Is it going to reach 2**31 limit soon? 200 days if I'm not mistaken.

 reliably, at times having 1500 concurrent INSERT/UPDATE requests.

 Shall we merge lock manager changes?

 In trunk - definitely. What about 2.5 - not sure. May be having patch
 for high-end systems is better approach than commit in svn?
Another option is
On github you can fork the firebird 2.5 branch
https://github.com/asfernandes/firebird/tree/B2_5_Release and keep the
set of patches  for high-end systems in your fork if you want

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Firebird-devel] Issue with TlsValue class initialization (Firebird-2.5.1)

2012-03-25 Thread Elena 
Hi

Now I’m
building and testing Firebird-2.5.1.26351 (got from http://www.firebirdsql.org/)
on HP-UX 11i v3 (HP Integrity server  rx2800 i2 with Intel®  Itanium® 
processors) using aCC (HP C++ compiler).

I've met the following issue:

Despite aCC
supports __thread keyword it is set not to use it in src/jrd/common.h, so 
workaround
TlsValue class is used. But when firebird programs are run Firebird::TlsValue
contextPool is not initialized and this cause the programs to get caught in an
endless loop (see create_db runtime stack contents below).

I managed
to build Firebird enabling __thread keyword use and will be testing it.

Could 
the issue with TlsValue class be investigated and fixed?

Thanks a lot in advance.

Best
regard,

Elena.

create_db runtime stack contents  (#0-#7 are endlessly repealed during 
execution):

#0 gds__log
(text=0x4029e220 Assertion (%s) failure: %s %ld\n) at
src/jrd/gds.cpp:1185

#1
0x404f80e0:2 in inline Firebird::TlsValue::get()
(this=0x600d6ba8) at src/include/../common/classes/fb_tls.h:129

#2
0x404f8080:0 in Firebird::MemoryPool::getContextPool () at
src/common/classes/alloc.cpp:300

#3
0x40505f40:0 in Firebird::AutoStorage::getAutoMemoryPool () at
src/common/classes/alloc.cpp:2031

#4
0x40534390:2 in inline Firebird::AutoStorage::AutoStorage() () at
src/include/../common/classes/alloc.h:588

#5
0x40534380:1 in inline Firebird::AbstractString::AbstractString() () at
src/common/../common/../common/classes/fb_string.h:159

#6
0x40534370:1 in
Firebird::StringBase::StringBase
(this=0x9fffc7e0) at
src/common/../common/../common/classes/fb_string.h:609

#7
0x40539520:0 in fb_utils::getPrefix
(No.Identifier_5=0x9fffcd10, prefType=fb_utils::FB_DIR_LOG,
name=0x402b5af0 firebird.log) at src/common/utils.cpp:926

#8
0x40572ab0:0 in gds__log (text=0x4029e220 Assertion (%s)
failure: %s %ld\n) at src/jrd/gds.cpp:1185

#9
0x404f80e0:2 in inline
Firebird::TlsValue::get()
(this=0x600d6ba8) at src/include/../common/classes/fb_tls.h:129

#10
0x404f8080:0 in Firebird::MemoryPool::getContextPool () at
src/common/classes/alloc.cpp:300

#11
0x40505f40:0 in Firebird::AutoStorage::getAutoMemoryPool () at
src/common/classes/alloc.cpp:2031

#12
0x40534390:2 in inline Firebird::AutoStorage::AutoStorage() () at
src/include/../common/classes/alloc.h:588

#13
0x40534380:1 in inline Firebird::AbstractString::AbstractString() () at
src/common/../common/../common/classes/fb_string.h:159

#14
0x40534370:1 in
Firebird::StringBase::StringBase
(this=0x9fffd1a0) at 
src/common/../common/../common/classes/fb_string.h:609

#15
0x40539520:0 in fb_utils::getPrefix
(No.Identifier_5=0x9fffd6d0, prefType=fb_utils::FB_DIR_LOG,
name=0x402b5af0 firebird.log) at src/common/utils.cpp:926

#16
0x40572ab0:0 in gds__log (text=0x4029e220 Assertion (%s)
failure: %s %ld\n) at src/jrd/gds.cpp:1185

#17
0x404f80e0:2 in inline
Firebird::TlsValue::get()
(this=0x600d6ba8) at src/include/../common/classes/fb_tls.h:129

#18 0x404f8080:0
in Firebird::MemoryPool::getContextPool () at src/common/classes/alloc.cpp:300

#19
0x40505f40:0 in Firebird::AutoStorage::getAutoMemoryPool () at
src/common/classes/alloc.cpp:2031

#20
0x4114f050:2 in inline Firebird::AutoStorage::AutoStorage() () at
src/include/../common/classes/alloc.h:588

#21
0x4114f050:0 in inline Firebird::InlineStorage::InlineStorage() () at
src/jrd/../jrd/../common/classes/array.h:42

#22
0x4114f050:0 in inline Firebird::Array::Array() () at 
src/jrd/../jrd/../common/classes/array.h:83

#23
0x4114f040:0 in inline Firebird::HalfStaticArray::HalfStaticArray() 
(this=0x9fffdb60) at
src/jrd/../jrd/../common/classes/array.h:466

#24
0x4114f030:2 in inline Firebird::Aligner::Aligner(unsigned
char const*,unsigned int) (this=0x9fffdb60, len=2,
buf=0x4047a732 ) at src/jrd/../common/classes/Aligner.h:95

#25
0x4114f020:0 in Firebird::IntlUtil::cvtUtf16ToUtf8
(obj=0x601092c0, nSrc=2, ppSrc=0x4047a732 ,
nDest=4, pDest=0x601091d8 юн«нюн«нюн«нюн«н,
err_code=0x9fffdd90, err_position=0x9fffdd94) at
src/jrd/IntlUtil.cpp:385

#26
0x408336a0:0 in Jrd::CsConvert::convert (this=0x9fffe100,
srcLen=2, src=0x4047a732 , dstLen=4, dst=0x601091d8
юн«нюн«нюн«нюн«н, badInputPos=0x0, ignoreTrailingSpaces=false) at
src/jrd/../jrd/../jrd/CsConvert.h:199

#27
0x41022f10:2 in inline Jrd::CsConvert::convert(unsigned int,unsigned
short const*,unsigned int,unsigned char*,unsigned int*,bool) () at
src/jrd/../jrd/../jrd/CsConvert.h:89

#28
0x41022dc0:1 in inline Jrd::CharSet::CharSet(unsigned short,charset*)
() at src/jrd/../jrd/../jrd/CharSet.h:58

#29
0x41022d70:0 in inline