SystemTapで真犯人を捕まえろ！：Linuxトラブルシューティング探偵団 番外編（3）（1/4 ページ） NTTグループの各社で鳴らした俺たちLinuxトラブルシューティング探偵団は、各社で培ったOSS関連技術を手に、NTT OSSセンタに集められた。普段は基本的にNTTグループのみを相手に活動しているが、それだけで終わる俺たちじゃあない。 ソースコードさえあればどんなトラブルでも解決する命知らず、不可能を可能にし、多くのバグを粉砕する、俺たちLinuxトラブルシューティング探偵団！ 助けを借りたいときは、いつでもいってくれ！ OS：高田哲生 俺はリーダー、高田哲生。Linuxの達人。俺のようにソースコードレベルでOSを理解している人間でなければ、百戦錬磨のLinuxトラブルシューティング探偵団のリーダーは務まらん。 Web：福山義仁 俺は、福山義仁。Web技術の達人さ。Apache
概要 自分で構築したProxmox VE(PVE)のwebコンソールを眺めていたら、 4GBメモリのVMを4台しか起動していないのに仮想ホストでは48GB中37GBもメモリが使用されていた。 それの原因を突き止めるために調べていたらzfsが原因ということが判明した。 何も知らず、何も気にせず、zfsでPVEを構築していたら気付かない事象だと感じたのと、 メモリについて知ったことが多いため記事にした。 調査1(ホスト再起動) 困った時はホスト再起動するのが一番ということで、まずは再起動。 再起動後はメモリをほとんど使用されていなく、VM起動してもVMのメモリ領域くらいしか使われていない。 これで解決したと思い放置していたら、いつの間にかメモリ使用量が増えている。 なので変なプロセスがいるとかではなく、何かが起きていることがわかった。 調査2(プロセス確認) まずはメモリ使用量を確認する。 /
1.はじめに 1-1.この記事の要旨 1-2.(予習)メモリに関する指標とlinuxのメモリ挙動について 2.検証環境と検証方法 2-1.検証環境 2-2.検証方法 2-3.測定方法 (1)psコマンドによるVSZ,RSS情報の取得 (2)freeコマンドとmeminfo情報の取得 3.結果 3-1.全体の結果 3-2.プロセスのVSZ/RSS挙動 ポイント① malloc()した時の挙動→VSZのみ増加 ポイント② 1回目のデータread時→RSSは増えない ポイント③ データwrite→RSSが増加する 3-3.システムワイドな挙動(freeコマンド/meminfo) ポイント① malloc()した時の挙動→usedもAnonymousPageも増えない ポイント②1回目のデータread時→変化しない。 ポイント③ データwrite→used上昇、AnonymousPage上昇 4.
ヒープは空いているメモリー空間から動的に獲得するものでが、ユーザメモリー空間に空きが有る限り獲得できるものでありません。ユーザプロセスで使用するmalloc関数は、glibcで実装されており、すなわちユーザプロセスとして実装されています。ヒープ処理としてカーネルはそのヒープと使えるメモリー空間を提供するのみで、ヒープ領域を設定するシステムコールはbrk関数です。 まず、min_brkにヒープ開始アドレスをセットしています。CONFIG_COMPAT_BRKでそのアドレスをmm->end_code（実行コードの終端アドレス）か、mm->start_brk（ヒープ開始アドレス）としているようです。そして拡張するアドレスがそれより小さければエラーです。 rlim = current->signal->rlim[RLIMIT_DATA].rlim_curで、プロセスのデータのリソースの拡張が可能で
◆プロセスのアドレス空間の実装 プロセスのアドレス空間は、次のような連続領域に分割されている。 テキスト 機械語を置く。VM_EXEC 属性と VM_READ属性が付いている。書き込み禁止 で共有可能。mm_struct の start_code と end_code が、開始番地と終了番地 を保持する。 データ(初期値付き) データを置く。VM_READ|VM_WRITE 属性が付いている(以下同様)。共有不 可。ファイルに初期値が含まている。 BSS(初期値無しデータ) 0 で初期化されるデータを置く。ファイルに初期値が含まれない。 ヒープ データを置く。malloc() の原資(の１つ)。brk() や sbrk() システム・ コールで大きさが変更される。番地が大きい方に伸びる。mm_struct の start_brk とbrk が開始番地と終了番地を保持する。 スタック 関数呼
HEAP領域とSTACK領域の間の未使用領域は、下記の領域に使われる 共有ライブラリのロード領域 メモリ・マップト・ファイル用領域 プロセス間共有メモリ用領域 メモリ・マップト・I/O用領域 メモリ・マップトによる追加HEAP領域 小さなサイズをmallocをしたときはHEAP領域に確保されるが、大きなサイズのメモリをmallocしたときはメモリマップ領域に確保される(glibcの場合) すべてmmapにするとメモリのフラグメンテーションがおきないが、mmapは重いしページサイズ単位しか扱えない。 32bit環境では論理メモリが2^32=4GBまでしか確保できない。このうちOSがメモリの上位1or2GBを使うので、実際にはアプリは3or2GBまでしかメモリは使えない。64bit環境になると、もっと使えるようになる。 HEAP領域は下に（上位アドレス方向）、STACK領域は上に（下位アドレス
Linuxのメモリ管理について
Linuxのメモリ管理について勉強中なので、簡単なまとめをメモ。 仮想アドレスと実アドレス多くのマルチタスクOSでは仮想アドレス空間を持っています。仮想アドレス空間の仕組みを利用すれば、物理メモリ上では不連続にマッピングされたページでも、プロセスからは連続した領域として扱うことができます。 ここでいうページとは、メモリを一定の大きさに区切って管理するための単位のことで、4Kバイトのことが多いようです。仮想アドレスと実アドレスへの変換はページ変換テーブルを用いて行われます。 実メモリの管理実メモリはバディシステムと呼ばれる仕組みで管理されています。 バディシステムは空きページを２の冪剰の単位で分割したページフレームのリストで管理します。たとえば、4ページ分の連続メモリを確保したい場合は、まずオーダー2（2の2剰個の連続ページ）のリストから空きを探し、無かった場合は一つ上のオーダーから探します
Linux x64環境において、ELF実行ファイル、共有ライブラリ、スタック領域、ヒープ領域のアドレスがどのように決まるのかについてのメモ。 環境 Ubuntu 12.04 LTS 64bit版 $ uname -a Linux vm-ubuntu64 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 12.04.4 LTS Release: 12.04 Codename: precise $ gcc --version gcc (Ubuntu/Linaro 4
2014-05-25 進撃のmalloc #kernelvm 勉強会 malloc - Wikipedia ガチャピン先生 進撃のmallocってなんだ gblicのmalloc近辺の開発にかかわる MM Summit Ruby core commiter(コミット率TOP10コミッタ) @kosaki55tea LKMLでのdisりあい 殴り合い [www.youtube.com/watch?v=cjaRZEtDTxc:embed] ebizzy | Free Development software downloads at SourceForge.net N個のスレッドがs病の間に何回malloc memcpy freeが出来るかを測定 カーネルでは時間をあまり食ってない mallocバグ知識 2行消したら20倍高速化 Linuxキーワード - glibc とは：ITpro 1スレッ
(vm.overcommit_memoryの説明はぐぐってください: google:vm.overcommit_memory) 例えば vm.overcommit_memory = 2 vm.overcommit_ratio = 90なときに、実際の上限と今現在の値はどこで確認できるか？ the total virtual address space on the system is limited to (SS + RAM*(r/100)), where SS is the size of the swap space, and RAM is the size of the physical memory, and r is the contents of the file /proc/sys/vm/overcommit_ratio. proc(5): process info pseu
プログラミング言語 malloc(3)のメモリ管理構造 2007/11/30 技術本部 クラウド基盤エキスパート 角馬 文彦 この記事の目次 malloc()といえばＣ言語ではお馴染みのライブラリで、最も良く使用されるライブラリの一つです。しかしその分だけ何らかの不具合を経験した人も多いのではないでしょうか。本書ではmalloc()、free()で確保、解放されるメモリリソースが内部的にどのように管理されているかを説明していきます。mallocライブラリの仕様を理解する事で、ライブラリ使用時に何らかの不具合が発生した際の手助けになればと思います。 ここではLinuxディストリビューションで標準的に使用されているglibcのmallocライブラリを扱います。今回の調査では次の環境を使用しています。 ディストリビューション :Debian sarge パッケージバージョン :glibc-2.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
