這與 高性能設置 正好相反，如果您想減少 ASF 的記憶體使用，請遵循這些提示以降低整體性能的成本。

根據您的使用情況，ASF在資源上非常輕量級，即使是使用128 MB VPS也可以在Linux上運行它，儘管不推薦這麼低的配置，因爲可能會導致各種問題。 在輕裝上陣的同時，ASF 並不害怕要求操作系統提供更多的記憶體以支援其以最佳速度運行。

作為應用程序，ASF 試圖盡可能地優化和高效，這也考慮了在執行期間使用的資源。 當涉及到記憶體時，ASF 更喜歡提升性能而不是節省記憶體，這會導致臨時記憶體“峰值”，例如，您將會注意到，ASF將從具有3個以上徽章頁面的帳戶獲取並解析第一頁，從中讀取總頁數，然後為每個額外頁面啟動獲取任務，這導致並發獲取和解析剩餘頁面。 “額外”記憶體使用（與操作的最小值相比）可以顯著加快執行和整體性能，同時增加並行執行所有這些操作所需的記憶體使用成本。 類似的事情發生在可以並行運行的所有其他常規ASF任務上，例如解析活躍交易報價，ASF可以立即解析所有這些報價，因為它們彼此獨立。 最重要的是，ASF（C＃運行時）將不會立即將未使用的記憶體釋放給操作系統，您可以通過ASF進程的形式注意到ASF只佔用越來越多的記憶體，但從不將記憶體釋放到操作系統。 有些人可能已經覺得有問題了，甚至可能懷疑記憶體洩漏，但不要擔心，一切盡在掌握之中。

ASF 經過了非常好的優化，並會盡可能地利用可用的資源。 ASF的高內存使用率並不意味著ASF主動使用該記憶體並需要它。 ASF通常會將分配的記憶體作為未來操作的“空間”，因為如果我們不需要為我們即將使用的每個記憶體塊詢問操作系統，我們就可以大幅提高性能。 當操作系統真正需要它時，運行時應自動將未使用的ASF記憶體釋放回操作系統。 於記憶體而言，未使用即浪費。 當您需要的內存高於可用的內存時，您可能會遇到問題，這並不是因爲ASF保留一些額外的分配以加速稍後將執行的功能。 You run into problems when your Linux kernel is killing ASF process due to OOM (out of memory), not when you see ASF process as top memory consumer in htop.

Garbage collector being used in ASF is a very complex mechanism, smart enough to take into account not only ASF itself, but also your OS and other processes. When you have a lot of free memory, ASF will ask for whatever is needed to improve the performance. This can be even as much as 1 GB (with server GC). When your OS memory is close to being full, ASF will automatically release some of it back to the OS to help things settle down, which can result in overall ASF memory usage as low as 50 MB. The difference between 50 MB and 1 GB is huge, but so is the difference between small 512 MB VPS and huge dedicated server with 32 GB. If ASF can guarantee that this memory will come useful, and at the same time nothing else requires it right now, it'll prefer to keep it and automatically optimize itself based on routines that were executed in the past. The GC used in ASF is self-tuning and will achieve better results the longer the process is running.

This is also why ASF process memory varies from setup to setup, as ASF will do its best to use available resources in as efficient way as possible, and not in a fixed way like it was done during Windows XP times. The actual (real) memory usage that ASF is using can be verified with stats command, and is usually around 4 MB for just a few bots, up to 30 MB if you use stuff like IPC and other advanced features. Keep in mind that memory returned by stats command also includes free memory that hasn't been reclaimed by garbage collector yet. Everything else is shared runtime memory (around 40-50 MB) and room for execution (vary). This is also why the same ASF can use as little as 50 MB in low-memory VPS environment, while using even up to 1 GB on your desktop. ASF is actively adapting to your environment and will try to find optimal balance in order to neither put your OS under pressure, nor limit its own performance when you have a lot of unused memory that could be put in use.

Of course, there are a lot of ways how you can help point ASF at the right direction in terms of the memory you expect to use. In general if you don't need to do it, it's best to let garbage collector work in peace and do whatever it considers is best. But this is not always possible, for example if your Linux server is also hosting several websites, MySQL database and PHP workers, then you can't really afford ASF shrinking itself when you run close to OOM, as it's usually too late and performance degradation comes sooner. This is usually when you might be interested in further tuning, and therefore reading this page.

Below suggestions are divided into a few categories, with varied difficulty.

Below tricks do not affect performance negatively and can be safely applied to all setups.

