우리가 개발 중인 시스템은 웹 앱 프런트엔드와 SQL Server 2008 R2의 저장 프로시저를 사용하여 많은 데이터 처리를 수행하는 백엔드로 구성됩니다(이유는 묻지 마세요...). 이러한 저장 프로시저는 임시 테이블(생성, 삽입, 조인)을 많이 사용하므로임시 DB쓰기 및 읽기에서 I/O 속도가 높습니다. 우리 고객은 속도가 필요하므로 다음을 권장합니다.
- 주요 데이터베이스를 저장하기 위한 RAID 1 SSD 어레이(돈이 있다면 RAID10일 수도 있음)가 있는 서버를 구입하고, OS 및 SQL Server 설치용으로 다른 하드 드라이브를 사용하여 중요한 데이터가 복제를 통해 빠른 드라이브에 저장되도록 하고, 64GB RAM.
- Ramdisk를 사용하여 저장임시 DB따라서 임시 테이블(가장 큰 성능 병목 현상이라고 생각함)은 RAM에서 처리됩니다.
일부 컨텍스트 데이터:
- 우리 데이터베이스는 10GB 이하를 사용하며 예상 증가율은 매우 낮습니다. Tempdb는 일반적으로 2~3GB 이하로 증가합니다.
- 서버는 DB와 Web Server로 사용됩니다.
- Ramdisk 소프트웨어는 Windows 시작 시 ramdisk를 마운트할 수 있습니다.
우리는 RAM이 많은 노트북에서 램디스크 접근 방식을 테스트했습니다. 속도 향상은 놀랍습니다(저장 프로시저 실행 시간이 1/3로 감소).
이것이 좋은 해결책인지 아닌지를 판단하고 내가 놓쳤을 수 있는 결함(명백하든지 덜 명백하든)을 감지하려면 도움이 필요합니다.
편집: 지금까지 답변해 주셔서 감사합니다! 애플리케이션을 사용하는 동시 사용자가 있을 것이므로 여러 임시 테이블 작업이 실행될 것이라는 점을 명시적으로 언급하는 것을 잊었습니다. 또한 웹 서버와 DB 서버를 혼합하는 것은 우리의 선택이 아니며, 우리는 그것이 최적이 아니라는 것을 이미 알고 있습니다.)
답변1
단지 요금이 아니라 기다리는 것입니다. 벤치마킹을 제대로 하세요. IOPS와 디스크 대기열 길이를 확인하세요. Perfmon 및 SQL 프로파일링을 사용합니다. 계속하세요 – 기다릴게요.
실제 성능 문제가 있는 경우 OS는 하나의 스핀들 세트, 다른 MDF, 다른 LDF, tempdb 파일에 또 다른 세트에 있어야 한다는 것을 이미 알고 있습니다. 그렇게 하기로 약속할 수 없다면 벤치마킹하고 우선순위를 찾으십시오. 또한 서로 다른 읽기 및 쓰기 패턴에 따라 각 항목에 대해 서로 다른 RAID 수준이 결정될 수 있습니다.
올바른 RAID 구성을 갖춘 표준 디스크를 사용하면 엔터프라이즈 SSD에 맞춰 용량을 줄이지 않고 필요한 위치에 도달할 수 있다는 것을 알 수 있습니다. 그러나 tempdb가 충분히 손상되면 단일 SSD가 적합할 수 있습니다. 아마도 성능을 위해 RAID가 필요하지 않을 수도 있지만 중복성을 위해서는 좋은 생각일 수도 있습니다. 물론 예산과 다운 기간에 따라 다릅니다.
SQL 서버는 웹 서버와 분리되어야 한다는 것도 알고 계시죠? 성능이 문제라면? 지금은 문제가 없더라도 성장하면 어느 것이 더 세게 망치고 있는지, 어떤 해결책이 적절한지 판단하기 어려울 것입니다.
답변2
RAID는중복성, 성능이 창 밖으로 나옵니다. 예를 들어 RAID 5에서는 데이터를 읽습니다.모두구성 요소 디스크를 읽어야 하며 패리티를 확인해야 합니다(즉,~이다단일 디스크에서 읽는 것보다 느리면 헤드 움직임이 반드시 동기화되지 않으므로가장 긴평균이 아닌 세트의) 쓰기는 모두 읽고, 패리티를 계산하고, 새로운 데이터와 패리티를 쓰는 것을 의미하며, 이는 단순히 쓰는 것보다 확실히 느립니다.
예, 좋은 RAID 구현과 스마트 운영 체제는 이를 많이 완화할 수 있습니다. 단일 디스크라도 RAM에 비해 엄청나게 느리기 때문에 가치 있는 운영 체제는 디스크에 관계없이 광범위한 캐싱을 수행해야 합니다.
예, 스마트 DBMS는 가능한 한 많은 데이터를 RAM에 캐시합니다(데이터 일관성, 장애 저항 등과 관련하여 약속한 사항을 존중합니다. 필요한 경우 계속 진행하기 전에 데이터가 디스크에 안전하게 있을 때까지 명시적으로 기다립니다).
모든 DB에서 RAMdisk는 순수한 독입니다("디스크에 명시적으로 기록된 데이터이므로 안전함"은 그렇지 않습니다).
답변3
모든 답변에 감사드립니다. 그들은 매우 도움이 되었습니다. 몇 가지 후속 연구를 통해 I/O 속도가 일반적으로 중요하지만 이 특별한 경우의 주요 병목 현상이 아니라는 사실을 발견했습니다. tempdb 관리의 모범 사례에는 최소 4개의 데이터 파일을 보유하는 것이 포함됩니다. Microsoft는 또한 각 CPU 코어에 대해 1개의 데이터 파일을 권장합니다. 파일이 많으면 경합 문제를 줄이는 데 도움이 됩니다.
이에 대한 일부 링크:
답변4
쓰기 및 읽기에서 tempdb I/O 속도가 높도록
RAM이 너무 적습니다. tempdb는 오버플로될 때 IO만 수행합니다. 그렇지 않으면 SQL Server는 tempdb 페이지를 디스크에 덤프하지 않습니다.
따라서 RAM 디스크는 도움이 되지 않으며 오히려 더 많은 메모리를 저장합니다.