일부 ERP 및 데이터베이스 워크로드가 대용량 메모리에 더 많이 의존하는 이유

더러운 비밀: CPU가 기다리고 있을지도 모릅니다.

빠른 CPU는 거짓말을 합니다.

저는 구매팀이 최신 프로세서, 더 빠른 NVMe 드라이브 및 또 다른 “성능 튜닝'을 승인하는 것을 지켜보면서 데이터베이스 팀이 활성 데이터, 버퍼 풀, 열 저장소 또는 ERP 게시 워크로드를 더 이상 RAM에 상주시킬 수 없다는 사실을 조용히 인정하는 동안 서버가 느리게 컴퓨팅하는 것이 아니라 비용이 많이 드는 대기 중이라는 것을 알았습니다. 왜 여전히 미스터리처럼 취급되고 있을까요?

여기 어려운 진실이 있습니다: 메모리 집약적 워크로드 추측을 처벌합니다. 부드럽게는 아니죠. 결국엔 안 돼 즉시.

ERP 및 데이터베이스 워크로드는 상태 비저장 웹 계층처럼 작동하지 않습니다. 히스토리를 담고 있습니다. 트랜잭션 체인이 있습니다. 인덱스, 잠금, 열 구조, 실행 취소/다시 실행 압력, 캐시된 실행 계획, 보고 쿼리, 배치 작업, 월말 급증 등이 유리벽을 뚫고 들어오는 트럭처럼 섬세하게 전달됩니다.

SAP는 조용한 부분에 대해 다음과 같이 분명히 말합니다. SAP HANA 사이징 가이드: SAP HANA 사이징은 주로 메인 메모리 크기를 중심으로 이루어지며, 압축은 충분히 다양하므로 사이징은 공상 수학이 아닌 SAP 사이징 도구 또는 보고서를 사용해야 합니다.

그렇기 때문에 “이 서버의 RAM 용량이 얼마나 되나요?”라고 먼저 묻지 않습니다.

묻습니다: 비즈니스가 압박을 받을 때 기억에 남아야 할 것은 무엇인가요?

작업 세트가 너무 클 때 용량이 클럭 속도를 능가하는 경우

대부분의 공급업체는 견적서에 속도를 쉽게 인쇄할 수 있다는 이유로 속도를 판매합니다.

용량은 더 추악합니다. 불편한 질문을 강요합니다: 핫 데이터 세트는 얼마나 큰가요? OS 예비 공간, 데이터베이스 메모리 예비 공간, HA 오버헤드, VM 오버헤드 및 성장 후 얼마나 많은 헤드룸이 존재하나요? ECC RDIMM을 사용하고 있는가, 아니면 LRDIMM을 사용하고 있는가? 모든 메모리 채널이 균형을 이루고 있나요? 아마추어처럼 순위를 섞고 있지는 않나요?

하지만 인프라 구매와 관련하여 수년간의 경험을 바탕으로 제 의견을 말씀드리자면, ERP 또는 데이터베이스 워크로드가 페이징, 캐시 이탈 또는 지속적으로 핫 페이지를 제거하는 경우 다른 CPU 계층은 장식용 금속에 불과한 경우가 많습니다.

Microsoft의 SQL Server 설명서에 따르면 페이지 기대 수명이 갑자기 떨어지면 버퍼 풀의 입출입이 심해져 워크로드가 이미 메모리에 있는 데이터를 충분히 활용하지 못할 수 있다고 합니다. 이는 추상적인 이야기가 아닙니다. 바로 데이터베이스에 적신호가 켜진 것입니다. Microsoft SQL Server 메모리 모니터링 를 사용하면 버퍼 풀 메트릭과 캐시 히트 동작을 통해 이를 확인할 수 있습니다.

그래서 누군가 “데이터베이스에 왜 그렇게 많은 RAM이 필요한가요?”라고 묻는다면, 저는 이렇게 솔직하게 대답합니다.

메모리 용량과 메모리 대역폭: 두 가지를 혼동하지 마세요.

메모리 대역폭은 CPU가 대용량의 데이터를 빠르게 스트리밍할 때 중요합니다.

작업 세트가 RAM에 꼭 맞아야 하는 경우 메모리 용량이 중요합니다.

이는 같은 문제가 아닙니다. 더 많은 채널이 있는 DDR5 플랫폼은 데이터를 더 빠르게 이동할 수 있지만 서버에 512GB만 설치되어 있고 실제 작업 세트가 분기 마감 시 900GB에 도달하는 경우 대역폭이 해결해 주지 못합니다. 당신은 부족합니다. 완전히 멈추세요.

