メモリチューニングの一環としてページキャッシュの効率化を纏めてみます。
ちなみに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 商品詳細を見る メモリ管理とプロセス・スケジューリングの項が増補されている。プロセス管理、ファイルシステム、メモリ管理、割り込みハンドラ、同期などソースを交えて説明があるので結構分かりやすい。 |
スポンサーサイト
0
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"を書き込みます。
以上。
カーネルパラメータの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 商品詳細を見る メモリ管理とプロセス・スケジューリングの項が増補されている。プロセス管理、ファイルシステム、メモリ管理、割り込みハンドラ、同期などソースを交えて説明があるので結構分かりやすい。 |
前回のLDAPセッション数の問題ついでに。
セッション数といってもサーバ側はリッスンソケットを生成するだけなので、
扱いはローカルのファイルと同じ。つまりファイルディスクリプタによる訳です。
一プロセス辺りのファイルディスクプリタの限界はulimitのopen filesによるので、
ulimitを使えば簡単に変更可能。
デフォルトは1024だった。
(前回はセッション数1000を超えていたのでかなり危険な状態でした。。)
サービス毎にulimitiの値を指定するにはinitスクリプトに以下を追記するだけ。
例えば、LDAP(slpad)のulimitの値を変えるには以下のようにする。
/etc/init.d/slapd
ulimit -Sn 8192 ←ソフトリミットを8192に変更
ulimit -Hn 8192 ←ハードリミットを8192に変更
これでセッション数が1000を超えても全然大丈夫。
(もちろん物理リソースの許す限り)
ついでにOS全体の扱えるファイルディスクリプタを変更するにはカーネルパラメータで。
sysctl -w fs.file-max=xxxxxx ←システム全体で使えるファイルディスクリプタ上限
sysctl -w kernel.threads-max=xxxxxx ←システム全体で使えるスレッド上限(ついで)
以上。
セッション数といってもサーバ側はリッスンソケットを生成するだけなので、
扱いはローカルのファイルと同じ。つまりファイルディスクリプタによる訳です。
一プロセス辺りのファイルディスクプリタの限界はulimitのopen filesによるので、
ulimitを使えば簡単に変更可能。
デフォルトは1024だった。
(前回はセッション数1000を超えていたのでかなり危険な状態でした。。)
サービス毎にulimitiの値を指定するにはinitスクリプトに以下を追記するだけ。
例えば、LDAP(slpad)のulimitの値を変えるには以下のようにする。
/etc/init.d/slapd
ulimit -Sn 8192 ←ソフトリミットを8192に変更
ulimit -Hn 8192 ←ハードリミットを8192に変更
これでセッション数が1000を超えても全然大丈夫。
(もちろん物理リソースの許す限り)
ついでにOS全体の扱えるファイルディスクリプタを変更するにはカーネルパラメータで。
sysctl -w fs.file-max=xxxxxx ←システム全体で使えるファイルディスクリプタ上限
sysctl -w kernel.threads-max=xxxxxx ←システム全体で使えるスレッド上限(ついで)
以上。
 | Linuxシステムプログラミング (2008/04/16) Robert Loveロバート ラブ 商品詳細を見る Linuxの概要、カーネル、Cライブラリ、Cコンパイラの基礎知識から、ファイルI/O、バッファサイズ管理、メモリマッピング、システムコール、メモリ管理等実践的なトピックが多く盛り込まれている。 |
