2008年11月このブログは、日々頭の中に蓄積されては薄れていく技術情報を書き留めておく為のものです。MySQL久しぶりにMySQLを触っていたらイベントログに下記のような警告を多数発見。MySQLの起動時かクラインアントからの新規接続をトリガーにしている模様。http://www.mysql.com.-----------------------------------------------------------------------------早速調査開始。Windows版のMySQLはmax_open_fileの既定値が2048で固定されていて、しかも変更が出来ないらしい。max_open_fileは以下の計算式で求める事が出来る。2計算した所、確かに2048を上回っている。table_cacheの値がなんか変?ログの619という端数はどこから?再び調査開始。max_open_fileの既定値を超えた場合、table_cacheの値が再計算されるよう。再計算した結果、619という値になったとの事。table_cacheは以下の計算式で求める。2計算したら確かに619になりました。ログの警告の文の意味は以下になる。「max_open_fileを計算したら既定値の2048を上回ってました。table_cacheの値を再計算して、その結果をtable_cacheとして再設定します」my.iniで設定した値ではなく、実際のtable_cacheは619で動いていた訳ね。再設定されるなら初めから設定してしてしまおうとmy.iniを編集して再起動。イベントログにも警告文も出なくなりました。今回のシステムは書き込みはほぼなしなのでI/Oパフォーマンスは気にしなくてよい。MySQLMySQLには4つのログがあります。それぞれの説明は以下。起動時刻と停止時刻、および実行中に発生したエラーに関する情報を記録しています。ステートメントも記録します。更新済みのステートメントがあります。ステートメントすべてが入ります。(要するに時間のかかるクエリ)通常使うのは1だけで、差分バックアップやレプリケーションを行っている場合は3も。2と4についてはデバッグ時や性能の最適化を行うときだけ使用する感じ。設定方法下記見れば分かります。リファレンスマニュアル今更感が拭えない記事ですがとりあえず覚え書き。VMwareESXはデフォルトインストールすると最初からFW(iptables)が効いていて、ntpの123番ポートも閉じられてしまっています。ESXでntpdateやntpdを使用するにはFWに穴を開けてやる必用があります。普通にiptables使用して穴を開けてやることも出来ますが、esxには専用のコマンドも用意されているのでどうせなのでそちらを使ってみます。後は実際にntpdateなど動かして疎通確認すればOK。ちなみに、ftpなども閉じられているので使いたい場合は穴あけが必用。--allowoutgoingftpは入口と出口でポートが違うので両方必用です。Firewall意外にすぐやり方を忘れるので覚え書き。NetScreenやSSGは一度アラームのLEDが点灯すると自動では消えない。ブラウザからの管理画面からも消せない。再起動しても消えない。TomcatTomcat5のログの一覧。Tomcatはログの種類が多数ある上に、起動時に叩くバッチ、exeにより吐き出しログが違う。ややこしいのでとりあえず纏めておく。設定方法はtomcat5.exeから行う。service.batを叩いてサービスへ登録その後、tomcat5を使って各設定の変更が可能。(ログレベルやログの吐き出し先、ログファイル名の変更などなど)設定方法の詳細は下記リンク見れば分かりやすい。windows-service-howto次に、catalina.batから直接起動した場合。Appのログ設定は$TOMCAT_ROOT\conf\配下にあるlogging.propertiesで行う。(ログレベルやログの吐き出し先、ログファイル名の変更などなど)この他にアクセスログの設定も別であるのだがそれはまた次の機会に。Linuxメモリチューニングの一環としてページキャッシュの効率化を纏めてみます。ちなみにLinuxは空きメモリをがしがしファイルI/O用のキャッシュとして利用しますが、メモリはページ単位で分割管理されており、これらのキャッシュをページキャッシュと言います。要は無駄なページキャッシュを残さないようにしてあげればよいのです。通常のI/O処理はライトバックで処理されているので、ページキャッシュに書き込まれた時点でプロセスには書き込み完了通知が返され、キャッシュ上のデータはバックグランドでディスクに書き込まれていきます。頻繁にライトバックをしてあげる事でキャッシュの解放サイクルを早める事が出来ます。結果的に無駄なページキャッシュの使用を抑える事が出来るのです。カーネル2.6系では「pdflush」デーモンがライトバックしているので、pdflushのタイミングを変更していく事になります。変更方法はカーネルパラメータで、以下の4種類が主なパラメータになります。vm.dirty_backgroud_ratiovm.dirty_ratiovm.dirty_expire_centisecsvm.dirty_writeback_centisecsではひとつずつ見ていきましょう。全物理ページに対する割合(%)を超えていると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空きメモリーがこの値を下回った場合にページ回収処理が動くので、この値を大きくしてあげればページの解放処理も早くなります。この値を大きくし過ぎてしまうと常にシステム上に大量の空きメモリが必要となり、メモリーを有効に活用出来なくなってしまうので注意が必用です。これらの値を調整しつつ、自システムに最適な値を見つけて下さい。Cesati商品詳細を見るメモリ管理とプロセス・スケジューリングの項が増補されている。プロセス管理、ファイルシステム、メモリ管理、割り込みハンドラ、同期などソースを交えて説明があるので結構分かりやすい。Tomcat前回に引き続きTomcatのログのお話。今回はアクセスログの取り方について書いてみます。設定はserver.xmlで行いますが、もともとパラメータについては最初から載っているのでそれをコメントアウトするのみでアクセスログを取る事が出来ます。resolveHosts="false"/>上記のパラメータをコメントアウトするだけ。directoryやprefixでログの吐き出し先やファイル名の変更も可能。ちなみに吐かれるログの形式はapacheと同じような感じです。MySQL今回はmysqldumpを使ってバックアップリストアについて。ちなみにバイナリログは取得しないので差分は取りません。mysqldumpはDB構造からデータまで全てをSQL文でダンプしてくれます。リストアはそれを読むだけでOK。お手軽なうえ簡単なのでよく使われているバックアップ方式だと思います。mysqldumpしてみます。使われるオプション付です。お手軽なのでしょうか。(ちなみに-pとパスワードの間はスペースなし)オプションの説明は以下。ログファイルをフラッシュします。リストア時に速くなる)。(これはあとで挿入する際、よりコンパクトかつ速くなります。--lock-tablesダンプを開始する前に全てのテーブルをロックする。--quickクエリをバッファにためない。簡単に説明するとダンプ時の読み込みを出来るだけ早くしてます。後は-Fでフラッシュされたログファイルをバックアップ先へコピーして終了。これらをタスクスケジューラで回すだけでも充分バックアップが取れます。次にリストアしてみましょう。お手軽なのでしょうか。(対象DBを指定しているので分かると思いますがDB自体は先に作成しておく必要あり)但し、差分バックアップではないので障害時に復旧できるのはバックアップ取得時点まで。差分バックアップについてはまたの機会に。MySQL最近のMySQLはInnoDBが主流かと思うけど、InnoDBでテーブル作ると二つのファイルが出来る。レコードデータやインデックスデータつまり、table名.frmはカラム構造などを、実際のデータはibdata1にある訳ですね。これらの格納位置を変更するにはどうするか?設定はmy.iniで簡単に出来ます。SECTION配下にある)datadir="格納パス"innodb_data_home_dir="格納パス"ちなみに上のがtable名.frmファイルで下のがデータファイルのパラメータ。編集後、一旦MySQLをシャットダウン。この後、必ず今まで使用していた格納場所からデータのコピーをする事。system系のDBをコピーし忘れるとMySQLが立ち上がりません。既存のデータがある場所は、ibdataはコンフィグレーションウィザードで指定したInnoDBの格納場所で、frmファイルはMySQLのインストールフォルダのdata配下に存在している。これらを全て新ディレクトリにコピーし終えたらMySQLを立ち上げる。以上で格納位置の変更が可能。2003はEditionによって以下のように使用可能なメモリが制限される。残りの2GBはカーネル空間で使われるような仕様になっている。Serverなど1プロセスで大量のメモリを必要とするアプリでは足りなくなってしまう事がある。そこで、Windows2003には/3GBと/Userveという二つのスイッチを用いて、ユーザー空間領域を2GB~3GBの間でチューニング出来るようになっている。Serverの頃からあり、これはユーザ空間領域を3GBにして、カーネル空間を1GBにするよ、というオプション。/Userveは2003の新機能で、/3GBにて割り当てたメモリを、さらに細かく制御できる。/Userveに2900と指定した場合、3072(/3GB)-2900(Userve)の差分メモリ分カーネルに返される。上記の指定だと1172MBがカーネルモードで使えるようになる。このようにして、メモリのチューニングが可能です。ちなみに二つとも設定はBoot.iniファイルで行えます。下記のようなオプションを追記するのみです。/Userva=2900ちなみにBoot.iniはルートパーティション直下にあります。これをテキストエディタで手動で編集するかもしくはmsconfigでも編集可能です。最後に、PAEについて少し。PAEとは物理アドレス拡張の事で、4GBを超えるメモリを認識させるスイッチです。Editionを使っているにも関わらずOSがメモリを4GBまでしか認識してない場合などに使用するものになります。残りの4GBは全く使用されない事になります。それで困るので/PAEというオプションが存在しています。Extensions)が4GBを超えるメモリを予約できるようなります。AWEはユーザ空間の2GB(/3GBオプションなしの場合)のなかに4GB以上のメモリをマッピングする為の領域を確保します。Windowを通じて使われるという仕組みです。Cache用としてしか使えなかったりなど問題もあります。ぶっちゃけIA64を使用したほうが手っ取り早いです。最後にPAEのオプションだけ記述。Linuxページキャッシュを手動で解放するやり方。カーネルパラメータのdrop_cachesを使えば簡単に出来ます。drop_cachesはライトバック済みのページキャッシュやslabキャッシュを解放します。/proc/sys/vm/drop_cachesちなみにデフォルト状態に戻す場合は"0"を書き込みます。Cesati商品詳細を見るメモリ管理とプロセス・スケジューリングの項が増補されている。プロセス管理、ファイルシステム、メモリ管理、割り込みハンドラ、同期などソースを交えて説明があるので結構分かりやすい。今回は仮想化の種類とその概要について纏めてみます。主な仮想化のタイプとして以下の三つが挙げられます。アプリケーションタイプ厳密に言えばもう少し細かく分類出来るのですが、それは後述するとして順にひとつずづ見ていきましょう。ファームウェアタイプIBMのLPARやHPのvParsなどに代表され、パーティショニング方式と呼ばれる事もあります。実際にはさらに物理パーティションニング、論理パーティショニングと分類される。物理パーティショニングはレガシーサーバのCPU・メモリ・I/Oスロットなどを一塊にし、物理的なブロック単位で管理します。論理パーティショニングは更にCPU単位、メモリブロック単位などで細かく分類し、リソースの配分をより柔軟に設定する事が出来ます。これらはつまりHWのリソースを上位の仮想OS毎に物理的に割り振り実現しているのです。仮想OSとHWの間にはファームウェアや仮想マシンソフトウェアのみが存在するので、仮想化によるオーバーヘッド処理が他のタイプに比べ少ない。物理的に違うリソースが割り振られている場合、障害の影響範囲が少ない。短所リソースの割当てが他のタイプに比べ柔軟に割り当てる事が出来ない。以上がファームウェアタイプの特徴になります。ServerやXenに代表される専用カーネルを用意する方式。この専用カーネルの事を「ハイパーバイザ」、または「VMM」などと呼びます。簡単に言ってしまえば予め仮想化に特化され最適化されているソフトウェアを用意し、その上に仮想OSを作成していくと言った方式です。ハイパーバイザタイプの中でもBIOSを持つものと持たないものの違いがあります。後者の方式を「パラバーチャライゼーション(準仮想化)」と言います。これらの違いはCPUの動作モードの違いやそれにより処理形態の違いなど、これの説明だけで記事が出来上がってしまうので詳細はまた別の機会に。簡単に言いますと、バイナリートランスレーションは多少のオーバーヘッドがあるが仮想OS側の修正はなくても済む。パラバーチャライゼーションはバイナリートランスレーションよりオーバーヘッドが少ないが仮想OS自体に修正が必要になる。(ゲストOSが限られてしまう)と言った違いになります。長所リソースの割当てがファームウェア方式に比べ自由度が高い。ピーク時などに合わせて動的に自動で割当てる事が可能。短所HWとの間にVMMが存在しているため、少なからずオーバーヘッドが存在する。物理的なリソースを仮想OS間で共有する為、障害に影響範囲が多岐に渡る。以上がハイパーバイザータイプの特徴になります。エミュレーションタイプの仮想化方式である。ホストOS上に専用のアプリケーションをインストールして、そのアプリ上で仮想OSをエミュレートして動かします。長所アプリを入れるだけで仮想環境の構築が可能な為、導入が非常に容易。ハードウェア依存の傾向も他の方式に比べると少ない。仮想OSとHWの間に、エミュレーションソフト、ホストOSと階層があるため他の方式に比べオーバーヘッドが多くなる。以上がアプリケーション方式の特徴になります。突き詰めて行くとだんだんと難しくなります。簡単に纏めてみました。前回詳細な説明を省いてしまったこの二つについてお話してみたいと思います。本題に入る前に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はリング0で動作しているので、ここからの特権命令はもちろん例外なく実行されると言う訳です。これがバイナリートランスレーションと呼ばれる仕組みになります。(実際には仮想OSからの全ての処理を例外ハンドラで処理している訳ではなく、VMMの実装の仕方、命令によっては、直接命令を横取りしたりもしています。)バイナリートランスレションは上記のようなトリッキーかつ複雑な動きをする為、オーバーヘッドが少なからず発生してしまいます。パラバーチャライゼーションパラバーチャライゼーションもVMMを持っている事は先程説明しましたが、パラバーチャライゼーションの場合は仮想OSがリング1、もしくは2で動作します。バイナリートランスレーションと違い、仮想OS上のコードを変更し、リング0でしか処理できないような特権命令をCPUに命令するのではなく、VMMに一度渡してあげるようしています。仮想OS自身が自分が動作しているレベルはリング0以外である事を認識していると言う事になります。例外ハンドラやトラップの処理がない為、バイナリトランスレーションよりオーバーヘッドが少なくて済むという利点があります。専用にコンパイルされているOSしか動かせないといった制限があります。説明してみましたが、ソフトウェアレベルでの仮想化はどうしてもオーバーヘッドや制限などが存在してしまいます。これに対して、最近はハードウェアレベルでの仮想化を支援する技術もあり、IntelのVTやAMD-VなどのCPUの仮想化支援機能などが代表的なものです。こちらはまた機会があったら纏めてみたいと思います。ESX(3.0と3.5)の環境でFCスイッチの障害が起こりました。この環境はESXにFC経由で共有ストレージを持たせており、そこの途中にあるFCスイッチに障害が発生してFCの経路が切り替わりました。ここまではいいのですが、FCパスのFailOver後になんとLinuxサーバの1/3くらいファイルシステムがReadOnlyになってしまった。軽くパニックったがどうしようもなかったのでReadOnlyのサーバを全台再起動して復旧。復旧はさせたので原因調査を開始。ReadOnlyになったサーバだが、Linuxサーバのうち約1/3程度。現象が発生しなかったサーバとの違いはどうやらOSのバージョンくらい。Documentを眺めていたらあっさり原因を発見。Documentどうやら、パスのFailOverが発生した場合に特定のGestOSを使用していると発現する障害らしい。やっかいな事にESX側のバグではなく、GestOS側の問題なので、修正はGestOS側になるらしい。その修正にはOSのバージョンをあげろとの事。結局対処方法が他に見つからなかったのでOSのバージョンをあげる事にしました。修正パッチとかもう少しスマートな方法で対応出来ると思ってたけど、なんだかな~。VMwareESXではパスが二重化されていて且つストレージのコントローラが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なのに片系しか使用しておらずリソースを無駄に余らせてしまう事になります。そこで、下記にある通りにパスを切り替えてあげることにします。A上記のように設定してあげれば、アクセスが均等に分散されます。実際に設定する場合は、まずVIClientからVCに繋げます。「Storage」メニューから対象LUNを選択して、「Properties」を開きます。Pathes画面にいきます。「Enable」にチェックを入れてあげればOKです。後は上記の繰り返しとなります。以上で、手動ではありますがパスのロードバランシングが可能になります。balancer」という項目があります。これは今回のように手動で設定していくのではなく、自動で負荷分散してくれる設定です。今回こちらで設定しなかったといつと、これはまだ試験的サポートのみとあったからです。(少し前の話なのでもしかしたらもう本番サポートも開始したかも?)この辺調べきれてなくてすみません。どなたか情報お持ちでしたら教えて下さい。CowboyフリーランスのLinuxエンジニア(仕事募集中@20代後半)生業として主にインフラ系(サーバ、ネットワーク、ストレージとなんでも)設計、構築、運用を行ってます。技術書の執筆などなど仕事があれば何でもこなします。問いませんのでご興味のある方はご相談下さい。記事にご質問、ご興味のある方はご連絡頂ければ可能な限り回答致します。