自己紹介
|
|
Sakila (MySQL イルカ) 写真集
Navigation
MySQLはLinuxよりもSolarisで動かした方が速い？
06.08.2009 | 0 投稿されたコメント
MySQL は元々 Linux 上でよく利用されていましたが、Sun に買収されてから、チューニングやスケールアウト/アップの方法がいろいろと検討されてきています。社内でも、OS の機能を使ったり、ストレージと組み合わせたりして検証が行われていますが、次期 5.4 のリリースでは Solaris 上での性能が飛躍的に向上するようです。
MySQL 5.4 は性能向上を主な目的とした初のリリースとらしいです。具体的には、
InnoDB において、
・16-way のスケールアップ (x86 サーバ)
・64-way のスケールアップ (CMT サーバ)
・特定のクエリにおいては 90% のレスポンスタイム向上
ということだそうです。
特に CMT サーバの方は 64-way まできれいにスケールアップしているのが以下のブログで確認できます。
MySQL 5.4 Scalability on 64-way CMT Servers
http://blogs.sun.com/allanp/entry/mysql_5_4_scalability_on
一方で MySQL は Solaris 上で動かすのが良いのか、Linux の方が相性が良いのか、という質問をよく受けます。実績では Linux だと思いますが、性能面ではどうなのか、、、今回はとある事情で Solaris の方が優れている、という情報を集めることになりましたので、それをメモしておきたいと思います。
まずはじめは 2006 年の結果ですので、少し情報の鮮度は落ちますが、同一サーバ、MySQL 5.0 の同じ設定で、OS を Red Hat Linux Advanced Server 4 と Solaris 10 で比較したベンチマークが公開されています。
詳細はこのプレスリリースとこちらの詳細結果 (PDF) に書かれていますが、
ハードウェア
・Sun Fire V40z: 4CPU (Dual Core AMD Opteron Model 875)
MySQL
・MySQL 5.0.18
こういう構成で比較したところ、両 OS とも、最もパフォーマンスが出た同時ユーザコネクション数は 8 で、その際、Solaris は Linux よりも 30% 速かったそうです。
さらに、read-only テストでは、91% のテストケースで Solaris が Linux を上回り、性能のピークは Solaris が 16 同時ユーザコネクションだったのに対し、Linux は 8 同時ユーザコネクションで、秒間あたりのトランザクション数は Solaris が Linux を53% も上回ったそうです。
次の情報は、MySQL 5.4 での比較です。
5.4 での比較は先ほどのブログに記載されています。
5.4 では Solaris 上での性能向上にスポットが当たっていることもあって、Solaris にとってかなり良い結果が出ています。このベンチでの特長を２つほど。
１つは、"Read Only Test" であっても "Read Write Test" であっても、全体的に On Solaris が On Linux を上回っているということです。特に "Read Only Test" については On Solaris が スレッド数に関わらず高い性能を発揮しています。
もう１つは、On Solaris ではスレッド数を増やしても性能が劣化せず（On Linux では 32 スレッド前後を境に性能が大きく劣化して行く）安定しているというところです。
MySQL 5.4 での性能向上は Google SMP パッチ や Google IO パッチ によって実現されています。この辺りの詳細は以下の Webinar や製品マニュアルの中に記載されています。
MySQL 5.4 Benchmarks In-Depth
http://www.mysql.com/news-and-events/on-demand-webinars/display-od-343.html"
またこの "性能向上" は MySQL 5.1 にフィードバックされるらしいです。
MySQL + ソリューションセミナ Feb'09
02.17.2009 | 0 投稿されたコメント
気が付けばもうあさってですが、2 月 19 日 (木) にサンの神宮前オフィスにて "MySQL + ソリューションセミナー" を開催します。今回は、技術的に深い内容、というわけではなく、MySQL(Sun) が提供する製品、ライセンス、サービスの概要、及び MySQL Enterprise Monitor のご紹介が中心です。非技術者の方でも理解しやすい内容になっておりますので、ご興味がありましたら是非お越し下さい。
開催日時：2009年02月19日（木）
開催場所：サン・マイクロシステムズ株式会社 神宮前オフィス（Googleマップ）
費用：無料（事前登録制）
前半が MySQL のご紹介で、後半は Glassfish のご紹介 by 寺田さんの２部構成になっています。
公式イベントページはこちら。MySQLのレプリケーションは同期か非同期か...それとも？
11.26.2008 | 0 投稿されたコメント
MySQL にはレプリケーション機能が付いています。非常に多くの導入事例があり、mixi のような大規模サイトでも使われています。単に、マスタ・スレーブの関係だけではなく、マルチマスタの構成も可能です。
...そんなことはもう知ってる、と言われるかもしれません。嬉しいのか悲しいのかわかりませんが、MySQL は Sun の社員よりも社外のかたの方が詳しいこともあります; ではレプリケーションは同期処理なのか非同期処理なのかご存知でしょうか？「レプリケーション」という言葉のイメージから想像できるかもしれませんが答えは「非同期」です。
詳しい説明は「MySQL 5.1 リファレンスマニュアル 5.5.1. レプリケーション実装の詳細」に記載されていますが、改めて絵でご紹介すると次のようになります。
 | 1. MySQL サーバのマスタに書き込みが行われると、マスタは更新情報を バイナリ ログ (binlog) に書き込みます。 2. スレーブでは I/O スレッドが作成され、マスタに接続要求を投げます。 3. マスタはバイナリログを送信するためにスレッドを作成してスレーブに送信します。 4. スレーブはマスタから受信した情報をリレーログと呼ばれるローカルファイルに書き込みます。(絵の中では「中継 binlog」と表記) 5. 続いてスレーブは SQL スレッドを起動して、リレーログのクエリを実行します。 |
しかし、この方式ではマスタが関与するのは binlog に書き込む所までで、それ以降は知ったこっちゃない、ということになってしまいます。つまり、スレーブが更新情報を取得する前にマスタがダウンするとデータの不整合が起こります。これを解消しようという試みが次のメージャーバージョン 6.0 で追加されます。それが、 半同期レプリケーション (Semisynchronous Replication) です。既に「MySQL 6.0 Reference Manual 16.2.9. Semisynchronous Replication」にその仕組みが記載されています。
If semisynchronous replication is enabled on the master side and there is at least one semisynchronous slave, a thread that performs a transaction commit on the master blocks after the commit is done and waits until at least one semisynchronous slave acknowledges that it has received all events for the transaction, or until a timeout occurs.
マスタは少なくとも１つのスレーブがトランザクションのすべてのイベントを受信するか、もしくはタイムアウトする仕組みだそうです。