High performance setup ru RU

Конфигурация для высокой производительности

Это полная противоположность конфигурации для низкого потребления ОЗУ и обычно вы захотите следовать этим советам если хотите дополнительно увеличить производительность ASF (в плане скорости ЦПУ), ценой увеличения потребляемой памяти.

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

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

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

.NET runtime allows you to tweak garbage collector in a lot of ways, effectively fine-tuning the GC process according to your needs.

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

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

`gcServer`

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

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

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

Однако, в наши дни у нас есть ЦПУ c большим количеством ядер, и ASF может получить из этого выгоду, имея по одному выделенному потоку сборки мусорк на каждое доступное виртуальное ядро ЦПУ. Это может значительно улучшить производительность во время тяжёлых задач в ASF, таких как обработка страниц значков или инвентаря, поскольку каждое виртуальное ядро ЦПУ сможет помочь, в противовес только 2 (основной и сборка мусора). Серверный сборщик мусора рекомендуется для машин с 3 и более виртуальных ядер ЦПУ, сборщик мусора для рабочих станций принудительно включается если машина имеет только одно виртуальное ядро ЦПУ, а если у вас их ровно 2 вы можете попробовать оба способа (результаты могут быть разные).

Серверный сборщик мусора сам по себе не даёт большого увеличения потребляемой памяти просто будучи включенным, однако у него гораздо больше объёмы генерации, и поэтому он более ленивый когда дело доходит до возвращения памяти ОС. Вы можете обнаружить что вам нравится как сильно серверный сборщик мусора увеличивает производительность и вы хотите этим пользоваться, но в то же время вы не можете позволить себе значительного увеличения потребляемой памяти, которое из этого следует. К счастью для вас, есть вариант настроек для получения "лучшего из обоих миров", это использование серверного сборщика мусора совместно с настройкой GCLatencyLevel установленной в 0, что позволит использовать серверный сборщик мусора, но ограничить размеры поколений объектов и больше сфокусироваться на памяти. В качестве альтернативы вы также можете поэкспериментировать с другой настройкой, GCHeapHardLimitPercent, или даже одновременно с ними обеими.

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

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

export COMPlus_gcServer=1

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

Или для Windows (powershell):

$Env:COMPlus_gcServer=1

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

Рекомендуемые оптимизации

Убедитесь что используете значение по умолчанию в параметре OptimizationMode, равное MaxPerformance. На данный момент это самая важная настройка, поскольку использование значения MinMemoryUsage имеет драматический эффект на производительность.
Включите серверный сборщик мусора. Вы сразу заметите что серверный сборщик мусора активен по значительному увеличению потребляемой памяти в сравнении со сборщиком мусора для рабочих станций.
Если вы не можете повзолить себе такое увеличение памяти, подумайте о настройке GCLatencyLevel и/или GCHeapHardLimitPercent чтобы получить "лучшее из обоих миров". Однако, если память позволяет, лучше оставить этот параметр по умолчанию - серверный сборщик мусора подстраивает себя во время работы и достаточно умён чтобы использовать меньше памяти когда вашей ОС это действительно необходимо.

Если вы включили серверный сборщик мусора и оставили прочие настройки по умолчанию, вы достигнете превосходной производительности ASF, который будет работать молниеносно с сотнями и даже тысячами включенных ботов. ЦПУ больше не будет узким местом, поскольку ASF сможет использовать при необходимости всю доступную производительность ЦПУ, снижая требуемое время до необходимого минимума. Следующим шагом будет апгрейд процессора и памяти.