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_KERNEL=2.4.19 in
>> init script). When we left NPTL running, we saw almost instant
>> deadlocks just watching replication catching up (no other site traffic
>> directed to the machine). This is in 2.4 btw, so this is the
>> backported NPTL kernels from Fedora. I somewhat suspect NPTL being a
>> problem in 2.6 as well due to impressions I get from sifting through
>> mysql's bug tracking system. The IO scheduler was also an obvious
> Another point I wanted to note.
> What version of glibc were you running. We were running Debian with
> glibc 2.3.2 (libc6-i686-2.3.2) and were running into deadlocks with
> another piece of code.
> 2.3.2 has a number of known issues and we had to migrate to an
> experimental 2.3.4 build. I've been considering moving our databases to
> 2.3.4 but they weren't having any problems.
> It might be that opteron is raising these issue more than Xeon.
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).