タグ

メモリに関するatsuizoのブックマーク (9)

  • 【RHEL】linuxメモリのfreeとmeminfoの関係を図解し利用率の計算方法を説明してみる - のぴぴのメモ

    はじめに linuxのメモリ利用容量(空き容量)の考え方 linuxのメモリ利用容量/空き容量の計算方法 ■RHEL7 【freeコマンドとmeminfoの図解】 【計算方法】 freeコマンド表示例 /proc/meminfo表示例 ■RHEL6 【freeコマンドとmeminfoの図解】 【計算方法】 freeコマンド表示例 /proc/meminfo表示例 ■RHEL5以前 【freeコマンドとmeminfoの図解】 【計算方法】 freeコマンド表示例 /proc/meminfo表示例 蛇足 その1:無名ページとファイルページ その2:図解の内容のツッコミ その3:RHEL6の計算 その4:Inactiveを空き領域とすることは間違い。 はじめに linuxサーバを利用する上で何時も頭を悩ますものの一つが、メモリ利用状況の評価(メモリ利用率)ではないでしょうか。私も悩みます。そこで

    【RHEL】linuxメモリのfreeとmeminfoの関係を図解し利用率の計算方法を説明してみる - のぴぴのメモ
  • プロセス毎のメモリ消費量を調べたい時に使えるコマンド - Qiita

    # 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 -

    プロセス毎のメモリ消費量を調べたい時に使えるコマンド - Qiita
  • Java開発の性能改善! その3 ヒープダンプを取ろう - Qiita

    プロセスIDがわかったらjmapコマンドでダンプを取ります。 サーバのディスク容量に注意してください。 heapサイズを2GBとかに設定した場合は2GB以上のファイルが 生成されることがあります。 これで指定した場所にダンプファイルができます。 -dump:live,format=...というようにliveをつけるとGCが起きて コマンド実行時に活きているオブジェクトのみのダンプになるようです。 とりあえず今回はフルで取ります。 ヒープダンプの中身を解析をする 解析をするにはツールを使います。 java標準のjhatやMemory Analyzer、HeapAnalyzerなど いくつかありますが今回はMemory Analyzerを使います。 Eclipseベースなのでサイズの大きいダンプファイルを開く場合は MemoryAnalyzer.iniの設定でツール自体のヒープサイズを 増やす

    Java開発の性能改善! その3 ヒープダンプを取ろう - Qiita
  • Java開発の性能改善! その2 GCログの解析とHeapの設定 - Qiita

    第2回です。 なかなか更新できる時間がないですが マイペースで書いていこうと思います。 ストックやフォローをして頂けると励みになります。 さて前回はGCの仕組みの概要説明とjstatでのモニタリングでした。 今回はCGログの分析をしてみようと思います。 JVMのGCログ設定 まずはGCログが取得できるように設定しないと始まりませんね。 以下のようなオプションをjavaの起動コマンドに付与すると GCの情報を取れるようになります。 -verbose:gc [GC 919089K->41941K(943744K), 0.2300771 secs] こんな感じのGCログが出ます。 -XX:+PrintGCDetails -XX:+PrintGCDateStamps [GC2015-12-10T07:06:41.209+0900: 308.418: [ParNew: 903392K->50610K

    Java開発の性能改善! その2 GCログの解析とHeapの設定 - Qiita
  • Java開発の性能改善! その1 jstatによるヒープ/GCの確認 - Qiita

    JavaのWeb開発の開発後期になると性能試験や負荷試験を実施することになると思いますが、 そのフェーズになると色々な問題が起こることが多い。 今まで起きた問題と調査・解決方法をいくつかの回に分けて紹介しようと思います。 まずはメモリリーク。 長時間サーバを起動して運用していたり、負荷試験を実施するとメモリリークを起こすことがある。 ガベージコレクションのおさらい Javaのヒープは大きくnew領域(young領域)とold領域に分かれます。 new領域には生成されてすぐのオブジェクトが格納されてマイナーGCにて未使用になった際に開放されます。 マイナーGCを何度も繰り返されても開放されない(長く参照されている)オブジェクトは old領域へと移動され、こちらはメジャーGC(フルGC)で開放されます。(メジャーGCはnewとperm領域も開放。) もう少し細かく説明すると・・・ new領域は

    Java開発の性能改善! その1 jstatによるヒープ/GCの確認 - Qiita
  • JDK8(Linux 64bit)のデフォルトヒープサイズ - n-agetsumaの日記

    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より大きい場合

    JDK8(Linux 64bit)のデフォルトヒープサイズ - n-agetsumaの日記
  • tmpfsが/dev/shmをマウントしている件 - サーバー技術メモ

    前から気になってた。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なのがよくわからない。 仮想メモリベースの

    tmpfsが/dev/shmをマウントしている件 - サーバー技術メモ
  • Mac OS Xで、再起動せずにスワップを解放する方法 - kazuhoのメモ置き場

    Mac を使っていて、だんだん動きがもっさりしてきたなー*1と思って /private/var/vm/ 下を見ると、案の定スワップファイルが溜まっていることがある。 こういうケースでの対策としては、・スワップ禁止にする、・/usr/sbin/purgeする、・再起動する、といった手があるけど、スワップ禁止にするのは当にメモリ不足になる可能性を考えると怖いし、purgeはスワップアウトしたデータを回収してくれないので効果は一時的だし、再起動はめんどい。 そんな場合は、処理が落ち着いたタイミングで以下のようにして、スワップを実メモリに書き戻せばよい*2。スワップファイルも全部消える。 $ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.dynamic_pager.plist $ sudo launchctl load

    Mac OS Xで、再起動せずにスワップを解放する方法 - kazuhoのメモ置き場
  • 均一性のNECと一点突破の日立 手段と目的を履き違えていた半導体技術文化 | JBpress (ジェイビープレス)

    1999年12月にNECと日立製作所のDRAM合弁会社エルピーダメモリ(当時はNEC日立メモリ)ができたときのことである(大変古い話で恐縮ですが)。私は、2000年2月にNEC相模原内のエルピーダ・プロセス開発センターに出向して、同様にNECから出向してきた技術者と一緒にDRAMのプロセス開発を行った。 そのとき、会社が違うと、仕事のやり方がかくも違うものなのかと驚いた。DRAMのプロセスフローは、500工程以上になるが、その各工程で使用する装置が違うとか、そのプロセスの毛色が違うとか、そういったことではない(もちろん、それも違うのではあるが)。プロセス開発の方針と言うか、哲学がまるで違うのである。 簡単に言えば(よく言えば)、NECは「均一性第一主義」であり、日立は「新技術優先主義」であった。悪く言えば、NECは「病的なまでの潔癖完璧主義」であり、日立は「新技術オタクの一点突破主義」であ

    均一性のNECと一点突破の日立 手段と目的を履き違えていた半導体技術文化 | JBpress (ジェイビープレス)
    atsuizo
    atsuizo 2013/07/09
    おもしろいエピソード。そして、平たく言うとパレートの法則そのまんま。
  • 1