Hi Gerd, the 'task dump' is a 'feature' whenever you reach task limit (src/en/ven84.c)... If reaching task limit becomes a normal state, this is someting to be changed...
You can get much more details about the current internal state of tasks using 'x_cons YourDbname show tasks'. For overall status of your database you can use 'x_cons YourDbname show all'. Using 'x_cons YourDbname show active' you will see which tasks are active. You reached the task limit, but the number of vserver is less. Several possibilities... - you send 'ps -aux' while connections have been closed already (most likely if only short connections are used) - you had additional local connections open, that do not use vserver - the internal state of the database is corrupted (Task limit is reached, if no free task is found but the search of a free task needs pointers which could have been corrupted. Unfortunatly the task 'dump' you see whenever task limit is reached does not show if the internal links that may have been corrupted. But in such a case, you would permanantly run into the problem of less tasks available than configured. Does the task limit situation solves itself or is it permanent like described above? Which database version do you use? I could prepare for you a special console program (which depends on your database version), that verifies your database is not corrupted. In case the loss of tasks is permanent, this would at least pinpoint the problem. CU jrg > -----Original Message----- > From: Gerd K�nig [mailto:[EMAIL PROTECTED] > Sent: Freitag, 16. Januar 2004 10:06 > To: SAPDB Mailinglist > Subject: Vsuspend, task limit, problems > > > Hi, > > today we have some problems concerning task limit. > From time to time, the database isn't responding because task > limit (current > setting: 120) > is reached. > Is it possible to get more details from the log-files why the > tasks are not > being finished ? > > > thanks in advance ...GERD... > > > > some details: > ============= > > The cpu-load, and the system-load are not that high (please > have a look): > > trying to connect via dbmcli: > ERR > -24988,ERR_SQL: sql error > 1,task limit > ===================================================================== > ps -aux | grep -c vserver => 118 > ===================================================================== > uptime: > 9:08am up 173 days, 22:31, 2 users, load average: 0.15, 0.71, 0.97 > total used free shared > buffers cached > Mem: 3946776 3935556 11220 0 > 407524 2092584 > -/+ buffers/cache: 1435448 2511328 > Swap: 1052632 15928 1036704 > > ===================================================================== > in the knldiag there are a lot of entries like this (I've > choosen those for > "T81"): > > 2004-01-16 09:09:02 32228 11580 COMMUNIC e84_find: UKT6 T81 conn > 1074240204 'Vsuspend' > .... > 2004-01-16 09:09:02 32228 WNG 11832 COMMUNIC rejecting request > 2004-01-16 09:09:02 32228 WNG 11837 COMMUNIC ALL are busy (in > all UKTs) > .... > 2004-01-16 09:09:02 32228 11580 COMMUNIC e84_find: UKT6 T81 conn > 1074240204 'Vsuspend' > .... > .... > 2004-01-16 09:09:06 32227 WNG 11840 COMMUNIC Killing T81 for > died apid 6779 > > > > > -- > 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]
