Low memory setup ko KR

낮은 메모리 설치

이는 고성능(high-performance) 설정 과 정확히 반대되는 내용이며, 전반적인 성능을 낮추더라도 ASF의 메모리 사용량을 줄이고 싶다면 이 팁들을 따르는 것이 일반적입니다.

---

ASF는 태생적으로 리소스를 매우 적게 사용하며, 사용 방식에 따라 128MB짜리 Linux VPS에서도 실행이 가능할 정도입니다. 다만 그렇게 낮은 사양은 다양한 문제를 일으킬 수 있어 권장하지 않습니다. 가볍게 동작하면서도, ASF는 최적의 속도로 동작하기 위해 필요하다면 OS에 추가 메모리를 요청하는 것을 주저하지 않습니다.

ASF는 애플리케이션으로서 최대한 최적화되고 효율적으로 동작하려 하며, 실행 중 사용되는 리소스 또한 이를 고려합니다. 메모리와 관련해 ASF는 메모리 사용량보다 성능을 우선시하며, 이로 인해 예를 들어 배지 페이지가 3개 이상인 계정에서 일시적인 메모리 "스파이크"가 발생할 수 있습니다. ASF는 먼저 페이지를 가져와 파싱하여 전체 페이지 수를 파악한 뒤, 나머지 각 페이지에 대해 가져오기 작업을 실행하여 나머지 페이지들을 동시에 가져오고 파싱합니다. 이러한 "추가" 메모리 사용(동작에 필요한 최소치 대비)은 모든 작업을 병렬로 처리하는 데 필요한 대가로, 실행 속도와 전반적인 성능을 크게 향상시킬 수 있습니다. 활성 거래 제안을 파싱하는 것과 같이, 병렬로 실행 가능한 다른 일반 ASF 작업들에서도 비슷한 현상이 발생합니다. 이런 작업들은 서로 독립적이므로 ASF는 이를 한꺼번에 파싱할 수 있습니다. 이에 더해, ASF(C# 런타임)는 사용하지 않는 메모리를 즉시 OS에 반환하지 않습니다. 이로 인해 ASF 프로세스가 점점 더 많은 메모리를 사용하기만 하고 (거의) 반환하지 않는 것처럼 보일 수 있습니다. 일부 사람들은 이를 이상하게 여기거나 메모리 누수를 의심할 수도 있지만, 이는 모두 정상적인 현상이니 걱정하지 않으셔도 됩니다.

ASF는 매우 잘 최적화되어 있으며, 가용 리소스를 최대한 활용하도록 만들어졌습니다. ASF의 높은 메모리 사용량이 곧 ASF가 그 메모리를 실제로 사용하고 필요로 한다는 의미는 아닙니다. ASF는 매번 OS에 메모리 청크를 요청하지 않아도 성능을 크게 향상시킬 수 있기 때문에, 할당된 메모리를 향후 작업을 위한 "여유 공간"으로 보유해두는 경우가 많습니다. 런타임은 OS가 실제로 그 메모리를 정말 필요로 할 때 자동으로 사용하지 않는 ASF 메모리를 반환합니다. 사용되지 않는 메모리는 낭비되는 메모리입니다. 문제가 발생하는 시점은 ASF가 잠시 후 실행할 함수의 속도를 높이기 위해 일부 여분의 메모리를 확보해두는 때가 아니라, 여러분에게 필요한 메모리가 사용 가능한 메모리보다 많아지는 때입니다. 마찬가지로, htop에서 ASF 프로세스가 메모리를 가장 많이 사용하는 것으로 보이는 때가 아니라, Linux 커널이 OOM(메모리 부족)으로 인해 ASF 프로세스를 강제 종료시키는 때에 문제가 발생합니다.

ASF에서 사용하는 가비지 컬렉션 프로세스는 매우 정교한 메커니즘으로, ASF 자체뿐만 아니라 OS 및 다른 프로세스까지 고려할 만큼 스마트합니다. 여유 메모리가 많을 때, ASF는 성능 향상을 위해 필요한 만큼 메모리를 요청합니다. (서버 GC를 사용하는 경우) 이는 최대 1GB에 달할 수도 있습니다. OS 메모리가 거의 가득 차면, ASF는 상황을 안정시키기 위해 자동으로 일부 메모리를 OS에 반환하며, 이로 인해 전체 ASF 메모리 사용량이 최소 50MB까지 낮아질 수 있습니다. 50MB와 1GB의 차이는 크지만, 작은 512MB VPS와 거대한 32GB 전용 서버의 차이 역시 그만큼 큽니다. ASF가 이 메모리가 유용하게 쓰일 것이라 확신하면서 동시에 다른 어떤 것도 지금 당장 그 메모리를 필요로 하지 않는다면, ASF는 그 메모리를 계속 보유하면서 과거에 실행된 루틴을 기반으로 자동으로 스스로를 최적화하는 것을 선호합니다. ASF에서 사용되는 GC는 자체 튜닝(self-tuning) 방식이며, 프로세스가 오래 실행될수록 더 나은 결과를 얻습니다.

이것이 바로 ASF 프로세스의 메모리 사용량이 설정마다 다르게 나타나는 이유이기도 합니다. ASF는 Windows XP 시절처럼 고정된 방식이 아니라 가능한 한 효율적인 방식으로 가용 리소스를 사용하려 하기 때문입니다. ASF가 실제로 사용 중인 (실질적인) 메모리 사용량은 stats 명령어 로 확인할 수 있으며, 봇이 몇 개 안 될 때는 보통 약 4MB 정도이고, IPC 등 고급 기능을 사용하는 경우 최대 30MB까지 늘어날 수 있습니다. stats 명령어로 반환되는 메모리에는 가비지 컬렉터가 아직 회수하지 않은 여유 메모리도 포함된다는 점을 유의하세요. 그 외 나머지는 공유 런타임 메모리(약 40~50MB)와 실행을 위한 여유 공간(사용량은 상황에 따라 다름)입니다. 이것이 바로 동일한 ASF가 저메모리 VPS 환경에서는 최소 50MB만 사용하면서도, 데스크톱에서는 최대 1GB까지 사용할 수 있는 이유입니다. ASF는 사용자의 환경에 능동적으로 적응하며, OS에 부담을 주지 않으면서도 사용하지 않는 여유 메모리가 많을 때는 자체 성능을 제한하지 않는 최적의 균형점을 찾으려 합니다.

---

물론, 사용자가 기대하는 메모리 사용 방향으로 ASF를 유도할 수 있는 다양한 방법이 있습니다. 일반적으로 굳이 그럴 필요가 없다면, 가비지 컬렉터가 알아서 최선이라고 판단하는 대로 조용히 동작하게 두는 것이 가장 좋습니다. 하지만 항상 그럴 수 있는 것은 아닙니다. 예를 들어, Linux 서버가 여러 웹사이트, MySQL 데이터베이스, PHP 워커까지 함께 호스팅하고 있다면, OOM에 근접했을 때 ASF가 스스로 메모리를 줄이기를 기다릴 여유가 없을 수 있습니다. 대개 그 시점에는 이미 늦었고, 성능 저하가 더 먼저 찾아오기 때문입니다. 이런 경우가 바로 추가적인 튜닝에 관심을 가지고, 이 페이지를 읽어야 할 때입니다.

아래 제안들은 난이도에 따라 몇 가지 카테고리로 나뉘어 있습니다.

---

ASF 설정 (쉬움)

아래 방법들은 성능에 부정적인 영향을 주지 않으며, 모든 설정에 안전하게 적용할 수 있습니다.

• 가능하다면 ASF의 일반(generic) 버전 을 실행하세요. 제네릭 버전 ASF는 내부에 런타임을 포함하지 않고, 단일 파일 형태도 아니며, 실행 시 자체 압축 해제 과정도 필요 없기 때문에 더 작고 메모리 사용량이 적습니다. OS별 패키지는 사용하기 편리하지만, ASF 실행에 필요한 모든 것이 함께 번들로 포함되어 있습니다. 이는 사용자가 직접 관리할 수 있는 부분이므로, 대신 제네릭 ASF 버전을 사용하는 것이 좋습니다.
• ASF 인스턴스는 절대 2개 이상 동시에 실행하지 마세요. ASF는 원래 무제한의 봇을 한꺼번에 처리하도록 설계되었으므로, 각 ASF 인스턴스를 서로 다른 인터페이스/IP 주소에 바인딩하는 것이 아니라면, (필요하다면 여러 봇을 포함한) 정확히 하나의 ASF 프로세스만 실행해야 합니다.
• 봇의 FarmingPreferences에서 ShutdownOnFarmingFinished를 활용하세요. 활성 상태인 봇은 비활성화된 봇보다 더 많은 리소스를 사용합니다. 이는 큰 절약은 아닙니다. 봇의 상태는 여전히 유지되어야 하기 때문이지만, TCP 소켓 등 네트워킹과 관련된 리소스는 어느 정도 절약할 수 있습니다. 필요하면 언제든 다른 봇을 다시 활성화할 수 있습니다.
• 봇의 수를 적게 유지하세요. Enabled되지 않은 봇 인스턴스는 ASF가 굳이 시작시키지 않으므로 리소스를 덜 사용합니다. 또한 ASF는 각 설정 파일마다 봇을 생성해야 한다는 점을 유의하세요. 따라서 특정 봇을 시작할 필요가 없고 추가 메모리를 절약하고 싶다면, 해당 Bot.json을 예를 들어 Bot.json.bak과 같이 임시로 이름을 바꿔서 ASF가 비활성화된 봇 인스턴스의 상태를 생성하지 않도록 할 수 있습니다. 이렇게 하면 이름을 다시 되돌리기 전까지는 해당 봇을 시작할 수 없게 되지만, ASF도 이 봇의 상태를 메모리에 유지하지 않아 다른 작업을 위한 여유 공간을 확보할 수 있습니다(다만 매우 작은 절약이므로, 99.9%의 경우에는 굳이 이렇게 하지 않고 그냥 봇의 Enabled를 false로 두는 것으로 충분합니다).
• 설정 파일을 세밀하게 조정하세요. 특히 전역 ASF 설정에는 조정할 수 있는 변수가 많습니다. 예를 들어 LoginLimiterDelay를 늘리면 봇이 더 느리게 시작되며, 이는 이미 시작된 인스턴스가 그동안 배지를 가져올 수 있게 해줍니다. 반대로 봇을 더 빠르게 시작하면 배지 파싱과 같은 주요 작업을 동시에 수행하는 봇이 많아져 더 많은 리소스를 사용하게 됩니다. 동시에 처리해야 할 작업이 적을수록 메모리 사용량도 줄어듭니다.

이는 메모리 사용량을 다룰 때 유념할 수 있는 몇 가지 사항입니다. 다만 이러한 사항들은 메모리 사용량에 있어 "결정적인" 영향을 주지는 않습니다. 메모리 사용량은 대부분 ASF가 처리해야 하는 작업 자체에서 비롯되며, 카드 파밍을 위한 내부 구조에서 비롯되는 것이 아니기 때문입니다.

리소스를 가장 많이 소모하는 기능은 다음과 같습니다:

• 배지 페이지 파싱
• 인벤토리 파싱

즉, ASF가 배지 페이지를 읽거나 인벤토리를 다룰 때(예: 거래 전송이나 STM 작업 시) 메모리 사용량이 가장 크게 치솟습니다. 이는 ASF가 매우 방대한 양의 데이터를 처리해야 하기 때문입니다. 여러분이 즐겨 쓰는 브라우저로 그 두 페이지를 열더라도 메모리 사용량이 그보다 낮아지지는 않을 것입니다. 안타깝지만 원래 그런 구조입니다 - 배지 페이지 수를 줄이고 인벤토리 아이템 수를 적게 유지하면 분명 도움이 됩니다.

---

런타임 튜닝 (고급)

아래 방법들은 성능 저하를 동반하므로 주의해서 사용해야 합니다.

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

.NET 런타임은 다양한 방식으로 가비지 컬렉터를 조정 할 수 있게 해주어, 필요에 따라 GC 프로세스를 세밀하게 튜닝할 수 있습니다. 아래에는 저희가 특히 중요하다고 생각하는 속성들을 문서화해두었습니다.

GCHeapHardLimitPercent

전체 물리 메모리 대비 허용되는 GC 힙 사용량 비율을 지정합니다.

ASF 프로세스에 대한 "하드" 메모리 제한으로, 이 설정은 GC가 전체 메모리가 아닌 일부만 사용하도록 조정합니다. 서버 환경 등에서 서버 메모리의 일정 비율만 ASF에 할당하고 그 이상은 사용하지 못하게 하고 싶을 때 특히 유용할 수 있습니다. ASF가 사용할 메모리를 제한한다고 해서 필요한 메모리 할당 자체가 마법처럼 사라지는 것은 아니라는 점에 유의하세요. 따라서 이 값을 너무 낮게 설정하면 메모리 부족(out of memory) 상황이 발생해 ASF 프로세스가 강제 종료될 수 있습니다.

반대로 이 값을 충분히 높게 설정하면, ASF가 현실적으로 감당할 수 있는 메모리 이상을 절대 사용하지 않도록 보장하면서도, 부하가 높은 상황에서도 시스템에 어느 정도 여유를 남겨줄 수 있는 좋은 방법입니다.

GCConserveMemory

가비지 컬렉션 빈도를 높이고 일시 정지 시간이 길어질 수 있는 대가로 메모리를 절약하도록 가비지 컬렉터를 구성합니다.

0에서 9 사이의 값을 사용할 수 있습니다. 값이 클수록 GC는 성능보다 메모리를 더 우선적으로 최적화합니다.

GCHighMemPercent

GC가 더 적극적으로 동작하기 시작하는 메모리 사용량 기준을 지정합니다.

이 설정은 전체 OS 메모리 사용량의 임계값을 구성하며, 이 임계값을 넘으면 GC가 더 적극적으로 동작하여 더 집중적인 GC 프로세스를 실행함으로써 OS의 메모리 부담을 낮추고 결과적으로 더 많은 여유 메모리를 OS에 반환하도록 돕습니다. 이 속성은 전체 OS 성능에 있어 "위험 수준"이라고 판단되는 최대 메모리 사용량(백분율)으로 설정하는 것이 좋습니다. 기본값은 90%이며, 보통 80~97% 범위로 유지하는 것이 좋습니다. 값이 너무 낮으면 별다른 이유 없이 GC가 불필요하게 공격적으로 동작해 성능이 저하될 수 있고, 값이 너무 높으면 ASF가 메모리를 반환해 도움을 줄 수 있는 상황임에도 불필요하게 OS에 부담을 줄 수 있습니다.

GCLatencyLevel

최적화하고자 하는 GC 지연 수준(latency level)을 지정합니다.

이는 문서화되지 않은 속성이지만, GC 세대의 크기를 제한함으로써 GC가 더 자주, 더 적극적으로 정리 작업을 수행하도록 만들어 ASF에서 매우 효과적으로 작동하는 것으로 확인되었습니다. 기본값(균형 잡힌) 지연 수준은 1이지만, 메모리 사용량 최적화를 위해서는 0을 사용할 수 있습니다.

gcTrimCommitOnLowMemory

이 값을 설정하면, 임시(ephemeral) 세그먼트에 대해 커밋된 공간을 더 적극적으로 정리(trim)합니다. 이는 커밋된 메모리를 최대한 적게 유지하고자 하는 다수의 서버 프로세스 인스턴스를 실행할 때 사용됩니다.

이 설정은 개선 효과가 크지는 않지만, 특히 스레드풀 작업을 많이 사용하는 ASF의 경우 시스템 메모리가 부족할 때 GC를 더 적극적으로 동작하게 만들 수 있습니다.

---

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

# Don't forget to tune those if you're planning to make use of them
export DOTNET_GCHeapHardLimitPercent=0x4B # 75% as hex
export DOTNET_GCHighMemPercent=0x50 # 80% as hex

export DOTNET_GCConserveMemory=9
export DOTNET_GCLatencyLevel=0
export DOTNET_gcTrimCommitOnLowMemory=1

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

또는 Windows(파워셸)에서는:

# Don't forget to tune those if you're planning to make use of them
$Env:DOTNET_GCHeapHardLimitPercent=0x4B # 75% as hex
$Env:DOTNET_GCHighMemPercent=0x50 # 80% as hex

$Env:DOTNET_GCConserveMemory=9
$Env:DOTNET_GCLatencyLevel=0
$Env:DOTNET_gcTrimCommitOnLowMemory=1

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

특히 GCLatencyLevel은 매우 유용한데, 저희가 검증한 바에 따르면 이 런타임 설정은 서버 GC를 사용하는 경우에도 코드 실행을 메모리 측면에서 실제로 최적화하여 평균 메모리 사용량을 크게 낮춰줍니다. OptimizationMode로 인한 성능 저하 없이 ASF의 메모리 사용량을 크게 줄이고 싶다면 적용할 수 있는 최고의 방법 중 하나입니다.

---

ASF 튜닝 (중급)

아래 방법들은 심각한 성능 저하를 동반하므로 주의해서 사용해야 합니다.

• 최후의 수단으로, 전역 설정 속성 인 OptimizationMode를 통해 ASF를 MinMemoryUsage로 튜닝할 수 있습니다. 이는 메모리 절약 효과는 거의 없으면서 성능은 심각하게 저하되는 설정이므로, 그 목적을 신중히 읽어보시기 바랍니다. 이는 일반적으로 정말 어쩔 수 없을 때 마지막으로 시도해야 할 방법 이며, 런타임 튜닝 을 충분히 거친 후에도 어쩔 수 없이 이 방법을 써야 하는 상황이어야 합니다. 설정상 반드시 필요한 경우가 아니라면, 메모리가 제한된 환경에서도 MinMemoryUsage 사용은 권장하지 않습니다.

---

추천 최적화

• 먼저 일반(generic) ASF 버전 과 같은 간단한 ASF 설정 팁부터 시작해서, 혹시 모든 봇에 대해 프로세스를 여러 번 실행하거나, 자동 시작이 필요한 봇이 한두 개뿐인데도 전부 활성 상태로 두는 등 ASF를 잘못된 방식으로 사용하고 있지는 않은지 확인하세요.
• 그래도 부족하다면, 위에서 설명한 적절한 DOTNET_ 환경 변수를 설정해서 모든 구성 속성을 활성화하세요. 특히 GCLatencyLevel은 성능 손실은 크지 않으면서도 상당한 런타임 개선 효과를 제공합니다.
• 그래도 도움이 되지 않는다면, 최후의 수단으로 MinMemoryUsage OptimizationMode를 활성화하세요. 이 설정은 ASF가 거의 모든 작업을 동기적으로 실행하도록 강제하여, 동작 속도는 훨씬 느려지지만 병렬 실행 시 스레드 풀에 의존하지 않게 되어 부하를 분산시키는 데는 도움이 됩니다.

이 상태에서는 메모리를 더 이상 물리적으로 줄일 수 없으며, 여러분의 ASF는 이미 코드적으로도 런타임적으로도 가능한 모든 방법을 소진하여 성능이 크게 저하된 상태입니다. ASF가 사용할 수 있도록 여유 메모리를 조금이라도 추가하는 것을 고려해보세요. 128MB만 늘려도 큰 차이를 만들 수 있습니다.