これは 高パフォーマンス設定 とは正反対のものであり、全体的なパフォーマンスの低下と引き換えに ASF のメモリ使用量を減らしたい場合は、通常これらのヒントに従うことになります。

ASFは、Linuxを搭載した128メガバイトのVPSでさえも実行可能であるため、定義上、リソース上で非常に軽量です。 その低さは推奨されず様々な問題につながる可能性がありますが ASFは軽いが、OSに多くのメモリを要求することを恐れず、ASFが最適な速度で動作するためにそのようなメモリが必要な場合。

アプリケーションとしてのASFは、可能な限り最適化され、効率的であり、実行中に使用されるリソースも念頭に置いています。 メモリに関しては、ASFは一時的なメモリ「スパイク」につながる可能性のあるメモリ消費量よりもパフォーマンスを好みます。例えば、 3つ以上のバッジページを持つアカウントで、ASFは最初のページを取得して解析し、合計ページ数から読み取ります。 次に、追加のページごとにfetch タスクを起動し、残りのページのフェッチと解析が同時に行われます。 余分なメモリ使用量(動作の最小限と比較して)は、実行を劇的に高速化し、全体的なパフォーマンスを向上させることができます。 これらすべてを並行して行うのに必要なメモリ使用量を増やすことができます 同様のことは、並列に実行できる他のすべての一般的なASFタスクにも起こっています。例えば、 アクティブなトレードオファーを解析することで、ASFはすべて独立しているため、すべてを一度に解析できます。 それに加えて、ASF（C# ランタイム）は、未使用になったメモリをその直後に OS へ返却しません。そのため、ASF プロセスのメモリ使用量が増え続ける一方で、そのメモリが OS に返されることは（ほとんど）ない、という形ですぐに気づくことができます。 何人かの人々はすでにそれが疑わしい見つけるかもしれません, 多分メモリーリークが疑わしいです, しかし、心配しないでください, これのすべてが期待されています.

ASFは極めて最適化されており、可能な限り利用可能なリソースを利用しています。 ASFのメモリ使用量が多いということは、ASFが積極的に を使用し、 が がを必要とするということではありません。 ASFは、将来のアクションのために割り当てられたメモリを「ルーム」として保持します。 使用しようとしている全てのメモリチャンクをOSに問い合わせる必要がなければパフォーマンスが大幅に向上するからです OS が未使用の ASF メモリを本当に必要としたときには、ランタイムが自動的にそのメモリを OS へ解放するはずです。 未使用のメモリは メモリを無駄にします。 問題が発生するのは、あなたが必要とするメモリが利用可能なメモリを上回った場合です。ASF が、すぐ後に実行される機能を高速化する目的で、余分なメモリを確保したままにしている場合ではありません。 LinuxカーネルがOOM(メモリ不足)のためにASFプロセスを停止しているときに問題が発生します。 htop でASFプロセスがトップメモリコンシューマとして表示された場合はそうではありません。

ASF で使用される ガベージコレクション 処理は非常に複雑な仕組みであり、ASF 自体だけでなく、OS や他のプロセスも考慮できるほど賢く設計されています。 多くの空きメモリがある場合、ASFはパフォーマンスを向上させるために必要なものは何でも要求します。 これは、最大1GB(サーバーGC)を使用することができます。 お使いのOSメモリがいっぱいに近い場合、ASFはその一部をOSに自動的に解放し、解決に役立ちます。 これにより、ASF全体のメモリ使用量は50MBと低くなります。 50 MB と 1 GB の違いは巨大です。 しかし、小型512 MBのVPSと32 GBの巨大な専用サーバーの違いもあります。 ASFがこのメモリが役に立つことを保証でき、同時に今すぐ必要としない場合。 過去に実行されたルーチンに基づいて自動的に最適化する ASFで使用されているGCはセルフチューニングであり、プロセスの実行時間が長くなります。

