On 8/12/2010 2:32 PM, Mike Spreitzer wrote:
I also find that if I have both tables in MyISAM and use STRAIGHT_JOIN to
force the better query plan (enumerate the longer table, for each longer
table row use the shorter table's index to pick out the one right matching
row from the shorter table) t
0.00
0.000.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.000.00 0.00 0.00
Thanks,
Mike Spreitzer
From: Mike Spreitzer/Watson/i...@ibmus
To: Dan Nelson
Cc: MySql
Date: 08/11/2010 01:30 PM
Subject: Re: idle query
I finally started trying to optimize along the memory-based lines you
suggested. I am surprised to find that the query plan is to enumerate the
memory-based table and then pick out the hundreds of related rows from the
much larger MyISAM table. What's going on here?
`show create table` says t
I installed iostat and used it. It showed that my MySQL data is striped
over four devices. During my "idle" query each of those four devices has
about 25% utilization, which is consistent with the hypothesis that this
I/O is the bottleneck. It looks like case closed. I am lo
In the last episode (Jul 27), Dan Nelson said:
> In the last episode (Jul 27), Mike Spreitzer said:
> > If I want to try to actually hold a 2GB table in RAM, is there anything I
> > need to set in my.cnf to enable that?
>
> Just make sure your key_buffer_size is large enough to hold the index. Y
In the last episode (Jul 27), Mike Spreitzer said:
> Does `iostat` consider GPFS mounts at all? If so, how can I tell which
> line of `iostat` output is about the GPFS mounted at /dev/gpfscf ? I do
> not see such a thing mentioned in the iostat output.
iostat works at the disk device level, no
>-Original Message-
>From: Dan Nelson [mailto:dnel...@allantgroup.com]
>Sent: Monday, July 26, 2010 11:31 PM
>To: Mike Spreitzer
>Cc: MySql
>Subject: Re: idle query
>iostat -x output would be helpful here, too, so we can see whether your
>disks are at 100% busy.
&
Does `iostat` consider GPFS mounts at all? If so, how can I tell which
line of `iostat` output is about the GPFS mounted at /dev/gpfscf ? I do
not see such a thing mentioned in the iostat output.
In `vmstat` output, I thought "bi" is in terms of fixed-size blocks, not
I/O commands.
Thanks,
M
In the last episode (Jul 27), Mike Spreitzer said:
> Sure, `wc` is different from mysql --- but different enough to account for
> a 16000:75 ratio?
Most definitely. wc is reading sequentially, and the OS is probably
coalescing those reads and prefetching disk blocks in 128KB chunks.
16*128 i
Sure, `wc` is different from mysql --- but different enough to account for
a 16000:75 ratio?
Will iostat give a good utilization metric for GPFS?
If I want to try to actually hold a 2GB table in RAM, is there anything I
need to set in my.cnf to enable that?
Thanks,
Mike Spreitzer
SMTP: mspre..
In the last episode (Jul 27), Mike Spreitzer said:
> Thanks for the clues. In this case the storage is not on a SATA disk,
> rather is it on a GPFS (
> http://en.wikipedia.org/wiki/IBM_General_Parallel_File_System) mount. This
> thing is capable of quite a lot more I/O bandwidth. I invoked `wc`
Thanks for the clues. In this case the storage is not on a SATA disk,
rather is it on a GPFS (
http://en.wikipedia.org/wiki/IBM_General_Parallel_File_System) mount. This
thing is capable of quite a lot more I/O bandwidth. I invoked `wc` on a
large file and it took the "bi" stat of `vmstat` ove
In the last episode (Jul 26), Mike Spreitzer said:
> A colleague is running MySQL community server 5.1.34 on RHEL 5 on a big
> Xeon-based SMP (16 CPUs, 64 GB memory). It is taking a surprisingly long
> time to execute a query, yet is not working particularly hard at it. I
> wonder why this might
A colleague is running MySQL community server 5.1.34 on RHEL 5 on a big
Xeon-based SMP (16 CPUs, 64 GB memory). It is taking a surprisingly long
time to execute a query, yet is not working particularly hard at it. I
wonder why this might be. Following are details. First, some `vmstat`
outpu
14 matches
Mail list logo
