golangで書いたプログラムをDockerで動かしOOMが発生した際になるべく情報を残して殺される方法を紹介します。 2020/08/16追記: この記事の内容はgolangに関してはやや現実的ではなくなってしまいました。 詳しくは続編を参照してください。 TL;DR golang製のプログラムは仮想メモリ(VSZ)の確保に失敗するとgoroutineのダンプを吐いて死ぬ DockerのOOMはRSSベースで検出時にSIGKILLを投げてくる Docker利用時にVSZで制限をかけるスクリプトを書いた golang製のプログラムはlinux-amd64において最低でも101MBのVSZを要求する VSZの制限がそれより小さいと当然起動できない 実際のRSSは3MB程度で起動する Background コンテナ内で動いているプロダクション上のgolang製のプログラムが時々OOMに殺されて
GoはいつGCするのか?
TL;DR Go(のランタイム)は以下のタイミングで自動的にGCを実行する 前回のGC後に占有していたメモリと同量を新たに確保したとき 前回のGCから2分後 cgroupなどでメモリ制限しているときは、メモリ使用量が制限の50%以上になったらruntime.GC()を呼び手動でGCすべきである 前置き: GoとOOMのこれまで 以下はGo 1.16での調査結果です。Goのバージョンが異なった場合は事情が異なる可能性があります。 Goでプログラムを書く際に、使用メモリ量を気にしなければならないシーンはGCのおかげでそう多くはありません。実際それは間違いではないのですが、運用まで視野に入れるとそうは言ってられないことがあるのもまた現実です。昨今はコンテナの利用が当たり前になったことに伴い、OOMによりプロセスが強制的に終了させられることもあり、それを避けるために一定量以下のメモリで動くことが重
Kubernetes で運用する JVM アプリケーションの OutOfMemoryError に備える - Uzabase for Engineers
こんにちは。SPEEDA 開発チームの old_horizon です。 JVM アプリケーションの運用について回るのが、OutOfMemoryError (以下 OOM) への対処です。 しかし実際に発生した際に、適切なオペレーションを行うのは意外と難しいのではないでしょうか。 特に本番環境では、まず再起動して復旧を急ぐことも多いかと思います。しかし、ただそれを繰り返すばかりでは原因がいつまでも特定できません。 今回は Kubernetes で運用する JVM アプリケーションに対して、ダウンタイムを抑えつつ調査に役立つ情報を自動的に収集する仕組みを構築してみたいと思います。 環境構築 OOM 発生時に、自動的にヒープダンプを取得しコンテナを再起動する java コマンドのオプション指定 補足 ヒープダンプ出力先のボリュームをマウント readinessProbe によるヘルスチェック レ
こんにちは、SWETグループ所属のkariadです。 昨年10月に開催されたiOS Test OnlineにてSWETチームのkuniwakが「実践9つのメモリリークどう見つける？」というタイトルで発表しました。 その発表では触れられなかった、メモリリークから引き起こされるOOMクラッシュを発見する手法についてSWETで実践したことを紹介します。 メモリリークについての説明は多くの記事で説明されているため、省略します。 OOMクラッシュ メモリリークが発生するとOOMクラッシュの危険性があります。 OOMとはOut Of Memoryの略であり、アプリが確保しているヒープ領域を超えてメモリを利用しようとした際に、OSからアプリがキルされクラッシュしてしまいます。 通常のクラッシュにおいては大半のアプリで導入されているであろうFirebase Crashlyticsにて検知可能です。 一方で
Introduction When working with Kubernetes, Out of Memory (OOM) errors and CPU throttling are the main headaches of resource handling in cloud applications. Why is that? CPU and Memory requirements in cloud applications are ever more important, since they are tied directly to your cloud costs. With limits and requests, you can configure how your pods should allocate memory and CPU resources in orde
Linux Daily Topics 2020年1月8日Fedora 32がEarlyOOMをデフォルト実装へ、メモリ不足によるフリーズを回避 Fedoraプロジェクトは1月5日（米国時間）、2020年春にリリース予定の「Fedora 32」において「EarlyOOM」パッケージをデフォルトでインストール/有効化することを明らかにした。 Changes/EnableEarlyoom rfjakob /earlyoom -GitHub EarlyOOMは物理メモリおよびスワップ領域が不足した場合、特定のしきい値に応じてもっともメモリを占有するプロセスを終了させる、ユーザスペースで動くデーモン。利用可能なメモリおよびスワップ領域をつねに監視し、それぞれ10％を下回るとSIGTERMを、5％を下回るとSIGKILLを、もっとも占有するプロセスに対して送信し、プロセスを強制終了させる。 Fed
この記事は、LIFULLその2 Advent Calendar 2020の23日目の記事です。 今回は、Androidの低レイヤーな話を取り上げてみようと思います。 具体的には、OOM Killerでプロセスがkillされるのを未然に防ぐLowMemoryKillerの仕組みについてです。 ネイティブアプリの開発は、よりメモリの事を意識した開発が必要だなと日々感じていたので、もっと低いレイヤーで何が行われているかをちゃんと理解したいと思ったのがきっかけで、勉強してきた内容になります。 読んでいただけたらこの辺の内容を理解できる内容になっていると思います。 LowMemoryKillerの仕組み Activityが破棄される基準 onSaveInstanceState()でBundleに保存するデータは実際どこに保存されているのか Androidエンジニアじゃなくても、Androidの世界を
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
golangとDockerとOOM — KaoriYa
iOSのOOMクラッシュをみつける - DeNA Testing Blog
Kubernetes OOM and CPU Throttling
2020年1月8日 Fedora 32がEarlyOOMをデフォルト実装へ、メモリ不足によるフリーズを回避 | gihyo.jp
LowMemoryKiller 〜AndroidのActivityが破棄される仕組み〜 - Qiita