우리가 뭘해야하는지 대략적인 대략적인 추정치를 얻을 수 있기를 바랐습니다.
쿼리 및 데이터 크기에 대한 추가 정보가 없으면 정확한 견적은 물론 모든 종류의 견적을 제공하기가 매우 어렵습니다.
데이터베이스 : SQL Server 2008 R2 엔터프라이즈 데이터베이스
Windows : Windows 2008 r2 Enterprise 64 비트, VMware에서 실행 중입니다.
프로세서 : Intel® Xeon® CPU E7-4860 @ 2.27GHz 2.26 GHz (2 프로세서)
설치된 메모리 : 4GB
두 개의 프로세서 (이것이 VM에 2 개의 코어로 노출되어 있다고 가정합니다)가 프로비저닝되지 않았거나 그렇지 않을 수 있습니다. VM에 할당 된 코어가 물리적 코어에 직접 매핑 될 필요는 없으며 (필요할 때 단일 코어의 100 %를 사용할 수도 있습니다!) 메모리보다 유연한 리소스임을 알 수 있습니다. 워크로드 또는 하드웨어 / 가상화 구성에 대한 추가 정보가 없으면 이것을 4로 늘리면 좋을 것입니다.
메모리 할당. 오 소년. 이다 조잡한 작업 부하에 대한 비전 아래-. Windows 자체는 행복을 유지하기 위해 최소 2-3GB가 필요하며, 상자에서 BIDS를 실행하는 2 명의 사용자 각각은 각각 500MB 이상이 필요합니다. 그리고 그로 인해 상자가 이미 최대로 확보되었으며 데이터베이스 에 필요한 양을 파악하기조차 시작하지 않았습니다 .
대부분의 사용자는 asp.net 웹 사이트 및 보고서 서버 웹 사이트를 통해 데이터베이스와 상호 작용합니다.
당신이 말하지는 않았지만 이것들이 같은 상자에서 실행되고 있다면 그것들에 대한 메모리 요구 사항도 고려해야합니다.
마지막으로, 서버에서도 실행되는 SSIS 패키지를 통해 하루에 3 백만 건의 레코드를 가져 오는 상당히 관련된 데이터웨어 하우징 작업이 있습니다.
시스템에 실제 사용자가 없을 때 밤에 실행한다고 가정하면 실행하는 데 너무 오래 걸리지 않는 한 이것을 문제로 보지 않습니다. 사물의이 부분은 당신의 걱정 중 가장 적은 부분입니다. 실제 사용자가 더 중요합니다.
추가 메모리에 대한 이전 요청은 더 많은 쿼리 최적화를 수행해야하는 일반적인 응답으로 거부되었습니다.
위에서 설명한 것처럼 프로비저닝 된 현재 메모리 양이 완전히 부적절합니다. 그러나 동시에 스펙트럼의 다른 쪽 끝에서 전체 데이터베이스를 한 번에 메모리에 유지할 수 있도록 충분한 메모리를 프로비저닝 할 수 없을 것 입니다.
그런 식으로 담요 응답을 받았지만 ( 실제로 추가 리소스에 대한 정당화가 실제로 설득력이 아니라 얼마나 설득력이 있는지와 더 관련이 있었음에도 불구 하고) 데이터베이스의 효율성이 높을 수 있습니다. 향상. 그러나 현재 겪고있는 문제를 해결할 수있는 튜닝 양은 없습니다. 그 제안은 나에게 완전한 비 스타터입니다.
나는 현재 프로비저닝 메모리의 양 (최대한 빨리 수정해야하는) 필요한 최소 아래에있는 전체적인 접근 방식을 것이고, 추가 리소스 사용 가능한 수준으로 사용자 경험을 향상해야 할 수 있습니다 동안 개선의 효율성을 높이기 위해 만들어진 시스템.
다음은 몇 가지 생각입니다 (공격 순서).
더 많은 리소스를 프로비저닝 할 때마다 얼마나 많은 성능이 향상되는지 증명할 수 있으면 이길 것 입니다. 가능한 경우 웹 사이트 응답 시간을 포함 하여 성능 모니터 로깅 (참고 : 로깅 부분이 매우 중요 함)을 사용하여 성능 메트릭을 추적하십시오 . 다른 작업을하기 전에 지금 이 작업을 시작하십시오 . 마지막으로 최소 메모리 양에 도달하면 (즉시 32GB를 얻지 않을 것임 ) 갑자기 추가 된 메모리가 개선 되었다는 증거 가 생겼습니다. 더 많은 것을 추가하면 도움이 될 것입니다! 현재 구성에 대한 기준을 수집하지 않으면 상황이 최소 권장 수준으로 올라갈 때 보트를 놓칠 수 있습니다.
서버의 대기 통계를 분석하십시오 . 시스템에서 가장 큰 병목 현상이 무엇인지 알려줍니다. 당신은 아마거야 PAGEIOLATCH_XX/ O 디스크에서 페이지를 가져 오기 위해 수행되고 너무 많은 I를 나타내는 가장 일반적인 / 최대 대기 시간으로. 메모리를 추가하면이를 완화 할 수 있으므로 필요한 데이터가 이미 메모리에 있으므로 물리적 I / O의 빈도가 줄어 듭니다. 이 분석은 거의 확실한 결론이지만, 이러한 통계를 수집했다는 사실은 자원의 필요성을 정당화 할 때 더 많은 탄약을줍니다.
위에서 언급했듯이 메모리에 대한 최소 요구 사항이 충족되지 않습니다. 실행중인 모든 소프트웨어에 대한 권장 하드웨어 요구 사항을 수집하고 작업 관리자의 스크린 샷을 얻을 수도 있습니다. 이것만으로도 최소한 4-8GB 이상 더 정당화 할 수있을 것입니다. 그래도 거부하는 경우 일주일 동안 사용해 볼 수 있도록 설득하고 그 이후에 다시 제공하십시오 (성능 통계를 수집하는 중이므로 주중에 반품 할 필요가 없습니다). 상황이 얼마나 개선되었는지 증명할 수 있습니다). 그들이 여전히 거부 한다면 , 당신은 실패하도록 설정되고있는 것입니다; URLT .
일부 워크로드를 오프로드 할 수있는 경우 (특히 가능한 경우 원격으로 이동하지 마십시오) 데이터베이스에 사용할 수있는 메모리 양이 증가하므로 더 중요합니다.
당신은 매우 신중하게 설정 SQL 서버의 최대 메모리 설정해야합니다 즉, 한 번에 메모리에 전체 데이터베이스를 맞게 할 수 없습니다 커밋을 통해 메모리를 방지 등의 성능을 죽이고, 다른 아무것도 . 오버 커밋은 실제로 모든 데이터를 메모리에 맞추지 못하는 것보다 훨씬 나쁩니다 . 사용 가능한 메모리가 전혀 없기 때문에 현재이 시나리오에있을 가능성이 높으며 최대 메모리 설정이 기본값 (무제한)으로 설정되었을 수 있습니다.
SQL Server Enterprise Edition을 실행 중이고 메모리가 부족하므로 데이터 압축 구현을 강력하게 고려할 것 입니다. 이는 메모리 공간 절약을위한 CPU 사용량 증가와 디스크 액세스 감소 (상당히 매우 느림)를 상쇄합니다.
데이터베이스를 조정하십시오. 인덱싱 및 액세스 패턴이 진행되는 한 구조와 쿼리가 개선 사항을 사용할 수 있습니다. 또한 많은 데이터를 자주 스캔하고 집계하는 경우 인덱스 된 뷰, 요약 테이블 또는 사전 계산 된 보고서를 만드는 것이 매우 유용 할 수 있습니다.
더 많은 하드웨어 프로비저닝을 의미하지만 캐싱 솔루션을 구현하기 때문에 이것이 오래 걸릴 수 있습니다. 가장 빠른 쿼리는 결코 만들지 않는 쿼리입니다 .
그것들은 단지 몇 가지 아이디어입니다. 결론은 튜닝만으로는 여기서 문제를 해결하지 못하고 하드웨어만으로는 문제가 해결되지는 않지만 대부분의 즉각적인 문제는 완화 될 수 있다는 것입니다. 그것이 실제로 진행되는 방법입니다. 단기적으로는 문제에 하드웨어를 던져서 불을 끄고 장기적으로 문제를 조정하여 근본 원인을 최대한 잘 해결하십시오.