데이터베이스 서버에 더 빠른 메모리 또는 더 많은 용량이 필요합니까?

불편한 대답: 일반적으로 용량이 우선이다

용량이 우선입니다.

저는 데이터베이스 서버 RAM을 구입하기 전에 중요한 한 가지 질문을 하지 않았기 때문에 데이터베이스 서버가 여전히 임시 유출, 버퍼 이탈, 페이지 읽기 및 끔찍한 대기 통계가 발생하는 동안 더 높은 클럭의 DIMM에 실제 비용을 지출하는 팀을 보았습니다: 활성 작업 세트가 실제로 부하가 걸린 상태에서 메모리에 맞는가??

그렇다면 더 빠른 RAM은 무엇을 구할 수 있을까요?

간단히 대답하자면, 대부분의 데이터베이스 서버에는 다음이 필요합니다. 더 많은 가용 메모리 용량 더 빠른 메모리가 필요하기 전에. 항상 그런 것은 아닙니다. 하지만 저는 “더 빠른 RAM'을 첫 번째 대화가 아닌 두 번째 대화로 취급할 만큼 자주 사용합니다.

데이터베이스는 게임용 PC가 아닙니다. 벤치마크 스크린샷을 찍는 것이 목적이 아닙니다. 중요한 것은 핫 테이블, 인덱스, 실행 계획, 조인, 정렬, 버퍼/캐시 레이어를 가능한 한 느린 스토리지 경로에서 멀리 떨어뜨리는 것입니다. 서버가 페이징을 시작하거나, 디스크로 유출하거나, 유용한 페이지를 메모리에서 지속적으로 제거하기 시작하면 DIMM 레이블에 몇 백 MT/s가 추가된다고 해서 설계가 저장되지는 않습니다.

오래되었지만 여전히 유용한 Google의 현장 연구입니다, 야생에서의 DRAM 오류, 는 2.5년 이상의 프로덕션 서버 데이터를 분석한 결과, 연간 8% 이상의 DIMM이 오류의 영향을 받는 것으로 나타났습니다. 이는 연구실에서나 볼 수 있는 귀여운 각주가 아닙니다. 그렇기 때문에 마케팅 등급의 속도 주장에 앞서 ECC, 검증, 조달 규율에 관심을 기울입니다.

그리고 가동 중단 비용도 있습니다. 업타임 인텔리전스에서는 2024년 연간 가동 중단 분석 에 따르면 응답자의 541명 중 3분의 1이 가장 최근에 겪은 중대, 심각 또는 심각한 장애로 인해 100만 달러 이상의 비용이 발생했다고 답했으며, 161명 중 3분의 1은 100만 달러가 넘는다고 답했습니다. 메모리 결정이 저렴한 액세서리처럼 취급되어야 하는 이유를 다시 한 번 말씀해 주시겠어요?

데이터베이스 서버 RAM은 스티커 문제가 아닌 작업 세트 문제입니다.

“데이터베이스 서버에 필요한 RAM 용량”이라는 문구는 간단하게 들립니다. 그렇지 않습니다.

먼저 핫 테이블, 핫 인덱스, 임시 구조, 연결 오버헤드, 버퍼/캐시 크기 조정, 쿼리 메모리 할당량, 복제 또는 백업 영향, 모니터링 에이전트, OS 예약, 최대 동시성 등 활성 작업 세트부터 살펴봅니다. 그런 다음 플랫폼을 살펴봅니다: CPU 세대, 지원되는 DDR 세대, DIMM 슬롯, 채널 수, RDIMM 또는 LRDIMM 지원, 슬롯당 최대 밀도, 운영 체제 및 데이터베이스 버전에서 구매하려는 메모리를 사용할 수 있는지 여부 등을 살펴봅니다.

구매자가 실수하기 쉬운 부분입니다.

