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? 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]