• Never run more than one ASF instance. ASF is meant to handle unlimited number of bots all at once, and unless you're binding every ASF instance to different interface/IP address, you should have exactly one ASF process, with multiple bots (if needed).
• Make use of ShutdownOnFarmingFinished. Active bot takes more resources than deactivated one. It's not a significant save, as the state of bot still needs to be kept, but you're saving some amount of resources, especially all resources related to networking, such as TCP sockets. You need only one active bot to keep ASF instance running, and you can always bring up other bots if needed.
• Keep your bots number low. Not Enabled bot instance takes less resources, as ASF doesn't bother starting it. Also keep in mind that ASF has to create a bot for each of your configs, therefore if you don't need to start given bot and you want to save some extra memory, you can temporarily rename Bot.json to e.g. Bot.json.bak in order to avoid creating state for your disabled bot instance in ASF. This way you won't be able to start it without renaming it back, but ASF also won't bother keeping state of this bot in memory, leaving room for other things (very small save, in 99.9% cases you shouldn't bother with it, just keep your bots with Enabled of false).
• Fine-tune your configs. Especially global ASF config has many variables to adjust, for example by increasing LoginLimiterDelay you'll bring up your bots slower, which will allow already started instance to fetch badges in the meantime, as opposed to bringing up your bots faster, which will take more resources as more bots will do major work (such as parsing badges) at the same time. The less work that has to be done at the same time - the less memory used.

Those are a few things you can keep in mind when dealing with memory usage. However, those things don't have any "crucial" matter on memory usage, because memory usage comes mostly from things ASF has to deal with, and not from internal structures used for cards farming.

The most resources-heavy functions are:

• Badge page parsing
• Inventory parsing

Which means that memory will spike the most when ASF is dealing with reading badge pages, and when it's dealing with its inventory (e.g. sending trade or working with STM). This is because ASF has to deal with really huge amount of data - the memory usage of your favourite browser launching those two pages will not be any lower than that. Sorry, that's how it works - decrease number of your badge pages, and keep number of your inventory items low, that can for sure help.

Below tricks involve performance degradation and should be used with caution.

ArchiSteamFarm.runtimeconfig.json 允許您調整 ASF 運行時，特別是在伺服器 GC 和工作站 GC 之間切換。

垃圾收集器是自調整的，可以在各種情況下工作。 您可以使用設定檔根據工作負荷的特徵設置垃圾回收的類型。 CLR 提供以下類型的垃圾回收： ——工作站垃圾回收，適用于所有用戶端工作站和獨立 PC。 這是運行時配置架構中 <gcServer> 元素的默認設置。 ——伺服器垃圾回收，適用于需要高吞吐量和可伸縮性的伺服器應用程式。 伺服器垃圾回收可以是非並發方式的，也可以在後台運行。

可在**垃圾收集概要**中了解更多。

ASF is already using workstation GC, but you can ensure that it's truly the case by checking if System.GC.Server property of ArchiSteamFarm.runtimeconfig.json is set to false.

In addition to verifying that workstation GC is active, there are also interesting configuration knobs that you can use - gcTrimCommitOnLowMemory and GCLatencyLevel.

Specifies the GC latency level that you want to optimize for.

This works exceptionally well by limiting size of GC generations and in result make GC purge them more frequently and more aggressively. Default (balanced) latency level is 1, we'll want to use 0, which will tune for memory usage.

When set we trim the committed space more aggressively for the ephemeral seg. This is used for running many instances of server processes where they want to keep as little memory committed as possible.

This offers little improvement, but might make GC even more aggressive when system will be low on memory.

You can enable both by setting appropriate COMPlus_ environment variables. For example, on Linux:

export COMPlus_GCLatencyLevel=0
export COMPlus_gcTrimCommitOnLowMemory=1
./ArchiSteamFarm

Or on Windows:

SET COMPlus_GCLatencyLevel=0
SET COMPlus_gcTrimCommitOnLowMemory=1
.\ArchiSteamFarm.exe

Especially GCLatencyLevel will come very useful as we verified that the runtime indeed optimizes code for memory and therefore drops average memory usage significantly, even with server GC. It's one of the best tricks that you can apply if you want to significantly lower ASF memory usage while not degrading performance too much with OptimizationMode.

Below tricks involve serious performance degradation and should be used with caution.

• As a last resort, you can tune ASF for MinMemoryUsage through OptimizationMode global config property. Read carefully its purpose, as this is serious performance degradation for nearly no memory benefits. This is typically the last thing you want to do, long after you go through runtime tuning to ensure that you're forced to do this.

• Start from simple ASF setup tricks, perhaps you're just using your ASF in a wrong way such as starting the process several times for all of your bots, or keeping all of them active if you need just one or two to autostart.
• If it's still not enough, enable all configuration knobs listed above by setting appropriate COMPlus_ environment variables. Especially GCLatencyLevel offers significant runtime improvements for little cost on performance.
• If even that didn't help, as a last resort enable MinMemoryUsage OptimizationMode. This forces ASF to execute almost everything in synchronous matter, making it work much slower but also not relying on thread pool to balance things out when it comes to parallel execution.

It's physically impossible to decrease memory even further, your ASF is already heavily degraded in terms of performance and you depleted all your possibilities, both code-wise and runtime-wise. Consider adding some extra memory for ASF to use, even 128 MB would make a great difference.