EXT Filesystem 성능 향상을 위한 Mount Option 적용 여부

현재 기업 내 많이 도입되는 Red Hat 계열의 Linux(RHEL, CentOS, Oracel Linux 등)에서 보편적으로 사용 중인 파일 시스템을 꼽으라면 ext(extended file system, 확장 파일 시스템)일 것입니다.

 

하지만, 최근 x86/Linux기반 가상화, 클라우드 시장으로의 다양한 Workload를 요구하는 시점의 server환경에서는 ext파일 시스템의 한계점(확장성, 입출력 등)이 분명히 존재하였고 이를 타개하고자 많은 노력이 있었던 걸로 알고 있습니다.

 

초기 ext filesystem은 기업에서 적용하고자 함에 있어 기존 메인프레임과 유닉스의 성능과 안정성을 두고 많은 비교대상이 되었고 적용 여부를 두고도 많은 화제가 되었던 시절이 있었습니다.

 

제가 아래에서 말하고자 하는 요점은 다양한 환경(가상화, 클라우드, 물리서버 등)에서 사용되고 있는 ext filesystem 성능 문제로 고민하는 분에게는 또 다른 질문과 고민이 될 수 있을 것이라고 생각해서 작성해보았습니다.

이는 어쩌면 아주 단순한 출발점에서 시작한 생각일수고 있으며 다시금 생각해볼수 있는 시발점일 수 있습니다.

 

먼저,

이미 구글이나 블로그 등을 통해 알려진 ext파일시스템의 다양한 마운트 옵션 중에 성능 향상에 도움될 만한 옵션은 다음과 같습니다.

 

[각 옵션 설명]

- noatime : filesystem meta정보에 file의 access time 기록하지 않음.

- nodiratime : fiesystem meta정보에 directory의 access time기록하지 않음.

- nobarrier : fsync 기능을 사용하지 않도록 설정.

- data=writeback : 메타 데이터가 journal 되지만 데이터는 journal 되지 않음.

 

아래 참고문헌을 통해 확인해보면 기본적으로 안정성을 중점으로 두기 보다는 성능 향상을 초점을 맞춘 옵션이라 생각합니다. 이에 실제로 테스트를 통해 어떠한 부분으로 성능 향상을 주는지와 이에 따른 문제로 인해 선택할 수 있는 글귀를 함께 작성해보았습니다.

 

[참고문헌]

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/writebarrieronoff

http://en.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec73.html

The atime and noatime attribute

https://rhlinux.tistory.com/38

Write Barrier란 무엇인가?

 

1. ext filesystem mount option 적용 방법

[수정 내역]

/etc/fatab의 각 마운트 구문중, noatime, nodiratime, nobarrier, data=writeback 옵션을 추가

 

[적용 방법]

/dev/sda1 장치에는 위 옵션을 적용 /data1 디렉토리에 마운트를 하였고, /dev/sdb1 장치에는 기본 default 옵션을 적용되도록 옵션을 설정을 하였습니다.

/dev/sda1               /data1                  ext4    noatime,nodiratime,nobarrier,data=writeback     0 0 /dev/sdb1               /data2                  ext4    defaults        0 0

mount 명령어로 확인하면 아래와 같이 각각 다른 옵션이 적용된 것을 확인할 수 있습니다.

# mount | grep /data /dev/sda1 on /data1 type ext4 (rw,noatime,nodiratime,seclabel,nobarrier,data=writeback) /dev/sdb1 on /data2 type ext4 (rw,relatime,seclabel,data=ordered)

 

2. 파일 시스템 I/O 테스트를 통한 R/W 성능 방법

Disk/Storage 성능 테스트는 가장 일반적으로 접근성이 높고 즉시 테스트가 가능한 dd 명령어를 통해 수행하였으며 각각의 수행 시 conv옵션을 다르게 지정하여 3번을 수행, 평균치를 내도록 하였습니다.

 

해당 옵션에 대한 설명은 아래 URL를 참고하십시오.

https://www.computerhope.com/unix/dd.htm

Linux dd command help and examples

[dd 명령어를 옵션별 수행 스크립트]

#!/bin/bash iostat -tkx 1 > iostat.log & echo ""                                     | tee     datestamp.log echo "$(date +%H:%M:%S) ; 1. Start"         | tee -a  datestamp.log sleep 2; sync; sleep 5   ; echo 3 > /proc/sys/vm/drop_caches echo "$(date +%H:%M:%S) ; 2. Create"        | tee -a datestamp.log dd if=/dev/zero of=test.file bs=128k count=1000 echo "$(date +%H:%M:%S) ; 3. Done"          | tee -a datestamp.log sleep 2; sync; sleep 5  ; echo 3 > /proc/sys/vm/drop_caches echo "$(date +%H:%M:%S) ; 3. Create w/sync" | tee -a datestamp.log dd if=/dev/zero of=test.file bs=128k count=1000 conv=fdatasync echo "$(date +%H:%M:%S) ; 4. Done"          | tee -a datestamp.log sleep 2; sync; sleep 5  ; echo 3 > /proc/sys/vm/drop_caches echo "$(date +%H:%M:%S) ; 5. Recreate"      | tee -a datestamp.log dd if=/dev/zero of=test.file bs=128k count=1000 conv=nocreat, notrunc echo "$(date +%H:%M:%S) ; 6. Done"          | tee -a datestamp.log sleep 2; sync; sleep 5  ; echo 3 > /proc/sys/vm/drop_caches echo "$(date +%H:%M:%S) ; 7. End"           | tee -a datestamp.log rm -f test.file killall5 iostat

 

3. 디스크 장치별 R/W IO테스트 수행

