더 많은 CPU 코어와 더 빠른 디스크

평소처럼 여러 가지 역할을 담당하는 소규모 회사에 속해 있습니다. 최신 버전은 .NET 웹앱 전용 SQL Server 상자를 조달하고 있습니다. 32GB의 RAM을 갖춘 듀얼 Xeon E5-2620 (6 코어) 2.00GHz CPU 구성 (총 12 코어)에 대해 인용했습니다. 이는 RAID 1 구성에서 2 개의 2.5 "SAS 300GB 드라이브 (15k RPM)로 구성된 디스크 어레이 예산을 제한했습니다.

디스크 설정이 SQL Server에 적합하지 않다는 것을 알고 있으며 데이터베이스, 로그 파일 및 tempdb를 자체 드라이브에 넣을 수 있도록 RAID 10을 푸시하고 싶습니다. 예산과 호환되도록하려면 CPU 코어 수를 줄여야합니까? 아니면 듀얼 RAID 1 설정에서 코어를 유지하고 더 적은 수의 드라이브를 사용하는 벅에 더 나은 은행을 얻습니까?

추가 통계는 다음과 같습니다.

• SQL Server 데이터베이스는 쓰기에 대한 읽기 수가 많을 것으로 예상됩니다 (각각 80 % 대 20 %). 현재 DB 크기는 현재 약 10GB 26GB이며 한 달에 250MB의 속도로 증가합니다.

• 현재 웹 서버 (RAID 1의 12GB Ram, 2 x 10k 300GB SAS 드라이브)와 공유되는 단일 쿼드 코어 Xeon 박스에서 SQL Server 2008 R2 Standard에서 실행 중이며 SQL Server 2012 Standard로 이동하려고합니다.

• 데이터베이스는 약 100-150 명의 동시 사용자에게 일부 백그라운드 스케줄링 작업을 수행합니다. 이것을 읽으면 12 개의 코어가 심각한 오버 킬이라고 생각합니다!

전체 응용 프로그램을 SQL Azure DB에 연결된 Azure 클라우드 서비스 (작은 인스턴스 2 개)에 배포했습니다. 테스트 할 때 성능이 합리적 이었지만 (거의 무부하), 내가 읽은 예측할 수없는 예측으로 인해 프로덕션 환경에서 사용할 용기를 잃었습니다. 스케일 아웃 접근 방식에서는 더 잘 작동하지만 10GB 데이터베이스 만 있으면 지금 스케일 업으로 벗어날 수 있으며 현금을 절약 할 수 있습니다.

처음에 라이센스 비용을 간과했지만 SQL Server 2012 라이센스가 코어 수를 기반으로한다는 것을 알지 못했습니다. SQL Server 2012 Standard 라이센스로 BizSpark MSDN을 구독하고 있으므로 기본적으로 사용할 수있는 코어 수를 읽어야합니다.

겸손하지만 공유할만한 가치가 있다고 생각하는 SQL 데이터베이스 (Sybase 및 SQL Server)의 주요 병목 현상은 스토리지입니다.

그러나 누군가가 잘못된 가정을하기 전에 먼저 설정을 벤치마킹하는 것이 공정하다고 생각합니다. 필자의 경우, CPU 사용률은 언제라도 CPU 업그레이드를 정당화 할만큼 충분히 높아지지 않았습니다. 대신 단일 드라이브에서 RAID 1로 업그레이드 한 다음 RAID 10 + 8GB에서 16GB RAM으로 업그레이드했습니다.

이러한 모든 RAID 업그레이드는 이전 대기 시간을 2 ~ 6 배로 줄이는 데 도움이되었습니다. SSD로 업그레이드하는 것이 더 나을 것 같습니다. 그것에 대해 생각하면 모두 (이론적) 대역폭으로 줄일 수 있습니다. [(RAM Speed ​​+ RAM Size + Memory controller) to CPU] 콤보에는 대역폭 제한이있어 데이터를 항상 캐시해야 할 때 읽기 작업에서 가장 중요한 요소가 될 수 있습니다. 특정 (RAID) 스토리지에는 대역폭 제한이 있습니다 ( 캐시가 누락 된 경우 읽기에 영향을 미치고 플러시 할 때 또는 많은 클라이언트가 많은 데이터를 결합하여 쓸 수 있습니다).

이러한 모든 한계를 가능한 한 많이 정규화하고 (자원을 낭비하지 않도록 더 가까이 가져 오십시오) 가능한 한 많이 늘리십시오 (필요한 경우 업그레이드하고 필요한 경우에만 시스템이 작동 할 경우 리소스가 낭비되지 않도록하십시오). 다른 병목 현상이 발생하여 사용할 수 없습니다.) 결국 최악의 병목 현상은 특정 구성에서 성능이 가장 낮은 (가장 대역폭이 적은) 서버 하위 시스템입니다.

