High performance setup ru RU

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

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

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

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

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

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

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

`gcServer`

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

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

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

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

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

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

`DOTNET_TieredPGO`

Эта настройка позволяет проводить динамическую или многоуровневую оптимизацию (PGO) в .NET 6 и более поздних версиях.

Отключено по умолчанию. В общем, это заставит JIT тратить больше времени на анализ кода ASF и его шаблонов для создания превосходного кода, оптимизированного для вашего типичного использования. Если вы хотите узнать больше об этом параметре, посетите улучшения производительности в .NET 6.

`DOTNET_ReadyToRun`

Определяет, используется ли предварительно скомпилированный код для изображений с доступными данными ReadyToRun. Отключение этой опции вынуждает запускать код JIT-компиляции.

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

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

export DOTNET_gcServer=1

export DOTNET_TieredPGO=1
export DOTNET_ReadyToRun=0

./ArchiSteamFarm # For OS-specific build
./ArchiSteamFarm.sh # For generic build

Или для Windows (powershell):

$Env:DOTNET_gcServer=1

$Env:DOTNET_TieredPGO=1
$Env:DOTNET_ReadyToRun=0

.\ArchiSteamFarm.exe # For OS-specific build
.\ArchiSteamFarm.cmd # For generic build

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

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

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