Hi!
>>>>> "Steven" == Steven Roussey <[EMAIL PROTECTED]> writes: Steven> I tried the skip-name-resolve and it had no effect. So there goes my Steven> hypothesis. Steven> Here are the results from test: Steven> Benchmark DBD suite: 2.14 Steven> Date of test: 2002-06-24 11:19:19 Steven> Running tests on: Linux 2.4.16-0.13smp i686 Steven> Arguments: Steven> Comments: Steven> Limits from: Steven> Server version: MySQL 3.23.51 log <cut> Steven> TOTALS 2098.00 436.22 126.65 562.87 The above looks quite ok. On a Intel Xeon 2M cache, 4x700 Mhz, 2G, key_buffer=16M, gcc 3.1 machine I get: TOTALS 3399.00 664.19 179.00 843.19 (This is a newer benchmark version with some new tests, but still comparable) So at least there is nothing strange with the basic MySQL queries on the machine. Now there are two different possible problems: - A problem with the thread library that causes a problem when using many threads. - Some query / specific feature that you use that is slower like before. (For example a query that doesn't use indexes anymore). Could you by any change check by using the slow query log if there is some specific query that is causing problems ? Another option is to run the 3.23.51 server for a while and when you get a load problem do 'mysqladmin proc ext'. This command should show us if MySQL is using more table scans than usual. Regards, Monty --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
