プロセスのVSZ,RSSとfree,meminfo挙動を実機で確認 - のぴぴのメモ
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.
Go言語のメモリ管理
ソフトウェアにとってメモリは不可欠です。 実行する命令も、メモリにロードしなければ実行できません。 ソースコードに書かれた定数値も、いったんメモリにロードしないと使えません。 関数を呼び出すにも、スタックと呼ばれるメモリ領域が必要です。 スタック以外に、ヒープと呼ばれるメモリ領域が必要なこともあります。 今回は、Go言語のプログラマーが作成するプログラムの下で、どのようにメモリが管理され利用されるかを探ります。 Go言語のメモリ管理というとガベージコレクターの話を思い起こすかもしれませんが、ガベージコレクターについては本連載では取り上げません。 メモリ確保の旅 コンピューターに接続されている物理的なメモリチップが、どのような過程を経てプログラムで使われるのか、順番に見ていきましょう。 （1）: カーネル 最近のオペレーティングシステムでは複数のプロセスを同時に実行できます。 それらのプロセ
どうしてメモリはスワップするのか！？
こんにちは。斎藤です。 最近、新しいスキー板が欲しいなと思っています。現在使っているOGASAKAの板は5年目に入り、メーカーからこれ以上はチューンナップ(メンテナンス)はできないよ、と言われてしまいました。もし、次に買うなら、スノーボーダーの人と一緒にパウダーに飛び込みやすいセミファットタイプが良いのかなと考えています。皆さんのオススメ、ぜひ教えてください。 さて、今日はLinux Kernel上でのメモリ管理、特にページ回収(Page Reclaim)とスワップに絞り、「スワップの理由」「ページを回収する仕組み」そして「スワップの様子を観察する」の3点に分けてお話しします。「スワップするのが気持ち悪い」と考えている方は少なくないと思いますし、私もそう考えていた時期がありました。しかし、それは本当に悪い事なのか、今回掘り下げて行きます。 ※主な対象Kernelは2.6.32(Red Ha
物理アドレス空間と仮想アドレス空間の違いとその基礎知識 : WebとPCのメモ帳
以前のエントリ3GBの壁についての個人的なまとめ(補足)でWindowsの3GBスイッチについてまたの機会に触れる、と書きました。今回はそれについてのエントリを起こそうと思ったのですが、よく考えるとその理解の前提となる「仮想アドレス空間」と「物理アドレス空間」についてまったく扱ってないということに気がつきました。 両者は非常に混同しやすく、このふたつの違いがわかっていないと3GBスイッチのエントリを読んでも意味不明なだけで終わってしまうでしょう。 というわけで、このエントリでは「仮想アドレス空間」と「物理アドレス空間」とは何であってどう違うのかを、私が調べた範囲でまとめてみようと思います。 ご注意 このエントリは話をわかりやすくするために、技術的な話を非常に簡略化して書いています。「正しい情報」を求める場合は、きちんとした文献に当たることをお勧めします。また、明らかな間違い・認識違いがある
減り続けるメモリ残量！ 果たしてその原因は!?
Mem行のfree（MemFreeと呼ぶことにします）は「空きメモリ量」ではなく、何の用途にも使っていない物理メモリ量と考えてください。「MemFreeが少ない→空き物理メモリ量が少ない→利用可能な物理メモリ量が足りない」という発想を防ぐためです。この場合、単純に物理メモリを追加しても、いつかはMemFreeが少ない状況に落ちていくため、解決にはなりません。 システム全体のメモリ利用量の監視は、freeのみを判断基準とするのではなく、もっと総合的に「利用可能な物理メモリ量」を計算する必要があります。 システムが利用可能なメモリ量を計算するには、Linuxのページキャッシュの扱いを理解する必要があります。LinuxはHDDなどのストレージに保存してあるデータの読み出し／書き出し時に確保したメモリをページキャッシュという形で保持します。 CPU はストレージのデータを直接読むことはできません。
エラーログで障害原因を突き止めろ！
エラーログに対応する～OOM Killer編 続いて、/var/log/messagesに図2-1のようなログが記録された場合の対応を考えてみましょう。このログはOOM（out of memory） Killerによりhttpdプロセスが強制終了されたことを示すログです。 OOM Killerとは、システムがメモリ枯渇すると、稼働中のプロセスを強制終了させて空きメモリを確保するLinuxカーネルの仕組みで、メモリ枯渇によるシステム停止を防止するために用意されています。 このログが記録された場合、まず必要になるのはプロセスの存在確認です。OOM Killerは比較的重要なプロセスも容赦なく強制終了させてしまいますので、必要なプロセスが存在しているかを確認する必要があります。 図2-1のログではhttpdが終了させられているので、以下のコマンドを実行しhttpdプロセスの存在を確認します。 $
さくらクラウド・さくらVPS・AmazonEC2・Rackspace CloudでRailsプロジェクトを作ってベンチマーク - ふじおかのブログ -Ruby牛タン親方は休憩中です-
環境 Ubuntu 12.04 Ruby-1.9.3 Rails-3.2 apache2 + Passenger この環境をすべてのクラウドに構築して、 ベンチマークをしてみました。 ベンチマーク用のRailsプロジェクトは https://github.com/xibbar/bench に置いておきました。 ベンチマークはapache benchを使って ab -n 400 -c 200 xxxx という感じです。 さくらVPS 2GB プラン 1480円/月 Requests per second: 80.61 [#/sec] (mean)PassengerMaxPoolSizeはデフォルト6なので、 これを16にしても劇的な変化なしです。 ちっちゃいRailsプロジェクトなので、 Passengerプロセスのサイズが50MBを切っているので、 16にしても2GBのプランで大丈夫でした
GC - GCアルゴリズム詳細解説 - livedoor Wiki（ウィキ）
GC¥¢¥ë¥´¥ê¥º¥à¾ÜºÙ²òÀâ ÆüËܸì¤Î»ñÎÁ¤¬¤¹¤¯¤Ê¤¤GC¥¢¥ë¥´¥ê¥º¥à¤Ë¤Ä¤¤¤Æ¾ÜºÙ¤Ë²òÀ⤷¤Þ¤¹ ¥È¥Ã¥×¥Ú¡¼¥¸¥Ú¡¼¥¸°ìÍ÷¥á¥ó¥Ð¡¼ÊÔ½¸ GC ºÇ½ª¹¹¿·¡§ author_nari 2010ǯ03·î14Æü(Æü) 20:47:11ÍúÎò Tweet ¤³¤ÎWiki¤¬Ìܻؤ¹½ê GC¤È¤Ï¡© GC¤ò³Ø¤ÖÁ°¤ËÃΤäƤª¤¯»ö ¼Â¹Ô»þ¥á¥â¥ê¹½Â¤ ´ðËÜ¥¢¥ë¥´¥ê¥º¥àÊÔ Reference Counter Mark&Sweep Copying ±þÍÑ¥¢¥ë¥´¥ê¥º¥àÊÔ IncrementalGC À¤ÂåÊÌGC ¥¹¥Ê¥Ã¥×¥·¥ç¥Ã¥È·¿GC LazySweep TwoFinger Lisp2 Pa
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
