정말로 64 GB 메모리가 필요할 때 (그리고 2 GB면 충분할 때)

"서버가 느리니 메모리를 두 배로 늘리자"는 호스팅에서 가장 비싼 반사 작용입니다. 맞을 때도 있습니다. 하지만 머신이 디스크를 기다리고 있거나 CPU가 한계까지 차 있는 경우가 많고, 그러면 새 메모리는 아무 일도 안 한 채 청구서만 두 배가 됩니다.

그래서 누가 64 GB가 필요한지 이야기하기 전에, 실제로 무엇이 부족한지부터 알아봅시다. 작업별 일반적인 메모리 수치만 필요하다면 이전 가이드 VPS에 필요한 메모리 용량에 언어 모델 공식까지 정리돼 있습니다. 이 글은 진단에 관한 이야기입니다. 메모리인지, 디스크인지, CPU인지.

명령 세 가지, 2분

아무 일도 없는 새벽 4시가 아니라, 서버가 느린 바로 그때 느린 서버에서 실행하세요.

free -m
vmstat 1 10
cat /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io

교과서 없이 읽는 법은 이렇습니다.

free -m. free 열은 무시하세요. Linux는 남는 메모리를 일부러 디스크 캐시로 채웁니다. 봐야 할 건 available입니다. 2 GB 머신에서 수백 MB만 남아 있고 swap의 used가 계속 늘어난다면 메모리가 빠듯한 상태입니다.

vmstat 1 10. 네 개의 열이 대부분을 말해 줍니다.

가끔 si/so에 0이 아닌 값이 몇 개 나오는 건 정상입니다. 진짜 신호는 매초 이어지는 꾸준한 swap입니다.

/proc/pressure/*. 셋 중 가장 정직합니다. 각 파일은 작업이 그 자원을 기다리며 멈춰 있던 시간의 비율을 보여 줍니다. memory의 some avg60=25.00은 지난 1분 동안 무언가가 시간의 4분의 1을 메모리를 기다렸다는 뜻입니다. 세 파일 중 숫자가 가장 큰 곳이 병목입니다.

디스크가 원인이라면

wa가 높고, io 압박이 크고, swap은 적습니다. 흔한 원인은 데이터베이스나 로그가 많은 앱이 캐시에 들어가는 양보다 더 많이 읽는 경우입니다.

여기서 반전이 있습니다. 메모리를 늘리면 해결될 수 있습니다. Linux가 디스크를 더 많이 캐시하기 때문입니다. 데이터베이스가 6 GB이고 핫한 부분이 3 GB라면, 메모리를 2 GB에서 8 GB로 늘리는 것만으로 디스크 문제가 사라질 수 있습니다. 하지만 데이터베이스가 300 GB이고 쿼리마다 다른 부분을 건드린다면, 현실적인 메모리 양으로는 캐시할 수 없습니다. 그럴 땐 더 나은 인덱스, 더 작은 쿼리, 다른 데이터 구조가 답입니다. 여기의 모든 요금제는 NVMe를 쓰므로 느린 건 대개 디스크 자체가 아니라 접근 방식입니다.

CPU가 원인이라면

us+sy가 높고, cpu 압박이 있으며, swap은 없고, 디스크 대기도 적습니다. 압축, 빌드, 영상 인코딩, 이미지 처리, 암호 연산 같은 작업이죠. 메모리를 늘려도 전혀 도움이 안 됩니다.

st도 지켜보세요. VPS에서 vCPU는 물리 코어 전체가 아니라 그 시간의 일부입니다. 요금제의 숫자는 순간적인 부하를 위한 상한이고, 오래 지속되는 전체 부하는 머신 위 모두에게 공정하도록 제한될 수 있습니다. 작업이 몇 시간씩 모든 코어를 100%로 써야 한다면 그건 작업 자체의 문제이고, 더 큰 요금제를 산 뒤가 아니라 지금 말씀드리는 편이 낫다고 생각합니다.

정말 메모리가 원인이라면

꾸준한 swap, 높아지는 메모리 압박, dmesg에 찍힌 OOM killer. 이제 질문은 "얼마나"입니다.

2 GB로 충분하고, 몇 년씩 충분한 경우가 많은 것: 봇 하나나 몇 개, 작은 API, VPN, Nginx 뒤의 정적 사이트, cron으로 도는 스크레이퍼 몇 개, 모니터링 에이전트. Micro는 2 vCPU, 2 GB, 25 GB를 NAT로 월 5달러, 전용 IPv4 포함 월 10달러에 제공합니다.

4–8 GB는 편안한 중간: 데이터베이스가 딸린 웹 앱, 작은 검색 인덱스, 헤드리스 브라우저 자동화, 나란히 도는 에이전트 두세 개.

32–64 GB는 메모리에 상주해야 하는 데이터를 위한 것:

• 작업 세트가 수십 GB인 데이터베이스. 캐시가 핫 데이터를 정말로 붙잡고 있도록;
• 디스크로 넘치면 모든 게 느려지는 대용량 인메모리 캐시나 큐;
• 수백만 개의 조각을 대상으로 하는 검색용 벡터 인덱스 (실제 수치는 대규모 셀프 호스팅 RAG에 있습니다);
• 가중치가 메모리에 들어가야 하는 중간 규모 언어 모델의 CPU 추론;
• 통합: 예전에 작은 서버 열 대에 흩어져 있던 서비스 열 개.

Pro-64가 바로 이런 용도입니다. 12 vCPU, 64 GB 메모리, 600 GB NVMe, 전용 IPv4가 월 70달러입니다. 중간 단계로 월 40달러의 Pro-32와 월 55달러의 Pro-48이 있고, 그 위로 월 90달러의 Pro-80이 있습니다. Pro 요금제의 위치별 사용 가능 여부는 주문할 때 표시됩니다.

큰 머신이 맞지 않는 경우

감당할 수 있더라도 64 GB가 틀린 답인 경우가 세 가지 있습니다.

GPU 작업. 이 요금제들에는 GPU가 없습니다. 모델이 학습이나 빠른 추론에 GPU를 필요로 한다면, 메모리가 많은 CPU 머신으로도 돌릴 수는 있지만 느리고, 결국 인내심에 돈을 내게 됩니다.

오래 지속되는 CPU 풀가동 작업. 앞서 말했듯 vCPU는 순간 부하용 용량입니다. 열두 개를 하루 종일 100%로 돌리는 건 VPS가 만들어진 목적이 아닙니다.

그리고 "혹시 모르니까". 세 명령에서 메모리 압박이 보이지 않는다면, 추가된 60 GB는 읽지도 않는 파일의 캐시가 될 뿐입니다. 작게 시작하세요. 같은 네트워크 유형의 더 큰 요금제로 바꾸면 재부팅 한 번으로 vCPU, 메모리, 디스크를 그 자리에서 늘릴 수 있습니다. 자세한 내용은 요금제 변경에 있습니다. 그 자리에서 줄이는 건 불가능하므로, 너무 크게 사면 실제 비용이 생깁니다. 줄이려면 새 서버로 옮겨야 하고, 다운타임 없이 VPS 옮기기는 가능하면 피하고 싶은 일입니다.

여러 업체의 요금제를 비교하고 있다면, VPS 사양 읽는 법이 vCPU, 디스크, 포트 숫자가 실제로 무엇을 약속하는지 설명합니다.