hdparm -Tt /dev/sdX ?
Ian Simpson wrote:
That's pretty much what I've been doing to get that the drive is running
at 100% bandwidth.
What I'd like is something that just gives the bandwidth of the device
in terms of Mb/s: you can probably work it out using that iostat
command, seeing how
Please check if the my.cnf configurations to be the same.
What are your configuration parameters in terms of innodh flush log trx
commit , bin logging, sync binlog and innodb unsafe for binlog ?
If the systems have raid, check if the BBWC is enabled on the new host and
WB is enabled.
On Fri,
Hi Alex,
Configurations are identical, other than the differences I initially
mentioned. I've diffed both the configuration files and the output of
SHOW VARIABLES on both servers.
I've contacted my hosting provider to ask about the RAID settings.
Variable_name: innodb_flush_log_at_trx_commit
check for iostat to see if the disk is heavly used.
On 6/13/08, Ian Simpson [EMAIL PROTECTED] wrote:
Hi Alex,
Configurations are identical, other than the differences I initially
mentioned. I've diffed both the configuration files and the output of
SHOW VARIABLES on both servers.
I've
also how often do you issue a commit. batching the inserts inside a
transaction might help.
On Fri, Jun 13, 2008 at 6:53 PM, Ananda Kumar [EMAIL PROTECTED] wrote:
check for iostat to see if the disk is heavly used.
On 6/13/08, Ian Simpson [EMAIL PROTECTED] wrote:
Hi Alex,
Configurations
Hi guys, thanks for pitching in.
The inserts are from replication; we're not using transactions on the
master (yet), and I don't think there's a way of telling MySQL to batch
incoming replication statements if they're not already in a transaction.
Disk usage: the older server (the one that's
replication based inserts are serial whereas most of the time the inserts on
masters are concurrent. this leads to the slaves falling behind. to tackle
this we have used the following strategies :
1. Use raid 0 on the slaves (master users raid 10) so as to speed up writes.
2. pre fetch and cache
Disk usage: the older server (the one that's running fine) is running
more transactions per second, but has lower blocks written and read per
second than the new server:
[JS] That, to me, suggests that the difference might be in the way the systems
themselves are configured. Unfortunately, I
Hi Guys,
Having delved a little more into the capabilities of iostat, I've
discovered that the drive bandwidth seems to be maxed out while MySQL is
running, which I'd peg as the primary candidate for the problem.
Looks like I'll be having more words with my hosting company about
this...
Thanks
Having delved a little more into the capabilities of iostat, I've
discovered that the drive bandwidth seems to be maxed out while MySQL is
running, which I'd peg as the primary candidate for the problem.
[JS] That suggests even more strongly that there is a difference in the kernel
configuration.
Hi Jerry,
It could be a kernel issue; however, currently I'm suspecting that the
drive in the new server simply doesn't have the same bandwidth
capability. The iostat results I'm getting (although I'm not an expert
in reading them, having only learned of it about 3 hours ago) suggest
that the
On Fri, June 13, 2008 08:26, Ian Simpson wrote:
Hi Jerry,
It could be a kernel issue; however, currently I'm suspecting that the
drive in the new server simply doesn't have the same bandwidth
capability. The iostat results I'm getting (although I'm not an expert
in reading them, having only
That's pretty much what I've been doing to get that the drive is running
at 100% bandwidth.
What I'd like is something that just gives the bandwidth of the device
in terms of Mb/s: you can probably work it out using that iostat
command, seeing how much it wrote and what percentage of the
13 matches
Mail list logo
