WSL2によるホストのメモリ枯渇を防ぐための暫定対処 - Qiita
5/27にWindows 10 2004 Updateが正式リリースされて、それに伴いWSL2もWindows Insider Preview版を使用しなくても利用可能となりました しかしWSL2を使用してるとVmmemというプロセスのメモリ使用量が増加し続けて、Windowsホストのメモリが枯渇してしまう問題があります。そしてこの問題は正式リリース後も解消されず残っています。 NOTE: Windowsホストで動いているVmmemプロセスで「WSL2のHypver-V仮想マシン全体が消費＆確保しているCPUとメモリ」を確認できるという大雑把な理解でOKです。 microsoft/WSLのIssueは１年近くOpenのままとなっており、Microsoft側も問題を認識して取り組んでいるものの未だに根本対処されていません。 本問題のアップデート情報 (2023/07/04更新) 本問題に関す
Linux OOM Killerについて - Qiita
OOMとは? Linuxは、メモリが不足してシステムが停止する恐れがある際、メモリリソースを多く消費しているプロセスを強制的に殺します。これをOOM Killerといいます。重要なプロセスでも問答無用で殺しにきます。 いるはずのプロセスがある日消えていたのなら、それはOOM Killerに殺されたのかもしれません 確認方法(CentOS) 5789のrubyのプロセスが殺されたことが分かります $ sudo cat /var/log/messages | grep Killed Oct 1 11:11:54 ip-xx-xx-xx-xx kernel: [1983378.957901] Killed process 5789 (ruby) total-vm:4957320kB, anon-rss:2717004kB, file-rss:0kB
Linux メモリ管理を理解したい - Qiita
Linux カーネルのメモリ管理方法について、勉強したことをまとめる。 メモリ管理はハードウェアに強く依存するため、x86_64 かつ OS起動後に 64bitプロテクトモード に移行したあとに話を絞る。また、OS は CentOS7.6、カーネルは次のバージョンを利用する。 ]# cat /etc/redhat-release CentOS Linux release 7.6.1810 (Core) ]# uname -a Linux localhost.localdomain 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux 概要 ノイマン型アーキテクチャ コンピュータの基本的な構成のひとつ。次の図が参考になる。 ほぼ全てのコンピュータが、このアーキ
Dockerのメモリ制限に関するメモ - Qiita
引用:Docker run リファレンス ここでは--memory-reservationと--oom-kill-disable=false、--memory-swappinessについて調べました。 環境 OSX 10.12 Docker for MAC(docker 1.12.1) --memory-reservation メモリのソフトリミットということで、ホストのメモリに余裕がある時はは制限はかからず、他に使用している時は制限がかかるということらしい。 試してみました。 コンテナ2つ起動し、1つは--memory-reservationを512MB、もうひとつは制限なしで設定します。Linuxの負荷ツールstressで以下のシナリオでメモリに負荷をかけます。 前提：ホストのメモリは2GB 1. 両方のコンテナに1.25GBの負荷をかける 2. メモリ制限のないコンテナへの負荷を停止
valgrindでC/C++のメモリリークを発見する - Qiita
==23525== Invalid free() / delete / delete[] / realloc() ==23525== at 0x1000089DF: free (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so) ==23525== by 0x100000F4F: main (sample.c:8) ==23525== Address 0x10081f510 is 0 bytes inside a block of size 4 free'd ==23525== at 0x1000089DF: free (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwi
gcを知らない人のためのmruby gc - Qiita
gc(garbage collection)とは 確保したメモリを自動的に解放してくれる仕組み メモリを確保する際は、アプリケーションが要求した量より多い量が確保される。その多い分は、要求したメモリの管理のためで、管理領域があることで要求したメモリが辿れるようになっている。アプリケーションが要求した領域を解放する際は、管理領域を使って、順次メモリを辿っていき、合致する領域を探すといった事を行う。 mark & sweep 古典的なgcの一つにmark & sweepがある mark & sweepでは、使っていないメモリを探して解放する。 例えば、rootと呼ばれるglobal変数があって、rootからたどることが出来る（参照がある）場合は、まだ使っていると判断出来る。反対に、どこからも参照されていない場合、そのメモリはもう使っていないと判断できる。 このように、どこからも参照されていない
RubyのGCと仲良くしたい〜WeakRefオブジェクトを削除するぞ編〜 - Qiita
Rubyでは、作成したオブジェクトがなにかのタイミングでGCによってメモリから解放されています。 一般的なオブジェクトは、どこからかに参照されている間は必要、参照されていないなら不要とGCに判断され、メモリから解放されます。 例外的に 弱い参照 -Wikipedia として定義されたオブジェクトは、まだ参照されていてもなにかのタイミングでGCにぽいぽいされてしまいます。 一見、使いようが無いようですが、生成コストがかかる値をキャッシュしておき、メモリに余裕がない場合（一般にGCが動くタイミング）にキャッシュを破棄する、というようなことができます。 機能の実現に必要となることはありませんが、速度改善などに役立つテクニック的な。 なおタイトルはてきとーです。「○○編」と書いていますが、別の編があったりはしません。たぶん。 Ruby2.1で動作検証をしましたが、1.9以降ならたぶん大丈夫なんじゃ
ActiveRecordがメモリを食って解放しない問題 - Qiita
[1] pry(main)> ObjectSpace.each_object(ActiveRecord::Base).count => 0 [2] pry(main)> User.limit(100) User Load (1.5ms) SELECT `users`.* FROM `users` LIMIT 10 [4] pry(main)> ObjectSpace.each_object(ActiveRecord::Base).count => 100 [5] pry(main)> User.limit(100) User Load (0.3ms) SELECT `users`.* FROM `users` LIMIT 10 [7] pry(main)> ObjectSpace.each_object(ActiveRecord::Base).count => 200 作ったActiveR
Java開発の性能改善！ その１ jstatによるヒープ/GCの確認 - Qiita
JavaのWeb開発の開発後期になると性能試験や負荷試験を実施することになると思いますが、 そのフェーズになると色々な問題が起こることが多い。 今まで起きた問題と調査・解決方法をいくつかの回に分けて紹介しようと思います。 まずはメモリリーク。 長時間サーバを起動して運用していたり、負荷試験を実施するとメモリリークを起こすことがある。 ガベージコレクションのおさらい Javaのヒープは大きくnew領域(young領域)とold領域に分かれます。 new領域には生成されてすぐのオブジェクトが格納されてマイナーGCにて未使用になった際に開放されます。 マイナーGCを何度も繰り返されても開放されない(長く参照されている)オブジェクトは old領域へと移動され、こちらはメジャーGC(フルGC)で開放されます。(メジャーGCはnewとperm領域も開放。) もう少し細かく説明すると・・・ new領域は
プロセス毎のメモリ消費量を調べたい時に使えるコマンド - 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 -
Linuxの不揮発メモリ対応について - Qiita
(2019/6/12追記) 今なおこの記事を参照してくれる方がいらっしゃるのですが、現在は以下のスライドのほうが情報が新しいです。 本記事は残しておきますが、新しい情報はこちらをご参照ください。 https://www.slideshare.net/ygotokernel/nvdimmlinux-137104084 はじめに Linux Advent Calendarの24日目の記事として不揮発メモリの状況について記載したいと思います。今回はkernelのソースの中とかのあまり技術的に深いところは突っ込まず、概略レベルです。（深いところはまだまだ勉強中の身です）。間違いなどがあればご指摘いただけると幸いです。 不揮発メモリとは これまでPCやサーバなどで主記憶装置といえば、電源を停止させたり再起動させるとデータがクリアされる揮発性のRAMが使われて来ました。この主記憶としてのメモリが不揮発
Ruby 2.1.1 GC Tuning - Qiita
Help us understand the problem. What is going on with this article? Ruby2.1では、RGenGCによりかなりパフォーマンスが改善されている。 また、チューニングパラメータが増えているが、まとまった日本語の解説が無かったので書いてみた。 間違いがある可能性があるので、指摘は歓迎です。 RGenGCとは RGenGC(Restricted Generational Garbage Collection)については、まずはこれを読むべし www.atdot.net/~ko1/activities/rubyconf2013-ko1_pub.pdf www.atdot.net/~ko1/activities/2014_rubyconf_ph_pub.pdf Ruby 2.1: RGenGC · computer talk by
Ruby でラインメモリプロファイラ - Qiita
プロファイラ好きなモニタの前の皆さんこんにちは。@sonots です。この記事では、Ruby コードのどの行がどのぐらいメモリを消費しているか調べる方法を紹介します。 オブジェクトの数を数える Ruby には ObjectSpace というオブジェクトの情報を集めたり操作したりする module があります。 このモジュールの each_object メソッドを使用すると、RubyVM 上の全てのオブジェクトを取り出すことができます。 このメソッドを使って、以下のようなコードを書くと、実行した地点で、RubyVM 中にどのクラスのオブジェクトが何個存在しているのかカウントできたりするわけです。興味深いですね! ObjectSpace.each_object.inject(Hash.new 0) {|h,o| h[o.class]+=1; h } #=> {Class=>241, Strin
cgroupsとメモリ資源と関係を勉強する前に、Linuxの仮想記憶周りを読む... - Qiita
あらまし 前回、cgroupsについて軽くではあるが書いてみました。 上記の文章の最後に「次はcgroupsとメモリ管理というネタで行ってみたい」と書きました。 もちろんすぐにcgroupsと仮想記憶の関係がわかればよいのであるが、何ぶんLinuxの仮想記憶は読むのも初めてです。よって、Linuxの仮想記憶の概要をつかむためにまずはソースを読んでみます。 流れがわかりにくい箇所もあります。が、ソースを読んで迷った過程をあえて記録に残したいと考えたからです。ご了解ください。 ということでfork() 仮想記憶の機能を理解するには、経験則上、とっかかりが必要です。 そのとっかかりの一つがfork()だと思っています。 人によっては、page fault(例外ハンドラ)から入ったり、mmap()から入ったりすることもあろうが、前回fork()がらみのところを読んだので、今回もここから行きます。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
