ORACLE 11g Troubleshooting - log file sync Waits v1.0
|
13.05.08 |
v1.0 |
|
|
|
|
|
|
|
|
|
l 메타링크 문서 ID 1376916.1 를 번역 했음을 알립니다.
1. What is a ‘log file sync’ wait?
User commit 이 발생하면 session 의 redo 정보는 메모리에서 redo logfile 로 씌어져야 한다.
커밋 시점에, 유저 세션은 LGWR 에게 log buffer 를 redo log file 에 쓰도록 지시한다.
LGWR 가 쓰기를 마치면, 이를 user session 에 알린다. LGWR 가 쓰기를 마치고 redo changes 가
전부 디스크에 안전하게 쓰여졌음을 확인하고 알리기까지 user session 은 ‘log file sync’ 를 대기한다
2. What should be collected for initial diagnosis of ‘log file sync’ waits?
l 비교를 위해 비슷한 기간, 시기의 log file sync 가 발생하지 않은 AWR report
l log file sync 가 발생했을 때의 AWR report
l LGWR trace file
LGWR trace file 은 ‘log file parallel wait’ 가 높을 때 경고메시지를 보여준다.
3. What causes high waits for ‘log file sync’?
‘log file sync’ 이벤트는 user process 가 LGWR 에게 redo information 을 쓰도록 보고 할 때와 LGWR 가
redo log buffer 를 disk 에 쓴 다음 user process 에게 보고할 때 그리고 user process 가 대기에서
빠져나올 때 발생할 수 있다.
4. Issues affecting LGWR’s IO performance
- Compare the average wait time for ‘log file sync’ to the average wait time for ‘log file parallel write’
‘log file parallel’ write 는 redo 에 대한 실제 쓰기연산이 일어날 때 LGWR 가 대기하는 wait event 이다.
만약 ‘log file parallel write’ 시간에 대해 ‘log file sync 시간의 비율이 높다면, 대부분의 대기시간은 IO 때문이다.
( log file parallel write 시간이 더 길다면) 20 millisecond 이상이 걸린다면 IO subsystem 을 확인한다.
Recommendations
빠른 I/O 장치를 사용. 반면 메타링크에서는 SSD 를 쓰지 말라 한다.
(log file sync 에 대한 내구력 때문, 문제가 심화되는 걸 깨닫지 못하기 때문? 이라는 뉘앙스)
다른 프로세스가 redo log 가 위치한 디바이스의 I/O 자원을 사용하는지 확인
log_buffer 가 너무 크지 않은지 확인한다. 너무 큰 log_buffer 는 flush 가 발생했을 때
wait 가 길어지는 역효과를 가진다.
- Check LGWR Traces
‘log file parallel write’ 평균 시간이 정상 범주의 짧은 시간이라더라도, Write time 의 peak 가 있을것이고,
이로인해 ‘log file sync’ 에 영향을 줄 수 있다. 10.2.0.4 부터 log file 에 대한 쓰기가 500ms 를 넘으면
LGWR trace 에 메시지가 쓰인다. 이는 상당히 높은 임계치로 메시지가 적다 해서 문제가 없다는 걸
의미하는 것은 아니다.
- Check to see if redo logs are large enough
‘log file sync’ 은 redo logs 가 다음의 log 로 변경될 때 next log 가 시작되기 전에 모든 것이 쓰여졌는지
확인하기 위해 매번 수행된다.표준 권고는 많더라도 15~20 분에 한번 스위칭하는 것이다.
만약 이보다 더 많이 스위칭이 일어난다면, 더 많은 ‘log file sync’ 더 많이 일어나고 개별 세션에 대해
더 대기한다는 것을 의미한다.
5. Excessive Application Commits
과도한 commit 은 ‘log file sync’ 를 유발하는 log buffer 로부터 redo logs 로의 redo flush 를 일으킨다.
높은 commit rate 를 식별하기 위해서는, ‘log file sync’ 에 대한 평균 대기시간이 ‘log file parallel write’ 에 대한 대기시간보다
훨씬 큰 경우로, 이는 많은 시간을 redo 가 쓰여지길 대기하기 때문으로 IO 로 인한 문제가 아니라는 것이다.
추가적으로 ‘log file sync’ 를 대기하는 평균 시간이 낮지만, 대기횟수가 높은경우, 이는 application 이 너무
빈번히 commit 함을 의미한다.
- Compare the average user commits and user rollbacks to user calls
user calls / (user commits + user rollbacks) 이 30보다 작으면 commit 이 빈번하다는 것을 의미한다.
6. Adaptive Log File Sync
11.2 에서 소개 된 기능으로, _use_adaptive_log_file_sync 를 사용해 기능을 컨트롤한다. 11.2.0.1 과 11.2.0.2 에서는
기본값을 false 로 가져가나, 11.2.0.3 에서는 default 값이 true 이다.
기능이 활성화 되어 있으면 ORACLE 은 두 가지 메소드에서 스위칭할 수 있다.
l Post/wait, redo log 에 대한 쓰기가 완료되었음을 알리는 기존의 방식
LGWR 가 명시적으로 commit 이 완료되기를 기다리는 모든 프로세스에게 알림
l Polling, Foreground process 가 LGWR 가 쓰기를 마쳤음을 체크하는 새로운 방법
Foreground processes sleep and poll to see if the commit is complete.
이 방식의 장점은 LGWR 가 commit 의 완료를 기다리는 많은 프로세스에 대한 알림으로부터 자유로워진다는 것이다.
기본적으로 LGWR 는 Post/wait 를 사용하면서 알고리즘에 의해 polling 이 나은지를 판단한다. 높은 로드에서는
Polling 방식이 더 나은 성능을 보일 수 있다. 왜냐하면 Post/wait 는 scale(확장, 규모) 이 어렵기 때문이다.
반대로 로드가 낮은 상황이라면 post/wait 가 더 나은 성능을 보이며 polling 보다 더 나은 응답속도를 보여준다.
Oracle 은 내부 통계정보에 의해 어떤 방법이 더 나은지 판단한다.
7. References
a. Troubleshooting : “log file sync” Waits [ID 1376916.1]
b. Waits for “log file sync” with Adaptive Polling vs Post/Wait Choice Enabled [ID 1541136.1]