Linux関連トピック中心のブログにするつもりでしたが
気付いたらあんまりLinux関連の記事をUPしてませんでした。。
なので今日は珍しくLinuxの話題を一つ。
karnel 2.6.19からリリースされているext4ですが、
世間一般にはあまり浸透してないようですね。
(ext4が既にリリースされている事を知っている人自体私の周りでもあまりいませんでした。。)
かくいう私も一度だけ話題作りの検証をしてみただけです。
検証したのが結構前で情報も乏しかったので今回は
とりあえずext4の特徴について纏めてみたいと思います。
まず初めにですが、ext4は今も開発中ですので機能リストは常に流動的です。
正確に把握しておきたいのであればsourceを読むかkarnel watchしておいて下さい。
今回は現時点の最新stable版2.6.28を中心に特徴を纏めます。
1. 16TB越ファイルシステムの利用(e2fsprogsではまだ未サポート)
1EB(100万TB)まで利用可能らしい、誰が使うんでしょうかと言いたくなる数字です。
ただ大規模なディスクアレイを組むシステムには(将来的にも)有用かも知れませんね。
ちなみに現行主流であるext3は最大約8TB(or16TB)です。
2. メタデータのオーバヘッドを減らすエクステントフォーマット
ext3ではブロックアルゴリズムで4Kbytesなどの単位(ブロック)に分けてディスク領域を
管理しています。ブロックアルゴリズムではディスク上の実アドレスを特定する時サイズが
小さめであれば直接参照できますが、サイズが大きくなると間接ブロックなるものを使用して
間接参照しなければいけません。間接ブロックは使用するブロック数を減らせるのでそういう
意味では非常に有難いのですが、直接参照と比べるとデータブロックへのアクセス回数も
増えますのでパフォーマンスが低下します。さらに、サイズが大きくなるにつれ、一段間接、
二段間接と多段になっていきますのでよりパフォーマンスが悪化します。
そこで、ext4では「エクステント」方式を採用しています。
エクステントとは、連続したブロック領域には一つのアドレス(開始アドレス)だけをサイズ、
オフセットなどと一緒に論理セットとして渡してあげアドレッシングを効率化する方式です。
ファイルサイズの大きいファイルの削除時などはこれによって削除時間が短縮できます。
その他にもfsckの時間が短くなるといった利点もあります。
3. ファイル割り当ての改善 (複数ブロックアロケーション)
ext3では連続データを書き込む時に都度空きブロックを探して割り当てていました。
しかしext4ではブロックアロケーター自身が書込みデータ量に応じて必要となる合計
ブロック数を認識し、単一コールで複数ブロックを一気に割り当てる事が可能になりました。
これにより、ブロックアロケートによるオーバヘッドを緩和する事が出来ます。
4. 32000 のサブディレクトリ数制限の撤廃
ext3では32000までとサブディレクトリの制限がありましたが、ext4では撤廃されました。
5. mtime, atime, ctime, create time(作成時刻) に nsec 単位のタイムスタンプ
ext3やたいていファイルシステムでは秒単位のタイムスタンプですが、
ext4ではナノ秒単位まで拡張します。
6. ディスク上での inode バージョンフィールド (NFSv4、Lustre)
これらのファイルシステムで利用される64bitのバージョン番号が導入されました。
7. uninit_bg 機能による e2fsck 時間の削減
ファイルシステム作成時に全てのグループを初期化しないので、
ファイルシステム作成時間が短くなります。
また、未初期化(未使用)部分はfsck時にスキップされるので、fsckの時間も短縮されます。
8. 頑健さと性能を向上させるジャーナルチェックサム機能
ジャーナルデータにチェックサム機構を取り入れました。
これにより信頼性とパフォーマンスが向上します。
9. 永続的事前割り当て(ストリーミングメディアやデータベース向け)
実際の動作前に、予めアプリケーションが使用予定の領域を確保する場合、
ほとんどのファイルシステムは確保済みだが未使用の領域には0を書き込みます。
ext4はこの方法を使わず一括してディスク割当てが行われるので、フラグメンテーション
を抑えられる。一部のデータベースやストリーミングではパフォーマンスが向上する。
10. 巨大ファイルのサポート
ext3では2TBであった最大ファイルサイズが、ext4では16TBになりました。
11. 遅延割当て
ext3では、データがバッファに書き込まれる際にディスク空間(ブロック)の割当てが
行われていました。これに対してext4ではバッファからディスクに書き込まれる際に
割当てが行われるようになったので、ディスク上でより連続した領域への保存が出来ます。
また、短期間やテンポラリなファイルは物理ディスク空間が割り当てられる前に消去される
可能性もあるので、パフォーマンスも向上します。
ざっとあげてみました。
この他にもflex_bgといった機能や将来的には
オンラインデフラグツールなんかもあるよとのことです。
(オンラインデフラグツールは実際にはもうありますがテストなどが充分ではないようです)
興味がある方は是非kernel sourceを読んで見てください。
気付いたらあんまりLinux関連の記事をUPしてませんでした。。
なので今日は珍しくLinuxの話題を一つ。
karnel 2.6.19からリリースされているext4ですが、
世間一般にはあまり浸透してないようですね。
(ext4が既にリリースされている事を知っている人自体私の周りでもあまりいませんでした。。)
かくいう私も一度だけ話題作りの検証をしてみただけです。
検証したのが結構前で情報も乏しかったので今回は
とりあえずext4の特徴について纏めてみたいと思います。
まず初めにですが、ext4は今も開発中ですので機能リストは常に流動的です。
正確に把握しておきたいのであればsourceを読むかkarnel watchしておいて下さい。
今回は現時点の最新stable版2.6.28を中心に特徴を纏めます。
1. 16TB越ファイルシステムの利用(e2fsprogsではまだ未サポート)
1EB(100万TB)まで利用可能らしい、誰が使うんでしょうかと言いたくなる数字です。
ただ大規模なディスクアレイを組むシステムには(将来的にも)有用かも知れませんね。
ちなみに現行主流であるext3は最大約8TB(or16TB)です。
2. メタデータのオーバヘッドを減らすエクステントフォーマット
ext3ではブロックアルゴリズムで4Kbytesなどの単位(ブロック)に分けてディスク領域を
管理しています。ブロックアルゴリズムではディスク上の実アドレスを特定する時サイズが
小さめであれば直接参照できますが、サイズが大きくなると間接ブロックなるものを使用して
間接参照しなければいけません。間接ブロックは使用するブロック数を減らせるのでそういう
意味では非常に有難いのですが、直接参照と比べるとデータブロックへのアクセス回数も
増えますのでパフォーマンスが低下します。さらに、サイズが大きくなるにつれ、一段間接、
二段間接と多段になっていきますのでよりパフォーマンスが悪化します。
そこで、ext4では「エクステント」方式を採用しています。
エクステントとは、連続したブロック領域には一つのアドレス(開始アドレス)だけをサイズ、
オフセットなどと一緒に論理セットとして渡してあげアドレッシングを効率化する方式です。
ファイルサイズの大きいファイルの削除時などはこれによって削除時間が短縮できます。
その他にもfsckの時間が短くなるといった利点もあります。
3. ファイル割り当ての改善 (複数ブロックアロケーション)
ext3では連続データを書き込む時に都度空きブロックを探して割り当てていました。
しかしext4ではブロックアロケーター自身が書込みデータ量に応じて必要となる合計
ブロック数を認識し、単一コールで複数ブロックを一気に割り当てる事が可能になりました。
これにより、ブロックアロケートによるオーバヘッドを緩和する事が出来ます。
4. 32000 のサブディレクトリ数制限の撤廃
ext3では32000までとサブディレクトリの制限がありましたが、ext4では撤廃されました。
5. mtime, atime, ctime, create time(作成時刻) に nsec 単位のタイムスタンプ
ext3やたいていファイルシステムでは秒単位のタイムスタンプですが、
ext4ではナノ秒単位まで拡張します。
6. ディスク上での inode バージョンフィールド (NFSv4、Lustre)
これらのファイルシステムで利用される64bitのバージョン番号が導入されました。
7. uninit_bg 機能による e2fsck 時間の削減
ファイルシステム作成時に全てのグループを初期化しないので、
ファイルシステム作成時間が短くなります。
また、未初期化(未使用)部分はfsck時にスキップされるので、fsckの時間も短縮されます。
8. 頑健さと性能を向上させるジャーナルチェックサム機能
ジャーナルデータにチェックサム機構を取り入れました。
これにより信頼性とパフォーマンスが向上します。
9. 永続的事前割り当て(ストリーミングメディアやデータベース向け)
実際の動作前に、予めアプリケーションが使用予定の領域を確保する場合、
ほとんどのファイルシステムは確保済みだが未使用の領域には0を書き込みます。
ext4はこの方法を使わず一括してディスク割当てが行われるので、フラグメンテーション
を抑えられる。一部のデータベースやストリーミングではパフォーマンスが向上する。
10. 巨大ファイルのサポート
ext3では2TBであった最大ファイルサイズが、ext4では16TBになりました。
11. 遅延割当て
ext3では、データがバッファに書き込まれる際にディスク空間(ブロック)の割当てが
行われていました。これに対してext4ではバッファからディスクに書き込まれる際に
割当てが行われるようになったので、ディスク上でより連続した領域への保存が出来ます。
また、短期間やテンポラリなファイルは物理ディスク空間が割り当てられる前に消去される
可能性もあるので、パフォーマンスも向上します。
ざっとあげてみました。
この他にもflex_bgといった機能や将来的には
オンラインデフラグツールなんかもあるよとのことです。
(オンラインデフラグツールは実際にはもうありますがテストなどが充分ではないようです)
興味がある方は是非kernel sourceを読んで見てください。
| 詳解 Linuxカーネル 第3版 (2007/02/26) Daniel P. BovetMarco Cesati 商品詳細を見る メモリ管理とプロセス・スケジューリングの項が増補されている。プロセス管理、ファイルシステム、メモリ管理、割り込みハンドラ、同期などソースを交えて説明があるので結構分かりやすい。 |
ちょっとした事情でBIG-IPで管理していたSSLの
証明書をWEBサーバに直接入れる事になりました。
ちなみに証明書はベリサインで署名済みのCSRです。
まずはBIG-IPで証明書と秘密鍵をエクスポートします。
この時中間証明書も忘れない事に注意。
そしては後はWEBサーバに持ってきてApacheで設定するだけ。
Virtual hostを使用しますが今回はIPベースのVirtual hostを使いました。
NameベースのVirtual hostはSSLが使えないと思っている人が結構いるみたいですが、
最近はSNIやワイルドカード証明書、subjectAltNameを使用すればいけます。
また機会がありましたらこちらは纏めてみたいと思います。
今回はApacheの2.0系を使用しましたので、SSLの設定はssl.confで行います。
ssl.confはデフォルトの設定のままでも動きますので、設定するパラメータはこれくらい。
Virtual host
SSLCertificateFile (証明書)
SSLCertificateKeyFile (秘密鍵)
SSLCertificateChainFile (中間証明書)
あとはerrorlogやtransferlogなどお好みで設定してください。
ちなみに一度設定した後にApacheの再起動をかけたら起動しませんでした。
起動時のログに以下の文言が。
[error] Init: Unable to read server certificate from file /xxx/xxx/xxx/xxx
どうやら証明書が壊れていて読み込めなかったようで、
もう一度BIG-IPから引っ張ってきて入れ直したら動きました。
あとはブラウザでアクセスして証明書をチェックして終了です。
以上。
証明書をWEBサーバに直接入れる事になりました。
ちなみに証明書はベリサインで署名済みのCSRです。
まずはBIG-IPで証明書と秘密鍵をエクスポートします。
この時中間証明書も忘れない事に注意。
そしては後はWEBサーバに持ってきてApacheで設定するだけ。
Virtual hostを使用しますが今回はIPベースのVirtual hostを使いました。
NameベースのVirtual hostはSSLが使えないと思っている人が結構いるみたいですが、
最近はSNIやワイルドカード証明書、subjectAltNameを使用すればいけます。
また機会がありましたらこちらは纏めてみたいと思います。
今回はApacheの2.0系を使用しましたので、SSLの設定はssl.confで行います。
ssl.confはデフォルトの設定のままでも動きますので、設定するパラメータはこれくらい。
Virtual host
SSLCertificateFile (証明書)
SSLCertificateKeyFile (秘密鍵)
SSLCertificateChainFile (中間証明書)
あとはerrorlogやtransferlogなどお好みで設定してください。
ちなみに一度設定した後にApacheの再起動をかけたら起動しませんでした。
起動時のログに以下の文言が。
[error] Init: Unable to read server certificate from file /xxx/xxx/xxx/xxx
どうやら証明書が壊れていて読み込めなかったようで、
もう一度BIG-IPから引っ張ってきて入れ直したら動きました。
あとはブラウザでアクセスして証明書をチェックして終了です。
以上。
| ホーム |
