SQL 2005에 프로덕션 DB 서버가 있습니다. 모든 것이 정상적으로 작동하지만 몇 주 후에 성능이 크게 저하됩니다. SQL Server를 다시 시작해야만 성능이 정상으로 돌아옵니다.
일부 배경 :
- 1200 개 이상의 데이터베이스 (주로 단일 테넌트, 일부 다중 테넌트)를 실행합니다. 멀티 테넌트로만 이사하는 것에 대해 강의하기 전에이 구조를 유지 해야하는 정당한 이유가 있습니다 ...
- RAM은 16GB입니다. 다시 시작한 후 SQL Server가 15GB 사용량으로 되돌아가는 데 시간이 오래 걸리지 않습니다.
- Active DB 연결은 약 80 개의 연결로, 프로세스 당 웹 서버 당 하나의 연결 풀이 있다는 점을 고려하면 상당히 건전합니다. 따라서 연결 누수 문제가 없습니다.
피크가 아닌 시간에 여러 가지를 시도했습니다.-DBCC DROPCLEANBUFFERS (CHECKPOINT 포함)를 실행하여 데이터 캐시를 지 웁니다. 효과가 없으며 RAM 사용을 지우지 않습니다.) -FREEPROCCACHE 및 FREESYSTEMCACHE를 실행하여 쿼리 계획 및 저장된 proc 캐시를 지우십시오. 효과가 없습니다.
실제 프로덕션 환경에서는 SQL Server를 다시 시작하는 것이 이상적이지 않습니다. 뭔가 빠졌습니다. 다른 사람이 이것을 겪고 있습니까?
업데이트 : 2012 년 4 월 28 일 여전히이 문제와 싸우고 있습니다. OS와의 경합을 배제하기 위해 SQL Server의 메모리를 10GB로 줄였습니다. 좁히는 데 가까워지고 있지만 다음 단계부터 도움이 필요합니다.
다음은 SQL Server를 다시 시작한 후 페이지 파일이 12.3GB와 12.5GB 사이에 있다는 것을 알았습니다. 며칠 동안 그런 식으로 유지됩니다. 전체 서버 스레드는 850에서 930 사이에서 중단됩니다. 또한 며칠 동안 안정적이고 일관성이 있습니다 (sqlserver는 트래픽에 따라 55에서 85까지 꾸준히 유지됩니다).
그런 다음 "이벤트"가 있습니다. 나는 이벤트가 무엇인지 전혀 모른다. 로그에서 볼 수 없으며, 요일이나 시간에 일관된 것을 볼 수 없지만 갑자기 모든 페이지 파일이 14.1 또는 14.2로 점프합니다. GB와 스레드가 1750에서 1785 사이로 이동합니다.
이런 일이 발생했을 때 성능을 검사하면 900 개가 넘는 스레드가 sqlserver입니다. sp_who2로 이동하여이 스레드가 어디에서 나오는지 확인합니다. 사용 된 80 개 정도의 DB 연결 만 있습니다.
그렇다면 누구든지 SQL 서버에서 나머지 900 개 스레드의 위치와 작업을 찾는 방법을 알고 있습니까?
업데이트 : 2012 년 6 월 1 일 여전히 문제와 싸우고 있습니다. 이 내용을 여전히 읽는 사람이라면 스레드가 점프하는 문제가 해결되었습니다. 이것은 자동화 된 ComVault 백업 소프트웨어로 인한 것입니다. 현재 데이터베이스를 백업하는 대신 더 이상 존재하지 않는 데이터베이스 (이전 데이터베이스 목록을 유지 관리하는 데이터베이스)를 백업하려는 스레드를 작성했습니다.
그러나 문제는 여전히 남아 있으며 매주 다시 시작해야하며 며칠 또는 몇 일이 걸립니다. 랙 스페이스 팀과 협력하여 조명을 비출 수 있는지 확인합니다.