メモリが限界に達し、CPU が 100% 使用されて RAM がほとんどなく、システムが事実上停止したため、AWS ERP サーバーが 4 回クラッシュしました。
Ubuntu 18.04.5 LTS (GNU/Linux 5.4.0-1060-aws x86_64) (AWS AMI)
GitHub アクションの途中で、この問題が 3 回発生しました。アクションはデータベースのインポートを実行しており、その後 Slack 通知を実行していました。したがって、これらのステップの 1 つが問題の原因であると思われますが、奇妙なことに、ステップはすべて正常に完了しました。データベースは正常で、Slack 通知がプッシュされました。
GitHub 自体がランナーとの接続を失い、アクションが完了した後でも仮想メモリが急増しました。
4 回目は、何も実行されていないときにこの現象が発生しました。サーバーは実際には何も実行されずにアイドル状態でした。ただし、そのログや「トップ」スクリーンショットはありませんが、1 回だけその動作を捉えました。
つまり、システムは 4G の RAM を搭載した AWS VM です。このシステムをセットアップした SI は、スワップ領域なしで構成したと思います。これは、メモリ リークが発生した場合にシステムがメモリ不足を報告して修正アクションを実行するという意味で、サーバーにとってはおそらく正しい (非常におそらく正しい) と言えます。メモリ リークが発生すると、いずれにせよ最終的には停止することになります。
短期的には、RAM を 2 倍にするように言われました。これは、非常に負荷の軽いシステム (通常、重いバッチ ジョブを実行するときに 2G 程度の RAM しか使用せずに動作します) なので、いくぶん不必要です。率直に言って、GitHub Runner.Worker が 4GB システムで 7GB の RAM で最大になるのであれば、8GB VM で 16GB の RAM で最大にならない理由はありません。ただし、再びクラッシュするかどうかはわかりません。TFG のスワップ構成を変更することに反対しているわけではありませんが、それが修正になるかどうかはわかりません。
私はこれを GitHub に報告しましたが、3 週間以上何もしなかったため、ここで確認して、誰かがアイデアや修正を持っているかどうかを確認しようと思いました。
ありがとう、
== ジョン ==