[CentOS 6.X] DB Query 실행시 느림

[CentOS 6.X] DB Query 시 느림 증상 해결

  DB Query 시 현저히 느려지는 데는 여러가지 이유가 있을 수 있다. CPU 부하, Disk 속도의 저하 등 H/W 사양에 따라 영향을 받을 수도 있고, 드라이버 미설치, 커널 튜닝값의 상이, mysql 설정값의 상이, 디스크 스케쥴링 방식 상이 등 OS에서 발생하는 문제일 수도 있다. 이 고객의 경우 물리호스팅 환경에서 클라우드 기반의 시스템으로 이전하며 발생한 실 사례이다. 물리 호스팅 사용 시에 SSD 기반의 E5606 CPU를 사용하고 있었고, OS의 경우 CentOS 5.3/mysql을 사용중이었다. 하지만 실제 물리호스팅 환경에서 클라우드 기반 시스템으로 이전하며 DB VM 구동시 발생한 실사례로, 클라우드 기반 시스템의 경우 E5-2670 V1, SSD Raid10이 구성된 PM서버에 DB VM을 Dedicated 하여 구성되었다.

정리하자면,

[기존 물리호스팅 환경]

E5606 / SSD / CentOS 5.3/mysql

-->

[클라우드 기반 환경]

E5-2670 V1, SSD Raid10 / CentOS 6.8/mysql

상위와 같이 서버의 사양이 변경되었다. 누가 보더라도 H/W의 사양은 높아졌고, OS 또한 더이상 yum repository를 지원하지 않는 5.3 -> 6.8로 상향되었다. 위의 사양을 보더라도 H/W 사양에 따른 DB 느림 증상이 원인일 가능성은 희박하다.

첫번째 문제는 드라이버 미설치였다. 실제 SSD Raid 구성된 PM서버의 Disk 성능 테스트에서 Write성능은 324MB/s의 속도를 보였으나, XenServer 기반에서 러닝중인 DB VM의 경우, Disk Write 성능이 212MB/s 의 속도밖에 보이지 않았다. 열심히 xen tool을 설치하고 다시 테스트 하였을 때 정상적인 속도를 보였다. 문제가 해결되었구나 싶었을 때, 아차 싶었다. DB 쿼리 실행시 튜플 2만개 이상을 가진 DB 테이블이 6개가 join 되었고, 다시금 성능이 떨어지는 것이었다.

OS version과 mysql version이 상이하였고, mysql 설정값의 경우 기존과 동일하였다. 이 때 문제를 야기할 수 있는 /etc/sysctl.conf 파일을 확인하였지만, 별다른 커널 튜닝의 흔적은 찾아보지 못했다.. 혹시나 하는 마음에 Disk BMT를 진행하였다.

1073741824 bytes (1.1 GB) copied, 3.29159 s, 326 MB/s [root@DB01 ~]#  [root@DB01 ~]#  [root@DB01 ~]#  [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 3.31254 s, 324 MB/s [root@DB01 ~]#  [root@DB01 ~]#  [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 3.40173 s, 316 MB/s [root@DB01 ~]#  [root@DB01 ~]#  [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 3.17768 s, 338 MB/s [root@DB01 ~]#  [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 4.75149 s, 226 MB/s [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out ---------------문제쿼리 진행------------------- 1073741824 bytes (1.1 GB) copied, 6.17193 s, 174 MB/s [root@DB01 ~]#  [root@DB01 ~]#  [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 6.266 s, 171 MB/s [root@DB01 ~]#  [root@DB01 ~]#  [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 6.22146 s, 173 MB/s [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 6.00452 s, 179 MB/s [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 6.26039 s, 172 MB/s [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 6.16185 s, 174 MB/s [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 6.18323 s, 174 MB/s [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 6.16354 s, 174 MB/s [root@DB01 ~]#  [root@DB01 ~]#  [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 6.08471 s, 176 MB/s [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 6.34997 s, 169 MB/s [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 6.37744 s, 168 MB/s [root@DB01 ~]#  ---------------10분 경과 이후------------------------ [root@DB01 ~]# ./write-test.sh  1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 3.15403 s, 340 MB/s

- write-test.sh 내용 확인

#!/bin/bash

sync; dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 oflag=direct; sync

위의 결과를 봐도 DB 쿼리 진행 후 Disk 의 성능이 현저히 줄어듬을 확인할 수 있다. Disk Scheduler 를 확인해보자.

