CPU 클럭 속도 대 CPU 코어 수-더 높은 GHz 또는 SQL Server의 더 많은 코어?


30

VMware 내에서 SQL Server 2016 노드의 가상 클러스터를위한 물리적 서버 세트를 프로비저닝하기 시작했습니다. Enterprise Edition 라이센스를 사용할 것입니다.

우리는 6 개의 노드를 설정할 계획이지만 CPU 클럭 속도 대 CPU 코어 수와 관련하여 물리적 서버를 프로비저닝하는 이상적인 방법에 대해서는 약간의 논쟁이 있습니다.

나는 이것이 다른 소프트웨어 관련 요소들 사이에 저장된 트랜잭션 볼륨과 데이터베이스 수에 크게 의존한다는 것을 알고 있지만 일반적으로 권장되는 규칙이 있습니까?

예를 들어 듀얼 8 코어 3.2GHz 물리적 서버 (16 코어)가 듀얼 16 코어 2.6GHz 서버 (32 코어)보다 더 선호됩니까?

이 유형의 주제를 자세히 다루는 백서가 있습니까?


요약 또는 라이센스 및 비용 효율성에 대한 우려, 성능은 무엇입니까?
Evan Carroll

답변:


40

일반적으로 코어 수는 가능한 한 낮게 유지하고 프로세서 속도는 최대한 높게 유지하는 것이 좋습니다. 이에 대한 라이센싱 수학은 Expensive Edition의 코어 당 ~ $ 7,500 USD에서 포인트를 입증합니다.

올바른 하드웨어를 구입하면 라이센스 비용을 절감 할 수 있습니다. Glenn Berry의 SQL Server 프로세서 선택을 참조하십시오 . SQL Server 용 프로세서를 선택하는 방법에 대한 훌륭한 리소스입니다.

SQL Server의 코어 별 라이센싱 구조를 고려하면 OLTP이든 분석이든 워크로드 유형에 관계없이 항상 가장 빠른 프로세서 속도를 사용하는 것이 좋습니다. 가장 빠른 코어 속도를 갖는 것은 결코 문제가되지 않습니다. 필요에 따라 코어 수를 늘리십시오. 그러나 코어 속도를 줄임으로써 절대 그렇게하지 마십시오.

다시 말해 16 x 2.2Ghz 프로세서가 8 x 4.5Ghz 프로세서와 동일하다고 생각하지 마십시오. 4.5Ghz 프로세서보다 2.2Ghz 프로세서를 사용하면 비용이 최대 약 $ 10,000 USD (일반적인 Xeon 기반 2 프로세서 시스템) 일 것입니다. SQL Server Enterprise Edition을 사용하여 8 코어에서 16 코어로 건너 뛰려면 라이센스 비용이 $ 60,000 USD를 넘을 것입니다. 다시 말해, 하드웨어 비용을 10,000 달러 절약 할 수 있지만 라이센스에서 5 만 달러를 추가로 잃게됩니다.

많은 병렬 처리 근육이 필요하다고 판단하고 현재 작업에 32 코어가 필요하다고 결정하면 가장 빠른 코어를 사용하면 처리 시간이 단축되어 배당금을 지불합니다. 아무도 당신을 잘못 생각하지 않을 것입니다.

선택 사항이 하나의 CPU 또는 둘 이상의 CPU 인 경우 항상 둘 이상으로 진행하십시오 . 단일 CPU에서 SQL Server (또는 모든 DBMS)를 실행하면 동시 작업 기능이 크게 제한되므로 모든 종류의 문제가 발생할 수 있습니다.


11

보류 보류 보류

성능 및 라이센스 측면은 흥미롭지 만 고려해야 할 작업의 유일한 측면은 아닙니다.

프로세서 선택에 영향을 줄 수있는 한 가지는 작업자 스레드입니다.

작업자 스레드?

그래 친구! 그것들은 SQL Server가 쿼리를 실행하고 상황을 유지하는 데 필요한 모든 배경 작업을 수행하는 데 사용하는 것입니다.

작업자 스레드가 부족 하면 THREADPOOL 대기

스레드 풀?

스레드 풀. 이것은 RESOURCE_SEMAPHORE 및 RESOURCE_SEMAPHORE_QUERY_COMPILE 과 함께 서버에서 가질 수있는 가장 빠른 대기 중 하나입니다 . 그러나 이것들은 메모리 대기이며, 이것은 CPU 질문입니다.

이것이 왜 위그 위크 (Wagity Wack) 인 이유로 돌아가겠습니다.

이것은 SQL Server가 작업자 스레드를 계산하는 방법입니다 .

견과류

코어 수를 두 배로 늘려도 Max Worker Threads가 두 배가되지 않고 4 개의 코어에서와 같이 1 개의 코어로 같은 수를 얻습니까? 방정식은 다음과 같습니다.512 + ((logical CPUs - 4) * 16)