워크로드 유형	메모리를 잠식하는 것	용량 신호	나쁜 구매 습관
SAP HANA ERP/S/4HANA	열 테이블, 델타 저장소, 압축 구조, 계산 뷰, 성수기 비즈니스 기간	월말, 연말 또는 마이그레이션 테스트 중 메모리 피크	피크 안전 용량 대신 “평균 사용률” 구매하기
SQL Server OLTP	버퍼 풀, 계획 캐시, 메모리 그랜트, 임시 데이터베이스 압력, 인덱스가 많은 읽기	페이지 기대 수명 감소, 높은 물리적 읽기, 낮은 캐시 안정성	버퍼 풀 압력을 수정하기 전에 CPU 추가하기
오라클 데이터베이스 인메모리	IM 열 저장소, 분석 개체, RAC 중복 선택, 핫 파티션	INMEMORY_SIZE, 객체 모집단, 콜드/핫 세그먼트 동작	열 저장소 크기를 조정하는 대신 인메모리 옵션을 마법처럼 취급하기
혼합 ERP + 보고	트랜잭션 테이블, 보고 추출, 웨어하우스 쿼리, 배치 작업	BI 새로 고침, 급여, MRP, 청구, 마감 중 급증하는 경우	주간 사용자를 위한 크기 조정 및 배치 창 무시하기
가상화된 데이터베이스	게스트 메모리, 하이퍼바이저 예약, NUMA 로컬리티, 풍선 위험	호스트 경합, NUMA 불균형, 예측할 수 없는 지연 시간	스프레드시트가 효율적으로 보였기 때문에 메모리를 과도하게 커밋하는 경우

오라클도 나름의 방식으로 직접적입니다. 오라클의 오라클 데이터베이스 인메모리 문서 는 인메모리 컬럼 저장소가 실시간 분석과 혼합 워크로드를 위한 핵심 기능이며, 쿼리가 이점을 누리려면 IM 컬럼 저장소의 크기를 조정하는 것이 필수 작업이라고 말합니다.

패턴을 주목하세요.

SAP는 메모리 크기를 말합니다. Microsoft는 캐시 이탈이 발생하는 시기를 보여줍니다. 오라클은 컬럼 저장소의 크기를 정해야 한다고 말합니다. 하지만 구매자들은 여전히 600GB 작업 세트를 384GB에 맞출 수 있는 CPU SKU에 집착합니다.

그렇지 않습니다.

ERP 워크로드가 특히 잔인한 이유

ERP 워크로드는 데이터베이스로 위장한 정치 시스템입니다.

재무팀은 빠른 마감을 원합니다. 운영 부서는 MRP를 원합니다. 영업은 약속에 대한 가용성을 원합니다. 규정 준수 부서에서는 보고서를 원합니다. 경영진은 대시보드를 원합니다. 아무도 “데이터베이스 서버'가 실제로 휘발성 메모리에 비즈니스 모델을 담고 있다는 말을 듣고 싶어 하지 않습니다.

ERP 데이터는 관계형, 기록형, 상호 연결되어 있고 타이밍에 민감하기 때문에 ERP 워크로드의 메모리 요구량은 매우 높습니다. 단일 게시 실행 또는 계획 주기가 재고, 가격, 공급업체 데이터, 고객 잔액, 세금 로직, 통화 테이블, 감사 추적 및 워크플로 상태에 영향을 미칠 수 있습니다. 이는 깔끔한 쿼리가 아닙니다. 이는 회사 전체에 대한 논쟁입니다.

SAP HANA는 인메모리 데이터베이스이기 때문에 이 점이 더욱 명확해집니다. AWS는 SAP HANA 마이그레이션의 경우 팀에서 시스템 규모를 결정해야 한다고 조언합니다. 최대 메모리 사용률, 연말 처리나 주요 세일 이벤트와 같이 부하가 많은 기간에 측정할 것을 권장합니다. AWS SAP HANA 사이징 가이드 는 많은 내부 팀이 기피하는 할당된 메모리가 측정된 최대 수요보다 덜 유용하다는 사실을 알려주기 때문에 유용합니다.

여기서 보통 조달 실수가 발생합니다.

그들은 정상적인 화요일에 대한 용량을 구매합니다. 비정상적인 금요일에 비즈니스가 실패합니다.

