無理なことだとは分かりますが、これをどのように実装するかについてある程度覚えています。
ターミナルまたはGUIを介して既存のプログラムには、実行に時間がかかる可能性がある開始順序と終了コマンドの順序があります。また、データベースからデータを取得することは常に可能ではない可能性があるなど、他の制限がある可能性があります。
プログラム実行中にＲＡＭが占める空間として定義されるプログラムの「メモリイメージ」。つまり、プログラムに割り当てられたすべてのメモリを1対1にマップすることです。
物理ディスクをイメージ化したり、イメージをマウントしたり、依存関係構造全体のAppImageを作成したり、仮想OSの状態（実際にはイメージ）の仮想マシンの状態を保存したりできます。プログラムメモリの状態（欠陥、非効率性など）をバイナリファイルに変換することは可能ですか？
（私が心配していることの1つは、画像に保存されているいくつかの参照が起動するたびに変更される可能性があることですが、これは技術的に解決可能な問題であり、おそらくアイデアを殺すことはありません）。
では、*nixシステムでこれをどのように実行しますか？
明らかに、これは常に（または一般的に）利点ではありませんが、見る価値があると思います。私がやろうとしていることを説明するには：
- 開いている
Vim - 大量のテキストを書く
Vim - 正式にVimを閉じずにディスクにシリアル化
- 数日待ってください。
Vimディスク上のインスタンスの逆シリアル化- 同じ文章を書き続ける
したがって、ファイルだけでなくプログラム全体の状態も保存されます。
私が考えた解決策の1つは、仮想インスタンスでプログラムを実行することでしたが、これはしばしば過剰であると感じることがあります。
ベストアンサー1
はい。 CRIUはこれを可能にするLinux技術の略語です。
ただし、プログラムで開かれたファイルが変更されずに「凍結」され、ソケットがまだ存在し、すべての外部状態が同じであるか、または状態損失が少なくとも回復可能でなければならないという論理的な必要性によって引き起こされる深刻な制限があります。これはX11プログラムを効果的に除外し、Curses / Graphic ttyを使用するプログラムがCRIUを通過するのを容易にしません。
このようなことが頻繁に起こる場所はコンテナ化サーバーワークロード - とにかく、ファイルシステム全体がプライベートで、ネットワーク接続が簡単に切断されるため、回復機能がサーバーソフトウェアに組み込まれていることがよくあります。