또한 업그레이드 과정에서 데이터베이스 파일과 데이터베이스 로그 파일에 대해 별도의 RAID 구성을 만들었습니다. 데이터베이스 로그 파일은 쓰기 집약적 인 경향이 있기 때문입니다. 로그 파일은 충돌로부터 데이터베이스를 복구하는 데 사용되며 데이터가 데이터베이스 파일에 기록되기 전에 트랜잭션이 커밋되면 항상 즉시 기록됩니다.

일부 데이터베이스 복제 서버에서도 로그 파일을 사용하지만 대부분의 복제는 즉시 수행되지는 않지만 읽기 성능에 미치는 영향은 최소화됩니다. 적어도 그렇게 생각합니다. 이 업그레이드를 다시 수행하는 동안 최소한의 벤치마킹을 수행 했으므로 CPU 업그레이드에 대해 생각하기 전에 먼저 다른 구성을 벤치마킹하고 스토리지, RAM 및 네트워크 링크를 먼저 업그레이드하는 것이 좋습니다.

5 대 이상의 서버에서보다 광범위한 업그레이드를 한 후 다시 경험을 공유했습니다. 나는 여전히 스토리지를 먼저 업그레이드 한 다음 RAM을, CPU를 업그레이드하도록 확실히 옹호합니다. 이유는 스토리지, RAM 및 CPU 간 시스템에서 대역폭의 차이가 가장 낮거나 높은 순서입니다. 그래서 많은 서버를 RAID10 및 듀얼 RAID1에서 SSD로 업그레이드했습니다.

비용 문제로 인해 업그레이드를 수행 한 방법 (업그레이드 할 서버가 20 대 더 있음)은 데이터베이스 데이터 및 개체 파일을 SSD (예 : RAID0에 하나의 SSD)로 옮기고 트랜잭션 로그와 tempdb를 4xHDD RAID10으로 옮기는 것입니다 구성. 나는 SSD에서 tempdb와 함께 좋은 결과 (실제로 15 배 이상 빠른 쿼리로 아주 좋은 결과를 보였으며 과거 몇 분이 아닌 몇 초가 걸리는 일부 보고서를 생성 함)로 나중에 tempdb를 디스크 RAID10으로 옮겼습니다. SSD에 대한 집중적 인 쓰기 마모 문제.

이제 기본적으로 가장 긴 쿼리 중 일부에서 응답 시간이 10-15 배 빠릅니다. SSD는 데이터를 RAM으로 빠르게 읽는 데 유용합니다. SQL Server는 요청 된 데이터가있을 때까지 데이터를 RAM으로 가져 오지 않으며 CPU에서 처리하기 위해 데이터를 RAM으로 먼저로드해야합니다 (나중에 L1, L2, L3 캐시). 따라서 SSD는 초기 대기 시간을 크게 줄여줍니다. 또한 SSD는 스왑 시간을 줄여줍니다. 특히 데이터베이스가 RAM에 비해 크면 RAM을 지우고 새 데이터를로드합니다.

전체 서버를이 구성으로 전환하기 전에 마모 수준 정보를 수집 할 수 있도록 서버를 실행할 수 있도록 일종의 느린 마이그레이션 프로세스에서 몇 개월 동안 매우 기쁘고 실행되었습니다. 그리고 이것은 단지 SQL Server Express입니다! : D-SSD가 지속적으로 IOPS를 제공 할 수 있는지 확인하십시오 .Google과 큰 차이가 있기 때문입니다. 그렇기 때문에 인텔 DC (DataCenter) 시리즈 SSD를 선택했습니다.

아마도 첫 번째 부분에서 찾고있는 대답은 아니지만 클라우드로 푸시하는 것을 고려 했습니까? AWS를 사용하면 하드웨어를 처리하지 않고도 위의 요구를 대부분 충족하고 구매력을 확장 할 수 있습니다.

두 번째 부분-하드웨어는 실제로 작업에 달려 있습니다. 맞춤형 CLR 통합을 수행 할 수있을 때 더 많은 CPU에 의존하는 경향이 있습니다. 문제에 대한 진정한 병렬 솔루션을 위해 최적화 할 수 있기 때문입니다. 대부분의 경우 기반 솔루션을 설정하는 것이 낫다면 RAM과 하드 드라이브 속도가 가장 큰 병목 현상이며 두 번째는 귀하의 경우 인 것 같습니다. (위의 SSD 아이디어가 도움이되는 곳)

서버의 실제 통계가 없으면 쓰기를 낮추기 위해 캐싱 솔루션을 살펴보십시오 (쓰기로 기록하거나 기록이 필요한 것들을 제외하고) 하드 드라이브에 더 많은 돈을 투자하지 않는 한 CPU보다. SQL 서버는 쿼리에 대해 병렬 처리하는 데 능숙하지만 (작성된 경우) 쓰기 작업이 많은 경우 하드 드라이브가 실제 병목 현상입니다.