대규모 메모리 서버 워크로드의 경우, 검증된 플랫폼과 모듈 계획, 즉 검증된 ECC RDIMM, 밀도가 필요한 경우 LRDIMM, 깨끗한 모집단 규칙, 정확한 부품 매칭에서 시작하는 것이 좋습니다. 서버딤의 대량 서버 RAM 공급업체 페이지는 엔터프라이즈 및 데이터 센터 구매자를 위한 DDR3, DDR4, DDR5, ECC, RDIMM 및 LRDIMM 소싱을 중심으로 구축되었기 때문에 이러한 조달 움직임에 적합합니다. 리프레시 프로젝트의 경우, 구형 제온 스케일러블 또는 EPYC 시스템을 다음과 비교하여 매핑합니다. DDR4 서버 메모리 및 최신 고밀도 플랫폼에 대한 DDR5 서버 메모리 가격을 말하기 전에.

가격이 중요합니다. 잘못된 메모리는 더 많은 비용이 듭니다.

회의에서 아무도 원하지 않는 신뢰도 각도

메모리는 단순한 용량이 아닙니다. 그것은 위험입니다.

저는 ECC를 마법의 종교적 대상으로 취급하는 팀을 본 적이 있습니다. “ECC가 있으니 괜찮습니다.” 아니요. ECC는 위험을 줄여줍니다. ECC는 장비의 현실, 노후화된 모듈, 한계 DIMM, 펌웨어 문제, 잘못된 검증, 잘못된 취급 또는 부실한 교체 재고를 지우지는 못합니다.

Google의 현장 연구, 야생에서의 DRAM 오류, 에 따르면 Mbit당 10억 장치 시간당 25,000~70,000개의 오류가 발생하고 연간 8% 이상의 DIMM이 오류의 영향을 받는 것으로 나타났습니다. 이는 Reddit의 일화가 아닙니다. 이는 프로덕션 규모의 데이터입니다.

카네기멜론/페이스북 논문, 대규모 프로덕션 데이터 센터의 메모리 오류 재검토, 는 14개월 동안 수십억 대의 디바이스를 대상으로 Facebook의 서버를 연구했으며, 이는 구매자가 메모리 위험을 이론적인 것으로 치부하기 전에 반드시 읽어봐야 할 증거입니다.

그리고 가동 중단은 결코 만만한 일이 아닙니다. 업타임 인스티튜트의 2024년 연간 가동 중단 분석 에 따르면 설문조사 응답자 중 541명이 가장 최근에 겪은 중대, 심각 또는 심각한 정전으로 인해 100만 달러 이상의 비용이 발생했다고 답했으며, 161명은 100만 달러 이상의 비용이 발생했다고 답했습니다.

그러면 구매 대화가 달라집니다.

아무도 제대로 테스트하지 않은 “호환 가능한” 모듈의 창고에 고장난 ERP 노드가 놓여 있을 때까지는 DIMM당 $40의 차이가 영리해 보입니다. 이것이 바로 제가 구매자 여정에 직접 검증 기사를 넣는 것을 좋아하는 이유입니다: 사용된 서버 메모리 유효성 검사 테스트 는 비용, 보증, 리드 타임과 같은 범주에 속합니다.

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

ERP 및 데이터베이스 워크로드에 대한 일반적인 RAM 계산기는 신뢰하지 않습니다.

저는 측정된 피크, 워크로드 윈도우, 공급업체 규칙, 그리고 정확한 서버, 소켓, DIMM 슬롯, 메모리 채널, 순위, 속도, BIOS 버전, 운영 체제, 데이터베이스 버전 및 성장 가정에 대한 이름을 지정하는 보기 흉한 스프레드시트를 신뢰합니다.

다음은 ERP 또는 데이터베이스 호스트의 메모리 용량을 승인하기 전에 사용하는 크기 조정 순서입니다:

1. 공손한 평균이 아닌 실제 피크를 측정하세요.

평균 메모리 사용률은 팀이 스스로에게 거짓말을 하는 방식입니다.

SAP HANA의 경우 월말, 분기 마감, 연말, 마이그레이션 드라이런 및 보고 급증 기간에 최대 메모리가 필요합니다. SQL Server의 경우 버퍼 풀 동작, 물리적 읽기, 메모리 보조금, 페이지 기대 수명 감소가 필요합니다. Oracle 데이터베이스 인메모리의 경우, 채워진 개체, IM 열 저장소 크기 조정, 핫/콜드 세그먼트 동작이 필요합니다.

2. 용량 문제와 대역폭 문제 분리

작업 세트가 맞지 않으면 용량을 구입하세요.

적합하지만 스캔이 CPU 파이프라인을 고갈시키는 경우 대역폭, 메모리 채널, NUMA 배치 및 CPU 아키텍처가 더 중요합니다. 많은 팀이 이를 모호한 “RAM 성능” 문제 하나로 통합한 다음 잘못된 해결책을 구입합니다.

3. 당신을 해칠 수 있는 것처럼 NUMA를 존중하세요.

