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 wr
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 runni
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 h
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:
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.
Thi
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 (LD_ASSUME_KE
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
init
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.
>
> Mo
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
> tha
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 f
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
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 sim
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
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 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 th
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
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 t
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 w/
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 anticipa
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:
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
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 kernel
om
Subject: MySQL not using optimum disk throughput.
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
age-
> From: Kevin Burton [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 06, 2005 1:58 PM
> To: mysql@lists.mysql.com
> Subject: MySQL not using optimum disk throughput.
>
>
> We have a few of DBs which aren't using disk IO to optimum capacity.
>
> They're ru
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 wsec/srkB/swkB/s
avgrq-sz avgqu-sz await svctm
25 matches
Mail list logo
