-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
High performance setup ru RU
Это полная противоположность конфигурации для низкого потребления ОЗУ и обычно вы захотите следовать этим советам если хотите дополнительно увеличить производительность ASF (в плане скорости ЦПУ), ценой увеличения потребляемой памяти.
ASF и так пытается предпочитать производительность когда дело доходит до баланса, поэтому вы не многое можете сделать чтобы улучшить производительность ещё больше, хотя некоторые возможности есть. Однако помните, что эти настройки не включены по умолчанию, а значит они недостаточно хороши чтобы считать их сбалансированными для большинства пользователей, поэтому вам надо решить, допустимо ли для вас дальнейшее увеличение потребляемой памяти в качестве платы за производительность.
Методы ниже приводят к значительному увеличению потребления памяти и должны использоваться с осторожностью.
Файл ArchiSteamFarm.runtimeconfig.json
позволяет вам настроить среду выполнения ASF, в частности позволяя переключаться между серверным GC и GC для рабочих станций.
Сборщик мусора самонастраивающийся и может работать по большому количеству сценариев. Вы можете использовать настройки в конфигурационном файле чтобы указать тип сборщика мусора основываясь на характеристиках нагрузки. Среда CLR предоставляет следующие типы сборщика мусора: - Сборка мусора рабочей станции, предназначенная для всех клиентских рабочих станций и автономных ПК. Это стандартная настройка для элемента
<gcServer>
в схеме конфигурации среды исполнения. - Серверная сборка мусора, которая предназначена для серверных приложений, требующих высокой пропускной способности и масштабируемости. Серверная сборка мусора может быть непараллельной или фоновой.
Вы можете узнать больше, прочитав статью "основы сборки мусора".
ASF по умолчанию использует сборку мусора для базовых станций. В основном потому, что этот вариант предоставляет хороший баланс между потреблением памяти и производительности, этого более чем достаточно для небольшого числа ботов, поскольку только один параллельный фоновый поток GC достаточно быстр чтобы справиться со всеми процессами выделения памяти в ASF.
Однако, в наши дни у нас есть ЦПУ c большим количеством ядер, и ASF может получить из этого выгоду, имея по одному выделенному потоку GC на каждое доступное виртуальное ядро ЦПУ. Это может значительно улучшить производительность во время тяжёлых задач в ASF, таких как обработка страниц значков или инвентаря, поскольку каждое виртуальное ядро ЦПУ сможет помочь, в противовес только 2 (основной и GC). Серверный GC рекомендуется для машин с 3 и более виртуальных ядер ЦПУ, GC для рабочих станций принудительно включается или машина имеет только одно виртуальное ядро ЦПУ, а если у вас их ровно 2 вы можете попробовать оба способа (результаты могут быть разные).
Вы можете включить серверный GC переключив параметр System.GC.Server
в файле ArchiSteamFarm.runtimeconfig.json
с false
на true
. Помните, что возможно это придётся сделать больше чем один раз, поскольку ASF будет использовать false
по умолчанию после авто-обновления.
Серверный GC сам по себе не даёт большого увеличения потребляемой памяти просто будучи включенным, однако у него гораздо больше объёмы генерации, и поэтому он более ленивый когда дело доходит до возвращения памяти ОС. Вы можете обнаружить что вам нравится как сильно серверный GC увеличивает производительность и вы хотите этим пользоваться, но в то же время вы не можете позволить себе значительного увеличения потребляемой памяти, которое из этого следует. К счастью для вас, есть вариант настроек для "лучшего из обоих миров", это использование серверного GC совместно с уровнем задержки GC установленном в 0
, что позволит использовать серверный GC, но ограничить размеры генерации и больше сфокусируется на памяти.
Однако, если память для вас не проблема (поскольку GC всё равно учитывает доступную у вас память и подстраивается), гораздо лучше вообще не менять GCLatencyLevel
, получив в результате превосходную производительность.
- Убедитесь что используете значение по умолчанию в параметре
OptimizationMode
, равноеMaxPerformance
. На данный момент это самая важная настройка, поскольку использование значенияMinMemoryUsage
имеет драматический эффект на производительность. - Включите серверный GC переключив параметр
System.GC.Server
в файлеArchiSteamFarm.runtimeconfig.json
сfalse
наtrue
. Это включит серверный GC, что будет сразу заметно по увеличению занимаемой памяти в сравнению с GC для рабочих станций. - Если вы не можете себе позволить такое увеличение потребляемой памяти, рассмотрите вариант с использованием
GCLatencyLevel
равным0
чтобы получить "лучшее из обоих миров". Однако, если память позволяет, лучше оставить этот параметр по умолчанию - серверный GC подстраивает себя во время работы и достаточно умён чтобы использовать меньше памяти когда вашей ОС это действительно необходимо.
Если вы включили серверный GC и оставили значение по умолчанию параметру GCLatencyLevel
, вы достигнете превосходной производительности ASF, который будет работать молниеносно с сотнями и даже тысячами ботов. ЦПУ больше не будет узким местом, поскольку ASF сможет использовать при необходимости всю доступную производительность ЦПУ, снижая требуемое время до необходимого минимума.
- 🏡 Главная
- 🔧 Конфигурация
- 💬 ЧАВО
- ⚙️ Настройка (начать здесь)
- 👥 Фоновая активация ключей
- 📢 Команды
- 🛠️ Совместимость
- 🧩 Плагин ItemsMatcherPlugin
- 📋 Управление
- ⏱️ Производительность
- 📡 Удаленная связь
- 👪 Steam Family Sharing
- 🔄 Обмены
- ⌨️ Аргументы командной строки
- 🚧 Устаревание
- 🐳 Docker
- 🤔 Расширенное ЧАВО
- 🚀 Конфигурация для высокой производительности
- 🔗 IPC
- 🌐 Локализация
- 📝 Журналирование
- 💾 Конфигурация для малого ОЗУ
- 🕵🏼♂️ Плагин мониторинга
- 🔌 Плагины
- 🔐 Безопасность
- 🧩 SteamTokenDumperPlugin
- 📦 Сторонние разработки
- 📵 Двухфакторная аутентификация