High performance setup ko KR

고성능 설정

이는 저메모리 설정(low-memory setup) 과 정확히 반대되는 방식이며, ASF 성능(CPU 속도 기준)을 더욱 끌어올리고 싶으시다면 이 팁들을 따라야 합니다. 다만 그 대가로 메모리 사용량이 증가할 수 있습니다.

---

ASF는 이미 전반적인 균형 잡힌 튜닝에서 성능을 우선시하도록 설계되어 있으므로, 성능을 추가로 끌어올릴 수 있는 여지는 그리 많지 않습니다. 다만 선택지가 완전히 없는 것은 아닙니다. 다만 이 옵션들은 기본적으로 활성화되어 있지 않다는 점을 유념하세요. 이는 대다수의 사용 환경에서 균형 잡힌 설정으로 간주할 만큼 충분히 좋은 옵션은 아니라는 뜻이므로, 이로 인해 증가하는 메모리 사용량이 본인에게 감내할 만한 수준인지는 직접 판단하셔야 합니다.

---

런타임 튜닝 (고급)

아래의 방법들은 상당한 메모리 사용량 증가를 수반 하므로 신중하게 사용하셔야 합니다.

이러한 설정을 적용하는 권장 방법은 DOTNET_ 환경 속성을 통하는 것입니다. 물론 runtimeconfig.json과 같은 다른 방법도 사용하실 수 있지만, 일부 설정은 이 방식으로는 아예 설정이 불가능하며, 게다가 ASF는 다음 업데이트 시 사용자가 직접 수정한 runtimeconfig.json을 자체 파일로 덮어쓰기 때문에, 프로세스를 실행하기 전에 손쉽게 설정할 수 있는 환경 속성 방식을 권장드립니다.

.NET 런타임을 사용하면 가비지 컬렉터(garbage collector)를 조정 할 수 있는 다양한 방법을 제공하여, 필요에 맞게 GC 프로세스를 효과적으로 미세 조정할 수 있습니다. 저희가 특히 중요하다고 판단하는 속성들을 아래에 문서화해두었습니다.

gcServer

애플리케이션이 워크스테이션(workstation) 가비지 컬렉션을 사용할지, 서버(server) 가비지 컬렉션을 사용할지를 설정합니다.

서버 GC의 정확한 세부 사항은 가비지 컬렉션의 기본 원리 에서 확인하실 수 있습니다.

ASF는 기본적으로 워크스테이션 가비지 컬렉션을 사용합니다. 이는 주로 메모리 사용량과 성능 사이의 균형이 좋기 때문이며, 소수의 봇만 운영하는 경우에는 이 정도로도 충분합니다. 보통 단일 동시 실행 백그라운드 GC 스레드만으로도 ASF가 할당한 전체 메모리를 처리하기에 충분히 빠르기 때문입니다.

다만 오늘날에는 ASF가 크게 활용할 수 있는 다수의 CPU 코어가 존재하며, 사용 가능한 각 CPU vCore마다 전용 GC 스레드를 할당함으로써 큰 이점을 얻을 수 있습니다. 이는 배지 페이지나 인벤토리 파싱과 같은 무거운 ASF 작업 중 성능을 크게 향상시킬 수 있습니다. 각 CPU vCore가 (메인 스레드와 GC 스레드, 단 2개뿐이 아니라) 모두 작업을 도울 수 있기 때문입니다. 서버 GC는 CPU vCore가 3개 이상인 기기에 권장됩니다. 기기에 CPU vCore가 1개뿐이라면 자동으로 워크스테이션 GC가 강제 적용되며, 정확히 2개라면 둘 다 시도해보시는 것도 고려해볼 만합니다(결과는 상황에 따라 다를 수 있습니다).

서버 GC 자체는 단순히 활성화된 상태만으로는 그리 큰 메모리 증가를 초래하지 않지만, 세대(generation) 크기가 훨씬 크기 때문에 메모리를 OS에 돌려주는 데 있어 훨씬 더 소극적(lazy)입니다. 서버 GC가 성능을 크게 향상시켜서 계속 사용하고 싶지만, 동시에 이로 인해 발생하는 큰 메모리 사용량 증가는 감당할 수 없는, 애매한 지점에 놓이실 수도 있습니다. 다행히도 "두 마리 토끼를 모두 잡는" 설정이 존재합니다. GCLatencyLevel 설정 속성을 0으로 설정하여 서버 GC를 사용하는 방법인데, 이렇게 하면 서버 GC는 계속 활성화된 상태를 유지하면서도 세대 크기를 제한하여 메모리 사용에 좀 더 집중하게 됩니다. 또는 GCHeapHardLimitPercent 라는 다른 속성을 실험해보시거나, 두 속성을 동시에 사용해보실 수도 있습니다.

다만 메모리가 문제가 되지 않는 환경이시라면(GC는 여전히 사용 가능한 메모리를 고려하여 스스로 조정하므로), 이러한 속성들을 전혀 변경하지 않는 것이 훨씬 더 좋은 방법이며, 그 결과 더 뛰어난 성능을 얻으실 수 있습니다.

---

적절한 환경 변수를 설정하여 원하는 속성을 활성화하실 수 있습니다. 예를 들어, Linux(셸)에서는:

export DOTNET_gcServer=1

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

또는 Windows(PowerShell)에서는:

$Env:DOTNET_gcServer=1

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

---

추천 최적화

• OptimizationMode의 기본값인 MaxPerformance를 그대로 사용하고 있는지 확인하세요. 이는 단연코 가장 중요한 설정입니다. MinMemoryUsage 값을 사용하면 성능에 극적인(부정적인) 영향을 미치기 때문입니다.
• 서버 GC 활성화하기. 서버 GC는 활성화되면 워크스테이션 GC 대비 눈에 띄게 증가하는 메모리 사용량으로 바로 확인할 수 있습니다. 이는 최대 속도로 GC 작업을 병렬 처리하기 위해, 기기가 가진 모든 CPU 스레드마다 하나씩 GC 스레드를 생성합니다.
• 서버 GC로 인한 메모리 증가를 감당할 수 없으시다면, "두 마리 토끼를 모두 잡기" 위해 GCLatencyLevel 및/또는 GCHeapHardLimitPercent 를 조정하는 것을 고려해보세요. 다만 메모리에 여유가 있으시다면, 기본값 그대로 유지하는 것이 더 좋습니다 - 서버 GC는 런타임 중 이미 스스로를 조정하며, OS가 실제로 메모리가 필요할 때는 더 적은 메모리를 사용할 만큼 충분히 똑똑합니다.

위의 권장 사항들을 적용하면 수백~수천 개의 봇이 활성화된 상태에서도 매우 빠른 ASF 성능을 얻으실 수 있습니다. 이제 CPU는 더 이상 병목 지점이 아니게 될 것입니다. ASF가 필요할 때 전체 CPU 성능을 활용할 수 있어, 필요한 처리 시간을 최소한으로 줄여주기 때문입니다. 다음 단계는 CPU 및 RAM 업그레이드, 또는 여러 서버와 ASF 인스턴스에 작업을 분산시키는 것입니다.