SQL Server가 좋은 예입니다. Microsoft의 SQL Server 2022 버전 제한 사항 를 보면 스탠다드 에디션은 인스턴스당 데이터베이스 엔진 버퍼 풀의 최대 메모리 제한이 128GB인 반면, 엔터프라이즈는 운영 체제 최대치를 사용할 수 있음을 알 수 있습니다. 따라서 SQL Server Standard를 실행 중이고 512GB RAM을 구매하면 한 인스턴스의 버퍼 풀이 마술처럼 채워질 것이라고 생각한다면 나쁜 소식이 있습니다.

MySQL도 비슷한 이야기를 다른 각도에서 들려줍니다. 오라클의 MySQL 8.4 InnoDB 버퍼 풀 문서 에 따르면 버퍼 풀은 테이블과 인덱스 데이터를 메인 메모리에 캐시하며, 전용 서버에서는 최대 80%의 물리적 메모리가 할당되는 경우가 많습니다. 이는 용량에 관한 이야기입니다. RGB 히트 스프레더가 아닙니다. 허영심이 아닌 속도입니다.

PostgreSQL은 또 다른 주름을 추가합니다. 그것의 공유_버퍼에 대한 현재 문서 에 따르면 1GB 이상의 RAM을 갖춘 전용 데이터베이스 서버의 합리적인 시작 값은 25%의 시스템 메모리이며, PostgreSQL도 운영 체제 캐시에 의존하므로 40% 이상의 값은 많은 워크로드에서 성능이 향상되지 않을 수 있다고 경고하고 있습니다. 쉽게 말해, 데이터베이스 서버 메모리가 많으면 도움이 되지만 무분별한 할당은 여전히 문제가 될 수 있습니다.

더 빠른 RAM이 중요하지만, 데이터베이스 고갈을 막아야만 가능합니다.

나중에는 속도가 중요합니다.

페이징을 피하고, 물리적 읽기를 줄이고, 유용한 인덱스 집합을 유지하고, 정렬/해시 작업을 제어할 수 있는 충분한 RAM이 이미 있는 서버는 특히 CPU 코어가 스토리지가 아닌 메모리 대역폭에서 대기하는 경우 더 빠른 메모리의 이점을 누릴 수 있습니다. 하지만 이는 “데이터베이스가 느리게 느껴진다”는 진단과는 다른 문제입니다.”

더 나은 질문을 하세요.

워크로드가 무작위 읽기와 긴박한 지연 시간 목표를 가진 OLTP인가요? 광범위한 팩트 테이블을 스캔하는 분석 작업인가요? 컬럼스토어가 있는 SQL Server인가요? 해시 조인이 임시 파일로 유출되는 PostgreSQL인가요? 보고 기간 동안 버퍼 풀 적중률이 붕괴되는 MySQL/InnoDB인가요? 동일한 NUMA 노드를 놓고 경쟁하는 여러 데이터베이스 VM을 호스팅하는 가상화인가요?

답변에 따라 구매가 달라집니다.

레노버의 작업 인텔 제온 6 2소켓 서버를 위한 균형 잡힌 메모리 구성 는 메모리 레이아웃이 장식용이 아니라는 점을 상기시켜주는 유용한 자료로, 언밸런스드 메모리는 프로세서당 8개의 동일한 DIMM을 사용하는 밸런스드 구성의 총 메모리 대역폭을 13%까지 낮출 수 있다고 명시하고 있습니다. Dell의 Xeon 6 DDR5 메모에 따르면 1DPC 구성은 최대 6400MT/s를 지원할 수 있는 반면, 해당 플랫폼 제품군에서 2DPC는 일반적으로 5200MT/s로 실행됩니다.

따라서 더 빠른 메모리가 중요할 수 있습니다.

하지만 더 빠른 DIMM을 구입한 다음 채널을 잘못 채우는 것은 비싼 타이어를 사서 구부러진 차축에 볼트로 고정하는 것과 같습니다. 영수증은 인상적으로 보입니다. 기계는 그렇지 않습니다.

데이터베이스 서버 워크로드를 위한 RAM 속도와 용량 비교