[root@~ data2]# ./iotest.sh 21:01:58 ; 1. Start 21:02:05 ; 2. Create 1000+0 records in 1000+0 records out 131072000 bytes (131 MB) copied, 0.1132 s, 1.2 GB/s 21:02:05 ; 3. Done 21:02:14 ; 3. Create w/sync 1000+0 records in 1000+0 records out 131072000 bytes (131 MB) copied, 1.44554 s, 90.7 MB/s 21:02:15 ; 4. Done 21:02:22 ; 5. Recreate 1000+0 records in 1000+0 records out 131072000 bytes (131 MB) copied, 0.0868156 s, 1.5 GB/s 21:02:22 ; 6. Done 21:02:31 ; 7. End [root@~ data2]# cd /data1/   [root@~ data1]# ./testio.sh 21:02:52 ; 1. Start 21:02:59 ; 2. Create 1000+0 records in 1000+0 records out 131072000 bytes (131 MB) copied, 0.120887 s, 1.1 GB/s 21:02:59 ; 3. Done 21:03:06 ; 3. Create w/sync 1000+0 records in 1000+0 records out 131072000 bytes (131 MB) copied, 0.190332 s, 689 MB/s 21:03:06 ; 4. Done 21:03:13 ; 5. Recreate 1000+0 records in 1000+0 records out 131072000 bytes (131 MB) copied, 0.0919899 s, 1.4 GB/s 21:03:13 ; 6. Done 21:03:22 ; 7. End

* 평균 결과 수치

		평균 결과(3회 수행)
장치명	마운트 옵션	Create	w/sync	Recreate	Read
/dev/sda1	noatime,nodiratime,nobarrier,data=writeback	1.3 GB/s	650 MB/s	1.4 GB/s	3 GB/s
/dev/sdb1	defaults	1.1 GB/s	85 MB/s	1.3 GB/s	3 GB/s

위 수행 결과로 얻은 수치로 보아 w/sync(conv=fdatasync) 파일 쓰기 측면에서 많은 성능 개선 효과가 있는 것으로 보입니다. 위 내용만 보면 Read 성능에 대한 개선 효과는 거의 없다고 보이네요.

수치로만 보면 Read성격이 강한 서비스에는 적용이 무의미하고 작은 단위의 파일 쓰기가 빈번한 서비스의 경우에는 옵션 설정만으로 많은 개선이 있을 것으로 판단됩니다.

 

아마 위 옵션은 대부분의 리눅스 사용자라면 한 번쯤은 들어봤거나 사용해본 적이 있는 옵션일 것입니다.

그리고 논란(?) 여지가 있는 부분이 아마도 저널링 모드에 대한 옵션 적용 부분일 것으로 생각됩니다.

 

위 테스트를 진행 중에 있어 참고할만한 글귀가 있어 첨부합니다.

https://help.marklogic.com/Knowledgebase/Article/View/209/0/linux-filesystem-tuning---performance-datawriteback-vs-dataintegrity-dataordered

Linux FileSystem Tuning - Performance (data=writeback) vs DataIntegrity (data=ordered) | MarkLogic Support

Linus Torvalds comments on 'data=writeback'
"it makes things much smoother, since now the actual data is no longer in the critical path for any journal writes, but anybody who thinks that's a solution is just incompetent.  We might as well go back to ext2 then. If your data gets written out long after the metadata hit the disk, you are going to hit all kinds of bad issues if the machine ever goes down." 

 

토발즈가 "data=writeback" 에 대한 견해를 밟힌 내용을 인용하면 "최근의 데이터는 더 이상 저널 쓰기의 중요한 경로에 있지 않기 때문에 적용이 얼마든지 가능하게 되었다. 그러나 이 옵션을 마치 솔루션이라고 생각하는 것은 옳지 않는다.

우리는 저널링을 제공하지 않던 ext2로 되돌아 갈 수도 있다. 데이터가 쓰여지면 메타 데이터가 디스크에 저장된 후에도 컴퓨터가 다운되면 모든 종류의 나쁜 문제들이 발생할 수 있기 때문이다."

 

개인적인 소견으로 말하자면 최근 x86/Linux 서버의 안정성과 시장 내 Ecosystem 구축 등으로 인해 더 이상 운영체제의 소프트웨어적인 부분으로 성능의 개션효과가 크지 않다고 생각하였습니다. 그리고 커널, 파일 시스템 자체로 문제보다는 side-effect로 인해 발생되는 문제가 훨씬 많다고 생각됩니다.

 

물론 다시금 생각해보면 단순히 운영체제 옵션만으로 성능 개선 효과를 보려는 무식한(?) 생각은 없어야 한다고 생각합니다. 하지만 최근 제가 겪었던 다양한 환경 내 자사 내 클라우드 기반의 플랫폼 서비스의 성능 문제로 인해 개선 포인트가 하나라도 있다고 가정한다면 이 또한 적용해볼 만한 가치가 있다고 생각합니다.

향후 어쩌면 Red Hat계열의 버전에서는 ext 파일 시스템은 향후 기업 내에서 볼 수 없는 존재(?)가 될 수도 있습니다. 이 시점에 이런 고민은 무모한 생각일지도 모른다고 생각되네요.

 

마지막으로 여러분이 사용하고 있는 다양한 인프라 환경에 성능 개선점이 될 수 있는 파라미터 적용 여부를 결정하는 것은 그 서비스를 책임지고 운영하는 부서가 모여 결정할 수 있는 문제라 생각합니다.

충분한 테스트를 거쳐 안정성과 성능 두 마리 성과를 얻을 수 있도록 노력해봅시다.

 

 

그럼 20000...