우리는 웹사이트를 준비하는 데 사용하는 전용 서버(테스트 서버)를 가지고 있습니다. 서버 성능이 정말 나빠져서 정기적으로 서버를 다시 시작해야 합니다. 성능이 좋지 않을 때 작업 관리자에서 프로세스와 메모리를 확인했지만 모든 것이 정상인 것 같습니다.
우리는 콘텐츠 관리 시스템을 사용하고 있으며 이 CMS의 관리 섹션을 사용할 때 항상 성능 저하를 발견합니다. 이는 CMS가 생성하는 DB 호출과 관련이 있을 수 있다고 생각하게 만듭니다.
이것이 실행 가능하게 들리나요? 이것을 테스트하는 방법에 대한 다른 제안이 있습니까?
미리 감사드립니다...
답변1
이것이 실행 가능하게 들리나요?
예.
이것을 테스트하는 방법에 대한 다른 제안이 있습니까?
성능 점검. 성능은 CPU에만 국한되지 않습니다. DB가 문제라고 생각한다면 IO 바인딩일 수 있습니다. 이 경우 디스크 대기 시간/활동 비율이 급등하게 됩니다. 디스크 성능 카운터를 확인하세요. 특히 IO 작업을 수행하는 경우 CPU는 IO가 완료될 때까지 기다리기 때문에 기본적으로 프로세스를 제공하지 않으므로 CPU 성능이 저하됩니다.
일반적으로 데이터베이스가 점점 더 바빠지면 상당한 IO 예산이 필요하며 이는 상당한 양의 디스크를 의미합니다. 여기에는 현재 6개의 10k RPM 디스크를 사용하는 데이터베이스가 있으며 곧 데이터용으로만 8개로 업그레이드됩니다. 일반적으로 저렴한 전용 서버는 IO 예산이 정말 형편없는 경우가 많습니다. 느린 대형 최종 사용자 디스크 중 일부는 빠른 하위 시스템을 만들지 못합니다. 이는 일부 시나리오에서는 꽤 잘 작동하지만 결국에는 과부하가 발생할 수 있습니다.
답변2
TomTom이 말했듯이 이는 시스템이 CPU 바인딩이 아닌 IO 바인딩임을 나타내는 거의 확실합니다. 근본 원인은 CMS 뒤의 증가된 로드 DB일 수도 있고 다른 것일 수도 있지만 어떤 경우에도 PerfMon에는 디스크 하위 시스템이 원인인지 확실히 알 수 있는 몇 가지 유용한 카운터가 있습니다.
\논리디스크\평균. 디스크 초/읽기 및 \LogicalDisk\Avg. 디스크 초/쓰기
읽기 및 쓰기 IO 작업에 대한 기본 대기 시간 수치는 낮을수록 좋습니다. 이 숫자가 약 15ms를 초과하면 서버 성능이 눈에 띄게 저하됩니다.
\LogicalDisk\Disk Bytes/Sec 및 \LogicalDisk\Disk Reads/Sec 및 이는 전체 디스크 처리량을 알려줍니다. 이러한 속도는 처리량만으로 인해 또는 읽기/쓰기 패턴에 대한 IOPS 제한에 도달했기 때문에 디스크 하위 시스템의 최대 용량을 포화시킬 수 있습니다. 하지만 예측 가능한 IO 패턴이 있다고 100% 확신하지 않는 한 이들로부터 중요한 것을 추론하기 어려울 수 있습니다. 여기에서 관찰할 특정 숫자를 제공할 수 있는 유용한 방법은 없지만 단일 SATA 디스크에서 50-100MBytes/sec 이상을 볼 수 있다면 예상할 수 있는 만큼 좋은 것입니다. 더 빠른 서버 디스크(10k, 15K, SSD)는 이를 초과할 수 있으며 SAN 연결 스토리지는 충분한 비용을 지불한다면 원하는 모든 것을 제공할 수 있습니다. 작은 임의 IO(일반적인 DB 작업)의 경우 이 숫자는 항상 낮으며 많은 것을 알려주지 않습니다.
\LogicalDisk\Disk 쓰기/초, \LogicalDisk\Disk 읽기/초 및 \LogicalDisk\Disk 전송/초 이는 초당 개별 IO 작업 수와 읽기/쓰기 비율을 알려줍니다. 이와 관련하여 회전 디스크는 상당히 제한적입니다. 7.2K SATA 디스크는 초당 약 70-80 IO를 유지할 수 있고, 10K 디스크는 이를 100-150 범위로 밀어올리고, 15K는 200+가 됩니다. SSD는 한 단계 또는 두 단계 더 높을 것입니다. RAID 그룹은 읽기에 대해 이를 상당히 선형적으로 증가시키지만 쓰기에는 2에서 5 사이의 패널티가 발생합니다. 예를 들어 3개 드라이브 RAID 5 팩(쓰기 패널티 4)은 단일 드라이브보다 약 25% 적은 쓰기 IO를 지원합니다.
대기 시간이 위험한 영역(예: 15ms 초과)으로 증가하는 동안 이 숫자가 증가하는 경향이 있다면 이는 보고된 특정 수치에 관계없이 디스크가 IOPS 제한에 도달했다는 강력한 표시입니다.
\LogicalDisk\분할 IO/초 이를 통해 얼마나 많은 IO 요청으로 인해 여러 작업이 발생하는지 알 수 있으며 조각화가 IO 활동에 얼마나 영향을 미치는지 알 수 있습니다.
PhysicalDisk: 현재 디스크 큐 길이 및 PhysicalDisk: 평균. 디스크 대기열 길이. 이는 물리적 디스크 수준에서 완료되기를 기다리고 있는 미해결 IO 수를 알려줍니다. 단일 디스크에서 2개 이상이거나 디스크가 구성된 RAID 그룹의 디스크 수를 초과하는 경우 적시에 완료할 수 있는 것보다 더 많은 IO를 디스크에 푸시할 수 있습니다. 이것이 별로 중요하지 않은 시나리오가 있지만 대기 시간이 짧은 디스크 IO(메모리 캐싱이 디스크의 약점을 커버할 수 없는 데이터베이스)가 필요한 시스템에는 정말 큰 문제가 될 것입니다. 첫 번째는 순간적인 읽기이므로 지속적으로 높거나 %disk 시간 카운터에 맞춰 변경되는 경우에만 걱정하세요. 평균 디스크 큐 길이가 너무 길면 문제가 있는 것입니다.
PhysicalDisk: 디스크 시간 % % 디스크 시간은 디스크 사용량을 알려줍니다. 100%에 가까워지면 모든 추가 IO가 대기열에 들어가는 경향이 있기 때문에 시스템이 해당 디스크에 의존하는 다른 작업을 수행하도록 하는 데 어려움을 겪게 됩니다. 100%보다 훨씬 낮은 숫자라도 문제가 있음을 나타낼 수 있으며, 이 수치가 높거나 증가하고 있고 현재 디스크 대기열 길이가 높다면 이는 디스크 용량을 초과하는 IO 로드를 명확히 나타내는 것입니다. 이 숫자는 실제로 이상한 방식으로 계산되므로 결과적으로 RAID 성능을 분석하는 데 그다지 유용하지 않을 수 있습니다.
이 Technet 블로그 기사이러한 카운터 중 일부와 이를 사용하여 문제를 식별하고 해결 방법을 설정할 수 있는 일부 시나리오에 대해 훨씬 더 자세히 설명합니다.
답변3
작업자 프로세스를 자주 재활용하도록 웹앱 풀을 구성하는 것을 고려해 볼 가치가 있습니까?