의사 결정 영역	일반적으로 RAM 용량이 클수록 유리한 경우	더 빠른 RAM이 일반적으로 승리하는 경우	먼저 확인해야 할 사항
OLTP 데이터베이스	핫 인덱스 및 페이지가 메모리에 맞지 않습니다.	버퍼 적중률이 이미 높고 CPU 대기 시간이 메모리 대역폭을 가리키고 있습니다.	버퍼 캐시 적중률, 페이지 읽기/초, 대기 통계
분석 / 보고	쿼리가 임시 저장소로 유출되거나 데이터를 반복적으로 스캔하는 경우	작업 세트 맞춤 및 스캔은 대역폭에 제한이 있습니다.	온도 유출, 스캔 볼륨, NUMA 로컬리티
SQL Server	버퍼 풀, 계획 캐시, 쿼리 보조금 또는 열 저장소 캐시가 제한됩니다.	에디션 및 워크로드는 대역폭을 사용할 수 있습니다.	SQL Server 버전 제한, 최대 서버 메모리, 대기 통계
MySQL InnoDB	버퍼 풀 누락으로 인해 반복되는 디스크 읽기가 발생합니다.	버퍼 풀의 크기가 올바르게 설정되고 스토리지가 더 이상 병목 현상이 발생하지 않습니다.	innodb_buffer_pool_size, 디스크 읽기, 더티 페이지 압력
PostgreSQL	공유_버퍼, OS 캐시, 작업_메모 및 동시 세션의 크기가 부족합니다.	캐시는 안정적이며 쿼리는 CPU/메모리 처리량이 제한됩니다.	공유_버퍼, 유효_캐시 크기, 임시 파일 생성
가상화된 데이터베이스 호스트	여러 데이터베이스 VM이 호스트 메모리를 오버커밋하는 경우	호스트의 메모리가 충분하고 채널 인구가 균형 잡힌 경우	NUMA, 풍선, 스왑, VM당 예약
레거시 DDR4 제품군	기존 플랫폼은 여전히 수명이 있고 밀도가 필요합니다.	플랫폼은 최신 속도를 사용할 수 없습니다.	서버 모델, CPU 생성, RDIMM/LRDIMM 규칙
새로운 DDR5 빌드	용량 계획으로 VM 밀도 또는 분석 공간 확보	플랫폼은 선택한 DPC 레이아웃에서 높은 MT/s를 지원합니다.	1DPC 대 2DPC, 채널 밸런스, 승인된 DIMM 목록

2026년에도 여전히 발생하는 데이터베이스 메모리 구매 실수

모호한 기억을 인용하는 것은 싫어합니다.

데이터베이스 서버 메모리를 구매할 때 “64GB DDR4 ECC 서버 RAM”이라는 견적만으로는 충분하지 않습니다. 제조업체 부품 번호, 등급, x4 또는 x8 구성, 속도 빈, RDIMM 또는 LRDIMM 등급, 테스트 조건, 보증 조건, 플랫폼이 일치하는지 확인해야 합니다. 그렇지 않으면 조달을 고려하지 않습니다. 향후 책임 회의를 검토하고 있습니다.

DDR4 에스테이트의 경우 구매자를 DDR4 서버 메모리 카테고리에만 서버 세대와 현재 DIMM 레이블을 확인해야 합니다. 새로운 밀도 빌드의 경우 DDR5 서버 메모리 경로를 사용하는 것이 합리적이지만 CPU, 마더보드, BIOS 및 DIMM 모집단 규칙이 목표 속도와 용량을 지원하는 경우에만 가능합니다.

하지만 카테고리 페이지에서 멈추지 마세요.

구매하기 전에 적절한 서버 메모리 호환성 감사 를 클릭하고 의도한 모듈과 실제 플랫폼을 비교하세요. ServerDimm의 광범위한 가이드 서버 메모리 구매 는 기가바이트당 가격 경쟁이 아닌 호환성, 안정성, 공급, 워크로드 적합성으로 메모리의 프레임을 구성하기 때문에 유용합니다.

이것이 바로 올바른 멘탈 모델입니다.

