タグ

memoryに関するrin51のブックマーク (9)

  • 第6回 Linux Kernelメモリ管理最新動向[その2] | gihyo.jp

    2012年6月6日~8日にLinuxCon Japan 2012 が開催されます。ここではLinux Kernelの最新技術の発表や議論がいろいろ行われるのですが、このカンファレンスを楽しむ手助けとなる記事を…ということで、最近のLinux Kernelのメモリ管理の以下のトピックについて、2回に分けて紹介しています。 第2回目の今回は、以下のテーマについて説明します。 ファイルシステム、デバイスと連携したエンハンス メモリ資源管理機能(cgroup) CleanCache ファイルシステム・デバイスと連携したエンハンス I/O less dirty throttling Linuxでは「ファイルシステムに書き戻す必要のあるデータを持ったページ」をdirty pageと呼びます。これらのページはファイルシステムにデータを書くまでは破棄できませんから、メモリ回収前にI/Oを行う必要があります

    第6回 Linux Kernelメモリ管理最新動向[その2] | gihyo.jp
  • 無視できないフラグメンテーション問題への解答は?(1/2) - @IT

    1月版 無視できないフラグメンテーション問題への解答は? 小崎資広 2010/2/10 当初、今回はmemory compactionとtransparent hugepageという2つのトピックを取り上げ「Hugepage大特集」にしようと思っていたのですが、並列プログラミングカンファレンスに触発され(正確には、そのカンファレンスに参加できなくて悔しかったことに触発され)、後者を急きょ、ロックレスネタに差し替えて紹介します。 でもこれが大失敗で、調査が大変過ぎて泣けたうえに、スケジュールがとんでもないことに。人間、思い付きで行動してはいけないといういい見ですね。 Melの悲願なるか? Memory Compactionチャレンジ Mel Gormanは、Memory Compaction v1パッチシリーズを投稿しました。これは「Linuxメモリ管理の最先端を探る」で説明したAnti

  • Linux メモリ断片化 (外部フラグメンテーション) の概要と解消方法 - Qiita

    ■ 記事概要 Linux OS におけるメモリ断片化 1 ( 以降、断片化 ) について、調査したことのまとめ。 ■ 要約 断片化していると、空きメモリが十分あるにも関わらず、メモリ確保に失敗することがある。 断片化の影響を受けるのは、DMA ( Direct Memory Access ) のように物理メモリ領域を直接参照する必要があるもの ( 仮想メモリを使える場合は、物理メモリ領域が連続している必要がないため影響なし )。 断片化のレベルは /proc/buddyinfo や /sys/kernel/debug/extfrag/unusable_index から確認可能。 明示的に断片化を解消する方法は、OS 再起動と、# echo 1 > /proc/sys/vm/compact_memory がある。 ■ 物理メモリ領域について 断片化の話の前に物理メモリ領域について整理する。

    Linux メモリ断片化 (外部フラグメンテーション) の概要と解消方法 - Qiita
  • メモリのデフラグはどうやって動いてる? Linux Kernelの「Compaction」にみる断片化解消の仕組み

    Kernel/VM探検隊はカーネルや仮想マシンなどを代表とした、低レイヤーな話題でワイワイ盛り上がるマニアックな勉強会です。齊加氏は、Linux KernelコードからCompaction機能の仕組みや工夫点を調査した結果について発表しました。 メモリの虫い状態を緩和するデフラグメンテーション 齊加匠氏:「Deep Dive into the Linux Kernel メモリ管理におけるCompaction機能について」というタイトルで株式会社エヌ・ティ・ティ・データの齋加が発表します。 自己紹介です。所属は株式会社エヌ・ティ・ティ・データで、業務はアプリケーション開発です。OSは関係ないんですが、アプリケーション開発をしていて、主にSpringを使っています。好きなものはGolangやArch Linuxです。かねてよりメモリ管理に興味があって、Linux Kernelのメモリ管理につ

    メモリのデフラグはどうやって動いてる? Linux Kernelの「Compaction」にみる断片化解消の仕組み
  • プロセスの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.

    プロセスのVSZ,RSSとfree,meminfo挙動を実機で確認 - のぴぴのメモ
    rin51
    rin51 2021/04/06
    rssやvmsなど
  • Debug out-of-memory with /var/log/messages

    The following report is thrown in my messages log: kernel: Out of memory: Kill process 9163 (mysqld) score 511 or sacrifice child kernel: Killed process 9163, UID 27, (mysqld) total-vm:2457368kB, anon-rss:816780kB, file-rss:4kB Doesn't matter if this problem is for httpd, mysqld or postfix but I am curious how can I continue debugging the problem. How can I get more info about why the PID 9163 is

    Debug out-of-memory with /var/log/messages
    rin51
    rin51 2021/03/30
    OOM Killerに殺されたときのログの項目の意味
  • TOMCAT殺害事件 - Qiita

    OOMKillerの殺意 顧客EC2のTomcatがアクセスの無い早朝にもかかわらずOOMKillerに突然殺されてしまったので、調査した顛末をたぶん同じような問題に直面されている方もおられるかと思いますので備忘録として記載します。 Javaヒープのチューニングにも多少役立つかと思います。 (この記事はJava8が対象となります。) OOMKillerとはOut of Memory時に、サーバ全体を守るためにメモリーを消費しているプロセスを停止するLinuxの標準機能です。 そのOOMKillerになんとTomcatが突然殺害されてしまいました。 問答無用の辻斬り状態です。 早朝ですのでアクセスログには何も記録されておらず、catalina.outには OpenJDK 64-Bit Server VM warning: Setting LargePageSizeInBytes has no

    TOMCAT殺害事件 - Qiita
    rin51
    rin51 2020/01/10
    この設定項目はeclipseくらいでしか見たこと無いので(Java知らん) 図がありがたい
  • 【Linux】stressコマンドを使わずに手軽にメモリ負荷をかける方法 - APC 技術ブログ

    ※前回はCPU負荷をかける方法でしたが、今回はメモリ負荷をかける方法のご紹介です 擬似障害などでメモリ負荷をかける際に一般的なstressコマンドですが、標準パッケージではないため、インストールできない場合(勝手にインストールできない、インターネットに接続できない環境など)は以下の方法で手軽にメモリ負荷がかけられます。(メモリ使用率/SWAP) 手順 1.以下のコマンドを実行 メモリ負荷コマンド /dev/null < $(yes) 2.1プロセスでは足りないという方は、バックグラウンドに回して複数実行 メモリ負荷×10 # /dev/null < $(yes) & # /dev/null < $(yes) & # /dev/null < $(yes) & # jobs [1] 実行中 /dev/null < $(yes) & [2]- 実行中 /dev/null < $(yes) & [

    【Linux】stressコマンドを使わずに手軽にメモリ負荷をかける方法 - APC 技術ブログ
  • slab肥大化とdentry_cacheに辿り着くまでの話 - Qiita

    内容(3行) memoryの使用量を監視している所からアラートが来て調査した アプリケーションのheap使用率は高くなく、top等を見ても他に怪しいプロセスが存在しない /proc/meminfoからslab領域の肥大を確認、slabtopでdentry_cacheが肥大化している事がわかったので、echo 2 > /proc/sys/vm/drop_caches を実施した 何があったのか 運用中のとあるサーバーのmemoryが残り20%を切ったとアラートが来たため、調査を行った。 当初は何かしらのプロセスがメモリリークしているか何かだろうとあたりをつけていた。 freeで現状確認 キャプチャとるの忘れた… が、一旦確かにfree(buffers, cahceを足したもの)がtotalの20%を切っていることを確認。 topで確認する アプリケーションプロセスにメモリを大量消費しているプ

    slab肥大化とdentry_cacheに辿り着くまでの話 - Qiita
  • 1