Hi Daniel,
We were using a software RAID-5 on top of hardware RAID-5 across 3
4-disk volume groups. (1 LUN from each array volume group built the
software RAID-5). So we were able to lose 3 disks in a worst case
scenario.
It seems to me that neither RAID-1 or RAID-5 can lose more than one
disk w
On 12/4/06, Jason J. W. Williams <[EMAIL PROTECTED]> wrote:
Hi Daniel,
Thank you very much for your help and advice. After some examination,
we discovered a couple of things. It looks like our storage array
layout was really bad for the IOPS MySQL was throwing at it, as a
result the InnoDB trans
Hi Daniel,
Thank you very much for your help and advice. After some examination,
we discovered a couple of things. It looks like our storage array
layout was really bad for the IOPS MySQL was throwing at it, as a
result the InnoDB transactions started to back-up under heavy load.
Changing the arr
Jason, in addition to Daniel's suggestions, I'll throw this out there:
I had a somewhat similar problem with a database I used to own, where
a handful of very hard-hit tables would become progressively slower
over time, despite the fact that (due to daily archiving and purging)
they were not grow
On 11/27/06, Jason J. W. Williams <[EMAIL PROTECTED]> wrote:
Hi,
We're running MySQL 5.0.27 under Solaris 10 on both Opteron and
UltraSparc T1 machines. The performance on both boxes starts out great
when the process is fresh, however over the course of a week of heavy
use the performance degrad
Hi,
We're running MySQL 5.0.27 under Solaris 10 on both Opteron and
UltraSparc T1 machines. The performance on both boxes starts out great
when the process is fresh, however over the course of a week of heavy
use the performance degrades to the point where its nearly unusable.
The Opteron has 2G
