하드웨어 (CPU) 증설 후 스토리지 성능 저하

이번 사례는 DB서버 CPU 증설 및 볼륨 작업 후 스토리지가 느려졌다는 고객 불만에 대해 원인 분석 및 진단한 결과를 공유한다.

 

사전 작업

• AP 및 DB 서버 CPU 및 Memory 증설
  AP : 28 → 32 core
  DB : 48 → 64 core
• Oracle용 Volume resize

 

현상 (고객 의견)

• 스토리지 볼륨 사이즈 증가 후 write latency 약 2배 증가 (5 → 9.5ms)
• 피크 타임 시, DB의 log file sync 평균 대기시간 약 30% 증가 (2.97 → 3.92ms)

 

원인 분석

• 서버/볼륨 작업 전후의 AWR을 제공받아 분석함
  9/15 : CPU, Mem 증설 전
  9/23 : CPU, Mem 증설 후
  9/24 : 볼륨 사이즈 증가 후
• 일일 평균 및 일 피크 타임 시 실행 횟수 상위 SQL 분석

 

<1 Day (24시간) 기준 실행 횟수 상위 SQL>

★ 시사점 : CPU 증설 이후 신규 업무 추가

 

 

<Peak time 기준 실행 횟수 상위 SQL>

★ 시사점 : CPU 증설 이후 신규 업무 추가 & 기존 업무 삭제

 

분석 결과

• 9/15과 9/23 사이, 고객 업무 추가/삭제 등 변경 관찰됨
• 추가 업무 : Rxx_xxxx_xxxx_x
• 변경 업무 : Txxxxx2_xxx 내 일부 Query
• 삭제 업무 : Txxxxx9_xxx, Txxxxx0_xxx, Txxxxx1_xxx 내 일부 Query

 

* 부연 설명 ;

AWR 상에서 실행 횟수 상위 SQL은 대부분 조회(select)가 차지하므로 update 또는 insert는 찾기 어려울 뿐, 변경 업무에 포함되었을 수 있음

 

최종 결론

9월 15일 이후 시스템 성능 변화는 기존 업무의 추가/변경/삭제로 인해 영향을 받았다고 보는 것이 매우 타당함

 

이후 고객 확인 결과, 하드웨어 증설이 9/19에 있었고, 이때 내부 처리 프로세스 증가에 따른 프로그램 변경 작업이 함께 이루어졌음을 확인함

볼륨 사이즈 증가 후 Latency가 커졌다는 것은, 그 날 이후의 성능 모니터링 결과가 그러했기 때문인 것으로 판단됨 (사양 증설 직후의 데이터를 보았으면 역시 동일했을 것임)

 

 

추가 성능 개선

• FC 상태 점검을 통해 No Command Resource Count : 159240520999108608 확인

  This counter is incremented everytime the OS doesn't have enough resources to handle the I/O and needs to wait for a system resource before being able to submit the I/O to the array (이 카운터는 OS에 I/O를 처리할 충분한 리소스가 없고 I/O를 어레이에 제출하기 전에 시스템 리소스를 기다려야 할 때마다 증가)

• "No Command Resource Count"가 꾸준히 증가하면 디스크 드라이버 (애플리케이션으로 인해)가 FC 어댑터에서 동시에 처리할 수 있는 것보다 더 많은 명령을 전송하고 있음을 나타냄. 0이 되어야 베스트임
• 이 값은, num_cmd_elems가 너무 낮아서 I/O가 리소스를 기다리는 동안 일시적으로 차단되었음을 나타내며, 이 값이 0이 아닐 경우, num_cmd_elems를 증가시키면 I/O 서비스 시간을 향상할 수 있음을 의미함
• So, FC HBA 파라미터 튜닝
  - num_cmd_elems : 1024 → 4096 (range : default 200 ~ 4096)
    (Maximum number of pending requests in a Fibre Channel adapter)
  - max_xfer_size : 0x100000 → 0x1000000 (range : default 0x100000 ~ 0x1000000)
    (The maximum transfer size of I/O requests)

• 명령어 :

  for i in 0 2 4 6

  do

  chdev -l fcs$i -a num_cmd_elems=4096 -a max_xfer_size=0x1000000 -P

  done

• 튜닝 후, write latency가 이전 수준 (9.5→5ms)으로 크게 감소함 (IOPS 수준은 동일)

 

 

Hidden Facts

1. 고객 정보 시스템은 오래전부터 FC Adapter 레벨의 심한 I/O Bottleneck을 겪고 있었다.
2. 변경된 업무의 최적화 필요성은 잔존한다.

 

 

* 참고 : www.ibm.com/support/knowledgecenter/ko/ssw_aix_71/performance/disk_disk_adapter.html