실제로 신뢰하는 사이징 방법

다음은 데이터베이스 서버 RAM을 승인하기 전에 사용하는 필드 프로세스입니다.

먼저 전체 비즈니스 주기에 대한 작업 부하를 측정합니다. 조용한 10분이 아니라. 가상의 데모가 아닙니다. 배치 작업, 보고 스파이크, 백업, 인덱스 유지 관리, ETL, 복제, 사용자 동시성 등이 포함된 실제 창에서 측정해야 합니다.

둘째, 문제를 분류하세요. 물리적 읽기, 페이지 기대 수명 붕괴, SQL Server RESOURCE_SEMAPHORE 대기, PostgreSQL 임시 파일, MySQL 버퍼 풀 누락, Linux 스왑 활동, NUMA 불균형 또는 스토리지 포화 등이 나타나고 있나요? 각기 다른 증상은 다른 구매를 가리킵니다.

셋째, 작업 세트의 크기와 여유 공간입니다. 일반적으로 핫 데이터와 인덱스, 데이터베이스 엔진 캐시, 쿼리 메모리, 연결, OS 캐시, 작업 급증에 대비해 충분한 메모리가 필요합니다. 전용 데이터베이스 서버의 경우, OS를 헐떡거리게 두는 것은 아마추어 작업입니다.

넷째, DIMM 아키텍처를 검증합니다. ECC RDIMM과 LRDIMM은 일반적인 대체품이 아닙니다. DDR4와 DDR5는 서로 호환되지 않습니다. 2Rx4와 2Rx8은 플랫폼 지원 매트릭스에서 다르게 작동할 수 있습니다. 그리고 모두가 용량에 대해 이야기할 때 순위와 채널 균형은 여전히 중요합니다.

다섯째, 테스트 및 보증의 명확성을 요구합니다. 생산 구매의 경우, 저는 공급업체의 품질 테스트 및 보증 지원 언어를 사용했습니다. 프로젝트가 큰 경우, 저는 또한 문의 및 견적 요청 경로에 정확한 서버 모델, CPU 세대, 현재 DIMM 부품 번호, 목표 용량, 허용되는 브랜드 및 배포 날짜를 입력하세요.

지루하면 돈이 절약됩니다.

더 많은 용량이 정답인 경우

활성 워크로드가 메모리에 충분히 맞지 않을 때는 일반적으로 데이터베이스 서버 RAM을 늘리는 것이 정답입니다.

여기에는 SQL Server 버퍼 풀이 지속적으로 변경되는 경우, MySQL InnoDB가 핫 테이블 및 인덱스 페이지를 유지할 수 없는 경우, PostgreSQL이 정렬 및 조인을 위한 임시 파일을 생성하는 경우, 가상화된 데이터베이스 호스트가 압박을 받아 메모리를 늘리기 시작하는 경우 등이 포함됩니다. 데이터베이스가 스토리지를 RAM의 확장으로 취급하게 되면 성능이 비싸고 불안정해지며 워크로드에 민감하게 반응하게 됩니다.

어려운 진실: 많은 “느린 데이터베이스” 불만은 CPU 문제가 아닙니다. 이는 CPU의 탈을 쓴 메모리 및 I/O 설계 문제입니다.

용량은 운영 안정성에도 도움이 됩니다. 백업, 재색인, ETL, 일괄 보고, 장애 조치 이벤트는 워크로드가 조용해질 때까지 정중하게 기다리지 않습니다. 시스템의 크기가 평균 부하에 맞춰져 있으면 실제 부하가 발생하면 당황하게 됩니다.

더 빠른 메모리가 정답일 때

용량이 이미 충분하고 병목 현상이 메모리 대역폭이나 지연 시간으로 이동한 경우 더 빠른 RAM이 정답이 됩니다.

