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`

This setting enables dynamic or tiered profile-guided optimization (PGO) in .NET 6 and later versions.

Disabled by default. In a nutshell, this will cause JIT to spend more time analyzing ASF's code and its patterns in order to generate superior code optimized for your typical usage. If you want to learn more about this setting, visit performance improvements in .NET 6.

`DOTNET_ReadyToRun`

Configures whether the .NET Core runtime uses pre-compiled code for images with available ReadyToRun data. Disabling this option forces the runtime to JIT-compile framework code.

Enabled by default. Disabling this in combination with enabling DOTNET_TieredPGO allows you to extend tiered profile-guided optimization to the whole .NET platform, and not just ASF code.

Вы можете включить выбранные настройки, установив соответствующие переменные среды. Например, для 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 имеет драматический эффект на производительность.
Включите серверный сборщик мусора. Вы сразу заметите что серверный сборщик мусора активен по значительному увеличению потребляемой памяти в сравнении со сборщиком мусора для рабочих станций. This will spawn a GC thread for every CPU thread your machine has in order to perform GC operations in parallel with maximum speed.
If you can't afford memory increase due to server GC, consider tweaking GCLatencyLevel and/or GCHeapHardLimitPercent to achieve "the best of both worlds". Однако, если память позволяет, лучше оставить этот параметр по умолчанию - серверный сборщик мусора подстраивает себя во время работы и достаточно умён чтобы использовать меньше памяти когда вашей ОС это действительно необходимо.
You can also consider increased optimization for longer startup time with additional tweaking through other DOTNET_ properties explained above.

Applying recommendations above allows you to have superior ASF performance that should be blazing fast even with hundreds or thousands of enabled bots. ЦПУ больше не будет узким местом, поскольку ASF сможет использовать при необходимости всю доступную производительность ЦПУ, снижая требуемое время до необходимого минимума. Следующим шагом будет апгрейд процессора и памяти.