Low memory setup ru RU

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

This is exact opposite of high-performance setup and typically you want to follow those tips if you want to decrease ASF's memory usage, for cost of lowering overall performance.

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

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

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

Сборщик мусора (Garbage collector, далее GC), используемый в ASF, достаточно интеллектуальный чтобы учитывать не только потребности самого ASF, но и всей вашей ОС. Когда у вас много свободной памяти - ASF будет запрашивать столько, сколько позволит увеличить производительность. Это может быть вплоть до 1ГиБ (с серверным GC). Если память вашей ОС почти заполнена, ASF, будет автоматически освобождать часть памяти назад в ОС чтобы помочь урегулировать это, что может привести к снижению потребляемой ASF памяти вплоть до 50 МиБ. Поэтому потребляемая ASF память может отличаться в разных условиях, поскольку ASF будет стараться использовать доступные ресурсы максимально эфффективно, а не в фиксированном объёме как это делалось во времена Windows XP. 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. Помните что память, которую возвращает команда stats включает в себя свободную память, которую ещё не забрал сборщик мусора. Всё остальное это разделяемая память среды выполнения (порядка 40-50 МиБ) и место для работы (может варьироваться). Именно поэтому ASF может использовать около 50 МиБ в среде VPS с малым объёмом памяти, и в то же время занимать до 1 GB на вашем домашнем ПК.

Разумеется, есть много способов помочь направить 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 предоставляет следующие типы сборки мусора:

Сборка мусора для рабочей станции, предназначенная для всех клиентских рабочих станций и отдельных ПК. Это значение по умолчанию для элемента в схеме конфигурации среды выполнения.

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

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

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

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

`GCLatencyLevel`

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

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

`gcTrimCommitOnLowMemory`

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

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

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

export COMPlus_GCLatencyLevel=0
export COMPlus_gcTrimCommitOnLowMemory=1
./ArchiSteamFarm

Или для Windows:

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

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

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

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

As a last resort, you can tune ASF for MinMemoryUsage through OptimizationMode global config property. Внимательно прочтите, зачем этот режим нужен, поскольку он приводит к серьёзному ухудшению производительности но незначительно улучшает ситуацию с памятью. В общем случае это последнее что стоит делать, уже после того как вы изменили настройки среды выполнения чтобы убедиться, что вам без этого не обойтись.