Hello Gerd, there seem to be two issues to verify:
1) There seems to be some load in general (~100 active threads, 20 requests per second with several SQL statements), these requests don't make big requests (data cache is enough), but how is the CPU usage - is the machine under high load when the performance problem occurs, and is this part of the problem? 2) Are the table locks application driven (LOCK TABLE statements) or have you 'Escalations'? In the 1st case there is nothing aside from an application change, that can be done, in the 2nd case I would suggest increasing the MAXLOCKS database parameter until the number of escalations decreases (is zero). Regards Alexander Schröder SAP DB, SAP Labs Berlin -----Original Message----- From: Gerd König [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 12. April 2006 13:14 To: maxdb@lists.mysql.com Subject: performance problems (avoid table locks) in 7.3 Hi, we're currently having strange performance problems with sapdb 7.3.0.48 on linux. The amount of vserver processes is about 100 and this leads to unacceptable response times to our application. During the lunch time (12.00-13.00) this number decreases to 20-30 (and then we have acceptable performance). It seems like the database cannot handle the heavy traffic with acceptable performance, so we don't know how to get the performance boost..... The dbm-gui activity overview shows a high number of table locks (my thought that this is high). The lock section of this overview: Available entries: 21150 maximum: 1650 average: 5 Row locks: 38359 Table locks: 27046 lock collisions: 140 I think the number of entries cannot be the problem, is there a parameter to adjust, so that we can avoid generating unnecessary table locks caused by this lock collisions...? the environment: Data cache: 1.8GB => 100% hit rate converter cache: 100% hit rate catalog cache: 91,46% hit rate => cache cannot be the bottleneck, ...?!? Connections to the database are established from a apache module. Each request from a customer is handled by a apache process, which itself connects to the database, and after all work is done the connection is closed. the execution time of the sql-statements fired to the database looks good (98% of them has exec.time < 1 sec.) My thoughts are that probably the amount of requests could lead to our performance problems. Currently we have about 20 requests per second, and each request produces several sql statements. any hint/help appreciated --GERD-- -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
