On Sat, 2005-05-07 at 08:18, Greg Whalin wrote:
Hi Peter,
As for reporting bugs ...
http://bugs.mysql.com/bug.php?id=7437
http://bugs.mysql.com/bug.php?id=10437
We have found Opteron w/ Mysql to be an extremely buggy platform,
especially under linux 2.6, but granted, we are running
I've added a fair bit of information on the Opteron HOWTO Wiki at:
http://hashmysql.org/index.php?title=Opteron_HOWTO
for using Fedora Core 3 with X86-64.
In my performance testing, I was finding that with so much RAM, everything
was coming from RAM anyway. RAID10 seemed to be most stable, and
Greg Whalin wrote:
I suspect this is an OS issue. Our Opteron's were completing large
data update queries aprox 2-3 times slower than our Xeons when running
under 2.6. After a switch to 2.4, Opteron's are faster than the
Xeons. I mentioned NPTL being shut off (LD_ASSUME_KERNEL=2.4.19 in
Kevin Burton wrote:
Greg Whalin wrote:
I suspect this is an OS issue. Our Opteron's were completing large
data update queries aprox 2-3 times slower than our Xeons when running
under 2.6. After a switch to 2.4, Opteron's are faster than the
Xeons. I mentioned NPTL being shut off
Greg Whalin wrote:
We are currently running 2.3.2 (Fedora Core 1) on our Opterons. When
we were still running linux 2.6, we were on 2.3.3 (Fedora Core 2).
Yeah... we were being bitten by 2.3.2's NPTL implementation for MONTHs
before I heard a rumor that the Internet Archive moved to 2.3.4.
Kevin Burton wrote:
Greg Whalin wrote:
We are currently running 2.3.2 (Fedora Core 1) on our Opterons. When
we were still running linux 2.6, we were on 2.3.3 (Fedora Core 2).
Yeah... we were being bitten by 2.3.2's NPTL implementation for MONTHs
before I heard a rumor that the Internet Archive
Greg Whalin wrote:
Curious, were you seeing deadlocks in Suns JVM w/ Tomcat?
Never with Tomcat but we might have a different number of threads. But
it *was* with Java...
We were forced to run Tomcat w/ NPTL off due to deadlocks under glibc
2.3.2+NPTL.
Yup.. thats the problem we had. But we
On Fri, 2005-05-06 at 22:16, John David Duncan wrote:
And no performance diff. Note that you're benchmarks only show a 20M
addition overhead. We're about 60x too slow for these drives so I'm
not
sure what could be going on here :-/
I know of a site that encountered a similar
On Fri, 2005-05-06 at 19:01, Greg Whalin wrote:
What drives are you using? For SCSI RAID, you definitly want deadline
scheduler. That said, even after the switch to deadline, we saw our
Opteron's running way slow (compared to older slower Xeons). Whatever
the problem is, we fought it for
Hi Peter,
As for reporting bugs ...
http://bugs.mysql.com/bug.php?id=7437
http://bugs.mysql.com/bug.php?id=10437
We have found Opteron w/ Mysql to be an extremely buggy platform,
especially under linux 2.6, but granted, we are running Fedora. Perhaps
we will try Suse, but I feel I have heard
On Fri, 6 May 2005, Kevin Burton wrote:
For the record... no a loaded system what type of IO do you guys see?
Anywhere near full disk capacity? I'm curious to see what type of IO
people are seeing on a production/loaded mysql box.
Mostly Linux in this thread so far, so I figured I'd throw
Atle Veka wrote:
On Fri, 6 May 2005, Kevin Burton wrote:
For the record... no a loaded system what type of IO do you guys see?
Anywhere near full disk capacity? I'm curious to see what type of IO
people are seeing on a production/loaded mysql box.
Mostly Linux in this thread so far, so I
On Sat, 7 May 2005, Kevin Burton wrote:
It looks like you're saying here that a single disk is FASTER than your
RAID 10 setup.
Correct?
Which is interesting. I'm wondering if this is a RAID config issue. It
just seems to make a LOT more sense that RAID 1 or 10 would be faster
than a
In the last episode (May 07), Atle Veka said:
On Fri, 6 May 2005, Kevin Burton wrote:
For the record... no a loaded system what type of IO do you guys
see? Anywhere near full disk capacity? I'm curious to see what
type of IO people are seeing on a production/loaded mysql box.
Mostly
What kernel are you running.
If your running 2.6.x use the deadline scheduler or downgrade to
2.4.23aavm 2.6.[0-9] has major problems with the IO scheduler since the
process scheduler is very fast now.
DVP
Dathan Vance Pattishall http://www.friendster.com
-Original
We have seen the exact same thing here. We used the deadline scheduler
and saw an immediate improvement. However, we still saw much worse
performance on our Opteron's (compared to our older Xeon boxes). We
ended up rolling back to Fedora Core 1 2.4.22-1.2199.nptlsmp kernel and
shut down
Greg Whalin wrote:
We have seen the exact same thing here. We used the deadline
scheduler and saw an immediate improvement. However, we still saw
much worse performance on our Opteron's (compared to our older Xeon
boxes). We ended up rolling back to Fedora Core 1
2.4.22-1.2199.nptlsmp
Kevin Burton wrote:
Greg Whalin wrote:
We have seen the exact same thing here. We used the deadline
scheduler and saw an immediate improvement. However, we still saw
much worse performance on our Opteron's (compared to our older Xeon
boxes). We ended up rolling back to Fedora Core 1
Greg Whalin wrote:
Deadline was much faster. Using sysbench:
test:
sysbench --num-threads=16 --test=fileio --file-total-size=20G
--file-test-mode=rndrw run
Wow... what version of sysbench are you running? Its giving me strange
errors
sysbench v0.3.4: multi-threaded system evaluation
Kevin Burton wrote:
Greg Whalin wrote:
Deadline was much faster. Using sysbench:
test:
sysbench --num-threads=16 --test=fileio --file-total-size=20G
--file-test-mode=rndrw run
So... FYI. I rebooted with elevator=deadline as a kernel param.
db2:~# cat /sys/block/sda/queue/scheduler
noop
What drives are you using? For SCSI RAID, you definitly want deadline
scheduler. That said, even after the switch to deadline, we saw our
Opteron's running way slow (compared to older slower Xeons). Whatever
the problem is, we fought it for quite a while (though difficult to test
too much
Greg Whalin wrote:
What drives are you using? For SCSI RAID, you definitly want deadline
scheduler. That said, even after the switch to deadline, we saw our
Opteron's running way slow (compared to older slower Xeons). Whatever
the problem is, we fought it for quite a while (though difficult
In the last episode (May 06), Kevin Burton said:
We have a few of DBs which aren't using disk IO to optimum capacity.
They're running at a load of 1.5 or so with a high workload of
pending queries.
When I do iostat I'm not noticing much IO :
Device:rrqm/s wrqm/s r/s w/s rsec/s
And no performance diff. Note that you're benchmarks only show a 20M
addition overhead. We're about 60x too slow for these drives so I'm
not
sure what could be going on here :-/
I know of a site that encountered a similar performance issue:
The OS was reading in a lot more data from the disk
24 matches
Mail list logo
