高性能MySQL 4th Nnwww 読書ログ 第4章 Operating System and Hardware Optimization
流れとしては本を追うが、正確な翻訳は目的ではないので必要な部分だけ抜粋、補足も付ける
あとで構造化する
Network Cofiguration
レイテンシとスループットがハードドライブの制限要因であるのと同様に、レイテンシと帯域幅がネットワーク接続の制限要因です。ほとんどのアプリケーションにとって最大の問題はレイテンシです。一般的なアプリケーションでは小さなネットワーク転送が大量に行われ、わずかな遅延が転送ごとに加えられます。
制限要因(limiting factor): ある事象や現象、働きが複数の要素の影響で起こる場合に、その全体の働き方を決める要素のこと
正常に動作していないネットワークも、パフォーマンスの大きなボトルネックになります。パケット損失はよくある問題です。1%の損失でも、重大なパフォーマンス低下を引き起こすのに十分です。これは、プロトコルスタックのさまざまなレイヤがしばらく待ってからパケットを再送信するなどの方法で問題を修正しようと試みることで、余分な時間が追加されるためです。もう1つのよくある問題は、DNS解決が壊れているか遅いことです。
DNSは、本番サーバでskip_name_resolveを有効にしたほうがいい程度には急所足りえます。DNS解決が壊れたり遅いことは、多くのアプリケーションにとって問題ですが、MySQLにとっては特に深刻です。MySQLは接続要求を受信すると、正引きと逆引き両方のDNSルックアップを行います。これが失敗する理由はたくさんあります。失敗すると、接続が拒否され、サーバへの接続プロセスが遅くなり、DoS攻撃を含む大混乱を引き起こします。skip_name_resolveオプションを有効にすると、MySQLはDNSルックアップをまったく行いません。ただし、これはユーザーアカウントがhost列にIPアドレス、"localhost"またはIPアドレスのワイルドカードのみを持つ必要があることも意味します。host列にホスト名を持つユーザーアカウントはログインできません。
しかし、多くの接続や小さなクエリを効率的に処理するために設定を調整することの方が、通常はより重要です。最も一般的な微調整の1つは、ローカルポート範囲を変更することです。Linuxシステムには使用できるローカルポートの範囲が決まっています。接続が呼び出し元に戻すときは、ローカルポートが使用されます。同時に多くの接続がある場合は、ローカルポートが不足する可能性があります。
(訳注:) エフェメラルポートという名前のが通りが良い気がする
デフォルト値に設定されているシステムを次に示します。
code:shell
$ cat /proc/sys/net/ipv4/ip_local_port_range
32768 61000
TCPプロトコルはシステムにやってきたコネクションをバケットのようにキューに入れることができます。バケットがいっぱいになると、クライアントは接続できなくなります。次のようにすると、より多くの接続をキューに入れることができます。
code:shell
$ echo 4096 > /proc/sys/net/ipv4/tcp_max_syn_backlog
内部でのみ使われるデータベースサーバの場合は、ピアがおかしくなってコネクションの片側が閉じない場合にソケットを閉じた後に発生するタイムアウトを短縮できます。ほとんどのシステムでは、デフォルトは1分です。これはかなり長い時間です。
TIME_WAITのことです
code:sh
$ echo <value> > /proc/sys/net/ipv4/tcp_fin_timeout
ほとんどの場合、これらの設定はデフォルトのままにしておくことができます。通常、これらの設定を変更する必要があるのは、ネットワークパフォーマンスが極端に低下している場合や接続数が非常に多い場合など、異常が発生したときだけです。インターネットで"TCP variables"を検索すると、これらの変数やさらに多くの変数について多くの優れた情報が見つかります。
Choosing a Filesystem
ファイルシステムの選択は、オペレーティングシステムに大きく依存しています。Windowsのような多くのシステムでは、実際には1つか2つの選択肢しかなく、1つ(NTFS)だけが実際に実行可能です。一方、GNU/Linuxは多くのファイルシステムをサポートしています。
多くの人が、GNU/Linux上のMySQLで最高のパフォーマンスを提供するファイルシステムを知りたいと思っていますし、さらに具体的には、InnoDBではどのファイルシステムが最高のパフォーマンスを提供するかを知りたいと思っています。ベンチマークは実際に、それらのほとんどがほとんどの点で非常に近いことを示していますが、パフォーマンス向上のためにファイルシステムに注目することはとてもいい気分転換になります(looking to the filesystem for performance is really a distraction)。ファイルシステムのパフォーマンスは極めてワークロード次第であり、特効薬となるファイルシステムはありません。ほとんどの場合、特定のファイルシステムが他のどのファイルシステムよりもパフォーマンスが大幅に良くも悪くもなりません。例外は、並行処理の方法、多数のファイルを処理する方法、断片化など、ファイルシステムの制限に遭遇した場合です。
(訳注:) 不可算名詞のdistractionは「気が散る」「注意散漫」「動揺」「乱心」などの悪い意味だが、可算名詞だと「娯楽」「気晴らし、気分転換なるもの」みたいなポジティブ?な意味合いになるそうです
全体的に見て、ext4やXFS、ZFSなどのジャーナリングファイルシステムを使うのが一番です。そうしないと、クラッシュ後のファイルシステムチェックに長い時間がかかることがあります。
ext3またはその後継であるext4を使用する場合、データのジャーナル処理には3つのオプションがあり、/etc/fstabマウントオプションで設定することができます。
data=writeback
このオプションは、メタデータ書込みのみがジャーナル処理されることを意味します。メタデータへの書込みはデータ書込みと同期されません。これは最速の構成であり、InnoDBには独自のトランザクションログがあるため、通常は安全に使用できます。例外は、8.0より前のバージョンのMySQLにおいて、特定のタイミングでクラッシュすると.frmファイルが破損する可能性があることです。
次に、この設定がどのように問題を引き起こすかを示す例を示します。プログラムがファイルを拡張してサイズを大きくすることを決定したとします。メタデータ(ファイルのサイズ)は、データが実際に(大きくなった)ファイルに書き込まれる前に記録されます。その結果、ファイルの末尾の新しく拡張された領域にゴミが含まれます。
data=ordered
このオプションもメタデータのみをジャーナルしますが、メタデータの前にデータを書き込むことで一貫性を提供します。これはwritebackオプションよりもわずかに遅いだけで、クラッシュ時にはずっと安全です。この設定では、プログラムがファイルを拡張しようとする場合、新しく拡張された領域に存在するデータが書き込まれるまで、ファイルのメタデータはファイルの新しいサイズを反映しません。
data=journal
このオプションは、最終的な場所に書き込まれる前にデータをジャーナルに書き込むというアトミックでジャーナル化された動作を提供します。通常、このオプションは不要であり、他の2つのオプションよりもオーバーヘッドが非常に高くなります。ただし、ジャーナル処理によってファイルシステムがデータの最終的な場所への書き込みを遅延させるため、パフォーマンスが向上する場合もあります。
ファイルシステムに関係なく、無効にした方が良い特定のオプションがいくつかあります。なぜなら、それらは何のメリットもなく、かなりのオーバーヘッドを加える可能性があるからです。最も有名なのはアクセス時間を記録することです。これはファイルやディレクトリを読んでいるときでも書き込みを必要とします。このオプションを無効にするには、noatime, nodiratime mountオプションを/etc/fstabに追加します。これはワークロードやファイルシステムによりますがパフォーマンスを5%から10%向上させることができます(上述の場合以外には大きな違いはありませんが)。ここに、前述したext3の/etc/fstab行の例を示します。
code:shell
/dev/sda2 /usr/lib/mysql ext3 noatime,nodiratime,data=writeback 0 1
ファイルシステムの先読み動作を調整することもできます。これは、ファイルシステムが冗長になる可能性があるためです。例えば、InnoDBは独自の先読み予測を行います。先読みを無効にしたり制限したりすることは、SolarisのUFSでは特に有益です。innodb_flush_method=O_DIRECTを使用すると、先読みは自動的に無効になります。
あなたが欲しい機能をサポートしていないファイルシステムもあるかもしれません。例えば、direct I/O のサポートは、InnoDBに対してO_DIRECTを使用している場合に重要です。また、ファイルシステムによっては、多数のディスクを他よりもうまく処理できるものもあります。例えば、XFSはext3よりもはるかに優れていることがしばしばあります。最後に、Logical Volume Manager(LVM)スナップショットを使用してレプリカの初期化やバックアップを行う場合は、選択したファイルシステムとLVMバージョンが適切に動作することを確認する必要があります。
表4-2: 一般的なファイルシステムの特徴をまとめたものです。
通常はXFSファイルシステムを使用することをお勧めします。ext3ファイルシステムには、inodeごとにmutexが1つしかないなどの深刻な制限や、fsync()すると1つのファイルのダーティブロックではなくファイルシステム全体のダーティブロックをフラッシュするなどの素行不良があまりにも多くあります。ext4ファイルシステムを選択しても問題はありませんが、特定のカーネルバージョンではパフォーマンス上のボトルネックがあるため、コミットする前に調査する必要があります。
データベース用のファイルシステムを検討する際には、そのファイルシステムが利用可能になってからの年数、成熟度、本番環境での実績などを考慮することをお勧めします。ファイルシステムは、データベース内のデータ整合性の最も低いレイヤです。(The filesystem bits are the very lowest level of data integrity you have in a database.)
Choosing a Disk Queue Scheduler
GNU/Linuxでは、キュースケジューラはブロックデバイスへのリクエストが実際に最下層のデバイスに送信される順序を決定します。デフォルトはCompletely Fair Queuing(cfq)です。ラップトップやデスクトップではI/O不足を防ぐために気軽に使うことはできますが、サーバーにとってはひどいものです。MySQLが生成するような種類のワークロードでは、キュー内の一部のリクエストを不必要にストールするため、レスポンスタイムが非常に悪くなります。
次のコマンドで、使用可能なスケジューラとアクティブなスケジューラを確認できます。
code:shell
$ cat /sys/block/sda/queue/scheduler
sdaはあなたの好きなディスクデバイス名に置き換えてください。この例では、角括弧はこのデバイスで使用されているスケジューラを示しています。他の2つの選択肢はサーバクラスのハードウェアに適しており、ほとんどの場合同じように機能します。noopスケジューラは、ハードウェアRAIDコントローラやストレージエリアネットワーク(SAN)など、バックグラウンドで独自のスケジューリングを行うデバイスに適しています。また、RAIDコントローラと直接接続されたディスクの両方に問題ありません。私たちのベンチマークでは、これら2つの間にほとんど違いはありません。重要なことは、重大なパフォーマンス問題を引き起こす可能性のあるcfq以外のものを使用することです。
Memory and Swapping
MySQLは、大量のメモリが割り当てられている場合に最もパフォーマンスが高くなります。第1章で学んだように、InnoDBはディスクアクセスを回避するためにメモリをキャッシュとして使用します。これは、メモリシステムのパフォーマンスがクエリの処理速度に直接的な影響を与える可能性があることを意味します。今日でも、より高速なメモリアクセスを保証する最善の方法の1つは、組み込みのメモリアロケータ(glibc)をtcmallocやjemallocなどの外部のものに置き換えることです。多くのベンチマーク2で、glibcと比較した場合、これらの両方でパフォーマンスが向上し、メモリフラグメンテーションが減少することが示されています。
スワップは、オペレーティングシステムが仮想メモリを保持するのに十分な物理メモリがないために仮想メモリーをディスクに書き込むときに発生します。スワップは、オペレーティングシステム上で実行されているプロセスに対して透過的に行われます。オペレーティングシステムのみが、特定の仮想メモリアドレスが物理メモリ内にあるかディスク上にあるかを認識します。
SSDを使用する場合、パフォーマンスの低下はHDDのころほど急激ではありません。それでもなお、ディスクの最終的な寿命を短くする可能性のある不要な書き込みを避けるために、スワップは積極的に避けるべきです。また、スワップを使用しない方法を検討することもできます。スワップを使用しない方法では、(パフォーマンスが落ちる)潜在的な可能性は完全になくなりますが、メモリ不足によってプロセスが終了する可能性がある状況に置かれます。
GNU/Linuxでは、vmstatでスワップを監視することができます(次節でいくつかの例を示します)。 swpd 列で報告されているスワップの使用状況よりも、si 列と so 列で報告されているスワップI/Oのアクティビティを確認する必要があります。swpd 列では、スワップ領域をうめているのに使用されていないプロセスを表示できますが、実際には問題になりません。(The swpd column can show processes that have been loaded but aren’t being used, which are not really problematic.) si 列と so 列の値を0にするのが好ましく、必ず毎秒10ブロックより小さく抑えるべきです。
極端な場合には、メモリのアロケーションが多すぎると、オペレーティングシステムのスワップ領域が不足する可能性があります。これが発生すると、仮想メモリが不足してMySQLがクラッシュする可能性があります。しかし、スワップ領域が不足していなくても、非常にアクティブなスワッピングによってオペレーティングシステム全体が応答不能になり、ログインしてMySQLプロセスを強制終了することさえできなくなる可能性があります。Linuxカーネルは、スワップ領域が不足すると完全にハングすることさえあります。データベースはスワップ領域をまったく使用せずに実行することをお勧めします。ディスクは依然としてRAMよりもはるかに遅いので、ここで述べた頭痛の種をすべて避けることができます。
極端な仮想メモリプレッシャーの下で頻繁に発生するもう1つのことは、メモリ不足(OOM)キラープロセスが起動して何かを殺すことです。これはMySQLであることが多いが、SSHのような別のプロセスでもあり、ネットワークからアクセスできないシステムを残す可能性がある。これを防ぐには、SSHプロセスのoom_adj または oom_score_adj 値を設定します。専用データベースサーバで作業する場合は、MySQLやSSHなどの主要なプロセスを特定し、OOMキラースコアを事前に調整して、それらが最初に終了対象として選択されないようにすることを強くお勧めします。
ほとんどのスワップにおける問題はMySQLバッファを正しく設定することで解決できますが、オペレーティングシステムの仮想メモリシステムがMySQLをスワップすることを決定する場合もあります。これはLinuxでのNUMA(nonuniform memory access)の動作3に関連しています。これは通常、オペレーティングシステムがMySQLからの大量のI/Oを認識し、かつより多くのデータを保持するためにファイルキャッシュを増やそうとするときに発生します。メモリが不足している場合はスワップアウトする必要がありますが、それはMySQL自体である可能性があります。古いLinuxカーネルバージョンの中には、スワップすべきでない時にスワップするという非生産的な優先順位を持つものもありますが、最近のカーネルでは少し緩和されました。
オペレーティングシステムでは通常、仮想メモリとI/Oをある程度制御することができます。GNU/Linuxでそれらを制御するいくつかの方法を紹介します。最も基本的な方法は、/proc/sys/vm/swappinessの値を0や1などの低い値に変更することです。これにより、仮想メモリが極端に必要でない限りカーネルはスワップしないように指示されます。例えば、現在の値をチェックする方法を以下に示します。
code: sh
$ cat /proc/sys/vm/swappiness
60
表示されている値60は、デフォルトのスワップ設定です(範囲は0~100)。これはサーバーには非常に悪いデフォルトです。ラップトップにのみ適しています。サーバーは0に設定してください:
code:sh
$ echo 0 > /proc/sys/vm/swappiness
もう1つのオプションは、ストレージエンジンによるデータの読取りおよび書込み方法を変更することです。たとえば、innodb_flush_method=O_DIRECTを使用すると、I/Oの負荷が軽減されます。Direct I/Oはキャッシュされないため、オペレーティングシステムはファイルキャッシュのサイズを増やす理由として認識しません。このパラメータはInnoDBに対してのみ有効です。
もう1つの選択肢は、MySQLをメモリ内でロックするMySQLのmemlock設定オプションを使用することです。これはスワップを回避しますが、危険な場合があります:ロック可能なメモリが十分に残っていない場合、MySQLより多くのメモリを割り当てようとしてクラッシュする可能性があります。ロックされているメモリが多すぎてオペレーティングシステムに十分なメモリが残っていない場合にも問題が発生する可能性があります。
トリックの多くはカーネルのバージョンに固有のものなので、特にアップグレードするときは注意してください。ワークロードによっては、オペレーティングシステムを適切に動作させることが困難な場合があり、バッファーサイズを最適以下の値に下げることが唯一の手段となる場合もあります。
Operating System Status
オペレーティングシステムには、オペレーティングシステムとハードウェアが何を実行しているかを調べるためのツールが用意されています。このセクションでは、広く利用されているiostatとvmstatの2つのツールの使用例を紹介します。システムがこれらのツールのどちらも提供していない場合は、おそらく同じようなツールが提供されるでしょう。したがって、iostatやvmstatの使い方の専門家になることではなく、これらのツールを使用して問題を診断しようとするときに何を探せばよいかを示すことが目的です。
これらのツールに加えて、オペレーティングシステムがmpstatやsarなどのツールを提供している場合もあります。ネットワークなどのシステムの他の部分に興味がある場合は、ifconfig(ネットワークエラーの数などを表示します)やnetstatなどのツールを代わりに使うとよいでしょう。
デフォルトでは、vmstatとiostatは、サーバが起動してからのさまざまなカウンタの平均値を示す1つのレポートしか生成しません。これはあまり有用ではありません。しかし、両方のツールにinterval引数を与えることができます。これにより、サーバが現在何を行っているかを示すインクリメンタルレポートが生成されます。(最初の行はシステムが起動してからの統計を示しています。この行は無視してもかまいません)。
How to read vmstat output
最初にvmstatの例を見てみましょう。新しいレポートを5秒ごとに出力するには、次のコマンドを使用します。レポートサイズはメガバイト単位です。
code: sh
$ vmstat -SM 5
procs -------memory------- -swap- -----io---- ---system---- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
11 0 0 2410 4 57223 0 0 9902 35594 122585 150834 10 3 85 1 0
10 2 0 2361 4 57273 0 0 23998 35391 124187 149530 11 3 84 2 0
vmstatを停止するには、Ctrl-Cキーを押します。表示される出力はオペレーティング・システムによって異なります。そのため、マニュアル・ページを読む必要があるかもしれません。
前述したように、インクリメンタルな出力を要求しましたが、値の最初の行はサーバーがブートされてからの平均を示します。2番目の行は現在何が起きているかを示し、後続の行は5秒間隔で何が起きているかを示します。列は次のいずれかのヘッダーでグループ化されます。
procs
r列には、CPU時間を待機しているプロセスの数が表示されます。b列には、割り込み不能(uninterruptible)なスリープ状態にあるプロセスの数が表示されます。これは、一般的にI/O(ディスク、ネットワーク、ユーザー入力など)を待機していることを意味します。
memory
swpd列には、ディスクにスワップアウトされた(ページングされた)ブロック数が表示されます。残りの3つの列には、空き(未使用)ブロック数、バッファに使われている(buff)ブロック数、オペレーティングシステムのキャッシュに使用されているブロック数を示します。
swap
これらの列には、スワップアクティビティが表示されます。つまり、オペレーティングシステムが(ディスクから)スワップインおよび(ディスクへ)スワップアウトしている1秒あたりのブロック数が表示されます。これらの列は、swpd列よりも非常に重要です。ほとんどの場合、siとsoが0と表示されることを望んでおり、1秒あたり10ブロック以上表示されることは絶対に望ましくありません。バーストもよくありません。
io
これらの列は、(bi)ブロック・デバイスから読み込まれ、(bo)ブロック・デバイスに書き込まれる1秒当たりのブロック数を示します。これは通常、ディスクI/Oを反映しています。
system
これらの列には、1秒あたりの割り込み数(in)と1秒あたりのコンテキストスイッチ数(cs)が表示されます。
cpu
これらの列には、ユーザー(非カーネル)コードの実行、システム(カーネル)コードの実行、アイドル状態、およびI/Oの待機に費やされた合計CPU時間の割合が表示されます。5番目の列(st)には、仮想化を使用している場合に仮想マシンから「盗まれた(stolen)」割合が表示されます。これは、仮想マシン上で何かが実行可能であったが、ハイパーバイザが代わりに他の何かを実行することを選択した時間を指します。仮想マシンが何も実行する必要がなく、ハイパーバイザが他の何かを実行する場合は、盗まれた時間としてカウントされません。
vmstatの出力はシステムによって異なりますので、上記のサンプルと異なる場合は、あなたのシステムのvmstat(8)のmanページを読んでください。
How to read iostat output
iostatに移りましょう。デフォルトでは、vmstatと同じCPU使用率情報が表示されます。ただし、通常はI/O統計のみに注目しますので、次のコマンドを使用して拡張されたデバイスの統計情報のみを表示します。
code: sh
$ iostat -dxk 5
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s
sda 0.00 0.00 1060.40 3915.00 8483.20 42395.20
avgrq-sz avgqu-sz await r_await w_await svctm %util
20.45 3.68 0.74 0.57 0.78 0.20 98.22
vmstatと同様に、最初のレポートにはサーバが起動されてからの平均が表示されます(スペースを節約するために通常は省略しています)。その後のレポートには平均が表示されていきます。1デバイスにつき1行が表示されます。
列を表示または非表示にするさまざまなオプションがあります。公式ドキュメントは少し混乱しているので、実際に何が表示されているのかを理解するためにソースコードを掘り下げる必要がありました。各列が表示している内容を以下に示します。
rrqm/s and wrqm/s
1秒間にキューに入れられた、読取りおよび書込みリクエストのうち、マージされた数。マージとは、オペレーティングシステムがキューから複数の論理リクエストを取得し、それらを実際のデバイスに対する1つのリクエストにグループ化したことを意味します。
r/s and w/s
1秒間にデバイスに送信された読取りリクエストおよび書込みリクエストの数。
rkB/s and wkB/s
1秒あたりの読み取りおよび書き込みのキロバイト数。
avgrq-sz
セクタ単位のリクエストサイズ。
avgqu-sz
デバイスのキューで待機しているリクエスト数。
await
ディスクキュー内で消費されたミリ秒数。
r_await and w_await
処理対象のデバイスに対して発行されたリクエストの平均時間(ミリ秒)。読取りと書込みの両方があります。これには、リクエストがキュー内で待機している時間と、リクエストの処理に費やされた時間が含まれます。
svctm
リクエストの処理に費やされたミリ秒数(キュー時間を除く)。
%util
少なくとも1つのリクエストがアクティブであった時間の割合。これは非常に紛らわしい名前です。待ち行列理論における利用率の標準的な定義を知っているなら、これがデバイスの利用率ではないとわかるはずです。複数のハードドライブ(RAIDコントローラなど)を持つデバイスは、1より高い平行性をサポートできるはずですが、計算に使用される数値に丸め誤差がない限り、%utilが100%を超えることはありません。結果として、単一の物理ハードドライブを参照している特別な場合を除き、ドキュメントに記載されている内容とは異なり、デバイスの飽和を示す適切な指標ではありません。
この出力を使用して、マシンの入出力サブシステムに関するいくつかの事実を推測できます。重要なメトリックの1つは、同時に処理されたリクエスト数です。読取りおよび書込みは1秒当たりで、サービス時間の単位は1秒の1000分の1であるため、リトルの法則(Little’s law)を使用して、デバイスが処理している同時リクエスト数に対する次の式を導出できます。
concurrency = (r/s + w/s) * (svctm/1000)
(訳注:)リトルの法則とは、安定な系において長時間平均化した顧客数 L (与えられた負荷、offered load)は、長時間平均化した到着率λと、長時間平均化した顧客が系に費やす時間 W の積に等しい、すなわち L = λW という法則。
安定した系ではバーストなどではなく流量が一定の状態なので、到着率 λ はカウンターに行く割合、店を出る割合に等しいとしてよいらしい。ここではそれをリクエストの処理速度とみなしている。
この長時間平均化した顧客数 L を、ここでは処理中の同時リクエスト数とみなしている。
先述のサンプル数を平行性の式に代入すると、平行性は約0.995になります。これは、平均して、デバイスがサンプリング間隔中に一度に処理したリクエストが1つ未満であることを意味します。
Other Helpful Tools
mpstatはCPUの統計を監視するのにも便利です。これはCPUをグループ化するのではなく、個々のCPUがどのように動作しているかをより良く知ることができます。これは問題を診断するときに非常に重要な場合があります。blktraceはディスクI/Oの使用状況を調べるときにも役立つかもしれません。
Perconaは、pt-diskstatsと呼ばれるiostatに代わるものを独自に開発しました。これはPercona Toolkitの一部です。読み取りと書き込みを集約して表示する方法や、平行性に対する可視性の欠如などの、iostatに関するいくつかの不満に対応しています。また、インタラクティブでキーストローク駆動なので、ズームインとズームアウト、集約の設定変更、デバイスのフィルタリング、列の表示と非表示の切り替えを行うことができます。これはディスク統計のサンプルを様々な観点から分析する優れた方法であり、ツールがインストールされていなくても簡単なシェルスクリプトで収集することができます。ディスクアクティビティのサンプルをキャプチャして電子メールで送信したり、後で分析するために保存したりすることができます。
最後に、Linuxプロファイラであるperfは、オペレーティングシステムレベルで何が起きているかを調べるための貴重なツールです。perfを使用して、カーネルがCPUを大量に使用している理由など、オペレーティングシステムに関する一般的な情報を調べることができます。また、特定のプロセスIDを調べることもでき、MySQLがオペレーティングシステムとどのように相互作用しているかを調べることができます。システムパフォーマンスの調査は非常に奥深いので、Brendan Gregg(Pearson)によるSystems Performance,Second Editionを優れたフォローアップ資料として推奨します。
Summary
MySQL用にハードウェアを選択して構成し、ハードウェア用にMySQLを構成することは、神秘的な技術ではありません。一般的に、他の多くの目的に必要なものと同じスキルと知識が必要です。ただし、MySQL固有の注意事項がいくつかあります。
私たちが一般的に提案していることは、パフォーマンスとコストのバランスを取ることです。第1に、私たちはさまざまな理由から、市販のサーバを使用しています。たとえば、サーバに問題があり、メンテナンス中にサービスを停止する必要がある場合や、単にメンテナンスの手段として別のサーバとスワップしたい場合は、50,000ドル以上のサーバよりも5,000ドルのサーバを使用した方がはるかに楽です。また一般的にMySQLは、ソフトウェア自体の観点からも、実行される一般的なワークロードの観点からも、市販のハードウェアに適しています。
MySQLが必要とする4つの基本的なリソースは、CPU、メモリ、ディスク、およびネットワークリソースです。ネットワークはそれほど頻繁に深刻なボトルネックとして現れる傾向はありませんが、CPU、メモリ、およびディスクは確かに深刻なボトルネックとして現れます。速度と機材数のバランスは実際にはワークロードによります。予算が許す限り、速さと機材の多さのバランスを取るように努力すべきです。並行性が高いほど、ワークロードに対応するためにより多くのCPUを使用する必要があります。
CPU、メモリ、ディスク間の関係は複雑であり、ある領域の問題が別の場所に現れることがよくあります。問題にリソースを投入する前に、リソースを別の問題に投入すべきかどうかを考えてください。I/Oバウンドの場合、I/Oのキャパシティを増やす必要がありますか、それとも単にメモリを増やすだけですか?その答えはワーキングセットのサイズによって定まります。ワーキングセットとは、特定の期間に最も頻繁に必要とされるデータのセットです。
(訳注:)ワーキングセットとは、仮想メモリが運用されているOS上で、実行中のプログラムがある時点で使用しているメモリページの集合のこと。
ソリッドステートデバイスは、サーバのパフォーマンス全体を向上させるのに適しており、現在では一般的にデータベース、特にOLTPワークロードの標準になるはずです。HDDを使用し続ける唯一の理由は、予算が非常に限られたシステムや、データウェアハウスのシチュエーションでペタバイト級の膨大なディスク容量が必要なシステムにあります。
オペレーティングシステムに関しては、正しく理解する必要がある重要なものがいくつかありますが、そのほとんどはストレージ、ネットワーキング、仮想メモリ管理に関連しています。GNU/Linuxを使用している場合は、ほとんどのMySQLユーザーが使用しているように、XFSファイルシステムを使用して、スワップとディスクキュースケジューラをサーバに適した値に設定することをお勧めします。変更が必要なネットワークパラメータや、その他の多くのこと(SELinuxを無効にするなど)を調整したいと思うかもしれませんが、これらの変更は好みの問題です。