久しぶりにMySQLを触っていたらイベントログに下記のような警告を多数発見。
どうやらMySQLの起動時かクラインアントからの新規接続をトリガーにしている模様。
-----------------------------------------------------------------------------
アプリケーションログ
ソース:MySQL イベントID:100
Changed limits: max_open_files: 2048 max_connections: 800
table_cache: 619
For more information, see Help and Support Center at http://www.mysql.com.
-----------------------------------------------------------------------------
早速調査開始。
どうやらWindows版のMySQLはmax_open_fileの既定値が2048で固定されていて、
しかも変更が出来ないらしい。max_open_fileは以下の計算式で求める事が出来る。
(max_connectionsとtable_chacheはmy.iniで設定可能)
max_open_file = (10 + max_connections + table_cache) * 2
計算した所、確かに2048を上回っている。
でもtable_cacheの値がなんか変？ログの619という端数はどこから？
再び調査開始。
どうやらmax_open_fileの既定値を超えた場合、table_cacheの値が再計算されるよう。
再計算した結果、619という値になったとの事。table_cacheは以下の計算式で求める。
table_cache = (max_open_file - 10 - max_connections) * 2
計算したら確かに619になりました。
つまり、ログの警告の文の意味は以下になる。
「max_open_fileを計算したら既定値の2048を上回ってました。なのでtable_cacheの
値を再計算して、その結果をtable_cacheとして再設定します」
my.iniで設定した値ではなく、実際のtable_cacheは619で動いていた訳ね。納得。
どうせ再設定されるなら初めから設定してしてしまおうとmy.iniを編集して再起動。
で、当然イベントログにも警告文も出なくなりました。
今回のシステムは書き込みはほぼなしなのでI/Oパフォーマンスは気にしなくてよい。
なのでtable_chacheの値はそれほど重要じゃないって事で一件落着。
以上。
どうやらMySQLの起動時かクラインアントからの新規接続をトリガーにしている模様。
-----------------------------------------------------------------------------
アプリケーションログ
ソース:MySQL イベントID:100
Changed limits: max_open_files: 2048 max_connections: 800
table_cache: 619
For more information, see Help and Support Center at http://www.mysql.com.
-----------------------------------------------------------------------------
早速調査開始。
どうやらWindows版のMySQLはmax_open_fileの既定値が2048で固定されていて、
しかも変更が出来ないらしい。max_open_fileは以下の計算式で求める事が出来る。
(max_connectionsとtable_chacheはmy.iniで設定可能)
max_open_file = (10 + max_connections + table_cache) * 2
計算した所、確かに2048を上回っている。
でもtable_cacheの値がなんか変？ログの619という端数はどこから？
再び調査開始。
どうやらmax_open_fileの既定値を超えた場合、table_cacheの値が再計算されるよう。
再計算した結果、619という値になったとの事。table_cacheは以下の計算式で求める。
table_cache = (max_open_file - 10 - max_connections) * 2
計算したら確かに619になりました。
つまり、ログの警告の文の意味は以下になる。
「max_open_fileを計算したら既定値の2048を上回ってました。なのでtable_cacheの
値を再計算して、その結果をtable_cacheとして再設定します」
my.iniで設定した値ではなく、実際のtable_cacheは619で動いていた訳ね。納得。
どうせ再設定されるなら初めから設定してしてしまおうとmy.iniを編集して再起動。
で、当然イベントログにも警告文も出なくなりました。
今回のシステムは書き込みはほぼなしなのでI/Oパフォーマンスは気にしなくてよい。
なのでtable_chacheの値はそれほど重要じゃないって事で一件落着。
以上。
スポンサーサイト
0
1MySQLには４つのログがあります。
それぞれの説明は以下。
①. エラーログ
②. 一般クエリログ
③. バイナリログ
④. スロークエリログ
①. エラーログについて
エラーログファイルでは、mysqld の起動時刻と停止時刻、
および実行中に発生したエラーに関する情報を記録しています。
②. 一般クエリログについて
サーバはこのログに、クライアント接続や切断の情報を書き込み、
そのときのクライアントからの SQL ステートメントも記録します。
③. バイナリログについて
バイナリ ログの内容には更新データのステートメント、
レコードに一致しない場合の DELETE などで更新済みのステートメントがあります。
④. スロークエリログについて
スロー クエリ ログの内容は、long_query_time 秒より
実行に時間がかかる SQL ステートメントすべてが入ります。
(要するに時間のかかるクエリ)
通常使うのは①だけで、差分バックアップやレプリケーションを行っている場合は③も。
②と④についてはデバッグ時や性能の最適化を行うときだけ使用する感じ。
設定方法下記見れば分かります。
My SQL5.1 リファレンスマニュアル
今更感が拭えない記事ですがとりあえず覚え書き。
それぞれの説明は以下。
①. エラーログ
②. 一般クエリログ
③. バイナリログ
④. スロークエリログ
①. エラーログについて
エラーログファイルでは、mysqld の起動時刻と停止時刻、
および実行中に発生したエラーに関する情報を記録しています。
②. 一般クエリログについて
サーバはこのログに、クライアント接続や切断の情報を書き込み、
そのときのクライアントからの SQL ステートメントも記録します。
③. バイナリログについて
バイナリ ログの内容には更新データのステートメント、
レコードに一致しない場合の DELETE などで更新済みのステートメントがあります。
④. スロークエリログについて
スロー クエリ ログの内容は、long_query_time 秒より
実行に時間がかかる SQL ステートメントすべてが入ります。
(要するに時間のかかるクエリ)
通常使うのは①だけで、差分バックアップやレプリケーションを行っている場合は③も。
②と④についてはデバッグ時や性能の最適化を行うときだけ使用する感じ。
設定方法下記見れば分かります。
My SQL5.1 リファレンスマニュアル
今更感が拭えない記事ですがとりあえず覚え書き。
ESXはデフォルトインストールすると最初からFW(iptables)が効いていて、
ntpの123番ポートも閉じられてしまっています。
なので、ESXでntpdateやntpdを使用するにはFWに穴を開けてやる必用があります。
普通にiptables使用して穴を開けてやることも出来ますが、
esxには専用のコマンドも用意されているのでどうせなのでそちらを使ってみます。
①FWへ穴あけ
# /usr/sbin/esxcfg-firewall -e ntpClien
②FWの確認
# /usr/sbin/esxcfg-firewall -q | grep 123
これだけです。後は実際にntpdateなど動かして疎通確認すればOK。
ちなみに、ftpなども閉じられているので使いたい場合は穴あけが必用。
# /usr/sbin/esxcfg-firewall -e ftpClient
# /usr/sbin/esxcfg-firewall --allowoutgoing
ftpは入口と出口でポートが違うので両方必用です。
以上。
ntpの123番ポートも閉じられてしまっています。
なので、ESXでntpdateやntpdを使用するにはFWに穴を開けてやる必用があります。
普通にiptables使用して穴を開けてやることも出来ますが、
esxには専用のコマンドも用意されているのでどうせなのでそちらを使ってみます。
①FWへ穴あけ
# /usr/sbin/esxcfg-firewall -e ntpClien
②FWの確認
# /usr/sbin/esxcfg-firewall -q | grep 123
これだけです。後は実際にntpdateなど動かして疎通確認すればOK。
ちなみに、ftpなども閉じられているので使いたい場合は穴あけが必用。
# /usr/sbin/esxcfg-firewall -e ftpClient
# /usr/sbin/esxcfg-firewall --allowoutgoing
ftpは入口と出口でポートが違うので両方必用です。
以上。
Tomcat5のログの一覧。
Tomcatはログの種類が多数ある上に、起動時に叩くバッチ、exeにより吐き出しログが違う。
なのでややこしいのでとりあえず纏めておく。
tomcat5.exeの場合
jakarta_service.log サービス起動停止のログ
stdout.log 標準出力
stderr.log 標準エラー出力
設定方法はtomcat5.exeから行う。
まずはservice.batを叩いてサービスへ登録
その後、tomcat5を使って各設定の変更が可能。
(ログレベルやログの吐き出し先、ログファイル名の変更などなど)
設定方法の詳細は下記リンク見れば分かりやすい。
windows-service-howto
次に、catalina.batから直接起動した場合。
catalina.out サービス起動停止(tomcat5.exeのstdoutと同じ)
localhost.log host(VirtualHost)に限定したログ
admin.log Tomcat Web Server Administration Toolのログ
manager.log Tomcat Manager Web Appのログ
host-manager.log Tomcat Host Manager Web Appのログ
設定は$TOMCAT_ROOT\conf\配下にあるlogging.propertiesで行う。
(ログレベルやログの吐き出し先、ログファイル名の変更などなど)
この他にアクセスログの設定も別であるのだがそれはまた次の機会に。
今回は以上。
Tomcatはログの種類が多数ある上に、起動時に叩くバッチ、exeにより吐き出しログが違う。
なのでややこしいのでとりあえず纏めておく。
tomcat5.exeの場合
jakarta_service.log サービス起動停止のログ
stdout.log 標準出力
stderr.log 標準エラー出力
設定方法はtomcat5.exeから行う。
まずはservice.batを叩いてサービスへ登録
その後、tomcat5を使って各設定の変更が可能。
(ログレベルやログの吐き出し先、ログファイル名の変更などなど)
設定方法の詳細は下記リンク見れば分かりやすい。
windows-service-howto
次に、catalina.batから直接起動した場合。
catalina.out サービス起動停止(tomcat5.exeのstdoutと同じ)
localhost.log host(VirtualHost)に限定したログ
admin.log Tomcat Web Server Administration Toolのログ
manager.log Tomcat Manager Web Appのログ
host-manager.log Tomcat Host Manager Web Appのログ
設定は$TOMCAT_ROOT\conf\配下にあるlogging.propertiesで行う。
(ログレベルやログの吐き出し先、ログファイル名の変更などなど)
この他にアクセスログの設定も別であるのだがそれはまた次の機会に。
今回は以上。
メモリチューニングの一環としてページキャッシュの効率化を纏めてみます。
ちなみにLinuxは空きメモリをがしがしファイルI/O用のキャッシュとして利用しますが、
メモリはページ単位で分割管理されており、これらのキャッシュをページキャッシュと言います。
(これらは使われっぱなしではなく頻繁に割当て、解放が行われています)
ではページキャッシュのチューニングとは何をするかと言うと、
要は無駄なページキャッシュを残さないようにしてあげればよいのです。
通常のI/O処理はライトバックで処理されているので、ページキャッシュに書き込まれた時点で
プロセスには書き込み完了通知が返され、キャッシュ上のデータはバックグランドでディスクに
書き込まれていきます。
ライトバックしたキャッシュ上のデータは解放可能なデータとなりますので、
頻繁にライトバックをしてあげる事でキャッシュの解放サイクルを早める事が出来ます。
そして結果的に無駄なページキャッシュの使用を抑える事が出来るのです。
カーネル2.6系では「pdflush」デーモンがライトバックしているので、
pdflushのタイミングを変更していく事になります。
変更方法はカーネルパラメータで、以下の4種類が主なパラメータになります。
vm.dirty_backgroud_ratio
vm.dirty_ratio
vm.dirty_expire_centisecs
vm.dirty_writeback_centisecs
ではひとつずつ見ていきましょう。
vm.dirty_backgroud_ratio
これは、キャッシュ上でまだディスクに書き込まれていないページ(dirtyな)が、
全物理ページに対する割合(％)を超えているとpdfluashによるライトバックが行われます。
但し、ライトバック処理は優先度の低いバックグラウンドプロセスとして動きます。
デフォルト値は10%です。
vm.dirty_ratio
これはvm.dirty_backgroup_ratioと全く同じ意味ですが、唯一異なるのはこの値を
超えた場合は、優先度が高いフォアグラウンドプロセスとして動くという事です。
デフォルト値は40%です。
この二つはお互い関連していて、通常vm.dirty_backgroud_ratioは
vm.dirty_ratioの半分ぐらいの値を目安にして設定していきます。
ちなみにvm.dirty_backgroud_ratioの値を
vm.dirty_ratioより大きくするとその値は無視されます。
vm.dirty_expire_centisecs
これは、キャッシュ上に存在しているページの
存在時間がこの値を過ぎた場合にライトバックされます。
デフォルト値は3000です(単位は10m/s)
vm.dirty_writeback_centisecs
これは、pdflushの起動間隔を指定するパラメータです。
デフォルト値は500です(単位は10m/s)
これらの値を適宜変更してあげれば効率化が出来ます。
環境によって違いがあるので一概には言えませんが、
vm.dirty_ratioの値を低くしてあげるのが一番効果が高いと思います。
ちなみに、ライトバックが完了しても解放可能となるだけで、
実際にページを解放するのはまた別の処理になります。
なのでライトバックと同時に「ページ回収」も早めてやる必用があります。
ページ回収処理もカーネルパラメータで調整可能です。
値はmin-free-kbytes
空きメモリーがこの値を下回った場合にページ回収処理が動くので、
この値を大きくしてあげればページの解放処理も早くなります。
但し、この値を大きくし過ぎてしまうと常にシステム上に大量の空きメモリが必要となり、
メモリーを有効に活用出来なくなってしまうので注意が必用です。
これらの値を調整しつつ、自システムに最適な値を見つけて下さい。
ちなみにLinuxは空きメモリをがしがしファイルI/O用のキャッシュとして利用しますが、
メモリはページ単位で分割管理されており、これらのキャッシュをページキャッシュと言います。
(これらは使われっぱなしではなく頻繁に割当て、解放が行われています)
ではページキャッシュのチューニングとは何をするかと言うと、
要は無駄なページキャッシュを残さないようにしてあげればよいのです。
通常のI/O処理はライトバックで処理されているので、ページキャッシュに書き込まれた時点で
プロセスには書き込み完了通知が返され、キャッシュ上のデータはバックグランドでディスクに
書き込まれていきます。
ライトバックしたキャッシュ上のデータは解放可能なデータとなりますので、
頻繁にライトバックをしてあげる事でキャッシュの解放サイクルを早める事が出来ます。
そして結果的に無駄なページキャッシュの使用を抑える事が出来るのです。
カーネル2.6系では「pdflush」デーモンがライトバックしているので、
pdflushのタイミングを変更していく事になります。
変更方法はカーネルパラメータで、以下の4種類が主なパラメータになります。
vm.dirty_backgroud_ratio
vm.dirty_ratio
vm.dirty_expire_centisecs
vm.dirty_writeback_centisecs
ではひとつずつ見ていきましょう。
vm.dirty_backgroud_ratio
これは、キャッシュ上でまだディスクに書き込まれていないページ(dirtyな)が、
全物理ページに対する割合(％)を超えているとpdfluashによるライトバックが行われます。
但し、ライトバック処理は優先度の低いバックグラウンドプロセスとして動きます。
デフォルト値は10%です。
vm.dirty_ratio
これはvm.dirty_backgroup_ratioと全く同じ意味ですが、唯一異なるのはこの値を
超えた場合は、優先度が高いフォアグラウンドプロセスとして動くという事です。
デフォルト値は40%です。
この二つはお互い関連していて、通常vm.dirty_backgroud_ratioは
vm.dirty_ratioの半分ぐらいの値を目安にして設定していきます。
ちなみにvm.dirty_backgroud_ratioの値を
vm.dirty_ratioより大きくするとその値は無視されます。
vm.dirty_expire_centisecs
これは、キャッシュ上に存在しているページの
存在時間がこの値を過ぎた場合にライトバックされます。
デフォルト値は3000です(単位は10m/s)
vm.dirty_writeback_centisecs
これは、pdflushの起動間隔を指定するパラメータです。
デフォルト値は500です(単位は10m/s)
これらの値を適宜変更してあげれば効率化が出来ます。
環境によって違いがあるので一概には言えませんが、
vm.dirty_ratioの値を低くしてあげるのが一番効果が高いと思います。
ちなみに、ライトバックが完了しても解放可能となるだけで、
実際にページを解放するのはまた別の処理になります。
なのでライトバックと同時に「ページ回収」も早めてやる必用があります。
ページ回収処理もカーネルパラメータで調整可能です。
値はmin-free-kbytes
空きメモリーがこの値を下回った場合にページ回収処理が動くので、
この値を大きくしてあげればページの解放処理も早くなります。
但し、この値を大きくし過ぎてしまうと常にシステム上に大量の空きメモリが必要となり、
メモリーを有効に活用出来なくなってしまうので注意が必用です。
これらの値を調整しつつ、自システムに最適な値を見つけて下さい。
 | 詳解 Linuxカーネル 第3版 (2007/02/26) Daniel P. BovetMarco Cesati 商品詳細を見る メモリ管理とプロセス・スケジューリングの項が増補されている。プロセス管理、ファイルシステム、メモリ管理、割り込みハンドラ、同期などソースを交えて説明があるので結構分かりやすい。 |
