はじめに linuxのメモリ利用容量(空き容量)の考え方 linuxのメモリ利用容量/空き容量の計算方法 ■RHEL7 【freeコマンドとmeminfoの図解】 【計算方法】 freeコマンド表示例 /proc/meminfo表示例 ■RHEL6 【freeコマンドとmeminfoの図解】 【計算方法】 freeコマンド表示例 /proc/meminfo表示例 ■RHEL5以前 【freeコマンドとmeminfoの図解】 【計算方法】 freeコマンド表示例 /proc/meminfo表示例 蛇足 その1：無名ページとファイルページ その２：図解の内容のツッコミ その３：RHEL6の計算 その４：Inactiveを空き領域とすることは間違い。 はじめに linuxサーバを利用する上で何時も頭を悩ますものの一つが、メモリ利用状況の評価(メモリ利用率)ではないでしょうか。私も悩みます。そこで
# ps aux | grep unicor[n] USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND user 1111 0.0 10.4 479180 177440 ? Sl Aug16 0:38 unicorn worker[0] -D -E production -c /RAILS_ROOT/config/unicorn.rb user 2222 0.0 10.5 547060 178604 ? Sl Aug16 0:39 unicorn worker[1] -D -E production -c /RAILS_ROOT/config/unicorn.rb user 3333 0.0 10.5 479180 178764 ? Sl Aug16 0:26 unicorn worker[2] -D -E production -
第３回になります。 記事を書くこと自体に時間がかかってしまうので 見やすい記事にするってのが難しいですね。。 少しずつ改良していきます。 ストックやフォローをして頂けると励みになります。 さて、本題です。 jstatやGCログなどを見てメモリがなかなか開放されない場合は ヒープダンプを取ってメモリの中身を解析することになります。 ヒープダンプの取得 まず、jstatやpsコマンド等で対象のJVMのプロセスIDを取得しましょう。 これで指定した場所にダンプファイルができます。 -dump:live,format=...というようにliveをつけるとGCが起きて コマンド実行時に活きているオブジェクトのみのダンプになるようです。 とりあえず今回はフルで取ります。 ヒープダンプの中身を解析をする 解析をするにはツールを使います。 java標準のjhatやMemory Analyzer、HeapA
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 第２回です。 なかなか更新できる時間がないですが マイペースで書いていこうと思います。 ストックやフォローをして頂けると励みになります。 さて前回はGCの仕組みの概要説明とjstatでのモニタリングでした。 今回はCGログの分析をしてみようと思います。 JVMのGCログ設定 まずはGCログが取得できるように設定しないと始まりませんね。 以下のようなオプションをjavaの起動コマンドに付与すると GCの情報を取れるようになります。 -verbose:gc [GC 919089K->41941K(943744K), 0.2300771 se
JavaのWeb開発の開発後期になると性能試験や負荷試験を実施することになると思いますが、 そのフェーズになると色々な問題が起こることが多い。 今まで起きた問題と調査・解決方法をいくつかの回に分けて紹介しようと思います。 まずはメモリリーク。 長時間サーバを起動して運用していたり、負荷試験を実施するとメモリリークを起こすことがある。 ガベージコレクションのおさらい Javaのヒープは大きくnew領域(young領域)とold領域に分かれます。 new領域には生成されてすぐのオブジェクトが格納されてマイナーGCにて未使用になった際に開放されます。 マイナーGCを何度も繰り返されても開放されない(長く参照されている)オブジェクトは old領域へと移動され、こちらはメジャーGC(フルGC)で開放されます。(メジャーGCはnewとperm領域も開放。) もう少し細かく説明すると・・・ new領域は
Oracleの公式ドキュメントには、-Xmxが未指定であった場合のエルゴノミクスによる最大ヒープサイズは『32GBを上限として、物理メモリの4分の1』書かれている。32GBは-XX:-UseCompressedOopsにより圧縮Oopを明示的に無効にした場合の最大デフォルトヒープサイズで、何もオプションを付けずに起動した場合は29GBが上限。 ヒープサイズの決定はarguments.cppのArguments::set_heap_size()で計算されている。デフォルトの最大および初期ヒープサイズは、物理メモリ量により異なる。 デフォルト最大ヒープサイズ(-Xmx) 物理メモリが248MB以下の場合 物理メモリの2分の1。 248MBは-XX:MaxHeapSize(デフォルト124MB) x -XX:MinRAMFraction(デフォルト2)の値。 物理メモリが248MBより大きい場合
前から気になってた。tmpfsって何？ ノートLinuxでファイルシステムのディスク容量を見てみるとこうなってる。 # df -Th Filesystem Type サイズ 使用 残り 使用% マウント位置 /dev/hda2 ext3 19G 7.1G 11G 41% / tmpfs tmpfs 248M 0 248M 0% /lib/init/rw udev tmpfs 10M 64K 10M 1% /dev tmpfs tmpfs 248M 0 248M 0% /dev/shm /dev/hda1 ext3 938M 51M 840M 6% /boot /dev/hda3 ext3 17G 9.7G 6.1G 62% /homeFilesystemの中の/dev/hda達は、/etc/fstabに書いてるから納得だけど、 Typeがtmpfsなのがよくわからない。 仮想メモリベースの
Mac を使っていて、だんだん動きがもっさりしてきたなー*1と思って /private/var/vm/ 下を見ると、案の定スワップファイルが溜まっていることがある。 こういうケースでの対策としては、・スワップ禁止にする、・/usr/sbin/purgeする、・再起動する、といった手があるけど、スワップ禁止にするのは本当にメモリ不足になる可能性を考えると怖いし、purgeはスワップアウトしたデータを回収してくれないので効果は一時的だし、再起動はめんどい。 そんな場合は、処理が落ち着いたタイミングで以下のようにして、スワップを実メモリに書き戻せばよい*2。スワップファイルも全部消える。 $ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.dynamic_pager.plist $ sudo launchctl load
1999年12月にNECと日立製作所のDRAM合弁会社エルピーダメモリ（当時はNEC日立メモリ）ができたときのことである（大変古い話で恐縮ですが）。私は、2000年2月にNEC相模原内のエルピーダ・プロセス開発センターに出向して、同様にNECから出向してきた技術者と一緒にDRAMのプロセス開発を行った。 そのとき、会社が違うと、仕事のやり方がかくも違うものなのかと驚いた。DRAMのプロセスフローは、500工程以上になるが、その各工程で使用する装置が違うとか、そのプロセスの毛色が違うとか、そういったことではない（もちろん、それも違うのではあるが）。プロセス開発の方針と言うか、哲学がまるで違うのである。 簡単に言えば（よく言えば）、NECは「均一性第一主義」であり、日立は「新技術優先主義」であった。悪く言えば、NECは「病的なまでの潔癖完璧主義」であり、日立は「新技術オタクの一点突破主義」であ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
