解決できないコンピュータの停止の問題があります。私は3台の同じコンピュータを持っています。どちらもカスタマイズ可能で、i7と64GBのRAMを搭載しています。 OSドライブは512GB NVMEドライブです。これらは、それぞれカーネル v3.10 とともに CentOS v7.8.2003 を実行します。私は大量のデータを保存して処理し、再保存するカスタムソフトウェアを実行しています。
関連する可能性があるオペレーティングシステムに対して実行されたカスタム構成を表示します。
カスタムfstab：
UUID=xxxxxx / ext4 noatime,nodiratime,discard 1 1
UUID=xxxxxx swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults,noatime,mode=1777 0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
LABEL=drive1 /data/drive1 auto noatime,nodiratime,discard,nofail 0 0
LABEL=drive2 /data/drive2 auto noatime,nodiratime,discard,nofail 0 0
LABEL=drive3 /data/drive3 auto noatime,nodiratime,discard,nofail 0 0
LABEL=drive4 /data/drive4 auto noatime,nodiratime,discard,nofail 0 0
LABEL=drive5 /data/drive5 auto noatime,nodiratime,discard,nofail 0 0
LABEL=drive6 /data/drive6 auto noatime,nodiratime,discard,nofail 0 0
カスタムsysctl.conf：
vm.swappiness=1
vm.vfs_cache_pressure=50
ソフトウェアについてあまり詳しく説明したくありませんが、重要なのは、データを非常に迅速に受信することです。データはマザーボードに直接接続された5つのSATA SSDに保存されます。 （5つを並列に書き込むことがデータの流入に沿って書き込み速度を維持する唯一の方法です。）データは大きなチャンク（ファイル）として保存し、後で処理してから6番目のSATA SSDに保存します。一部のソフトウェアがどのように動作するかは詳細にはわかりませんが、一部のプロセスが共有メモリの大部分を使用していることがわかります。
問題：新しいデータの塊が入るとPCがフリーズすることがあります。この凍結は回復できず、ハード再起動が必要です。発生時間はランダムですが、常に新しいデータ収集が開始されると発生します。ソフトウェアパラメータを変更して特定のプロセスを有効/無効にすると、停止の発生頻度に影響を与える可能性があります。ただし、これは特定のプロセスとは関係がないように見えるため、絞り込むことはできません。これが起こる可能性を高めるいくつかの構成があります。問題を一貫して再現できる特定の構成が見つかったので、少なくともテストに役立ちます。
ソフトウェアを書いた開発者と協力しましたが、コンピュータを停止させる問題が見つかりませんでした。また、ソフトウェアのメモリリークをテストしましたが、何も見つかりませんでした。
私が見るには、これらすべてがメモリの問題を指しているようです。しかし、実際にメモリの問題が見つかりません。 Gnomeのコマンドラインとシステムモニタでtopとfreeを使用しましたが、メモリの問題の兆候はありません。 CPU負荷もそれほど高くなく、PCは64GB RAMの半分も使用しません。これがメモリの問題であれば、何かが欠けているか、監視してログに記録するには早すぎます。
それでは問題の核心に進みます。切迫した心に私のパートナーの一人がこうしました。
vm.overcommit_memory=2
vm.overcommit_ratio=80
これは問題を解決するようです。これ以上停止状態を再現できません。問題を再現するための手順の実行中にメモリを監視してみると、奇妙なことは見つかりません。どのプロセスも競合せず、ソフトウェアは単に設計どおりに行われました。このため、停止の原因はソフトウェアではなく、PCの非定型使用に関連してオペレーティングシステムが構成される方法であると考えられます。
ドキュメントを読みましたが、overcommit_memoryの変更がシステムの他の部分にどのような影響を与えるか、または変更したい時期の例を提供することは役に立ちません。より多くの情報を得るためにフォーラムを見ましたが、ほとんど「何をしているのかわからない場合は触れないでください」という内容を発見しました。また、メモリが多すぎると、OOMが重要なプロセスを終了する可能性があることも心配されます。
overcommit_memory設定をいつ変更したいのか教えてもらえますか？私の状況はあなたが変えなければならない状況ですか？それでは、システムの他の側面にどのような影響を与えるかを知る必要がありますか？
ベストアンサー1
まず、OOMへの参照があるかどうかログを確認してください。。遅すぎるまでメモリ消費の増加を見ることができない場合があります。プログラムが突然一度に多くのメモリを消費しようとすると、遅すぎる可能性があります。
第二に、システムが停止している場合の原因を分析する最善の方法は、次の機能を有効にすることです。カーネルクラッシュダンプ前進、それから使用SysRq マジックキー（この場合はALT-SysRq-cキーボードの組み合わせを使用してください。） 将来の分析のためにカーネルのコアダンプを生成します。
については、次overcommit_memoryから読むことができますman 5 proc。
/proc/sys/vm/overcommit_memory
このファイルにはカーネル仮想メモリ計算モデルが含まれています。値は次のとおりです。
0: heuristic overcommit (this is the default) 1: always overcommit, never check 2: always check, never overcommitモード0から
mmap(2)、呼び出しはMAP_NORESERVE確認されず、基本的な確認は非常に弱いです。プロセスが「OOM 終了」する危険があります。モード2（Linux 2.6以降）で割り当て可能な仮想アドレス空間の合計（CommitLimit
/proc/mem‐info）は、次のように計算されます。CommitLimit = (total_RAM - total_huge_TLB) * overcommit_ratio / 100 + total_swap
多くのプログラムは、カーネルが許可するだけのメモリを割り当てようとします（overcommitデフォルトが0の場合は非常に大きくなる可能性があります）、そのメモリが実際に物理的に利用可能かどうかを確認せずに使用しますOOM-killer。発動する危険があります。 2の場合、カーネルはRAMの合計サイズ、スワップ領域、および値に基づいてアプリケーションが割り当て（マッピング）できるovercommitメモリ量を制限します。overcommit_ratio減らすOOMを実行する可能性があります。
メモリを正しく管理する多くのアプリケーションは、カーネルが要求に従わなくても死ぬことはなく、カーネルが割り当てることを許可したmmap(2)メモリのみを使用します。
必ずお読みください。この文書のセクション9.6 - 「過剰コミットとOOM」overcommit2に変更すると、テストコードの動作に何らかの影響を与え、OOMによって終了するのを防ぐ実際の例です。