前回に引き続きTomcatのログのお話。
今回はアクセスログの取り方について書いてみます。
設定はserver.xmlで行いますが、もともとパラメータについては最初から載っているので
それをコメントアウトするのみでアクセスログを取る事が出来ます。
$TOMCAT_ROOT\conf\server.xml
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="E:/logs/" prefix="localhost_access_log." suffix=".txt"
pattern="common" resolveHosts="false"/>
上記のパラメータをコメントアウトするだけ。
directoryやprefixでログの吐き出し先やファイル名の変更も可能。
ちなみに吐かれるログの形式はapacheと同じような感じです。
以上。
今回はmysqldumpを使ってバックアップリストアについて。
ちなみにバイナリログは取得しないので差分は取りません。
mysqldumpはDB構造からデータまで全てをSQL文でダンプしてくれます。
なのでリストアはそれを読むだけでOK。
お手軽なうえ簡単なのでよく使われているバックアップ方式だと思います。
早速mysqldumpしてみます。よく使われるオプション付です。
mysqldump -u root -pパスワード 対象DB --opt -F > ダンプ出力先
以上。
なんてお手軽なのでしょうか。(ちなみに-pとパスワードの間はスペースなし)
オプションの説明は以下。
--opt
--quick --add-drop-table --add-locks --extended-insert --lock-tables と同じ。
-F, --flush-logs
ダンプする前に、MySQL のログファイルをフラッシュします。
--add-locks
テーブルのダンプの前に LOCK TABLES 文を追加し、テーブルのダンプ後に
UNLOCK TABLE 文を追加( リストア時に速くなる)。
--add-drop-table
テーブル作成の前にテーブルを削除する
-e, --extended-insert
新しいマルチライン INSERT 構文を使用します。
(これはあとで挿入する際、よりコンパクトかつ速くなります。)
-l, --lock-tables
ダンプを開始する前に全てのテーブルをロックする。.
-q, --quick
クエリをバッファにためない。
簡単に説明するとダンプ時の読み込みを出来るだけ早くしてます。
後は-Fでフラッシュされたログファイルをバックアップ先へコピーして終了。
これらをタスクスケジューラで回すだけでも充分バックアップが取れます。
では次にリストアしてみましょう。
mysql -u root -ppassword 対象DB < ダンプファイル
以上。
なんてお手軽なのでしょうか。
(対象DBを指定しているので分かると思いますがDB自体は先に作成しておく必要あり)
但し、差分バックアップではないので障害時に復旧できるのはバックアップ取得時点まで。
差分バックアップについてはまたの機会に。
最近のMySQLはInnoDBが主流かと思うけど、
InnoDBでテーブル作ると二つのファイルが出来る。
table名.frmってやつとテーブルスペースのファイル(デフォルトではibdata1という名前)
まずこれらが何を意味すかと言うと、
table名.frm テーブル構造のデータ
ibdata1 レコードデータやインデックスデータ
つまり、table名.frmはカラム構造などを、実際のデータはibdata1にある訳ですね。
ではこれらの格納位置を変更するにはどうするか？
設定はmy.iniで簡単に出来ます。
以下二つのパラメータを変更
(両方ともSERVER SECTION配下にある)
datadir="格納パス"
innodb_data_home_dir="格納パス"
ちなみに上のがtable名.frmファイルで下のがデータファイルのパラメータ。
編集後、一旦MySQLをシャットダウン。
でこの後、必ず今まで使用していた格納場所からデータのコピーをする事。
特にsystem系のDBをコピーし忘れるとMySQLが立ち上がりません。
既存のデータがある場所は、ibdataはコンフィグレーションウィザードで指定したInnoDBの格納場所で、frmファイルはMySQLのインストールフォルダのdata配下に存在している。
これらを全て新ディレクトリにコピーし終えたらMySQLを立ち上げる。
以上で格納位置の変更が可能。
InnoDBでテーブル作ると二つのファイルが出来る。
table名.frmってやつとテーブルスペースのファイル(デフォルトではibdata1という名前)
まずこれらが何を意味すかと言うと、
table名.frm テーブル構造のデータ
ibdata1 レコードデータやインデックスデータ
つまり、table名.frmはカラム構造などを、実際のデータはibdata1にある訳ですね。
ではこれらの格納位置を変更するにはどうするか？
設定はmy.iniで簡単に出来ます。
以下二つのパラメータを変更
(両方ともSERVER SECTION配下にある)
datadir="格納パス"
innodb_data_home_dir="格納パス"
ちなみに上のがtable名.frmファイルで下のがデータファイルのパラメータ。
編集後、一旦MySQLをシャットダウン。
でこの後、必ず今まで使用していた格納場所からデータのコピーをする事。
特にsystem系のDBをコピーし忘れるとMySQLが立ち上がりません。
既存のデータがある場所は、ibdataはコンフィグレーションウィザードで指定したInnoDBの格納場所で、frmファイルはMySQLのインストールフォルダのdata配下に存在している。
これらを全て新ディレクトリにコピーし終えたらMySQLを立ち上げる。
以上で格納位置の変更が可能。
Windows Server 2003はEditionによって以下のように使用可能なメモリが制限される。
Standard Edition 4GB
Enterprize Edition 8GB
Datacenter Edition 64GB
しかし実際にユーザー空間で使えるメモリは2GBに限られており、
残りの2GBはカーネル空間で使われるような仕様になっている。
(IA32アーキテクチャの仕様)
これではOracelやSQL Server、Exchange Serverなど1プロセスで
大量のメモリを必要とするアプリでは足りなくなってしまう事がある。
そこで、Windows2003には/3GBと/Userveという二つのスイッチを用いて、
ユーザー空間領域を2GB～3GBの間でチューニング出来るようになっている。
/3GBスイッチは2000 Serverの頃からあり、これはユーザ空間領域を3GBにして、
カーネル空間を1GBにするよ、というオプション。
/Userveは2003の新機能で、/3GBにて割り当てたメモリを、さらに細かく制御できる。
例えば/Userveに2900と指定した場合、3072(/3GB)-2900(Userve)の差分メモリ分
カーネルに返される。つまり上記の指定だと1172MBがカーネルモードで使えるようになる。
このようにして、メモリのチューニングが可能です。
ちなみに二つとも設定はBoot.iniファイルで行えます。
下記のようなオプションを追記するのみです。
[Boot Loader]
Timeout=30
Default=multi(0)disk(0)rdisk(0)partition(2)\WINNT
[Operating Systems]
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows Server
2003"/fastdetect /3GB /Userva=2900
ちなみにBoot.iniはルートパーティション直下にあります。
これをテキストエディタで手動で編集するかもしくはmsconfigでも編集可能です。
最後に、PAEについて少し。
PAEとは物理アドレス拡張の事で、4GBを超えるメモリを認識させるスイッチです。
例えば8GBのメモリを積んでいて、OSはEnterprize Editionを使っているにも関わらず
OSがメモリを4GBまでしか認識してない場合などに使用するものになります。
OSが4GBまでしか認識してなければ当然アプリでも認識されないので、
残りの4GBは全く使用されない事になります。
それで困るので/PAEというオプションが存在しています。
では実際にはどのような動作になるかと言うと、
PAEが有効になると、AWE(Address Windowing Extensions)が4GBを
超えるメモリを予約できるようなります。
AWEはユーザ空間の2GB(/3GBオプションなしの場合)のなかに
4GB以上のメモリをマッピングする為の領域を確保します。 (AWE Window)
4GB以上のメモリを使用する場合、このAWE Windowを通じて使われるという仕組みです。
ただしアプリ側にもAWEの対応が必用なので、設定変更やリコンパイルが生じたり、
対応が行われていない場合System Cache用としてしか使えなかったりなど問題もあります。
なのでぶっちゃけIA64を使用したほうが手っ取り早いです。
最後にPAEのオプションだけ記述。
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server
2003, Enterprise" /fastdetect /PAE
Standard Edition 4GB
Enterprize Edition 8GB
Datacenter Edition 64GB
しかし実際にユーザー空間で使えるメモリは2GBに限られており、
残りの2GBはカーネル空間で使われるような仕様になっている。
(IA32アーキテクチャの仕様)
これではOracelやSQL Server、Exchange Serverなど1プロセスで
大量のメモリを必要とするアプリでは足りなくなってしまう事がある。
そこで、Windows2003には/3GBと/Userveという二つのスイッチを用いて、
ユーザー空間領域を2GB～3GBの間でチューニング出来るようになっている。
/3GBスイッチは2000 Serverの頃からあり、これはユーザ空間領域を3GBにして、
カーネル空間を1GBにするよ、というオプション。
/Userveは2003の新機能で、/3GBにて割り当てたメモリを、さらに細かく制御できる。
例えば/Userveに2900と指定した場合、3072(/3GB)-2900(Userve)の差分メモリ分
カーネルに返される。つまり上記の指定だと1172MBがカーネルモードで使えるようになる。
このようにして、メモリのチューニングが可能です。
ちなみに二つとも設定はBoot.iniファイルで行えます。
下記のようなオプションを追記するのみです。
[Boot Loader]
Timeout=30
Default=multi(0)disk(0)rdisk(0)partition(2)\WINNT
[Operating Systems]
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows Server
2003"/fastdetect /3GB /Userva=2900
ちなみにBoot.iniはルートパーティション直下にあります。
これをテキストエディタで手動で編集するかもしくはmsconfigでも編集可能です。
最後に、PAEについて少し。
PAEとは物理アドレス拡張の事で、4GBを超えるメモリを認識させるスイッチです。
例えば8GBのメモリを積んでいて、OSはEnterprize Editionを使っているにも関わらず
OSがメモリを4GBまでしか認識してない場合などに使用するものになります。
OSが4GBまでしか認識してなければ当然アプリでも認識されないので、
残りの4GBは全く使用されない事になります。
それで困るので/PAEというオプションが存在しています。
では実際にはどのような動作になるかと言うと、
PAEが有効になると、AWE(Address Windowing Extensions)が4GBを
超えるメモリを予約できるようなります。
AWEはユーザ空間の2GB(/3GBオプションなしの場合)のなかに
4GB以上のメモリをマッピングする為の領域を確保します。 (AWE Window)
4GB以上のメモリを使用する場合、このAWE Windowを通じて使われるという仕組みです。
ただしアプリ側にもAWEの対応が必用なので、設定変更やリコンパイルが生じたり、
対応が行われていない場合System Cache用としてしか使えなかったりなど問題もあります。
なのでぶっちゃけIA64を使用したほうが手っ取り早いです。
最後にPAEのオプションだけ記述。
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server
2003, Enterprise" /fastdetect /PAE
ページキャッシュを手動で解放するやり方。
カーネルパラメータのdrop_cachesを使えば簡単に出来ます。
drop_cachesはライトバック済みのページキャッシュやslabキャッシュを解放します。
1. ページキャッシュのみを解放する場合
# echo 1 > /proc/sys/vm/drop_caches
2. slabキャッシュを解放する場合
# echo 2 > /proc/sys/vm/drop_caches
3. ページキャッシュとslabの両方解放したい場合
# echo 3 > /proc/sys/vm/drop_caches
ちなみにデフォルト状態に戻す場合は"0"を書き込みます。
以上。
カーネルパラメータのdrop_cachesを使えば簡単に出来ます。
drop_cachesはライトバック済みのページキャッシュやslabキャッシュを解放します。
1. ページキャッシュのみを解放する場合
# echo 1 > /proc/sys/vm/drop_caches
2. slabキャッシュを解放する場合
# echo 2 > /proc/sys/vm/drop_caches
3. ページキャッシュとslabの両方解放したい場合
# echo 3 > /proc/sys/vm/drop_caches
ちなみにデフォルト状態に戻す場合は"0"を書き込みます。
以上。
| 詳解 Linuxカーネル 第3版 (2007/02/26) Daniel P. BovetMarco Cesati 商品詳細を見る メモリ管理とプロセス・スケジューリングの項が増補されている。プロセス管理、ファイルシステム、メモリ管理、割り込みハンドラ、同期などソースを交えて説明があるので結構分かりやすい。 |
今回は仮想化の種類とその概要について纏めてみます。
まず、主な仮想化のタイプとして以下の三つが挙げられます。
1. ファームウェアタイプ
2. ハイパーバイザータイプ
3. アプリケーションタイプ
厳密に言えばもう少し細かく分類出来るのですが、
それは後述するとして順にひとつずづ見ていきましょう。
ファームウェアタイプ
IBMのLPARやHPのvParsなどに代表され、パーティショニング方式と呼ばれる事もあります。
実際にはさらに物理パーティションニング、論理パーティショニングと分類される。
物理パーティショニングはレガシーサーバのCPU・メモリ・
I/Oスロットなどを一塊にし、物理的なブロック単位で管理します。
論理パーティショニングは更にCPU単位、メモリブロック単位などで
細かく分類し、リソースの配分をより柔軟に設定する事が出来ます。
これらはつまりHWのリソースを上位の仮想OS毎に物理的に割り振り実現しているのです。
長所
仮想OSとHWの間にはファームウェアや仮想マシンソフトウェアのみが
存在するので、仮想化によるオーバーヘッド処理が他のタイプに比べ少ない。
また、物理的に違うリソースが割り振られている場合、障害の影響範囲が少ない。
短所
リソースの割当てが他のタイプに比べ柔軟に割り当てる事が出来ない。
以上がファームウェアタイプの特徴になります。
ハイパーバイザタイプ
VMware ESX ServerやXenに代表される専用カーネルを用意する方式。
この専用カーネルの事を「ハイパーバイザ」、または「VMM」などと呼びます。
簡単に言ってしまえば予め仮想化に特化され最適化されている
ソフトウェアを用意し、その上に仮想OSを作成していくと言った方式です。
ハイパーバイザタイプの中でもBIOSを持つものと持たないものの違いがあります。
前者の方式を「バイナリートランスレーション」といい、
後者の方式を「パラバーチャライゼーション(準仮想化)」と言います。
これらの違いはCPUの動作モードの違いやそれにより処理形態の違いなど、
これの説明だけで記事が出来上がってしまうので詳細はまた別の機会に。
簡単に言いますと、バイナリートランスレーションは
多少のオーバーヘッドがあるが仮想OS側の修正はなくても済む。
パラバーチャライゼーションはバイナリートランスレーションより
オーバーヘッドが少ないが仮想OS自体に修正が必要になる。
(ゲストOSが限られてしまう）
と言った違いになります。
長所
リソースの割当てがファームウェア方式に比べ自由度が高い。
ピーク時などに合わせて動的に自動で割当てる事が可能。
短所
HWとの間にVMMが存在しているため、少なからずオーバーヘッドが存在する。
物理的なリソースを仮想OS間で共有する為、障害に影響範囲が多岐に渡る。
以上がハイパーバイザータイプの特徴になります。
アプリケーションタイプ
MiscrosoftのVirtual ServerやVMwareのVMware Serverなどに代表される、
言わばエミュレーションタイプの仮想化方式である。
ホストOS上に専用のアプリケーションをインストールして、
そのアプリ上で仮想OSをエミュレートして動かします。
長所
アプリを入れるだけで仮想環境の構築が可能な為、導入が非常に容易。
また、ハードウェア依存の傾向も他の方式に比べると少ない。
短所
仮想OSとHWの間に、エミュレーションソフト、ホストOSと
階層があるため他の方式に比べオーバーヘッドが多くなる。
以上がアプリケーション方式の特徴になります。
仮想化はHWとの関係(特にCPU)が密接な為、
結構突き詰めて行くとだんだんと難しくなります。
なのでとりあえず簡単に纏めてみました。
まず、主な仮想化のタイプとして以下の三つが挙げられます。
1. ファームウェアタイプ
2. ハイパーバイザータイプ
3. アプリケーションタイプ
厳密に言えばもう少し細かく分類出来るのですが、
それは後述するとして順にひとつずづ見ていきましょう。
ファームウェアタイプ
IBMのLPARやHPのvParsなどに代表され、パーティショニング方式と呼ばれる事もあります。
実際にはさらに物理パーティションニング、論理パーティショニングと分類される。
物理パーティショニングはレガシーサーバのCPU・メモリ・
I/Oスロットなどを一塊にし、物理的なブロック単位で管理します。
論理パーティショニングは更にCPU単位、メモリブロック単位などで
細かく分類し、リソースの配分をより柔軟に設定する事が出来ます。
これらはつまりHWのリソースを上位の仮想OS毎に物理的に割り振り実現しているのです。
長所
仮想OSとHWの間にはファームウェアや仮想マシンソフトウェアのみが
存在するので、仮想化によるオーバーヘッド処理が他のタイプに比べ少ない。
また、物理的に違うリソースが割り振られている場合、障害の影響範囲が少ない。
短所
リソースの割当てが他のタイプに比べ柔軟に割り当てる事が出来ない。
以上がファームウェアタイプの特徴になります。
ハイパーバイザタイプ
VMware ESX ServerやXenに代表される専用カーネルを用意する方式。
この専用カーネルの事を「ハイパーバイザ」、または「VMM」などと呼びます。
簡単に言ってしまえば予め仮想化に特化され最適化されている
ソフトウェアを用意し、その上に仮想OSを作成していくと言った方式です。
ハイパーバイザタイプの中でもBIOSを持つものと持たないものの違いがあります。
前者の方式を「バイナリートランスレーション」といい、
後者の方式を「パラバーチャライゼーション(準仮想化)」と言います。
これらの違いはCPUの動作モードの違いやそれにより処理形態の違いなど、
これの説明だけで記事が出来上がってしまうので詳細はまた別の機会に。
簡単に言いますと、バイナリートランスレーションは
多少のオーバーヘッドがあるが仮想OS側の修正はなくても済む。
パラバーチャライゼーションはバイナリートランスレーションより
オーバーヘッドが少ないが仮想OS自体に修正が必要になる。
(ゲストOSが限られてしまう）
と言った違いになります。
長所
リソースの割当てがファームウェア方式に比べ自由度が高い。
ピーク時などに合わせて動的に自動で割当てる事が可能。
短所
HWとの間にVMMが存在しているため、少なからずオーバーヘッドが存在する。
物理的なリソースを仮想OS間で共有する為、障害に影響範囲が多岐に渡る。
以上がハイパーバイザータイプの特徴になります。
アプリケーションタイプ
MiscrosoftのVirtual ServerやVMwareのVMware Serverなどに代表される、
言わばエミュレーションタイプの仮想化方式である。
ホストOS上に専用のアプリケーションをインストールして、
そのアプリ上で仮想OSをエミュレートして動かします。
長所
アプリを入れるだけで仮想環境の構築が可能な為、導入が非常に容易。
また、ハードウェア依存の傾向も他の方式に比べると少ない。
短所
仮想OSとHWの間に、エミュレーションソフト、ホストOSと
階層があるため他の方式に比べオーバーヘッドが多くなる。
以上がアプリケーション方式の特徴になります。
仮想化はHWとの関係(特にCPU)が密接な為、
結構突き詰めて行くとだんだんと難しくなります。
なのでとりあえず簡単に纏めてみました。
前回詳細な説明を省いてしまったこの二つについてお話してみたいと思います。
まず、本題に入る前にCPUの特権レベルについておさらいしてみます。
X86系のCPUは4段階のレベルを持っています。
ちなみにレベルの事は「リング」と呼ばれています。
リング0が一番高い動作レベルとなり、CPUリソース、メモリーの全空間へのアクセス、
HWデバイスへのアクセスなどが可能となっています。
通常のレガシーサーバで例えるとOSやデバイスドライバがリング0で動作し、
いわゆるカーネルモードと呼ばれるものになります。
対して、ユーザーモードと呼ばれる一般的なアプリケーションの
動作レベルはリング3になります。
リング3はアクセスが限定されている代わりに、そのレベルの致命的な障害が、
より上位のリング0で動作しているOSなどには影響を与えないようにしています。
つまりアプリの障害をシステム全体にまで影響を与えないようにしている訳です。
では、ようやく本題に入ります。
バイナリートランスレーション
バイナリートランスレーションもパラバーチャライゼーションも
VMMと呼ばれるゲストOSを制御するソフトウェアを持っています。
VMMはリング0で動作し、その上の仮想OSはリング1で動作する事になります。
しかし仮想OSは自分がリング1で動作している事を知らないので、リング1では実行できない
特権命令までも、さもリング0で動作しているかのように普通に発行してしまいます。
当然命令を受け取ったCPUでは例外、割り込みが発生します。
VMMはこの割り込みを全て監視しているので、
割り込みが発生した処理をVMMが横取りして処理してあげます。
VMMはリング0で動作しているので、ここからの特権命令は
もちろん例外なく実行されると言う訳です。
これがバイナリートランスレーションと呼ばれる仕組みになります。
(実際には仮想OSからの全ての処理を例外ハンドラで処理している訳ではなく、
VMMの実装の仕方、命令によっては、直接命令を横取りしたりもしています。)
バイナリートランスレションは上記のようなトリッキーかつ複雑な動きをする為、
オーバーヘッドが少なからず発生してしまいます。
パラバーチャライゼーション
パラバーチャライゼーションもVMMを持っている事は先程説明しましたが、
パラバーチャライゼーションの場合は仮想OSがリング1、もしくは2で動作します。
但し、バイナリートランスレーションと違い、仮想OS上のコードを変更し、
リング0でしか処理できないような特権命令をCPUに命令するのではなく、
VMMに一度渡してあげるようしています。
つまり、仮想OS自身が自分が動作しているレベルはリング0以外である事を
認識していると言う事になります。
最終的にはVMMから実行するという点はバイナリートランスレーションと同じですが、
例外ハンドラやトラップの処理がない為、バイナリトランスレーションよりオーバーヘッドが
少なくて済むという利点があります。
しかし、仮想OSのコードに手を入れなければならない為、
専用にコンパイルされているOSしか動かせないといった制限があります。
ざっと説明してみましたが、ソフトウェアレベルでの仮想化は
どうしてもオーバーヘッドや制限などが存在してしまいます。
これに対して、最近はハードウェアレベルでの仮想化を支援する技術もあり、
IntelのVTやAMD-VなどのCPUの仮想化支援機能などが代表的なものです。
こちらはまた機会があったら纏めてみたいと思います。
今回は以上。
まず、本題に入る前にCPUの特権レベルについておさらいしてみます。
X86系のCPUは4段階のレベルを持っています。
ちなみにレベルの事は「リング」と呼ばれています。
リング0が一番高い動作レベルとなり、CPUリソース、メモリーの全空間へのアクセス、
HWデバイスへのアクセスなどが可能となっています。
通常のレガシーサーバで例えるとOSやデバイスドライバがリング0で動作し、
いわゆるカーネルモードと呼ばれるものになります。
対して、ユーザーモードと呼ばれる一般的なアプリケーションの
動作レベルはリング3になります。
リング3はアクセスが限定されている代わりに、そのレベルの致命的な障害が、
より上位のリング0で動作しているOSなどには影響を与えないようにしています。
つまりアプリの障害をシステム全体にまで影響を与えないようにしている訳です。
では、ようやく本題に入ります。
バイナリートランスレーション
バイナリートランスレーションもパラバーチャライゼーションも
VMMと呼ばれるゲストOSを制御するソフトウェアを持っています。
VMMはリング0で動作し、その上の仮想OSはリング1で動作する事になります。
しかし仮想OSは自分がリング1で動作している事を知らないので、リング1では実行できない
特権命令までも、さもリング0で動作しているかのように普通に発行してしまいます。
当然命令を受け取ったCPUでは例外、割り込みが発生します。
VMMはこの割り込みを全て監視しているので、
割り込みが発生した処理をVMMが横取りして処理してあげます。
VMMはリング0で動作しているので、ここからの特権命令は
もちろん例外なく実行されると言う訳です。
これがバイナリートランスレーションと呼ばれる仕組みになります。
(実際には仮想OSからの全ての処理を例外ハンドラで処理している訳ではなく、
VMMの実装の仕方、命令によっては、直接命令を横取りしたりもしています。)
バイナリートランスレションは上記のようなトリッキーかつ複雑な動きをする為、
オーバーヘッドが少なからず発生してしまいます。
パラバーチャライゼーション
パラバーチャライゼーションもVMMを持っている事は先程説明しましたが、
パラバーチャライゼーションの場合は仮想OSがリング1、もしくは2で動作します。
但し、バイナリートランスレーションと違い、仮想OS上のコードを変更し、
リング0でしか処理できないような特権命令をCPUに命令するのではなく、
VMMに一度渡してあげるようしています。
つまり、仮想OS自身が自分が動作しているレベルはリング0以外である事を
認識していると言う事になります。
最終的にはVMMから実行するという点はバイナリートランスレーションと同じですが、
例外ハンドラやトラップの処理がない為、バイナリトランスレーションよりオーバーヘッドが
少なくて済むという利点があります。
しかし、仮想OSのコードに手を入れなければならない為、
専用にコンパイルされているOSしか動かせないといった制限があります。
ざっと説明してみましたが、ソフトウェアレベルでの仮想化は
どうしてもオーバーヘッドや制限などが存在してしまいます。
これに対して、最近はハードウェアレベルでの仮想化を支援する技術もあり、
IntelのVTやAMD-VなどのCPUの仮想化支援機能などが代表的なものです。
こちらはまた機会があったら纏めてみたいと思います。
今回は以上。
最近、VMware ESX(3.0と3.5)の環境でFCスイッチの障害が起こりました。
この環境はESXにFC経由で共有ストレージを持たせており、
そこの途中にあるFCスイッチに障害が発生してFCの経路が切り替わりました。
ここまではいいのですが、FCパスのFailOver後になんと
Linuxサーバの1/3くらいファイルシステムがReadOnlyになってしまった。
軽くパニックったがどうしようもなかったのでReadOnlyのサーバを全台再起動して復旧。
取り合えず復旧はさせたので原因調査を開始。
まずReadOnlyになったサーバだが、Linuxサーバのうち約1/3程度。
現象が発生しなかったサーバとの違いはどうやらOSのバージョンくらい。
でVMware Knowledgebase Documentを眺めていたらあっさり原因を発見。
vmware knowledgebase Document
どうやら、パスのFailOverが発生した場合に
特定のGestOSを使用していると発現する障害らしい。
だがやっかいな事にESX側のバグではなく、
GestOS側の問題なので、修正はGestOS側になるらしい。
で、どうやらその修正にはOSのバージョンをあげろとの事。
既にサービスインしているGuestOSなので簡単にはOSのバージョンをあげられないが、
結局対処方法が他に見つからなかったのでOSのバージョンをあげる事にしました。
修正パッチとかもう少しスマートな方法で対応出来ると思ってたけど、なんだかな～。
この環境はESXにFC経由で共有ストレージを持たせており、
そこの途中にあるFCスイッチに障害が発生してFCの経路が切り替わりました。
ここまではいいのですが、FCパスのFailOver後になんと
Linuxサーバの1/3くらいファイルシステムがReadOnlyになってしまった。
軽くパニックったがどうしようもなかったのでReadOnlyのサーバを全台再起動して復旧。
取り合えず復旧はさせたので原因調査を開始。
まずReadOnlyになったサーバだが、Linuxサーバのうち約1/3程度。
現象が発生しなかったサーバとの違いはどうやらOSのバージョンくらい。
でVMware Knowledgebase Documentを眺めていたらあっさり原因を発見。
vmware knowledgebase Document
どうやら、パスのFailOverが発生した場合に
特定のGestOSを使用していると発現する障害らしい。
だがやっかいな事にESX側のバグではなく、
GestOS側の問題なので、修正はGestOS側になるらしい。
で、どうやらその修正にはOSのバージョンをあげろとの事。
既にサービスインしているGuestOSなので簡単にはOSのバージョンをあげられないが、
結局対処方法が他に見つからなかったのでOSのバージョンをあげる事にしました。
修正パッチとかもう少しスマートな方法で対応出来ると思ってたけど、なんだかな～。
ESXではパスが二重化されていて且つストレージのコントローラがActive-Activeに
なっていても、LUN毎にパスが固定化されている為、自動でロードバランスしてくれない。
なので、LUN毎に手動でパスを指定してあげる必用があります。
例えば、ESXのサーバが二台(A,B)あり、ストレージにLUN(01,02)が二つあるとします。
(サーバではパスが二重化されており、ストレージコントローラもAct-Actとします。)
デフォルトの設定だと、AのサーバはLUN01,02に対してPrimaryのパスを使い、
Bのサーバも同様に両LUNに対してPrimaryのパスを使用します。
さらにPrimaryのパスはストレージAのコントローラに繋がっているので、
サーバA,B共にPrimaryパスを経由してストレージAのコントローラを使用して
LUN01,02に対してアクセスする事になります。
これでは、パスもストレージもせっかく二重化されていてAct-Actなのに
片系しか使用しておらずリソースを無駄に余らせてしまう事になります。
そこで、下記にある通りにパスを切り替えてあげることにします。
サーバ LUN パス コントローラ(ストレージ)
A 01 Primary A
A 02 Secondary B
B 01 Secondary B
B 02 Primary A
上記のように設定してあげれば、アクセスが均等に分散されます。
実際に設定する場合は、まずVIClientからVCに繋げます。
設定したいESXの「Configration」タブから「Hardware」メニュー、
「Storage(SCSI,SAN and NFS)」と選択。
「Storage」メニューから対象LUNを選択して、「Properties」を開きます。
Properties画面から「Manage Paths」を選択して、Manage Pathes画面にいきます。
対象のパスを選び、「Change」選択後、Change Path State画面にて「Preferred」
及び「Enable」にチェックを入れてあげればOKです。
後は上記の繰り返しとなります。
以上で、手動ではありますがパスのロードバランシングが可能になります。
補足：
実は最新のESXにはManage Pathで「Load Load balancer」という項目があります。
これは今回のように手動で設定していくのではなく、自動で負荷分散してくれる設定です。
何故今回こちらで設定しなかったといつと、これはまだ試験的サポートのみとあったからです。
(少し前の話なのでもしかしたらもう本番サポートも開始したかも？)
この辺調べきれてなくてすみません。。どなたか情報お持ちでしたら教えて下さい。。
なっていても、LUN毎にパスが固定化されている為、自動でロードバランスしてくれない。
なので、LUN毎に手動でパスを指定してあげる必用があります。
例えば、ESXのサーバが二台(A,B)あり、ストレージにLUN(01,02)が二つあるとします。
(サーバではパスが二重化されており、ストレージコントローラもAct-Actとします。)
デフォルトの設定だと、AのサーバはLUN01,02に対してPrimaryのパスを使い、
Bのサーバも同様に両LUNに対してPrimaryのパスを使用します。
さらにPrimaryのパスはストレージAのコントローラに繋がっているので、
サーバA,B共にPrimaryパスを経由してストレージAのコントローラを使用して
LUN01,02に対してアクセスする事になります。
これでは、パスもストレージもせっかく二重化されていてAct-Actなのに
片系しか使用しておらずリソースを無駄に余らせてしまう事になります。
そこで、下記にある通りにパスを切り替えてあげることにします。
サーバ LUN パス コントローラ(ストレージ)
A 01 Primary A
A 02 Secondary B
B 01 Secondary B
B 02 Primary A
上記のように設定してあげれば、アクセスが均等に分散されます。
実際に設定する場合は、まずVIClientからVCに繋げます。
設定したいESXの「Configration」タブから「Hardware」メニュー、
「Storage(SCSI,SAN and NFS)」と選択。
「Storage」メニューから対象LUNを選択して、「Properties」を開きます。
Properties画面から「Manage Paths」を選択して、Manage Pathes画面にいきます。
対象のパスを選び、「Change」選択後、Change Path State画面にて「Preferred」
及び「Enable」にチェックを入れてあげればOKです。
後は上記の繰り返しとなります。
以上で、手動ではありますがパスのロードバランシングが可能になります。
補足：
実は最新のESXにはManage Pathで「Load Load balancer」という項目があります。
これは今回のように手動で設定していくのではなく、自動で負荷分散してくれる設定です。
何故今回こちらで設定しなかったといつと、これはまだ試験的サポートのみとあったからです。
(少し前の話なのでもしかしたらもう本番サポートも開始したかも？)
この辺調べきれてなくてすみません。。どなたか情報お持ちでしたら教えて下さい。。
| ホーム |