ASF プロセスのメモリ使用量が環境によって異なるのも、このためです。ASF は、Windows XP 時代のように固定的な方法ではなく、利用可能なリソースをできるだけ効率的に使用しようとします。 ASF が使用している実際の（リアルな）メモリ使用量は、stats コマンド で確認できます。通常は、ボットが数体だけなら約 4 MB、IPC やその他の高度な機能を使用している場合でも最大 30 MB 程度です。 stats コマンドによって返されるメモリには、ガベージコレクタによってまだ回収されていない空きメモリも含まれていることに注意してください。 それ以外のものは、ランタイムメモリ(約40〜50MB)と実行の余地(異なります)を共有しています。 同じASFが低メモリVPS環境でわずか50MBを使用できる理由でもあります。 デスクトップでも1GBを使用しています。 ASFはあなたの環境に積極的に適応しており、OSを圧迫しないように最適なバランスを見つけようとします。 使用される可能性のある未使用のメモリをたくさん持っている場合は、独自のパフォーマンスを制限することもありません。

もちろんです ASFを正しい方向に向けて使用することが期待されるメモリに関して、どのようにして役立つのかがたくさんあります。 一般的に、あなたがそれを行う必要がない場合は、ごみ収集者が安心して動作し、それが最善であると考えていることを行うことが最善です。 しかし、たとえば、Linuxサーバーが複数のWebサイト、MySQLデータベース、PHPワーカーをホストしている場合など、これは常に可能ではありません。 OOMに近づくと、通常は遅すぎてパフォーマンスの低下が早くなるため、ASFが縮小する余裕はありません。 これは通常、さらにチューニングに興味がある場合であり、したがって、このページを読んでください。

以下の提案はいくつかのカテゴリに分かれており、難易度はさまざまです。

以下のテクニックはパフォーマンスに悪影響を与えないため、すべての環境に安全に適用できます。

• 可能であれば、ASF の generic 版 を実行してください。 ASFの一般的なバージョンは、ランタイムが内部に含まれていないため、単一のファイルとして来ないので、より少ないメモリを使用しています。 実行中に自分自身を解凍する必要はありませんしたがって、より小さく、メモリの足跡が少なくなります。 OS固有のパッケージは便利で便利ですが、ASFを起動するために必要なすべてのパッケージも同梱されています。 これは自分の世話をし、代わりに汎用ASFバリアントを使用することができます。
• 複数のASFインスタンスを実行しないでください。 ASFは、一度に無制限のボット数を処理することを意図しており、すべてのASFインスタンスを異なるインターフェース/IPアドレスにバインドしていない限り。 必要に応じて複数のボットを使用して、 **** ASFプロセスを正確に行う必要があります。
• ボットの FarmingPreferences で ShutdownOnFarmingFinished を使用します。 アクティブなボットは、無効化されたボットよりも多くのリソースを消費します。 Botの状態を保持する必要があるため、それは重要な保存ではありません。 しかし、あなたはいくらかの量のリソースを節約しています、特にTCPソケットのようなネットワークに関連するすべてのリソースです。 必要に応じて、いつでも他のボットを呼び出すことができます。
• あなたのボット番号を低くしてください。 有効ではない ボットインスタンスは、ASFが起動することを気にしないので、リソースが少なくなります。 また、ASF は設定ごとにボットを作成する必要があることにも注意してください。そのため、指定したボットを起動する必要がなく、少しでもメモリを節約したい場合は、無効化したボットインスタンスの状態が ASF 内に作成されないよう、Bot.json を一時的に Bot.json.bak などへリネームできます。 この方法では、元の名前に戻さない限りそのボットを起動できなくなりますが、ASF もそのボットの状態をメモリ内に保持しなくなるため、他の用途に使える余裕ができます（節約できる量はごくわずかなので、99.9% の場合は気にする必要はありません。単にボットの Enabled を false にしておけば十分です）。
• 設定を微調整します。 特にグローバル ASF 設定には、調整する多くの変数があります。例えば、 LoginLimiterDelay を増やすと、ボットが遅くなります。 すでに起動済みのインスタンスにバッジを取得させることができます。ボットを素早く呼び出すのではなく より多くのボットが同時に主要な作業(バッジの解析など)を行うため、より多くのリソースを必要とします。 同時に行う必要がある作業が少ないほど、メモリが少なくなります。

