Linux/Windows File System performance Check

Linux/Windows File System performance Check

최근에 캐미를 발생할 수 있는 좋은 대화를 이어갔다.

그중에 몇가지를 정리하여 올려보고자 한다. 그전에는 신경쓰지 않고 추천 하는 기본 설정을 활용하였는데, 이참에 정리하여 두면 추후에 좋을 것 같아 이렇게 남긴다.

Windows And Linux FileSystem

Windows는 크게 FAT16~FAT32로와 NTFS, 그리고 최근 REFS가 존재한다. FAT32는 단순 파일 시스템으로 Windows 95시절 많이 사용되었고, 현재는 거희 이용되지 않으며, NTFS가 대다수를 이룬다. FAT32의 최대 용량은 2TB(꽁수를 부리면 32TB까지 가능하지만, 추천하지 않는다)로 현재 사용하기에는 버겹다. NTFS는 FAT32의 문제점을 개선한 버전으로 최대 256TB까지 지원한다. Windows는 현재 NTFS를 주력으로 사용하다, 대용량과 NTFS의 기능을 개선한 REFS라는 파티션을 제공한다. 대용량이 필요하다면 REFS를, 일반적인 사용이라면 NTFS를 사용하기를 추천한다.

Linux는 EAT1~EAT4이 있으나, 대부분 EAT4를 최근 사용하고, 64비트로 EAT4보다 우수한 XFS 혹은 BTRFS가 사용된다. 다만 호환성 이나 대중적인 측면에서 성능 및 알맞은 크기를 제공하고 있어 EAT4가 대중적으로 많이 사용되지만, 최근 안정성이나 크기를 고려한다면 BTRFS, 혹은 XFS를 선택하는 것도 효율적일 것 같다.

다만 무조건 최신이 좋다기 보다는 파티션별 특징을 알고 사용하는 것이 좋을 것 같다.

NTFS

  • Maximum file name length: 255 Unicode characters
  • Maximum path name length: 32K Unicode characters
  • Maximum file size: 256 terabytes
  • Maximum volume size: 256 terabytes

REFS

  • Maximum file name length: 255 Unicode characters
  • Maximum path name length: 32K Unicode characters
  • Maximum file size: 35petabytes
  • Maximum volume size: 35petabytes

https://docs.microsoft.com/ko-kr/windows-server/storage/refs/refs-overview

XFS

  • Maximum file name length: 255 Unicode characters
  • Maximum path name length: 32K Unicode characters
  • Maximum file size: 8exbibytes
  • Maximum volume size: 8exbibytes

BTRFS

  • Maximum file name length: 255 Unicode characters
  • Maximum path name length: 32K Unicode characters
  • Maximum file size: 16exbibytes
  • Maximum volume size: 16exbibytes

각 파티션별 성능을 측정한 데이터는 신뢰 할 수는 없지만, 아래 사이트를 참고 하면 좋을 것 같다.

https://losst.ru/proizvoditelnost-btrfs-vs-ext4-vs-f2fs-vs-xfs-vs-ntfs-v-yadre-linux-4-7

만약 직접 파티션의 성능을 테스트하고자 한다면, 아래 코드를 이용하면 보다 효율적으로 활용할 수 있다.

소스의 원위치는 https://www.dropbox.com/s/viba8rzdq6uegsq/bench.py?dl=0 이다. 윈도우에서 사용하기 위해서는 파일 생성 경로와 생성과 삭제명을 변경해야 한다.

#!/usr/bin/python
# -*- coding: utf-8 -*-
 
filecount = 300000
filesize = 1024
 
 
import random, time
from os import system
flush = "sudo su -c 'sync ; echo 3 > /proc/sys/vm/drop_caches'"
 
randfile = open("/dev/urandom", "r")
 
print "\ncreate test folder:"
starttime = time.time()
system("rm -rf test && mkdir test")
print time.time() - starttime
system(flush)
 
print "\ncreate files:"
starttime = time.time()
for i in xrange(filecount):
    rand = randfile.read(int(filesize * 0.5 + filesize * random.random()))
    outfile = open("test/" + unicode(i), "w")
    outfile.write(rand)
print time.time() - starttime
system(flush)
 
