sqlserver 의 전형 적 인 기다 림
3971 단어 sqlserver 대기
첫 번 째 대기.memory 대기.
아침 에 한 사용자 가 RDS 인 스 턴 스 가 매우 느리다 는 피드백 을 받 았 습 니 다.sqlserver 활동 세 션 모니터(active monitor)의 waiting tasks(my sql 과 유사 한 thread running)를 관찰 하면 10 여 w 의 대기 임 무 를 볼 수 있 습 니 다.데이터 베 이 스 는 현재 비교적 큰 병목 이 나 타 났 음 을 확인 할 수 있 습 니 다.이 어 resource waits 를 통 해 데이터 베이스 에 대량의 memory 메모리 가 기다 리 고 있 음 을 볼 수 있 습 니 다.
memory 자원 이 기다 리 고 있 는 것 을 보고 즉시 사용자 애플 리 케 이 션 을 복원 하기 위해 메모 리 를 조정 하려 고 합 니 다.이 인 스 턴 스 가 24G 인 것 을 발 견 했 습 니 다.os 의 남 은 메모리 가 비교적 많은 것 같 습 니 다.그래서 메모 리 를 36G 로 늘 렸 습 니 다.resource waits 가 memory 에서 기다 리 고 있 는 것 을 발 견 했 습 니 다.이 럴 때 cpu 사용률 이 급 격 히 높 아 졌 습 니 다.90%정도(이전 에는 10%정도 기다 림)에 달 했 습 니 다.이렇게 근본 적 인 문 제 를 해결 할 수 없 기 때문에 recent expensive query 를 통 해 다음 sql 의 논리 적 읽 기 가 매우 높 고 실행 이 매우 빈번 하 다 는 것 을 알 게 되 었 습 니 다.
SELECT * FROM RefundOrder_Message messages0_ WHERE messages0_.Order_Id=@p0;
메모리 대기 sql 을 다음 과 같이 얻 을 수 있 습 니 다.
SELECT st.text FROM sys.dm_exec_query_memory_grants req CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as ST where req.grant_time is NULL or req.granted_memory_kb is NULL
The columns grant_time and granted_memory_kb will be NULL for those queries which are waiting to get their requested memory
sp_helpindex RefundOrder_Message
이 테이블 에 홈 키 인덱스 가 하나 밖 에 없 음 을 발 견 했 습 니 다:
색인 만 들 기:
create index ind_RefundOrder_Message_order_id on RefundOrder_Message(Order_Id);
두 번 째 대기:latch 대기
색인 을 추가 하면 memory 의 기다 림 은 즉시 사라 지지 만 resource waits 의 기다 림 은 lock 으로 변 합 니 다.
아래 내부 보 기 를 통 해 다음 호출 에 대기 가 있 음 을 알 수 있 습 니 다.
SELECT ss.host_name, req.blocking_session_id,req.wait_type ,req.wait_time ,req.wait_resource ,req.transaction_id ,st.text FROM sys.dm_exec_requests req CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as ST
cross apply sys.dm_exec_sessions ss where req.status =N'suspended' and ss.session_id=req.session_id;
다른 세 션 을 막 는 sql 가 져 오기:
(@p0 int,@p1 nvarchar(4000),@p2 bit)
SELECT TOP (@p0) this.* FROM ViewSalesOrder this_ WHERE this_.MemberCode = @p1 and this_.IsObsolete = @p2 ORDER BY this_.OdCode desc;
보기 ViewSalesOrder 는 매우 핵심 적 인 보기 로 주문,주문 메시지,주문 발송 등 여러 업무 논리 와 관련 되 어 있 습 니 다.조회 조건 에 membercode 를 점포 의 이름 으로 대 입 하여 특정한 점포 의 주문 서 를 조작 할 수 있 습 니 다.
ViewSalesOrder 보기 의 정 의 를 통 해 membercode,IsObsolete,OdCode 는 salesOrder 표 의 세 필드 로 salesOrder 에 해당 하 는 색인 이 없 음 을 확인 하고 다음 과 같은 색인 을 추가 합 니 다.
create index ind_salesOrder_member on salesOrder(membercode,IsObsolete,code)；
색인 을 추가 한 후 데이터베이스 의 waiting tasks 가 떨 어 지고 batch requests 가 향상 되 었 습 니 다.
세 번 째 대기:lock
세 번 째 기다 림 은 흔히 볼 수 있 는 기다 림 입 니 다.흔히 볼 수 있 는 상황 은 삭제 합 니 다.업데이트 할 때 조건 에 맞 는 색인 이 없어 잠 겨 있 는 기록 범위 가 너무 커서 다른 세 션 요청 을 막 습 니 다.
사용자 가 압력 측정 을 할 때 업데이트 문 구 를 매우 느리게 실행 하여 전체 시스템 이 걸 리 는 것 을 발견 했다.
update DD_ShenHe set ZF = 0 where zf is null;
dd 보기shenhe 표 위의 색인:
표 에 zf 필드 의 색인 이 없 는 것 을 볼 수 있 습 니 다.이 표 는 모두 400 w 의 데이터 가 있 습 니 다.zf 는 null 의 8000 개가 있 기 때문에 zf 필드 에 색인 을 추가 하 는 것 이 적당 합 니 다.
Create index ind_dd_shenhe_zf on dd_shenhe(zf);
색인 을 추가 한 후 시스템 이 정상 으로 돌 아 왔 습 니 다.
좋은 웹페이지 즐겨찾기