그럴 수 있으니까요.

멀티 소켓 서버에서 메모리 로컬리티는 깔끔한 데이터베이스 설계를 지연 시간 세금으로 바꿀 수 있습니다. 채널과 소켓 전체에 걸쳐 대칭적으로 DIMM이 채워지길 원합니다. 데이터베이스 메모리 계획이 물리적 플랫폼과 일치하기를 원합니다. 그리고 가상화 팀이 “할당된 RAM'과 ”빠른 로컬 메모리'를 항상 같은 것으로 착각하지 않기를 바랍니다.

4. 인시던트 발생 전 예비 풀 계획

여분의 풀은 쓰레기 서랍이 아닙니다.

라이브 ERP, 데이터베이스 및 분석 시스템의 경우 실제 예비 전략은 승인된 모듈, 정확한 사양, 테스트된 재고, 격리 규칙 및 보충 규율을 의미합니다. ServerDimm의 방법 가이드 서버 메모리 예비 풀 구축 교체 계획이 없는 용량 계획은 반쪽짜리 정책에 불과하기 때문입니다.

데이터베이스 워크로드를 위한 최고의 서버 메모리: 내가 구입하는 제품

저는 브랜드 선호도부터 따지지 않습니다.

저는 플랫폼의 진실부터 시작하겠습니다.

데이터베이스 워크로드의 경우, 가장 적합한 서버 메모리는 서버의 지원 세대, DIMM 유형, 순위 레이아웃, 속도 규칙, 채널 모집단 계획, 용량 목표 및 유효성 검사 요구 사항과 일치하는 메모리입니다. 이는 일반적으로 많은 메인스트림 데이터베이스 호스트의 경우 ECC RDIMM을, 소켓당 밀도가 단순성보다 더 중요한 경우에는 LRDIMM을 의미합니다.

다음은 불편한 구매자 체크리스트입니다:

의사 결정 포인트	내가 보고 싶은 것	중요한 이유
DDR 세대	플랫폼 지원과 일치하는 DDR4-2933/3200 또는 DDR5-4800/5600	잘못된 세대는 물리적, 전기적으로 호환되지 않습니다.
DIMM 유형	모호한 “서버 RAM”이 아닌 ECC RDIMM 또는 LRDIMM”	데이터베이스 가동 시간은 수정된 오류 처리 및 지원되는 토폴로지에 따라 달라집니다.
용량 계획	심각한 ERP/데이터베이스 시스템을 위한 측정된 피크 이상의 25-40% 헤드룸	성장, 배치 급증, 장애 조치 및 보고는 거의 허가를 요청하지 않습니다.
채널 잔액	CPU 메모리 채널 전반의 대칭적 모집단	피할 수 있는 대역폭 및 지연 시간 불이익 방지
순위 및 속도	OEM 메모리 규칙에 대한 확인	혼합 등급은 지원되는 구성을 다운클럭하거나 제한할 수 있습니다.
공급업체 증거	테스트 기록, 정확한 부품 번호, 보증, 포장 규정	“풀 작업”은 유효성 검사 정책이 아닙니다.
예비 전략	확장 재고와 분리된 비상 재고	계획된 업그레이드가 정전 복구 인벤토리를 훔치는 것을 방지합니다.

적극적인 소싱을 위해 저는 구매자에게 서버 모델, CPU 세대, 설치된 메모리 맵, 목표 용량, 선호하는 브랜드, 수량, 배포 일정 등 구체성을 강요하는 견적 흐름을 제시합니다. 이것이 바로 ServerDimm이 자사의 서버 메모리 견적 요청.

나쁜 인용문은 “64GB DDR4 서버 RAM”이라고 적혀 있습니다.”

좋은 견적에는 “64GB DDR4-3200 ECC RDIMM, 2Rx4, Dell PowerEdge R750용 플랫폼 승인, 일치하는 세트, 테스트 완료, 필요 수량 192개 모듈, 프랑크푸르트 배송, 보증 확인”이라고 적혀 있습니다.”

차이점이 보이시나요?

하나는 쇼핑입니다. 다른 하나는 구매 주문서가 있는 엔지니어링입니다.

자주 묻는 질문

메모리 집약적 워크로드란 무엇인가요?

메모리 집약적 워크로드는 주로 활성 데이터세트, 인덱스, 캐시, 트랜잭션 상태 및 작업 개체를 저장할 수 있는 충분한 RAM을 확보하는 데 성능과 안정성이 좌우되는 애플리케이션으로, 비즈니스 크리티컬 처리 중에 지속적인 디스크 읽기, 페이징, 퇴거, NUMA 페널티 또는 캐시 이탈이 발생하지 않도록 시스템이 방지합니다.

