[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sapdb-general
Subject:    RE: Performance problem after upgrading to 7.5.0.8
From:       "Mensing, Joerg" <joerg.mensing () sap ! com>
Date:       2004-03-31 16:31:39
Message-ID: B9A2DDA03044D311BBD40008C75D696814E19072 () dewdfx24 ! wdf ! sap ! corp
[Download RAW message or body]

Hi, 
i would check the parameter 'USE_COROUTINES' in your parameter file. 
With release 7.5 the default for coroutines usage should be YES, but in case the 
system do not support a valid 'getcontext()' routines (as some Linux supplied glibc does....) 
or if the parameter file says 'NO' we switch to use 'Threads for Tasks'. We like to use 
the 'getcontext()/makecontext()/swapcontext()' interface to get rid of our own hard to maintain
assembler code for coroutine switching..... 
'USE_COROUTINES=NO' means each task in the kernel runs on its own thread, which increases 
dispatch overhead dramatically. You can check this also by looking at the number of 
'clone processes'...

Without coroutines the database uses
a) much more resources
b) is slower on dispatching
but c) allows C++ exception coding, which is not working in combination with coroutines...

If you do not need all those user tasks configured to run in parallel, a good hint is to 
reduce the number of concurrent tasks by reducing 'MAXUSERTASKS' parameter. Especially if
each task runs in its own thread this is a must...

CU
jrg

> -----Original Message-----
> From: news [mailto:news@sea.gmane.org]On Behalf Of Mark Thomas
> Sent: Mittwoch, 31. März 2004 17:42
> To: maxdb@lists.mysql.com
> Subject: Performance problem after upgrading to 7.5.0.8
> 
> 
> We have just completed an upgrade from 7.3.0.46 to 7.5.0.8 on 
> Linux, and 
> have encountered significant performance problems.  Some 
> processes are 
> taking upwards of 100x longer to complete than prior to the 
> upgrade.  We 
> have ruled out hardware failure and verified that the system 
> has enough 
> free memory, and neither processor is fully utilized (the 
> system load is 
> quite low).  We have checked knldiag and knldiag.err, and 
> found nothing 
> useful.
> 
> With the database running, even OS commands have become 
> unresponsive.  We 
> have decreased the value of CACHE_SIZE, and the database performance 
> actually improved somewhat (though nowhere near the pre-upgrade 
> performance).  I wish I could provide more information, but 
> we really have 
> no idea what's going on.
> 
> Can anyone suggest where we might look next to find the problem?
> 
> -- 
> Mark Thomas
> United Drugs
> 
> 
> -- 
> MaxDB Discussion Mailing List
> For list archives: http://lists.mysql.com/maxdb
> To unsubscribe:    
> http://lists.mysql.com/maxdb?unsub=joerg.mensing@sap.com
> 

-- 
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:    http://lists.mysql.com/maxdb?unsub=sapdb-general@progressive-comp.com


[prev in list] [next in list] [prev in thread] [next in thread]