print "\nrewrite files:"
starttime = time.time()
for i in xrange(int(filecount / 10)):
    rand = randfile.read(int(filesize * 0.5 + filesize * random.random()))
    outfile = open("test/" + unicode(int(random.random() * filecount)), "w")
    outfile.write(rand)
print time.time() - starttime
system(flush)
 
print "\nread linear:"
starttime = time.time()
for i in xrange(int(filecount / 10)):
    infile = open("test/" + unicode(i), "r")
    outfile.write(infile.read());
print time.time() - starttime
system(flush)
 
print "\nread random:"
starttime = time.time()
outfile = open("/dev/null", "w")
for i in xrange(int(filecount / 10)):
    infile = open("test/" + unicode(int(random.random() * filecount)), "r")
    outfile.write(infile.read());
print time.time() - starttime
system(flush)
 
print "\ndelete all files:"
starttime = time.time()
system("rm -rf test")
print time.time() - starttime
system(flush)

DD, HDPARM,IOZONE 명령어등을 이용한 성능 테스트도 가능하므로, 여러가지 방안으로 성능을 테스트해보자.

hdparm -tT /dev/sda1
dd if=/dev/zero of=speetest bs=1M count=100
dd if=/dev/zero of=speetest bs=1M count=100 conv=fdatasync
dd if=/dev/zero of=speedtest bs=64k count=3200 conv=fdatasync

https://www.slashroot.in/linux-file-system-read-write-performance-test

Windows And Linux File Block

두번째로 확인할 부분은 File System을 통해 크게 성능을 개선할 수 있는 방법은 무엇일까? Windows, Linux 공통으로 파일이 저장되는 블럭 크기가 아마 가장 기본적으로 파일의 성능에 연관성이 있을 것으로 보인다.

윈도우에서는 기본값으로 설정할 경우 데이터를 저장하는 블럭의 크기가 4096byte로 설정되어진다. 즉 데이터의 최소 단위가 4096byte로 설정되며, 4096byte로 설정할 경우 하나의 데이터 블럭당 4096byte를 소모하므로, 한번에 읽어드리는 블럭도 4096단위라고 할 수 있다. 따라서 하나의 읽어 드려야 하는 사이즈가 크다면, 블럭도 크게 생성하는 것이 유리 할 수 있다.

즉 저장하는 파일의 특성을 고려해서 사용하는게 좋을 것이다.

Hardware RAID, SSD 구성

아무래도 성능에 가장 큰 기능을 차지하는 부분은 Hardware RAID와 SSD 구성이라고 할 수 있다.

DISK는 기본적으로 병렬 구성을 진행하면, 빠른 성능을 보장한다. 보통 여러장의 디스크를 하나의 볼륨으로 구성하면 가장 좋은 성능이 나타나게 된다.

RAID 1로 구성하면 데이터를 저장할 때 복수의 디스크에 나누어 저장하기 때문에 보다 빠른 속도를 유지할 수 있다. 이외 RAID은 복구를 생각한 부분으로, 물리적 관점에서 이중화라고 할 수 있다. 데이터를 중복으로 저장함으로써, DISK에 문제가 발생하였을 때 문제를 최소화 해준다. 요약해보면 다음과 같다.

RAID 0 – 분배,(Striping)
RAID 1 – 복제,(Mirroring)

그래소 보통 중요한 서버의 경우 RAID10로 구성하여 RAID를 복제하고, 거기에 분배를 하는 방식으로 구성하게 된다. 따라서 RAID10로 구성하면 DISK의 실제 사용량은 절반이 된다.

그리고 SSD(solid-state drive)는 반도체를 이용하여 정보를 저장하는 장치이다. 반도체이다보니, 처리속도가 빠르다. 하지만 사용가능 수명도 짧기 때문에 주의해야한다. SMART라는 HARDDISK 관리 기능을 이용해 모니터링을 하는것을 추천한다.

SNMP를 통해 관리할 수 있는 방안이 정리된 글이 도움이 될 것 이다.

https://baptiste-wicht.com/posts/2013/12/zabbix-low-level-discovery-cores-cpus-hard-disk.html

https://www.pitt-pladdy.com/blog/_20091031-144604_0000_SMART_stats_on_Cacti_via_SNMP_/

Facebook Comments

Leave A Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Detection ADBlockPlease, Disable or add to white list on our site.