[root@DB01 updates]# df -h Filesystem            Size  Used Avail Use% Mounted on /dev/mapper/VolGroup-lv_root                        50G  2.4G   45G   6% / tmpfs                 9.8G     0  9.8G   0% /dev/shm /dev/xvda1            477M   64M  388M  15% /boot /dev/mapper/VolGroup-lv_home                       384G  149G  216G  41% /home [root@DB01 updates]# df -h Filesystem            Size  Used Avail Use% Mounted on /dev/mapper/VolGroup-lv_root                        50G  2.4G   45G   6% / tmpfs                 9.8G     0  9.8G   0% /dev/shm /dev/xvda1            477M   64M  388M  15% /boot /dev/mapper/VolGroup-lv_home                       384G  149G  216G  41% /home [root@DB01 updates]# cat /sys/block/xvda/queue/scheduler  noop anticipatory deadline [cfq]  [root@DB01 updates]#

CentOS 6.8의 경우 cfq 방식의 디스크스케쥴링이 default로 적용중이다. 디스크 스케쥴러에 대한 자세한 설명은 아래 링크를 참조합니다,

http://www.mimul.com/pebble/default/2012/05/12/1336793032150.html

-I/O Elevator 종류

1. noop 스케줄러
- No Operation. 아무것도 하지 않는 스케줄러.
- 주로 지능형 RAID 컨트롤러있거나, SSD사용하거나, 반도체 디스크 등 성능 좋은 디스크를 사용할 경우 선택되어지는 스케줄러로 커널은 아무것도 하지 않는 것이 부하를 줄일 수 있다는 생각이 기저에 있다.

2. anticipatory(as) 스케줄러
- 발생되는 I/O 요청에서 향후 발생되는 I/O 요청의 위치를 예측하고 위치 떨어진 I/O 요청 처리를 중지하고 위치 가까운 I/O 요청을 처리하는 방식이다.
- 지연 시간을 줄이고 처리량을 향상하는 것.
- 전통적인 하드 디스크와 비슷한 구조이다.
- 입출력을 기다려 모아서 처리하는 성질이 있어 지연 시간은 나쁘게 될 가능성도 있다.

3. deadline 스케줄러
- I/O 대기 시간의 한계점(deadline)을 마련하고, 그것이 가까워 온 것부터 먼저 처리한다.
- 처리량보다 지연에 최적화된 스케줄링을 한다.
- 읽기 및 쓰기를 모두 균형있게 처리한다.
- 몇몇 프로세스가 많은 수의 I/O를 발생시키는 환경에 적합하다.
- 데이터 베이스의 파일 시스템에 많이 사용된다.

4. cfq(Completely Fair Queuing) 스케줄러
- 프로세스마다 I/O 대기열을 가지고 최대한 균등하게 예약을 한다.
- 많은 프로세스들이 세세한 I/O를 많이 발생시킬 때 사용하면 좋다.
- Fedora Core 커널 패키지의 기본이다.

위의 블로그에서 설명한 대로 SSD를 장착중인 PM의 디스크 스케쥴링 방식을 cfq -> noop 으로 변경하니 DB 느림 증상이 해결되었다.

----> 작업내용 1. 즉시 적용 echo 'noop'> /sys/block/xvda/queue/scheduler 2.1 grub.conf 내용 확인 [root@DB01 updates]# cat /boot/grub/grub.conf  # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE:  You have a /boot partition.  This means that #          all kernel and initrd paths are relative to /boot/, eg. #          root (hd0,0) #          kernel /vmlinuz-version ro root=/dev/mapper/VolGroup-lv_root #          initrd /initrd-[generic-]version.img #boot=/dev/xvda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.32-696.6.3.el6.x86_64)         root (hd0,0)         kernel /vmlinuz-2.6.32-696.6.3.el6.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD console=hvc0  KEYTABLE=us rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=VolGroup/lv_root rd_NO_DM rhgb quiet         initrd /initramfs-2.6.32-696.6.3.el6.x86_64.img title CentOS 6 (2.6.32-696.el6.x86_64)         root (hd0,0)         kernel /vmlinuz-2.6.32-696.el6.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD console=hvc0  KEYTABLE=us rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=VolGroup/lv_root rd_NO_DM rhgb quiet         initrd /initramfs-2.6.32-696.el6.x86_64.img [root@DB01 updates]#  2.2 grub.conf 수정하여 재부팅후에도 적용 grubby -update-kernel=ALL -args="elevator=noop"

이후 매우 화목한 주말을 보냈다고 한다. 하하하하하하하ㅏㅏㅏㅏㅏㅏㅏㅏㅏㅏㅏㅏ.....