プログラムを動かす時にメモリがどのように割り当て・解放されるのかをめちゃくちゃわかりやすいイメージ画像で解説してくれるサイト「Memory Allocation」
コンピューター上でプログラムを動作する際に必要になるのがメモリです。プログラム自体をメモリに読み込む必要があるのはもちろん、プログラムが行う動作はほとんど「メモリから値を取りだして計算し、メモリに保存する」であるといっても過言ではありません。プログラムが動作する際にメモリがどのように管理されているのかについて、ベテランプログラマーのサム・ローズさんがブログで解説しています。 Memory Allocation https://samwho.dev/memory-allocation/ C言語の標準ライブラリには「malloc」と「free」という2つの関数が用意されています。この2つはなんと1979年のUnix v7から存在している歴史ある関数で、mallocがメモリの割り当てを担当し、freeがメモリの解放を担当しています。サム・ローズさんの解説は「この2つの関数の中身を自分で実装する」
Memzoom
Memzoom lets you view/monitor the raw memory of processes/files in your UTF-8 terminal. Memzoom is like the less command except designed for binary data with live updates. It represents non-ASCII characters using IBM Code Page 437 as a base-256 binary alphabet. It implements zooming via CTRL+MOUSEWHEEL which uses an image scaling algorithm (better than Lanczos!) that enables you to monitor large a
プログラムがメモリをどう使うかを理解する(2)
この記事は このシリーズの2本目です。 値の表現 前回は 0xDEADBEEF という16進数を直接代入する瞬間を観察しましたが、それができたところであまり嬉しくはありません。なので、もう少し実用的な値がどのように表現され、メモリ上に配置されるのかを見ていこうと思います。 では、main関数の中に変数を色々追加してみましょう。 int main() { bool b0 = true; bool b1 = false; int hp = 9999; int mp = 255; float rate = 0.5f; double pi = 3.14159265358979323846; int intArray[10]; for (int i = 0; i < 10; ++i) { intArray[i] = i; } std::cout << "Hello World!\n"; // ここで
Debug memory leaks with the Microsoft Edge Detached Elements tool
Memory leaks occur when the JavaScript code of an application retains more and more objects in memory that it doesn’t need any longer instead of releasing them for the browser to garbage collect (GC). For long-running apps, small memory leaks of only a few kilobytes can add up to noticeably degrade performance over time. Web developers who use the React framework know that React maintains a virtua
Ruby: mallocでマルチスレッドプログラムのメモリが倍増する理由（翻訳）｜TechRacho by BPS株式会社
要約 メモリ断片化は測定や診断が困難ですが、驚くほど簡単に修正できることもあります。マルチスレッドのCRubyプログラム（mallocのスレッド単位メモリアリーナ）におけるメモリ断片化の原因を追ってみましょう。本記事のボリュームは3343語、20分程度です。 単純な設定変更だけで問題を完全に解決できることはめったにありません。 私の顧客のSidekiqプロセスが大量のメモリを消費していたことがありました（1プロセスあたり1 GB程度）。開始当初の各プロセスは300MB程度でしたが、時間の経過とともにじわじわと肥大化してほぼギガバイトレベルにまで達したところで落ち着き始めました。 私は顧客にMALLOC_ARENA_MAXというたった1つの環境変数の変更を依頼しました。「2に設定してください」と。 プロセス再起動後、「じわじわ肥大化」現象はピタリと止みました。プロセスのメモリ使用量は以前の半
The multi-generational LRU [LWN.net]
Did you know...?LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net. One of the key tasks assigned to the memory-management subsystem is to optimize the system's use of the available memory; that means pushing out pages containing unused data so that they can be put to better u
Linuxのfree コマンドの見方とオプション ~availableやbuff/cacheの定義~
メモリの状態確認コマンド freefree コマンドはメモリの利用状態を確認することができます。 例えば以下のように表示されます。(数値の単位は KiB= 1024 Bytes) [root@localhost ~]# free total used free shared buff/cache available Mem: 3868920 197528 3402296 8680 269096 3444844 Swap: 839676 0 839676ヘッダ (total, used, free, shared, buff/cache, available) のそれぞれの関係は下図の通りです。 このコマンドで、メモリの空き状況を確認したいのであれば、free を見るよりも available を見ましょう。 というのも、Linux の特性として「空きメモリを無駄にしない」という設計思想の元
tracemalloc — Trace memory allocations
Source code: Lib/tracemalloc.py The tracemalloc module is a debug tool to trace memory blocks allocated by Python. It provides the following information: Traceback where an object was allocated Statistics on allocated memory blocks per filename and per line number: total size, number and average size of allocated memory blocks Compute the differences between two snapshots to detect memory leaks To
【Ruby】LinuxとRubyとCoW - 地方エンジニアの学習日記
hiboma.hatenadiary.jp こちらのアンサー記事を書いてみますw なぜ CoW の話が出てきたのか なぜCoWを気にしたのかを話すとまず社内で動かしているAPIサーバがメモリ利用過多となってアラートがなったのが話のスタートでした。サービス自体はUnicornを使って動いています。 メモリ利用過多となったときに調べる手法は言語ごとに様々ですが私はRubyの経験がほぼなくプロファイラなども使ったことがありません。この状況でできることは/procを見るくらいしかなかったので/proc/$pid/smapsを見始めました。そこで始めたのがメモリ共有率の計算でした。 以下のツールを書いてUnicornの親子プロセスのメモリ共有率を確認するとなんと40~60%程度となっていて「え！？」ってなったのが始まりでした。プロセスの生存期間が長いのかと思ったのですが起動時間も出すと数分前に起動し
Rubyのメモリ割り当て方法とcopy-on-writeの限界（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: The Limits of Copy-on-write: How Ruby Allocates Memory 公開日: 2017/08/28 著者: Brandur サイト: https://brandur.org/ Unicorn（またはPumaやEinhorn）を実行していると、誰しもある奇妙な現象に気がつくでしょう。マスタからforkした（複数の）ワーカープロセスのメモリ使用量は開始当初は低いにもかかわらず、しばらくすると親と同じぐらいにまでメモリ量が増加します。大規模な本番インストールだと各ワーカーのサイズが100MB以上まで増加することもあり、やがてメモリはサーバーでもっとも制約の厳しいリソースになってしまい、しかもCPUはアイドル状態のままです。 現代的なOSの仮想メモリ管理システムは、まさにこの状況を防止するために設
Google、訂正不可能なメモリエラーによるクラッシュを回避する「Memory Poisoning Recovery」をGoogle Cloudで提供へ
Google、訂正不可能なメモリエラーによるクラッシュを回避する「Memory Poisoning Recovery」をGoogle Cloudで提供へ ずっと安定して稼働していたシステムが、ある日突然エラーでクラッシュ。調べても原因が分からないので、「何らかのノイズや放射線などの影響でメモリエラーが起きたのでは？」という推測を顧客に報告した、なんて経験を持つベテランのITエンジニアは少なくないのではないでしょうか。 実際のところ、2009年のGoogleの調査では同社の本番システムにおいて、1年間で8％以上のDIMMモジュールにメモリエラーが発生していたと報告されています。想像以上にメモリエラーというのは起きているのですね。 ただし、現代のメモリとCPUなどではエラー訂正機能を備えているため、多くのメモリエラーは訂正され、システムの動作に影響を与えないようになっています。 しかし訂正しき
Linux: mmap(2) したメモリに書き込みした際の Copy On Wirte を観察する - hibomaの日記
イントロ ペパボ社内 Slack で Linux の CoW = Copy On Write について、 id:ryuichi1208 id:udzura とディスカッションして盛り上がっていた。カーネル内で CoW を処理する関数を追えないか? という話があがったので、調べてみた次第。 ( なぜ CoW の話が出てきたのか / どんなことをディスカッションしてたのかは id:ryuichi1208 がまとめくれるかも? ) 結論 CoW を観察するには do_wp_pageを観察するといいみたい wiki.bit-hive.com ( いつもお世話になっております ) do_wp_page のソース https://elixir.bootlin.com/linux/v5.11.22/source/mm/memory.c#L3085 検証環境 Vagrant で用意した bento/ubu
valgrind を使って使用メモリ量を調べる
#include <vector> int main() { std::vector<std::vector<double>> vecs; for(int i=0; i < 100; i++) { std::vector<double> a(1000); vecs.push_back(a); } return 0; } valgrindコマンドは --tool で起動するサブプログラムを変更でき、--tool=massif とするとheap profilerである massif を起動できます desc: (none) cmd: ./a.out time_unit: i #----------- snapshot=0 #----------- time=0 mem_heap_B=0 mem_heap_extra_B=0 mem_stacks_B=0 heap_tree=empty #---
北森瓦版 - Micron 3D XPoint Memoryの研究・開発を中止へ
Micron Abandons 3D XPoint Memory Technology（AnandTech） Micron Abandons 3D XPoint Memory & Looks to Sell Factory（techPowerUp!） Micron Updates Data Center Portfolio Strategy to Address Growing Opportunity for Memory and Storage Hierarchy Innovation（Micron） Micronは3月18日、同社の技術・資産戦略をアップデートし、データセンター向けのメモリおよびストレージの技術革新を強化する方針とした。MicronはCompute Express Link (CXL) を用いたメモリ製品を今後強化していく。一方、3D Xpoint memoryの開発は
Linus Torvalds On The Importance Of ECC RAM, Calls Out Intel's "Bad Policies" Over ECC - Phoronix
Linus Torvalds On The Importance Of ECC RAM, Calls Out Intel's "Bad Policies" Over ECC Written by Michael Larabel in Hardware on 3 January 2021 at 03:48 PM EST. 231 Comments There's nothing quite like some fun holiday-weekend reading as a fiery mailing list post by Linus Torvalds. The Linux creator is out with one of his classical messages, which this time is arguing over the importance of ECC mem
3.7. memory Red Hat Enterprise Linux 6 | Red Hat Customer Portal
リソース管理ガイド 1. コントロールグループについて (cgroup) Expand section "1. コントロールグループについて (cgroup) " Collapse section "1. コントロールグループについて (cgroup) " 1.1. コントロールグループの構成 1.2. サブシステム、階層、コントロールグループ、タスクの関係 1.3. リソース管理に対する影響 2. コントロールグループの使用法 Expand section "2. コントロールグループの使用法" Collapse section "2. コントロールグループの使用法" 2.1. cgconfig サービス Expand section "2.1. cgconfig サービス" Collapse section "2.1. cgconfig サービス" 2.1.1. /etc/cgconf
不審なプロセスがないのにメモリ使用量が高い場合はslab領域の肥大化を疑うといいかも
メモリのfreeが10%を切ったとアラートが飛んできた時の対応のメモです。 top を見てもあやしいプロセスが見つからなくて、 /proc/meminfo を見てみると slab領域の肥大が確認できました。 slabtop で dentry_cache が肥大化している事がわかったので、 echo 2 > /proc/sys/vm/drop_caches を実行しました。 というはなし。 freeコマンドで現在のメモリの使用量を確認する [root@bacchi ~]# free total used free shared buffers cached Mem: 1030516 971468 59048 1088 278348 166456 -/+ buffers/cache: 526664 503852 Swap: 2064380 654596 1409784 確かにこのサーバーはメモ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実践 9 つのメモリリークどう見つける？/ How to detect 9 types of memory leaks?
その35 Address Space Location Randomization(ASLR)
"MGLRU" Code Updated For More Performant Linux Page Reclamation - Phoronix