I have 2 dual proc opterons and also have not seen this using MyISAM
(4.1.9), however, I have been less than impressed with mysql on opteron
(using the x86-64 binary from their site). Performance is generally
less than that of our remaining old 32 bit dual proc xeon machines (all
our db machines have 4 GB RAM and similar my.cnf settings giving 1.5GB
to keybuffer, 768M to sort_buffer). In some cases, we are seeing
queries take twices as long on the opteron machines as on the xeons, and
it is rare for the opterons to ever outperform our xeon cluster. It is
also much more likely for our tables to crash during big alters on the
opteron machines than on the xeon, especially if the table has a full
text on it (http://bugs.mysql.com/bug.php?id=7437).
We are planning a full switch to innodb, and I seriously hope that makes
the mysql on opteron experience a more pleasurable one.
Greg
Donny Simonton wrote:
I know this may be strange, but have you turned on innodb on the box? Even
if don't use it? I have 8 amd64 boxes and have never experienced this
problem you are talking about. They range from single proc to quad proc.
Never this problem but all of them have innodb turned on.
Turn it on and see what happens, it could be a bug inside the mysql code.
Donny
-Original Message-
From: Michel Buijsman [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 16, 2005 5:41 AM
To: mysql@lists.mysql.com
Subject: INSERT queries hang on amd64
My problem: INSERT queries hang on amd64.
This looks a lot like Don MacAskill's bugreport in
http://bugs.mysql.com/bug.php?id=3483
Which is listed as closed, but the bug is apparently still there
so maybe it should be reopened...
I've just upgraded from 4.1.9 to 4.1.10 (binary) on a dual opteron
with 8G ram, running Debian 3.1 pure64 gcc-3.4. Also tried 4.0.23
last week, but that had the same problems. Kernels I've tried are
2.6.11-rc1-mm1 and 2.6.11-rc2.
I'm running 2 boxes in a replication setup, using the amd64 as the
master (or standalone) gave me pretty much what Don describes in bug
3483, insert queries start hanging after a while with no way to kill
them except kill -9 from the OS, which is a bit rough. ;-)
The master or standalone setup required quite a bit of poking to get
it to hang in a test environment, or just a few short hours running
as a production server. I haven't been able to narrow it down to one
specific thing, but it appears to have something to do with indexes,
because it ran fine after dropping all of them.
I hacked up a test script that's throwing a random selection of selects
and inserts at it at random intervals between 0 and 2 seconds, from 20
concurrent threads.
I could trigger it by running a "repair table" on it while the test
script was running. The repair thread would wait for its turn, then lock
everything else out and do its thing, and when it was done the first
insert after that would hang indefinitely. (Left it hanging over the
weekend, nothing.)
Adding "skip-concurrent-insert" fixes the problem, but cripples the
performance so that's not really an option.
Then tried to run one of the amd64 boxes as a slave off of a xeon box:
Same problem, the replication thread hangs within seconds of starting
the server, and again won't budge for anything except kill -9. This is
on a server without _any_ other connections except for a processlist.
I've run out of things to try, so I hope someone here can help...
my.cnf:
[mysqld]
user=mysql
socket=/tmp/mysql.sock
skip-locking
set-variable= key_buffer=2G
set-variable= table_cache=1024
set-variable= sort_buffer=16M
set-variable= read_buffer=16M
set-variable= max_allowed_packet=10M
set-variable= thread_cache=64
set-variable= thread_stack=512K
set-variable= tmp_table_size=16M
set-variable= interactive_timeout=600
set-variable= wait_timeout=600
set-variable= max_connections=1024
set-variable= query_cache_type=2
set-variable= query_cache_size=100M
set-variable= join_buffer_size=8M
set-variable= thread_concurrency=4
set-variable= myisam_sort_buffer_size=64M
skip-innodb
--
Michel Buijsmantty.nl -- 2dehands.nl
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:
http://lists.mysql.com/[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