これらは、メモリ使用量を扱うときに覚えておくことができるいくつかのことです。 しかし、これらのことは、メモリ使用量に関して「重要な」問題を持っていません。 メモリ使用量は主にASFが扱うべきものであり、カードの農業に使用される内部構造ではないためです。

最もリソース重い関数は次のとおりです。

• バッジページの解析
• 在庫解析中

つまり、ASFが読書バッジページを扱っているときや、そのインベントリを扱っているときに、メモリが最も多く消費されることになります(e. をクリックします。 これは、ASFが本当に膨大なデータを処理しなければならないためです。これらの2ページを起動するお気に入りのブラウザのメモリ使用量はそれよりも低くなりません。 申し訳ありませんが、それはそれがどのように動作します - バッジページの数を減らし、確実に助けることができるあなたのインベントリアイテムの数を低く保ちます。

以下のトリック は性能劣化 を伴い、注意して使用する必要があります。

これらの設定を適用する推奨方法は、 DOTNET_ 環境プロパティです。 もちろん、runtimeconfig.json など他の方法を使用することもできますが、この方法では設定できない項目もあります。さらに、次回の更新時に ASF がカスタムの runtimeconfig.json を独自のものに置き換えてしまうため、プロセスを起動する前に簡単に設定できる環境プロパティをおすすめします。

.NET ランタイムでは、さまざまな方法で ガベージコレクタ を微調整できます。 GCプロセスを効果的に微調整します。 私たちは、私たちの意見では特に重要な特性以下を記録しました。

GCヒープ使用量を合計物理メモリのパーセンテージで指定します。

ASFプロセスの「ハード」メモリ制限。この設定では、GCを合計メモリのサブセットのみ使用し、すべてではありません。 これは、ASF用のサーバーメモリの固定パーセントを捧げることができる、さまざまなサーバーのような状況で特に有用になるかもしれません。 でもそれ以上のことはない ASFが使用するためにメモリを制限することは、魔法のように必要なメモリ割り当てをすべて解消するわけではないことに注意してください。 したがって、この値を低く設定すると、ASFプロセスが強制終了されるメモリシナリオが不足する可能性があります。

一方、 この値を十分に高く設定することは、ASFが現実的に可能な限り多くのメモリを使用しないようにする完璧な方法です。 重い負荷の下でもマシンに呼吸を与える一方で プログラムを可能な限り効率的に行うことができます

ガベージコレクタを設定して、より頻繁なガベージコレクションとおそらく長いポーズ時間を犠牲にしてメモリを節約します。

0-9の間の値を使用できます。 値が大きいほど、GCが増えるほどパフォーマンスよりもメモリを最適化します。

GCがより攻撃的になるまでのメモリ使用量を指定します。

この設定は、一度経過したOS全体のメモリ閾値を設定します。 GCはより積極的になり、より集中的なGCプロセスを実行し、より多くの空きメモリをOSに解放することで、OSのメモリ負荷を低減させる試みを行います。 このプロパティを、OS全体のパフォーマンスに対して「クリティカル」とみなす最大メモリ量(パーセンテージ)に設定することをお勧めします。 デフォルトは90%で、通常は80-97%の範囲に保持します。 値が低すぎると、GCからの不必要な侵略や性能劣化を理由なしに引き起こすからです 値が高すぎるとOSに不要な負荷がかかりますが、ASFはそのメモリの一部を解放して助けになる可能性があります。

最適化するGCレイテンシレベルを指定します。

これはASFにとって非常にうまく機能することが判明した文書化されていないプロパティです。 GC世代のサイズを制限し、結果としてGCパージをより頻繁に、より積極的に行います。 デフォルト(バランスの取れた)レイテンシレベルは 1ですが、 0 0を使用してメモリ使用量を調整できます。

設定すると、コミットされた空間をより積極的に一時的な縫い目のためにトリミングします。 これは、できるだけ少ないメモリを保持したいサーバプロセスの多くのインスタンスを実行するために使用されます。

これはほとんど改善を提供しませんが、システムがメモリ上で低くなったときにGCをさらに攻撃的にする可能性があります。 特に、スレッドプールのタスクを大きく利用するASFの場合。

適切な環境変数を設定することで、選択したプロパティを有効にできます。 例えば、Linux (shell):

# これらを使用する予定がある場合は、調整を忘れないでください
export DOTNET_GCHeapHardLimitPercent=0x4B # 16進数で 75%
export DOTNET_GCHighMemPercent=0x50 # 16進数で 80%

export DOTNET_GCConserveMemory=9
export DOTNET_GCLatencyLevel=0
export DOTNET_gcTrimCommitOnLowMemory=1

./ArchiSteamFarm # OS 固有ビルド用
./ArchiSteamFarm.sh # generic ビルド用

または、Windows (powershell)上で:

# これらを使用する予定がある場合は、調整を忘れないでください
$Env:DOTNET_GCHeapHardLimitPercent=0x4B # 16進数で 75%
$Env:DOTNET_GCHighMemPercent=0x50 # 16進数で 80%

$Env:DOTNET_GCConserveMemory=9
$Env:DOTNET_GCLatencyLevel=0
$Env:DOTNET_gcTrimCommitOnLowMemory=1

.\ArchiSteamFarm.exe # OS 固有ビルド用
.\ArchiSteamFarm.cmd # generic ビルド用

特に、 GCLatencyLevel は、ランタイムが実際にメモリ用のコードを最適化し、メモリ使用量を大幅に削減することを検証したため、非常に便利になります。 サーバーGCでさえも OptimizationMode でパフォーマンスを低下させずにASFメモリ使用量を大幅に削減したい場合に適用できる最良のトリックの1つです。

以下のトリック は、深刻な性能劣化 を伴い、注意して使用する必要があります。

• 最後の手段として、ASF を MinMemoryUsage 向けに調整できます。これは、OptimizationMode の グローバル設定プロパティ を通じて行います。 これはほとんどメモリの利益のために深刻な性能劣化であるため、その目的を注意深く読んでください。 これは通常、最後に検討すべきことです。先に ランタイムチューニング を十分に行い、本当にそうせざるを得ないことを確認してからにしてください。 セットアップに絶対的な重要性がない限り、 MinMemoryUsageを使用することをお勧めしません。

• まずは簡単な ASF セットアップの工夫から始め、generic ASF バリアント を使用してください。また、すべてのボットに対してプロセスを複数回起動していたり、自動起動が必要なのは 1 つか 2 つだけなのにすべてを有効なままにしていたりするなど、ASF を誤った方法で使用していないか確認してください。
• それでも十分でない場合は、適切な DOTNET_ 環境変数を設定することで、上記のすべての設定プロパティを有効にします。 特に、 GCLatencyLevel は、パフォーマンスにかかるコストが少ない大幅なランタイム改善を提供します。
• それでも役に立たなかった場合、最後の手段として MinMemoryUsage OptimizationMode を有効にします。 これにより、ASFは同期事項のほぼすべてを実行しなければなりません。 並列実行で物事のバランスを取るためにスレッドプールに頼らないようにしています

さらにメモリを減らすことは物理的に不可能です。 ASFはすでにパフォーマンスの面で大幅に低下しており、コード単位とランタイム単位の両方で、あらゆる可能性を失いました。 ASFを使用するために余分なメモリを追加することを検討してください。128メガバイトでも大きな違いがあります。