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.

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

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

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

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

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

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

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

Файл ArchiSteamFarm.runtimeconfig.json позволяет вам настроить среду выполнения ASF, в частности позволяя переключаться между серверным GC и GC для рабочих станций.

Сборщик мусора самонастраивающийся и может работать по большому количеству сценариев. Вы можете использовать настройки в конфигурационном файле чтобы указать тип сборщика мусора основываясь на характеристиках нагрузки. Среда CLR предоставляет следующие типы сборщика мусора: - Сборка мусора рабочей станции, предназначенная для всех клиентских рабочих станций и автономных ПК. Это стандартная настройка для элемента <gcServer> в схеме конфигурации среды исполнения. - Серверная сборка мусора, которая предназначена для серверных приложений, требующих высокой пропускной способности и масштабируемости. Серверная сборка мусора может быть непараллельной или фоновой.

Вы можете узнать больше, прочитав статью "основы сборки мусора".

ASF по умолчанию использует сборку мусора для рабочих станций, но вы можете убедиться что это действительно так, проверив что параметр System.GC.Server в файле ArchiSteamFarm.runtimeconfig.json равен false.

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

`GCHeapHardLimitPercent`

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

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

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

`GCLatencyLevel`

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

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

`gcTrimCommitOnLowMemory`

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

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

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

# Не забудьте изменить эту настройку если будете это использовать
export COMPlus_GCHeapHardLimitPercent=75

export COMPlus_GCLatencyLevel=0
export COMPlus_gcTrimCommitOnLowMemory=1

./ArchiSteamFarm # Для версии под конкретную ОС

Или для Windows (powershell):

# Не забудьте изменить эту настройку если будете это использовать
$Env:COMPlus_GCHeapHardLimitPercent=75

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

.\ArchiSteamFarm.exe # Для версии под конкретную ОС

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

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

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

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