Low memory setup ru RU

Конфигурация для низкого потребления ОЗУ

Это полная противоположность конфигурации для высокой производительности и обычно вам понадобятся эти советы если вы хотите уменьшить объём занимаемой ASF памяти за счёт общего снижения производительности.

ASF имеет чрезвычайно низкие требования к ресурсам по определению, в зависимости от ваших целей даже VPS с 128MB памяти и ОС Linux будет достаточно для запуска, хотя настолько экономить не рекомендуется во избежание различных проблем. Несмотря на малый вес, ASF не стесняется запрашивать у ОС дополнительную память, если это необходимо для оптимизации скорости работы ASF.

ASF как приложение пытается быть настолько оптимальным и эффективным насколько это возможно, учитывая при этом ресурсы необходимые для работы. Когда дело доходит до памяти, ASF предпочитает производительность а не экономию памяти, и в результате могут появляться "пики" потребления памяти, которые можно заметить если например у аккаунта 3+ страницы со значками, поскольку в этом случае ASF запросит первую страницу, считает с неё номер страниц и затем запросит сразу все дополнительные страницы для параллельной обработки. Это "дополнительное" потребление памяти (по сравнению с минимально необходимым для работы) может существенно ускорить работу и общую производительность, ценой увеличенного потребления памяти, необходимого для выполнения этих задач параллельно. Похожая ситуация и со всеми остальными задачами ASF, которые можно выполнять параллельно, например при обработке активных предложений обмена ASF может обрабатывать их все одновременно, поскольку они независимы друг от друга. On top of that, ASF (C# runtime) will not return unused memory back to OS immediately afterwards, which you can quickly notice in form of ASF process only taking more and more memory, but (almost) never giving that memory back to the OS. Некоторые люди могут счесть это подозрительным, и даже предположить наличие утечки памяти, но не волнуйтесь, это ожидаемое поведение.

ASF очень хорошо оптимизирована, и максимально эффективно использует доступные ресурсы. Высокое потребление памяти не означает что ASF активно использует эту память и нуждается в ней. Очень часто ASF будет удерживать выделенную память как "место" для будущих действий, поскольку мы можем радикально улучшить производительность если не понадобится делать запрос к ОС для каждого участка памяти который мы хотим использовать. Среда выполнения должна автоматически освободить неиспользуемую ASF память и отдать её ОС если ОС действительно в этом нуждается. Неиспользуемая память пропадает зря. Проблемы начинаются когда память, которая вам необходима больше чем объём доступной памяти, а не когда ASF резервирует дополнительную память с целью ускорения функций которые скоро будут выполняться. Проблемы начались если ядро Linux убивает процесс ASF из-за OOM (out of memory), а не когда вы видите процесс ASF как основной потребитель памяти в htop.

Garbage collection process 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. Когда у вас много свободной памяти - ASF будет запрашивать столько, сколько позволит увеличить производительность. Это может быть вплоть до 1ГиБ (с серверным сборщиком мусора). Если память вашей ОС почти заполнена, ASF, будет автоматически освобождать часть памяти назад в ОС чтобы помочь урегулировать это, что может привести к снижению суммарно потребляемой ASF памяти вплоть до 50 МиБ. Разница между 50 МиБ и 1 ГиБ громадна, но такова и разница между маленьким VPS на 512 МиБ и огромным выделенным сервером с 32 ГиБ. Если ASF может гарантировать что эта память будет полезна, и одновременно больше никто не использует её в данный момент, будет принято решение зарезервировать её и автоматически оптимизировать свою работу, основываясь на процедурах, которые выполнялись ранее. Сборщик мусора, используемый в ASF, само-настраиваемый, и чем дольше запущен процесс, тем лучше он будет работать.

Это одна из причин, почему потребляемая ASF память может отличаться в разных условиях, поскольку ASF будет стараться использовать доступные ресурсы максимально эфффективно, а не в фиксированном объёме как это делалось во времена Windows XP. Действительное (реальное) потребление памяти процессом ASF можно проверить командой stats, и обычно оно составляет около 4 МиБ для нескольких ботов, и до 30 МиБ если вы пользуетесь IPC и другими продвинутыми функциями. Помните что память, которую возвращает команда stats также включает в себя свободную память, которую ещё не забрал сборщик мусора. Всё остальное это разделяемая память среды выполнения (порядка 40-50 МиБ) и место для работы (может варьироваться). Именно поэтому ASF может использовать около 50 МиБ в среде VPS с малым объёмом памяти, и в то же время занимать до 1 GB на вашем домашнем ПК. ASF активно адаптируется к вашей среде, и будет пытаться найти оптимальный баланс между нагрузкой на вашу ОС и собственной производительностью когда у вас есть много свободной памяти, которую можно использовать.

Разумеется, есть много способов помочь направить ASF в нужном направлении в отношении ожидаемого использования памяти. В общем случае вам не надо этого делать, лучше позволить сборщику мусора работать как он сочтёт нужным. Но это не всегда возможно, например если ваш сервер под ОС Linux параллельно размещает несколько веб-сайтов, базу данных MySQL и обработчики PHP, вы не можете позволить ASF ужиматься только когда вы приблизились к состоянии OOM, это обычно уже слишком поздно и ведёт к ухудшению производительности. В подобных ситуациях вы будете заинтересованы в дальнейшей настройке, и соответственно в чтении этой статьи.

Предложения ниже разделены на несколько категорий, с различной сложностью.

Настройки ASF (лёгкий уровень)

Советы ниже не влияют отрицательно на производительность и могут быть безопасно использованы для любой конфигурации.

Никогда не запускайте больше одной копии ASF. ASF предназначен для одновременной работы с неограниченным числом ботов, и если вы не подключаете каждую копию ASF к отдельному интерфейсу/IP адресу, у вас должен быть ровно один процесс ASF, с несколькими ботами (если необходимо).
Используйте ShutdownOnFarmingFinished. Запущенный бот потребляет гораздо больше ресурсов, чем деактивированный. Это незначительная экономия, поскольку состояние бота всё равно придётся хранить, но вы экономите некоторые количество ресурсов, особенно связанных с сетью, таких как сокеты TCP. Вам нужен только один активным бот чтобы ASF продолжил работу, и вы всегда можете запустить других ботов при необходимости.
Используйте небольшое количество ботов. Бот без параметра Enabled занимает меньше ресурсов, поскольку ASF нет нужды запускать его. Также помните что ASF создаёт бота для каждого файла конфигурации, поэтому если вы не собираетесь запускать его командой start и хотите сэкономить немного памяти, вы можете временно переименовать Bot.json например в Bot.json.bak чтобы избежать создания неактивного бота в процессе ASF. При этом вы не сможете запустить его командой start не переименовав его назад, но ASF не будет сохранять состояние этого бота в памяти, освободив эту память для других нужд (очень маленький объём, в 99.9% случаев не стоит с этим возиться, просто поставьте своим ботам значение параметра Enabled равным 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. Чем меньше работы выполняется одновременно - тем меньше занимаемый объём памяти.

Это и есть те немногие вещи о которых стоит помнить, когда имеете дело с объёмом используемой памяти. Однако. все эти вещи не имеют "критического" значения на объём используемой памяти, поскольку основные объмы памяти требуются на то, с чем ASF приходится иметь дело, а не с внутренними структурами используемыми для фарма карточек.

Наиболее ресурсоёмкие функции это:

Разбор страниц со значками
Разбор инвентаря

Отсюда следует, что пики памяти будут в основном когда ASF читает и обрабатывает страницы значков, и когда работает с инвентарем (например, отсылает предложение обмена или работает с STM). Это связано с тем, что ASF приходится иметь дело с огромными объёмами данных - потребление памяти в вашем любимом браузере при запуске этих двух страниц не будет намного ниже. Извините, но так это работает - уменьшите количество страниц со значками, и не храните слишком много предметов в инвентаре, это точно поможет.

Расширенная настройка среды исполнения

Советы ниже ведут к ухудшению производительности и должны использоваться с осторожностью.

Среда выполнения .NET Core позволяет вам настраивать сборщик мусора несколькими способами, эффективно настраивая процесс сборки мусора в соответствии с вашими потребностями.

Рекомендуется применять эти настройки через переменные среды с префиксом COMPlus_. Разумеется, вы можете использовать и другие методы, например файл runtimeconfig.json, но некоторые настройки таким образом поменять не удастся, а кроме того ASF заменит ваш runtimeconfig.json на стандартный при следующем обновлении, поэтому мы рекомендуем переменные среды, которые вы легко можете установить перед запуском процесса.

Все доступные настройки вы найдёте в документации, а ниже мы расскажем о наиболее важных (по нашему мнению):

`GCHeapHardLimitPercent`

Задаёт используемый размер кучи сборщика мусора в процентах от общей памяти.

Эта настройка - "жесткий" предел памяти для процесса ASF, она указывает сборщику мусора использовать только часть общего объёма памяти, а не всю её. Это может оказаться особенно полезным для различных серверных ситуаций, где вы можете выделить фиксированный процент памяти сервера для ASF, но не более того. Имейте в виду, что ограничение памяти ASF не отменит магическим образом все необходимые для работы выделения памяти, поэтому если вы установите здесь слишком низкое значение это может привести к ситуации с нехваткой памяти, из-за чего процесс ASF будет вынужден завершить работу.

С другой стороны, при достаточно высоком значении этой настройки - это отличный способ обеспечить чтобы ASF никогда не использовал больше памяти чем ему реально требуется, давая вашей машине немного свободного пространства даже под высокой нагрузкой, при этом позволяя программе работать настолько эффективно, насколько возможно.

`GCHighMemPercent`

Specifies the amount of memory used after which GC becomes more aggressive.

This setting configures the memory treshold of your whole OS, which once passed, causes GC to become more aggressive and attempt to help the OS lower the memory load by running more intensive GC process and in result releasing more free memory back to the OS. It's a good idea to set this property to maximum amount of memory (as percentage) which you consider "critical" for your whole OS performance. Default is 90%, and usually you want to keep it in 80-97% range, as too low value will cause unnecessary aggression from the GC and performance degradation for no reason, while too high value will put unnecessary load on your OS, considering ASF could release some of its memory to help.

`GCLatencyLevel`

Задаёт уровень задержек сборщика мусора, который вы хотите оптимизировать.

Эта недокументированная настройка оказалось чрезвычайно полезной для ASF, она ограничивает размер поколений объектов в сборщике мусора, и в результате вынуждает сборщик мусора очищать их чаще и более агрессивно. Default (balanced) latency level is 1, but you can use 0, which will tune for memory usage.

`gcTrimCommitOnLowMemory`

Если активно - мы урезаем выделяемую память более агрессивно для недолговечных сегментов. Это используется для запуска множества процессов на сервере, где необходимо чтобы они использовали как можно меньше памяти.

Это даёт небольшое улучшение, но может сделать сборщик мусора более агрессивным когда в системе будет мало памяти, в особенности для ASF, где интенсивно используются задачи на базе пула потоков.

Вы можете активировать все настройки сборщика мусора установив соответствующие переменные среды с префиксом COMPlus_. Например, для Linux (shell):

# Don't forget to tune those if you're planning to make use of them
export COMPlus_GCHeapHardLimitPercent=4B # 75% as hex
export COMPlus_GCHighMemPercent=50 # 80% as hex

export COMPlus_GCLatencyLevel=0
export COMPlus_gcTrimCommitOnLowMemory=1

./ArchiSteamFarm # For OS-specific build

Или для Windows (powershell):

# Don't forget to tune those if you're planning to make use of them
$Env:COMPlus_GCHeapHardLimitPercent=4B # 75% as hex
$Env:COMPlus_GCHighMemPercent=50 # 80% as hex

$Env:COMPlus_GCLatencyLevel=0
$Env:COMPlus_gcTrimCommitOnLowMemory=1

.\ArchiSteamFarm.exe # For OS-specific build

GCLatencyLevel согласно нашим проверкам будет особенно полезным, поскольку среда выполнения при этом оптимизирует код для работы с памятью, и следовательно значительно снижает использование памяти, даже с серверным GC. Это одна из самых полезных настроек если вы хотите значительно уменьшить потребление памяти ASF и при этом не слишком навредить производительности как при использовании OptimizationMode.

Настройки ASF (средний уровень)

Методы ниже приводят к значительному уменьшению производительности и должны использоваться с осторожностью.

В качестве крайней меры, вы можете настроить ASF на минимальное потребление памяти включив MinMemoryUsage в параметре глобальной конфигурации OptimizationMode. Внимательно прочтите, зачем этот режим нужен, поскольку он приводит к серьёзному ухудшению производительности но незначительно улучшает ситуацию с памятью. В общем случае это последнее что стоит делать, уже после того как вы изменили настройки среды выполнения чтобы убедиться, что вам без этого не обойтись. Unless absolutely critical for your setup, we discourage using MinMemoryUsage, even in memory-constrained environments.