まとまりのないブログ

something which something is something

mysql sql

マシンスペックとデータベースのパフォーマンスの関係

投稿日:

マシンが高性能であればあるほど良いに越したことはないが、データベースソフトウェアのパフォーマンスにおいてはマシンの高性能化はあまり意味があるとはいえない。データベースのパフォーマンスを向上させるためには、データベースのテーブルの設計とそれに合わせたsql文のチューニング、そしてデータベースソフトウェア自体のチューニングがほとんどを占める。マシンスペックをあげても、たとえばcpuの処理の能力とメモリ容量を倍にしたとしても、パフォーマンス面ではその投資分の効果は得られない。 例えばメモリを増強すると同時接続やキャッシュなどのサイズを大きく取ることができる。cpuの処理速度はどうかというと、一回のsql文を実行した速度では、高スペックマシンと低スペックマシンではさほど差が表れなかった。試してみたところ、cpuがppc200Mhzでメモリ64MBの玄箱と、cpuがクアッドコア2.1Ghzでメモリ2GBのサーバーマシンでmysqlを使って速度比較をしたてみたら、sqlのselect文の実行にかかる時間は両者ほとんど変わらなかった。

玄箱でjavaを動かすことは現実的ではないが、mysqlなどデータベース専用マシンとしては十分な性能を発揮できることがわかった。マシン稼動音の静音性や省スペース、電力といった点からも優秀であると思う。(ただし、各種ソフトウェアをインストールする際のコンパイル作業は非常に時間がかかる。その時ばかりは高スペックマシンに乗り換えたくなる。)

その後

別のそこそこ高スペックマシン(P3の1Ghz*2、メモリ1.5GB)で速度比較をしてみたところ、やはりというか玄箱とは比較にならない程のパフォーマンス面での向上が見られた。一回のselect文を実行するのであれば、高スペックマシンも玄箱でもそれほど大差はない。しかし、それが100回や1000回での実行ではどうかということになると厳として差が明確になる。特に1000回のinsert文を実行するというようなケースの場合は処理を終えるのに高スペックマシンの3~4倍以上の時間を要することがわかった。

結論としては、玄箱はDB専用マシンとしての運用も難しいと言える。やはりapacheのみかftpのみといったファイルサーバ用途しか無理だろうというはじめからわかりきっていた答えに行き着いた。とは言っても、1秒間に200~300回ものsqlを実行するという処理はシステム的に高負荷すぎると思うし玄箱でやろうとするのは間違っていると思う。そこまで負荷はかからないシステムであれば、玄箱でも十分すぎるパフォーマンスを発揮することは可能だと思う。

追記

データベースのパフォーマンスにcpuやメモリはあまり関係ないが、補助記憶装置の性能はかなり関係するということがわかった。つまり、HDDの性能のこと。読み書きの速度が速い補助記憶装置を使うことで、データベースのパフォーマンスは劇的に向上する。補助記憶装置の性能を上げる方法としては、単純にHDDの回転数が高くて高速な読み書きをするものを使うか、RAID0で構成することで速度を上げるか、あるいは多少お金がかかってもいいならばSSDを使うことで読み書きの速度上げるか。個人的なオススメはSSDを使ってパフォーマンスアップをするのがいいと思う。

-mysql, sql

執筆者:


comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

関連記事

no image

mysqlのテーブルのクラッシュ

/usr/local/mysql/bin/myisamchk –recover –force –sort_buffer_size=2048M /usr/local/mysql/data/auc/ …

no image

DELL PowerEdge T105 のDebianのメモリが1GBしか認識しない

DELL PowerEdge T105にLinux のDebianをインストールしてから大分経過したが、今頃になってメモリが2GB搭載しているはずなのに1GBしか認識されていないことに気づいた。 cd …

no image

sqlインジェクション

ns.km22518.keymachine.de – – [19/Jul/2008:22:25:12 +0900] “GET /wordpress/index.php?cat=%27+UNION+SE …

no image

Wrong bytesec: 49-48-48 at linkstart: 14313808772

またテーブルのクラッシュ。mysqlのテーブルがクラッシュする頻度が激増してきた。以前はこんなことなかったのだが・・・。今は一日一回発生して絶えず見張っていなければならないという状態になってしまってい …

no image

mroongaよりsennaの方が検索速度が速い場合がある

DBのレコード件数1800~2000万件程度のテーブルで全文検索した場合に、mroongaを使って検索した時にやたら時間がかかった。大体3秒~10秒ほどselect count(*)を実行するのにかか …