Hi, Thanks for the detail information. It explains everything.
I've just tried on my machine, and it works perfectly as what you've described. It seems even my old Linux 7.3. can support it (although my glibc is glibc-2.2.5-34 :) After restart, if I do "ps -elf", i see a lot less processes (threads). Hope it works well. Thanks again. Andy -----Original Message----- From: Mensing, Joerg [mailto:[EMAIL PROTECTED] Sent: 2004?4?1? 15:39 To: Andy Chan Cc: Franki Cheung; Jason Cheng; [EMAIL PROTECTED] Subject: RE: Performance problem after upgrading to 7.5.0.8 Hi, > -----Original Message----- > From: Andy Chan [mailto:[EMAIL PROTECTED] > Sent: Donnerstag, 1. April 2004 05:55 > To: Mensing, Joerg; [EMAIL PROTECTED] > Cc: Franki Cheung; Jason Cheng > Subject: RE: Performance problem after upgrading to 7.5.0.8 > > > Hi, > > Thanks for the sharing. I've checked my Linux installation, > and discovers the parameter is default to NO. > > The machine is running RH7.3 with kernel 2.4.18-3, and glibc > version 2.2.5. > > My Q is: How do I know whether I can enable USE_COROUTINES ? > What's the impact if I enable it where it shouldn't be? after enabling the parameter the following subroutine is called: static void en81_CheckCoroutineUsage(RTE_XPARAM_REC *XparamParameters ) { if ( XparamParameters->fUseCoroutines ) { MSGD(( INFO_USE_COROUTINE_FOR_TASK )); if ( XparamParameters->fUseStackOnStack ) { MSGD(( INFO_USE_STACK_ON_STACK )); } if ( XparamParameters->fUseUcontext ) { /* first check if getcontext() works (there are linuxes where it doesn't) */ ucontext_t testContext; if( -1 == getcontext(&testContext) ) { MSGD(( ERR_COROUTINES_NOT_AVAILABLE )); vabort(false); } MSGD(( INFO_USE_UCONTEXT )); } else { MSGD(( INFO_USE_OWN_CONTEXT )); } } else { MSGD(( INFO_USE_THREADS_FOR_TASK )); } } this routine is part of the startup code of the database kernel (long before any persistent data are accessible...). On 7.5.00.08 the consequence of non working coroutines are therefore: vabort() That means a well defined crash: Kernel died before reaching admin state.... A successfull coroutine usage is visible in knldiag ( all MSGD macros produce messages in knldiag ): 2004-04-01 08:56:08 2201 12927 TASKING Using coroutines for tasks 2004-04-01 08:56:08 2201 12927 TASKING Using UKT stack for coroutine stack 2004-04-01 08:56:08 2201 12927 TASKING Using ucontext_t for coroutine context So if your Linux does not support coroutines, you can modify that parameter once and if it is not working your kernel will crash before really starting. Then you have to switch coroutine usage off again. I would recommend to think about upgrading your Linux distribution in such a case... But since it is only a glibc problem, you do not have to exchange your Linux kernel but you have to upgrade your glibc. 'Unfortunatly' our development system already had a glibc with working getcontext()... We are using > rpm -q glibc glibc-2.2.4-21 on our local test machine and > rpm -q glib glibc-2.2.5-179 on our production system. ..... In release notes for glibc 2.2.3 i found ( http://www.aoindustries.com/docs/glibc-2.2.4/NEWS ) .... Version 2.2.3 .... Ulrich Drepper <[EMAIL PROTECTED]> implemented the setcontext family of functions for Linux/x86. ...... This code was changed in 7.5.00.11 into (with this release USE_COROUTINES default was changed to YES...) if ( XparamParameters->fUseUcontext ) { /* first check if getcontext() works (there are linuxes where it doesn't) */ ucontext_t testContext; if( -1 == getcontext(&testContext) ) { MSGD(( ERR_COROUTINES_NOT_AVAILABLE )); XparamParameters->fUseCoroutines = false; MSGD(( INFO_USE_THREADS_FOR_TASK )); } else { MSGD(( INFO_USE_UCONTEXT )); } } else { MSGD(( INFO_USE_OWN_CONTEXT )); } With 7.5.00.11 the kernel will automatically switch back to USE_COROUTINES = NO. CU jrg P.S.: If you link a program on a Linux that does not support coroutines, you will get a linker message something like "getcontext() not yet implemented"... Unfortunatly some 'inbetween' glibc versions seem to have lost getcontext() support again... Nobody really needs fast coroutine switching but databases ;-) > > Cheers, > Andy > > > -----Original Message----- > From: Mensing, Joerg [mailto:[EMAIL PROTECTED] > Sent: 2004?4?1? 0:32 > To: 'Mark Thomas'; [EMAIL PROTECTED] > Subject: RE: Performance problem after upgrading to 7.5.0.8 > > > 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:[EMAIL PROTECTED] Behalf Of Mark Thomas > > Sent: Mittwoch, 31. M�rz 2004 17:42 > > To: [EMAIL PROTECTED] > > 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/[EMAIL PROTECTED] > > > > -- > MaxDB Discussion Mailing List > For list archives: http://lists.mysql.com/maxdb > To unsubscribe: > http://lists.mysql.com/[EMAIL PROTECTED] > ____________________________________________________________ (c) 2003 Interactive Technology Holdings Limited Group. All rights reserved. CONFIDENTIALITY: This communication and any attachment(s) is intended solely for the person or organisation to which it is addressed and it may be confidential. This communication may contain confidential or legally privileged material and may not be copied, redistributed or published (in whole or in part) without our prior written consent. This communication may have been intercepted, partially destroyed, arrive late, incomplete or contain viruses and no liability is accepted by any member of the Interactive Technology Holdings Limited Group as a result. If you are not the intended recipient, employee or agent responsible for delivering the message to the intended recipient you must not copy, disclose, distribute or take any action in reliance on it. If you have received this communication in error, please immediately reply and highlight the error to the sender immediately and destroy the original from your computer. -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