이는 코어 수가 많은 시스템, 광범위한 분석 스캔, 인메모리 OLTP, 과중한 컬럼스토어 워크로드, 메모리에 유지되는 대규모 PostgreSQL 해시 작업 또는 데이터베이스가 여러 코어에 분산되어 있는 고밀도 가상화 호스트에서 발생할 수 있습니다. 하지만 먼저 증거가 필요합니다: CPU 카운터, 메모리 대역폭 원격 측정, NUMA 로컬리티 검사, 대기 분석, 테스트 전/후 분석 등입니다.

브로셔에 DDR5-5600 또는 DDR5-6400이라고 적혀 있기 때문에 속도를 구매하지 않습니다.

저는 플랫폼이 의도한 DIMM 수로 실제로 실행할 수 있고 워크로드가 이를 사용할 수 있음을 증명할 때 속도를 구매합니다. 그렇지 않으면 모든 슬롯을 채우고 다운클럭을 수용하는 것보다 더 큰 DIMM을 줄이거나, 균형 잡힌 1DPC 레이아웃을 사용하거나, 플랫폼을 새로 구입하는 것이 더 나을 수 있습니다.

데이터베이스 서버 성능 튜닝에 대한 실제적인 결론

데이터베이스 서버 성능을 조정하는 경우, 처음부터 두 가지 선택 사항이 동등한 것처럼 “더 빠른 메모리 또는 더 많은 용량”을 요구하지 마세요.

대신 이렇게 물어보세요: 데이터베이스에 메모리가 부족하거나 메모리 대역폭이 부족하거나 잘못된 구성에 갇혀 있나요?

대부분의 프로덕션 데이터베이스의 경우, 구성을 수정하고, 호환 가능한 ECC 용량을 충분히 추가하고, 메모리 채널의 균형을 맞춘 다음 속도를 고려하는 순서는 간단합니다. 공급업체 목록에서 가장 빠른 모듈을 찾기 전에 SQL Server 메모리 요구 사항, MySQL 버퍼 풀 크기 조정, PostgreSQL shared_buffers 및 OS 캐시 동작, NUMA 레이아웃 및 DIMM 인구 규칙을 모두 고려해야 합니다.

덜 흥미진진하게 들릴 수 있다는 것을 압니다.

좋아요. 데이터베이스는 지루한 훈련에 대한 보상입니다.

자주 묻는 질문

데이터베이스 서버에 더 빠른 메모리나 더 많은 용량이 필요하신가요?

데이터베이스 서버는 일반적으로 활성 데이터 집합, 인덱스, 정렬 작업, 조인, 버퍼 풀 또는 동시 세션이 사용 가능한 메모리를 초과하여 워크로드 피크 중에 디스크 읽기, 페이징, 일시적인 유출 또는 불안정한 실행 계획을 강요하는 경우 더 빠른 메모리보다 더 많은 RAM 용량을 필요로 합니다. 더 빠른 메모리는 나중에 데이터베이스에 더 이상 메모리가 부족하지 않게 되면 문제가 됩니다.

실제로는 대부분의 OLTP 시스템, 혼합 워크로드 및 가상화된 데이터베이스 호스트에 대해 용량을 먼저 구매합니다. 워크로드가 이미 메모리에 적합하고 메모리 대역폭이나 지연 시간에 의해 제한된다는 것을 증명한 후에야 더 빠른 RAM의 우선순위를 정합니다.

데이터베이스 서버에는 얼마나 많은 RAM이 필요하나요?

데이터베이스 서버에는 페이징이나 반복적인 디스크 액세스 없이 핫 워킹 세트, 데이터베이스 캐시, 쿼리 실행 메모리, 연결 오버헤드, 운영 체제 예비 공간, 모니터링 도구 및 최대 워크로드 헤드룸을 저장할 수 있는 충분한 RAM이 필요합니다. 정확한 수치는 데이터베이스 크기, 워크로드 패턴, 동시성, 엔진 설정 및 플랫폼 제한에 따라 달라집니다.

소규모 SQL Server, MySQL 또는 PostgreSQL 워크로드의 경우 64GB면 충분할 수 있습니다. 더 무거운 프로덕션 시스템의 경우 256GB, 512GB 또는 그 이상이 합리적일 수 있습니다. 데이터베이스 파일 크기만 보고 구매하는 것은 잘못된 방법입니다.

