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]
>
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