쉽게 말해, 이러한 워크로드는 필요한 데이터가 CPU에 근접할 수 없을 때 속도가 느려집니다. 활성 데이터 세트가 설치된 메모리 이상으로 증가할 때 ERP 시스템, SAP HANA, SQL Server, Oracle 데이터베이스 인메모리, Redis, 분석 플랫폼, 대규모 가상화 클러스터가 모두 이 패턴에 해당합니다.

데이터베이스에 많은 RAM이 필요한 이유는 무엇인가요?

데이터베이스에는 자주 액세스하는 데이터 페이지, 인덱스, 실행 계획, 열 저장소, 트랜잭션 구조, 임시 작업 데이터가 메모리에 저장되므로 쿼리 및 비즈니스 프로세스에서 지연 시간을 늘리고, I/O 압력을 높이며, 최대 수요 시 성능을 불안정하게 만드는 반복적인 디스크 읽기를 방지할 수 있도록 많은 RAM이 필요합니다.

그렇기 때문에 데이터베이스 워크로드 메모리 용량은 단순한 하드웨어 세부 사항이 아닙니다. 급여, 청구, 마감, 보고 및 고객 대면 거래가 급증하는 동안 시스템이 예측 가능하게 작동하는지 여부를 제어합니다.

SAP HANA에는 얼마나 많은 메모리가 필요합니까?

SAP HANA 메모리 요구 사항은 소스 데이터베이스 크기, 압축 동작, 워크로드 유형, 최대 사용률, 배포 모델 및 SAP 사이징 출력에 따라 달라지므로 책임 있는 사이징은 일반적인 테라바이트당 RAM 가정이 아닌 SAP Quick Sizer, SAP 사이징 보고서, SAP Notes 또는 측정된 최대 사용량을 사용해야 합니다.

게으른 대답은 “HANA는 데이터를 압축하므로 RAM이 덜 필요합니다.”입니다. 전문적인 대답은 “실제 워크로드를 측정하고 크기를 조정하세요.”입니다. 압축은 다양합니다. 워크로드 동작은 다양합니다. 비즈니스 피크도 다양합니다.

메모리 대역폭보다 메모리 용량이 더 중요할까요?

워크로드의 활성 데이터 세트가 RAM에 맞지 않을 때는 메모리 대역폭보다 메모리 용량이 더 중요합니다. 시스템에 설치된 메모리가 실제 작업 세트에 비해 충분하지 않으면 아무리 추가 대역폭을 확보해도 페이징, 캐시 제거, 디스크 읽기 또는 메모리 부족 장애를 방지할 수 없기 때문입니다.

용량이 충분해지면 메모리 대역폭이 더 중요해집니다. 이때부터 채널 수, DDR5 속도, NUMA 로컬리티, CPU 메모리 아키텍처가 중요해지기 시작합니다. 용량 우선. 그다음은 대역폭입니다.

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

데이터베이스 워크로드에 가장 적합한 서버 메모리는 서버 플랫폼, CPU 세대, DIMM 구성 규칙, 속도 제한, 순위 레이아웃, 목표 용량, 데이터베이스의 안정성 요구사항에 부합하는 검증된 ECC RDIMM 또는 LRDIMM으로, 최대 사용량, 장애 복구 동작 및 향후 성장을 위한 충분한 헤드룸을 갖추고 있어야 합니다.

대부분의 서버에서는 ECC RDIMM이 기본값입니다. 고용량 시스템의 경우 LRDIMM이 필요할 수 있습니다. 용량 라벨만 보고 구매하는 것은 잘못된 선택입니다.

다음 단계: 사무용품처럼 RAM 구매 중단하기

“더 많은 메모리”를 요구하지 마세요.”

워크로드에 안전한 메모리 요금제를 요청하세요.

최대 사용량 감사, 플랫폼 제한 확인, DDR4 또는 DDR5 요구 사항 매핑, RDIMM과 LRDIMM 지원 문서화, 메모리 채널 균형 조정, 성장 헤드룸 확보, 다음 ERP 또는 데이터베이스 사고가 재무 문제로 전환되기 전에 테스트된 예비 재고를 준비해 두세요.

정확한 서버 모델, 현재 DIMM 레이아웃, 목표 용량, 워크로드 유형, 수량 및 배송 지역을 ServerDimm을 통해 보내주세요. 대량 서버 메모리 견적 페이지 를 통해 첫 이메일부터 구체적으로 대화하도록 유도합니다. 이것이 바로 진지한 팀들이 메모리 집약적인 워크로드를 위해 메모리를 구매하는 방식입니다.