더 빠른 RAM이 SQL Server에 가치가 있을까요?

인스턴스에 사용 가능한 메모리가 충분하고, 에디션이 구성된 용량을 사용할 수 있으며, 대기 통계 및 성능 카운터에 메모리 처리량 압박이 표시되고, 서버 플랫폼이 계획된 채널 모집단에서 목표 DIMM 속도를 지원하는 경우에만 SQL Server에 더 빠른 RAM을 사용할 가치가 있습니다. 그렇지 않으면 일반적으로 용량, 구성 및 스토리지 동작이 더 중요합니다.

저는 속도에 초점을 맞춘 메모리 구매를 승인하기 전에 SQL Server 버전 제한, 최대 서버 메모리, 버퍼 풀 동작, 페이지올라치 대기, RESOURCE_SEMAPHORE 대기, 컬럼스토어 사용량 및 NUMA 레이아웃을 확인합니다.

데이터베이스 서버에 가장 적합한 메모리는 무엇인가요?

데이터베이스 서버에 가장 적합한 메모리는 호환 가능한 ECC 서버 RAM(일반적으로 플랫폼에 따라 RDIMM 또는 LRDIMM)으로, 워크로드의 활성 데이터 세트에 맞게 크기가 조정되고 서버 공급업체가 지원하는 균형 잡힌 채널 레이아웃에 설치되어 있습니다. 가장 좋은 모듈은 단순히 가장 빠르거나 큰 모듈이 아니라 서버가 안정적으로 검증하고 사용할 수 있는 모듈입니다.

구형 플랫폼의 경우, 이는 32GB 또는 64GB 밀도의 DDR4 ECC RDIMM을 의미할 수 있습니다. 최신 플랫폼의 경우 CPU 세대 및 슬롯 규칙에 따라 64GB, 96GB 또는 128GB 모듈의 DDR5 RDIMM을 의미할 수 있습니다.

RAM이 너무 많으면 데이터베이스 성능이 저하될 수 있나요?

너무 많은 RAM은 잘못 구성되거나, 운영 체제 여유 공간 없이 할당되거나, 과도한 연결 메모리와 결합되거나, 불균형한 채널 레이아웃에 설치되거나, 쿼리 설계, 인덱싱, 임시 저장소 및 데이터베이스 엔진 제한을 무시하는 데 사용될 경우 데이터베이스 성능을 저하시킬 수 있습니다. 더 많은 용량은 플랫폼과 소프트웨어가 깔끔하게 사용할 수 있을 때만 유용합니다.

구매자가 잘못된 문제를 해결했기 때문에 크기가 큰 시스템의 성능이 저하되는 것을 본 적이 있습니다. 메모리는 누락된 인덱스, 잘못된 조인, 과부하된 임시 공간 또는 에디션 상한을 수정하지 못합니다.

최종 생각: 증거가 있는 용량 구매, 증거가 있는 속도 구매

소비자 업그레이드처럼 데이터베이스 서버 RAM을 구매하지 마세요.

견적을 요청하기 전에 서버 모델, CPU 세대, 현재 DIMM 부품 번호, 현재 용량, 목표 용량, 데이터베이스 엔진, 버전, 워크로드 유형, 최대 동시성, 문제 증상, 선호하는 모듈 클래스, 예상 보증 기간, 배포 기간 등 간단한 기술 개요를 작성하세요.

그런 다음 해당 요약서를 사용하여 호환 가능한 ECC 메모리를 소싱하고, DDR4 또는 DDR5가 올바른 경로인지 확인하고, 구매 주문서가 발송되기 전에 테스트 및 교체 조건을 요청하세요.

다음 단계는 간단합니다. 워크로드를 감사하고, 설치된 DIMM 레이블을 읽고, 플랫폼 규칙을 확인하고, 희망이 아닌 증거에 기반하여 메모리를 요청하세요.