코어 카운트가 증가 할 때 클럭 속도는 일반적으로 한두 세대로 돌아 가기 때문에 부끄러운 일입니다.

견과류

최근 인텔 칩 라인을 살펴보면 비슷한 경향이 나타납니다.

필요한 스레드 수를 어떻게 알 수 있습니까?

이것은 많은 것에 달려 있습니다 :

  • 사용자 수
  • 병렬 쿼리 수
  • 연속 쿼리 수
  • 데이터베이스 수 및 데이터 동기화 (미러링, AG, 로그 전달 용 백업)
  • MAXDOP 및 CTFP를 기본값으로두면

오늘 부족하지 않다면 아마 괜찮을 것입니다.

그러나 당신이 있는지 어떻게 알 수 있습니까?

좋은 질문이 있고 좋은 질문이 있으며 lemme이 당신에게 무언가를 말해줍니다 . 그것은 위대한 질문 입니다.

THREADPOOL은 연결 문제로 나타날 수 있으며 오류 로그에 스레드생성 할 수 없다는 메시지가 표시 될 수 있습니다 .

sp_Blitz 또는 sp_BlitzFirst 와 같은 무료 도구를 사용하여 서버의 대기 통계를 볼 수도 있습니다 (전체 공개,이 프로젝트에 기여합니다).

EXEC sp_Blitz

견과류

EXEC sp_BlitzFirst @SinceStartup = 1

견과류

Max Worker Threads 만 늘릴 수 없습니까?

MWT를 늘리면 SOS_SCHEDULER_YIELD대기 시간 이 늘어날 수 있습니다 .

그것은 세상의 끝이 아니지만, 선생님의 수업에 소리 지르는 아이들을 추가하는 것처럼 생각하십시오.

갑자기, 각 아이들이주의를 끌기가 더 어려워 질 것입니다.

프로세스 가 4ms quantum을 소진 하면 CPU보다 많은 스레드가 대기 할 가능성이 있습니다.

성능은 거의 비슷할 수 있습니다.

더 적은 수의 작업자 스레드를 사용하려면 어떻게해야합니까?

당신은 [명사]의 잔인한 [명사], 그들은 지원할 가족과 노동자입니다! 모기지! 꿈!

그러나 흠, 결론을 존중해야합니다. 당신은 보스입니다.

시작하기 가장 쉬운 곳은 MAXDOP 및 Cost Threshold For Parallelism과 같은 설정을 기본값에서 변경하는 것입니다.

설정 방법에 대해 궁금한 점이 있으면 여기로 이동하십시오.

그 후, 당신의 일은 훨씬 더 어려워집니다. 모든 스레드를 사용하는 것이 무엇인지 알아 내야합니다. 대기 통계를 보면 때때로 그렇게 할 수 있습니다.

보다 구체적으로, 병렬 처리에 대한 높은 대기 시간 ( CXPACKET)과 잠금에 대한 높은 대기 시간 ( LCK_)이있는 경우 병렬 쿼리와 관련된 긴 블로킹 체인이 실행될 수 있습니다.

무슨 냄새가 나는지 알아? 모든 병렬 쿼리가 잠금을 얻기 위해 대기하는 동안 할당 된 스레드를 다시 제공하지 않습니다.

관리자가 확인한 4 개의 핵심 VM이 모든 작업 부하를 처리하기에 충분하다고 들었을 것입니다.

불행히도, 그 문제를 해결하기 위해 수행 해야하는 쿼리 및 인덱스 튜닝 유형은 문제의 범위를 벗어납니다.

이것이 도움이되기를 바랍니다!


2

커뮤니티 위키 답변 :

장단점은 다음과 같습니다. SQL Server의 대부분의 워크로드는 OLTP이며 직렬 작업이기 때문에 더 높은 클럭 속도를 활용할 수 있습니다.

대규모 병렬 시스템을 위해 특별히 설계하지 않으면 클럭 속도가 항상 우수합니다. 에지 사례가 존재하지만 시간 응답의 95 %입니다. 비용이 적게 든다는 것도 좋은 일입니다.


-3

대답은 다음과 같습니다. 사용 사례에 따라 다릅니다.

  • 한 번에 또는 여러 개의 큰 요청으로 여러 개의 작은 요청을 처리하고 있습니까?
  • 실행하는 프로그램이 멀티 코어에 최적화되어 있습니까?

예를 들어, 쿼드 코어 컴퓨터가 있지만 ESP8266 컴파일러는 하나의 코어 만 사용하도록 설계 되었기 때문에 CPU의 25 % 만 사용합니다. 내가 하나의 빠른 코어를 가지고 있다면 그것은 더 최적 일 것입니다.


6
dba.stackexchange.com에 오신 것을 환영합니다 ! 귀하의 답변은 매우 일반적인 경우에 해당하지만 OP가 요구하는 SQL 또는 데이터베이스 사례에는 중점을 두지 않습니다. 그 문제에 더 깊이 들어가서 그것을 개선하십시오! :)
xDaizu
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.