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.
160000*128 is around 2GB/sec (iostat would tell you your actual throughput).
You probably either have a 2gb fibre-channel card, or else wc is CPU-bound
at this point, counting each character as it streams past. I bet "dd
if=largefile of=/dev/null bs=8k" would give you even more iops. "dd ...
bs=1m" would probably max out your fibre-channel card's bandwidth. None of
those commands are doing random I/Os, though, so you can't compare their
numbers to your mysql query.
> Will iostat give a good utilization metric for GPFS?
For your particular query, yes. You're doing single-threaded random IO, so
you are fetching a random disk block, waiting for the result, then fetching
another random block, etc. 100% of your time should be in iowait, waiting
for a disk head to seek to your data. If it's not at least 80%, then your
query isn't waiting on disk I/O, and since you aren't CPU-bound, I'm not
sure what your bottleneck would be at that point...
> 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. You
can find this number by setting key_buffer_size to a huge number (32GB for
example), running "LOAD INDEX INTO CACHE" for your index, then running "show
status like 'key_blocks_used'; ".
http://dev.mysql.com/doc/refman/5.1/en/load-index.html
--
Dan Nelson
dnelson@stripped
