Low memory setup ru RU

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

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

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

ASF как приложение пытается быть настолько оптимальным и эффективным насколько это возможно, учитывая при этом ресурсы необходимые для работы. Когда дело доходит до памяти, ASF предпочитает производительность а не экономию памяти, и в результате могут появляться "пики" потребления памяти, которые можно заметить если например у аккаунта 3+ страницы со значками, поскольку в этом случае ASF запросит первую страницу, считает с неё номер страниц и затем запросит сразу все дополнительные страницы для параллельной обработки. Это "дополнительное" потребление памяти (по сравнению с минимально необходимым для работы) может существенно ускорить работу и общую производительность, ценой увеличенного потребления памяти, необходимого для выполнения этих задач параллельно. Похожая ситуация и со всеми остальными задачами ASF, которые можно выполнять параллельно, например при обработке активных предложений обмена ASF может обрабатывать их все одновременно, поскольку они независимы друг от друга. В добавок к этому, ASF (а точнее среда выполнения C#) не возвращает неиспользуемую память назад ОС сразу же, что легко заметить по тому, что процесс ASF только берёт себе больше и больше памяти, но (почти) никогда не возвращает её ОС. Некоторые люди могут счесть это подозрительным, и даже предположить наличие утечки памяти, но не волнуйтесь, это ожидаемое поведение.

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

Процесс очистки мусора, используемый в ASF, - это очень сложный механизм, достаточно умный, чтобы учитывать не только сам ASF, но также вашу ОС и другие процессы. Когда у вас много свободной памяти - 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 (лёгкий уровень)

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

Run generic version of ASF if possible. Generic version of ASF uses less memory since it doesn't include runtime inside, doesn't come as single file, doesn't need to unpack itself on run, and is therefore smaller and has less memory footprint. OS-specific packages are handy and convenient, but they're also bundled with everything needed to launch ASF, which is something you can take care of yourself and use generic ASF variant instead.
Никогда не запускайте больше одной копии ASF. ASF предназначен для одновременной работы с неограниченным числом ботов, и если вы не подключаете каждую копию ASF к отдельному интерфейсу/IP адресу, у вас должен быть ровно один процесс ASF, с несколькими ботами (если необходимо).
Используйте ShutdownOnFarmingFinished. Запущенный бот потребляет гораздо больше ресурсов, чем деактивированный. Это незначительная экономия, поскольку состояние бота всё равно придётся хранить, но вы экономите некоторые количество ресурсов, особенно связанных с сетью, таких как сокеты TCP. Вы всегда можете запустить других ботов, если это необходимо.
Используйте небольшое количество ботов. Бот без параметра Enabled занимает меньше ресурсов, поскольку ASF нет нужды запускать его. Также помните что ASF создаёт бота для каждого файла конфигурации, поэтому если вы не собираетесь запускать его командой start и хотите сэкономить немного памяти, вы можете временно переименовать Bot.json например в Bot.json.bak чтобы избежать создания неактивного бота в процессе ASF. При этом вы не сможете запустить его командой start не переименовав его назад, но ASF не будет сохранять состояние этого бота в памяти, освободив эту память для других нужд (очень маленький объём, в 99.9% случаев не стоит с этим возиться, просто поставьте своим ботам значение параметра Enabled равным false).
Настройте свои конфиги. Файл глобальной конфигурации ASF имеет особенно много переменных, которые можно изменить, например, увеличив значение LoginLimiterDelay вы сделаете запуск ботов более медленным, что даст возможность уже запущенным ботам параллельно запрашивать страницы значков, в противоположность быстрому запуску ботов, который потребует больше ресурсов, поскольку больше ботов будут делать основную работу (такую как разбор страниц значков) в одно и то же время. Чем меньше работы выполняется одновременно - тем меньше занимаемый объём памяти.

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

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

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

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

Настройка среды выполнения (расширенная)

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

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

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

`GCHeapHardLimitPercent`

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

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

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

`GCHighMemPercent`

Задает объем используемой памяти, после которого сборщик мусора становится более агрессивным.

Этот параметр настраивает порог памяти для всей вашей ОС, который после прохождения приводит к тому, что сборщик мусора становится более агрессивным и пытается помочь ОС снизить нагрузку на память, выполняя более интенсивный процесс сбора мусора и в результате высвобождая больше свободной памяти обратно в ОС. Рекомендуется установить для этого свойства максимальный объем памяти (в процентах), который вы считаете «критическим» для всей производительности вашей ОС. По умолчанию это 90%, и обычно стоит сохранить его в диапазоне 80-97%, так как слишком низкое значение вызовет ненужную агрессию со стороны GC и снижение производительности без причины, а слишком высокое значение приведет к ненужной нагрузке на вашу ОС, учитывая ASF может освободить часть своей памяти, чтобы помочь.

`GCLatencyLevel`

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

Эта недокументированная настройка оказалось чрезвычайно полезной для ASF, она ограничивает размер поколений объектов в сборщике мусора, и в результате вынуждает сборщик мусора очищать их чаще и более агрессивно. Уровень задержки по умолчанию (сбалансированный) равен 1, но вы можете использовать 0, который уменьшит использование памяти.

`gcTrimCommitOnLowMemory`

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

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

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

# Не забудьте изменить настройку под себя, если планируете её использовать
export DOTNET_GCHeapHardLimitPercent=0x4B # 75% as hex
export DOTNET_GCHighMemPercent=0x50 # 80% as hex

export DOTNET_GCLatencyLevel=0
export DOTNET_gcTrimCommitOnLowMemory=1

./ArchiSteamFarm # Для платформно-специфичных сборок
./ArchiSteamFarm.sh # Для общих (generic) сборок

Или для Windows (powershell):

# Не забудьте изменить настройку под себя, если планируете её использовать
$Env:DOTNET_GCHeapHardLimitPercent=0x4B # 75% as hex
$Env:DOTNET_GCHighMemPercent=0x50 # 80% as hex

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

.\ArchiSteamFarm.exe # Для платформно-специфичных сборок
.\ArchiSteamFarm.cmd # Для общих (generic) сборок

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

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

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

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