- - PR -
Linux 2.4でのメモリ管理方式について
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-10-26 11:29
はじめまして。RedHat Enterprise Linux ES3 (Kernel 2.4.21SMP) を運用しておりますが、問題が発生しておりますので皆様のお知恵をお貸しいただければと思います。
尚、参照元記事としてリンクさせて頂いておりますのは、本件と関連があると思われた記事ですが、やや古いですので新規にスレッドを立ち上げさせていただきました。 6GBのメモリを搭載したIA32なDual XeonホストでRHEL ES3を動作させております。このホストは同時に50から100程度のユーザがリモートからXを利用するため、プロセス数は最大で1000程度になる事もあります。問題としては、このホストを利用している時に、物理ディスクに対してスワップアウト/インが発生する事により、ディスクのI/O待ちが発生し全てのユーザのXに待ちが発生する、というものです。 ただし、この状況では実際には物理メモリを2GB程度しか使用しておりませんでした。(free(1)コマンドの-/+行により確認) また、このスワップアウト/インが実際に発生しているかどうかについては、vmstatコマンドのsi/soを参照して確認しております。 調べたところ、Linuxの2.4以降では空きメモリは可能な限りキャッシュとして利用し、また、メモリ上のプロセスでも利用されていないものは積極的にスワップアウトして、空いたメモリをキャッシュとして利用するという事が分かりました。この事から、当方で発生している問題の原因としては、INACTIVEな（一時的に利用していない、ただし、実行中である）プロセスがスワップアウトされた後、再度そのプロセスを利用する際にスワップインが発生しているのではないか、と考えております。 この問題を解決するための方法としては、実行中のプロセスが利用しているメモリをスワップアウトしない、というものが考えられますが、このような事は/proc/sys/vm以下を変更するなどの方法で出来ますでしょうか。もしくは、「一時的にスワップアウト/インが大量に発生する」のを防ぐ（分散する）方法はありますでしょうか。 参照元の記事中でangel様がリンクされております「Linux V2.4 カーネル内部解析報告 ドラフト」も参照しましたが、「空きメモリを積極的に利用する」という事しか分かりませんでした。 以上、ご説明不足な点がございましたら、ご指摘をいただければと思います。 どのような情報でも結構ですので、よろしくお願いいたします。 | ||||||||||||
|
投稿日時: 2005-10-26 12:42
こんにちは。
kernelのhigh memoryサポートがどうなっているか…、が気になるところですね。 kernel-smpパッケージに含まれる、/boot/config-〜.ELsmp に、kernel の config が載っていると思います。 kernelのConfigure.helpによれば、1G・4G・64Gの三段階の壁があるようですが。 ※ RHEL3AS のメモリ関連だと、CONFIG_HIGHMEM64G と CONFIG_3GB が有効なようですね。 それにしても、
8GBって中途半端ですね…。どういう config なんでしょう?? | ||||||||||||
|
投稿日時: 2005-10-26 13:29
こんにちわ．
kernel-bigmem なる kernel の rpm package がありましたが， それをお使いでしょうか？ 自分は 2GB を超える Memory を使わせてもらったことが無いので， どう違うのか知りませんが．．． | ||||||||||||
|
投稿日時: 2005-10-26 13:38
こんにちは。早速のご回答、ありがとうございます。
質問の際に、kernelの正確なバージョンを書いておりませんでしたが、 Linux hostname 2.4.21-4.0.1.ELsmp #1 SMP Wed Jan 21 14:18:23 JST 2004 i686 i686 i386 GNU/Linux のようにやや古いものを使用しております。 このkernelの場合、ご指摘いただきましたCONFIG_HIGHMEM64Gは有効になっており ましたが、CONFIG_3GBは設定中に存在しませんでした。 (2.4.21-27...には存在しているのを確認しました。) また、のRHEL AS3のマシンもあるのですが、そのkernelのconfigとdiffを取ったところ、全く差異はありませんでした。 尚、現時点でのfreeの結果と/proc/meminfoの内容は以下のようになります。 # free total used free shared buffers cached Mem: 6125768 4386800 1738968 0 102260 3680708 -/+ buffers/cache: 603832 5521936 Swap: 4192956 65828 4127128 # cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: 6272786432 4492087296 1780699136 0 104714240 3785338880 Swap: 4293586944 67407872 4226179072 MemTotal: 6125768 kB MemFree: 1738964 kB MemShared: 0 kB Buffers: 102260 kB Cached: 3680712 kB SwapCached: 15908 kB Active: 3844588 kB ActiveAnon: 124804 kB ActiveCache: 3719784 kB Inact_dirty: 168500 kB Inact_laundry: 32 kB Inact_clean: 0 kB Inact_target: 802624 kB HighTotal: 5308352 kB HighFree: 1386292 kB LowTotal: 817416 kB LowFree: 352672 kB SwapTotal: 4192956 kB SwapFree: 4127128 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB この結果から、正しく6GB認識されているように思うのですが、、、。
関係あると思われる部分のみ（コメントアウトの不要な部分は除外して）抜き出したところ、 CONFIG_SMP=y CONFIG_NR_CPUS=8 CONFIG_HIGHMEM64G=y # CONFIG_X86_4G is not set のようになっておりました。RHEL ES3では8GBらしいのですが、RHEL ES4では16GBとかかれており、どこで制限かけているのか不明ですね、、、。 | ||||||||||||
|
投稿日時: 2005-10-26 16:22
ES と AS では、kernelの構成は基本同じになっているようですね。
※8GBは、単なるハッタリじゃないかと… しるしるさんの挙げられた freeの結果/meminfo を拝見するに…、ちゃんと6GB有効に使って、なおかつ余裕があると思います。 そうすると問題は、件の「2GB程度しか使用しておりませんでした」の時の状況だと思います。 メモリやswapが直接の原因ではなく、むしろ他のI/O や、CPU使用率、ネットワーク負荷 、ネットワークトラブルが原因となっている可能性が高いように感じるのですが。 ※「Xで待ちが発生」ということからも。 また、「メモリ上のプロセスでも利用されていないものは積極的にスワップアウトして」 というのは確かでして、多量の空きメモリがある状況でもswapは発生するのですが…、 これは恐らく、プロセスのメモリ空間の中で動作に殆ど影響がない部分 ( スタートアップルーチンや、汎用ライブラリの中で使わない部分 ) のみが対象となっているように思います。( アクセス頻度から見て、結果的にそうなる ) 少量の si, so 位では、多量の bi, bo が無い限り、影響は出ないと思います。 ※ なかなかコレ! という検証環境を作り出せないので、完全に憶測ですが。 もう少し、多角的な資料を揃えないと、なかなか絞込みは難しいような…。 以上、ご参考まで。 | ||||||||||||
|
投稿日時: 2005-10-26 23:37
RHELで8GBとか言ってるのは「まあ8GBくらいで勘弁しといてくれや」
くらいのことで、特になにか設定等があるわけではないはずです。 x86用の32ビット版Linuxで、利用できるメモリの限界に関わるのは ・HIGHMEMを使用するかどうか ・PAEを有効にするかどうか の2点です。 HIGHMEMを使わないと1GBまでしか使えませんが、いまどきの ディストロならまずどれでも使うようになってるでしょう。 PAEは、物理空間を32ビットから36ビットに拡張するものです。 すなわち、物理空間の限界が4GBから64GBに拡張されます。 # 余談。物理空間の大きさと、利用できる物理メモリ量とは一致しない RHELの場合、SMPカーネルではPAEが有効になっているので 6GBでも8GBでも、物理メモリはすべて利用できます。 16GBうんぬんという話は... カーネル空間に直接マッピングできるメモリの量から出てくる問題です。 PAEを有効にして約64GBのメモリが利用できるようになったといっても、 実際にそれだけメモリを積んでもパフォーマンスが上がらない、 ということがあって。 16GB超の場合は 4G/4G split を使うほうがいい、という話になって いまして、それが bigmem とかいう名前で出ているカーネルです。 ただし、4G/4G split は巨大なペナルティを伴うので、 動かすプログラムによってはどうしようもなく遅くなる可能性があります。 素直に64ビット版を使うほうが吉でしょう。 さて、本題。と言っても、「分かりません」なんですが 
以前のUnix系OSだと、ファイルキャッシュとして使用するメモリの 大きさをカーネルのパラメータとして設定していたのですが、 バッファ統合が行われてからはそういう設定はなくなっています。 「設定しなくても、カーネルがよきにはからってくれるから」 ということになっています。 ・・・とはいえ、実際にうまく行かないことはあるわけで。 Linuxは、どうもメモリの管理がうまくないという印象があります。 もし、長期間動作させているのなら、リブートしてみるのがいいんじゃ ないかと思うです。 | ||||||||||||
|
投稿日時: 2005-10-27 10:09
おはようございます。
>>kazさん、ぽんすさん ご回答を頂き、ありがとうございます。 kazさんから頂きましたbigmemなkernelというのは、ぽんすさん（詳細なご説明 ありがとうございます）のおっしゃってる4G/4G Splitに対応したものである、 との事ですね。Pentium ProからPAEにより36bitのアドレス空間 (64GB) が利用 出来るようになっているのは存じておりましたが、直にアクセスできる空間が 4GBしか無いため、実装としてはかなり大変なようですね。 (昔のEMSみたいです・・・) 今回当方で利用しているメモリは6GB程度であるため、以下のページによると 1G/3G Splitを利用しようと思います。 http://japan.linux.com/kernel/03/07/10/034238.shtml 尚、該当ホストは1ヶ月ほど前に再起動したばかりです、、、。 >>angelさん freeの結果などからも、やはりメモリは正しく認識されており、利用されて おりましたか、、、ご確認いただきありがとうございます。 そうなると、もう少しどういう状況が発生しているのかの再現確認から行う 必要があるという以前問題が発生したときには、その50-100ユーザ全てに目に 見えて影響がある（遅くて話にならない）という状況が発生しておりました。 後から確認すると確かにsi/soの値が増加しておりましたが、ご指摘を頂きました ように、それが本当の「原因」であるかどうかを切り分けを行う必要があり ますね。 （実は別のところがボトルネックになっていた可能性も・・・） とりあえず現在は運用を変更して同時に利用しないようにしておりますので 問題は発生しておりませんので、時間を見つけて状況の再現試験等を行おうと 思います。 皆様、どうもありがとうございました。 # 他にも何かお気づきの点がありましたら、ご指摘をいただけますと幸いです。 # 当方の情報に関しては可能な限りご提供させて頂きますので、どうぞよろしく # お願いいたします。 | ||||||||||||
|
投稿日時: 2005-10-27 10:32
一点補足させていただきます。
si/soの値が増加と書きましたが、最大でもたかだか500KB/sのIn/Outでした。 この事からもsi/soが問題の本質ではなく、別の問題が考えられそうですね。 また、swapの存在するディスクはRAID5であるため、確かに「高速」ではない ですが、たかだか500KB/s程度で問題があるとも考えにくいですし。 尚、ディスクのベンチマークを取って、RAID5なディスクと通常のディスクの 速度比較を行っておりますが、お勧めの祖父地はございますでしょうか。 現在はhdparmやbonnie++、iozone、hdbench を試しております。 私感としては、bonnie++が良い（デフォルトで実メモリの倍のファイルを 利用してテストを行う）と思われますが、実行するディレクトリが異なる (/dev/sda1 と /dev/sda2 等) と結果が倍以上異なる事があったりして、 いまいちです・・・。 | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。