개인 NAS를 구축해서 사용한지가 꽤 되었습니다. 그동안 오드로이드 HC1 -> 중국산 타오나스 -> 자작나스 순으로 하드웨어도 업그레이드해왔고요.
자작나스 구성하면서 내부망을 2.5Gbps로 새로 구축한 덕분에 smb로 네트워크 드라이브 붙인 후 파일 이동하면서 하드 성능의 뽕을 뽑을 수 있었습니다.
원인모를 속도저하 발생
처음 세팅 한 이후로 당연히 잘 돌아간다고 생각하면서 살고있었는데...
어느날 파일 정리를 하다보니 생각보다 쓰기 속도가 너무 느립니다.
오잉? 분명 150MB/s정도 뽑아주던 구성인데 어쩌다 이렇게 느린건가를 고민하면서 원인을 찾아봅니다.
ZFS의 잘못인가?
현재 저의 나스는 ZFS 하드 mirror + SSD slog 쓰기 캐시, lz4 compression으로 세팅되어있습니다. 파일 쓰기 속도에 관련있을법한 녀석들을 한놈씩 살펴보기로 했습니다.
slog
SSD는 플래시 메모리기 때문에 TBW(Total Bytes Written)를 다 채워버리면 정상적으로 동작하지 않을 수 있습니다.
당시 집에서 굴러다니던 2019년산 PM981 256GB짜리를 넣어줬기 때문에 충분히 의심해볼만했죠. smartctl로 상태를 확인해봅니다.
sudo smartctl -Ai /dev/nvme1n1 | grep Data Units Written
> Data Units Written: 38,306,826 [19.6 TB]음... 아무리 옛날 물건이라고 해도 겨우 20TB 언저리로는 뻑나지 않을겁니다. 그래도 혹시 모르니 zpool에서 삭제해봅시다
sudo zpool remove [pool] /dev/nvme1n1하지만 쓰기 속도는 여전하네요. 다음으로 넘어가봅니다.
lz4 compression
아무리 현대 CPU가 빠르다고는 하지만 모든 파일을 다 압축하기에는 벅찰 수도 있습니다. compression 기능을 꺼봅시다.
sudo zfs set compression=off [pool]꺼봤는데도 속도가 똑같은 거로 봐선 얘도 범인이 아니었네요.
저의 일천한 ZFS 지식으로는 쓰기속도가 1/10으로 줄어들 이유가 생각나는 게 없어서 다음으로 넘어갔습니다.
NAS 문제가 아닌가?
네트워크
추석도 지났지만 아직 날씨가 덥습니다. 날이 더우면 사람만 힘든 게 아니라 장비도 힘들어합니다.
비록 환경이 안좋아서 2.5gbps 스위치에 쿨링 솔루션을 추가로 달아줄 수는 없지만
잠시 쉬었다 다시 시작하면 정신 차릴수도 있습니다. 전원선이랑 랜선을 다 빼고 다시 꽂아봅니다.
한참 쉬게 해주고 다시 전원 넣어서 테스트해봤지만 역시 쓰기 속도는 차이가 없습니다.
SMB 클라이언트 프로토콜 버전
이것저것 뒤지다보니 윈11에서 smb 속도 버그가 있었다는 사실을 알았습니다.
저는 버그가 발생한 22H2버전이 아니지만 혹시나 모르잖아요? 그거 고치면서 다른 영향을 받았을지
일단 smb1 버전을 사용하면 여러모로 문제가 많으니까 smb2와 smb3을 사용하는 게 좋겠죠
현재 설정을 알아봅시다.
# powershell 관리자모드에서 실행
Get-SmbServerConfiguration | Select EnableSMB1Protocol,EnableSMB2Protocol,EnableSMBQUIC
>
EnableSMB1Protocol EnableSMB2Protocol EnableSMBQUIC
------------------ ------------------ -------------
False True True이런.. 프로토콜도 정상적으로 세팅되어있네요
원인은 다른곳에 있었다
이쯤되면 알고있는 범위 내에서는 다 테스트해본 듯 합니다. 이쯤에서 포기하고 저녁먹고 돌아오니까 뭔가 떠올랐습니다. 최근에 스마트TV에서 NAS 내부 영상을 볼 일이 있어서 DLNA 환경을 구축했거든요.
minidlna가 inotify 기능이 있어서 자동으로 미디어를 인식하는데다 가벼워서 선택했는데 환경 구축하니 영상도 잘 나와서 만족했었던 기억이 있습니다.
근데 아뿔사... 메인 하드 전체를 스캔 대상에 넣어버렸네요! 이러니까 쓰기가 발생할 때마다 inotify가 가야하니 느릴 수밖에요
당장 아래처럼 DLNA Deployment yaml 파일을 수정하고 apply 해보니까 원하는 속도가 나옵니다.
# dlna dockerhub 참조자료
docker run -d \
--net=host \
-v <media dir on host>:/media/audio \
-v <media dir on host>:/media/video \
-e MINIDLNA_MEDIA_DIR_1=A,/media/audio \
-e MINIDLNA_MEDIA_DIR_2=V,/media/video \
-e MINIDLNA_FRIENDLY_NAME=MyMini \
vladgh/minidlna# deployment 수정대상
# ~~~deployment metadata~~~
spec:
hostNetwork: true # ingress controller port 따로 뚫어주기 귀찮았다.
terminationGracePeriodSeconds: 0
containers:
- name: dlna
image: vladgh/minidlna:sha-42d882b
ports:
- containerPort: 8200
- containerPort: 1900
env:
- name: MINIDLNA_FRIENDLY_NAME
value: [Your name]
- name: MINIDLNA_MEDIA_DIR_1
value: [Dir 1]
- name: MINIDLNA_MEDIA_DIR_2
value: [Dir 2]
- name: MINIDLNA_MEDIA_DIR_3
value: [Dir 3]
volumeMounts:
- name: [Mount 1]
mountPath: [Dir 1]
- name: [Mount 2]
mountPath: [Dir 2]
- name: [Mount 3]
mountPath: [Dir 3]
- name: db
mountPath: /db
volumes:
- name: [Mount 1]
hostPath:
path: [Host 1]
- name: [Mount 2]
hostPath:
path: [Host 2]
- name: [Mount 3]
hostPath:
path: [Host 3]
- name: db
persistentVolumeClaim:
claimName: dlna-db오늘의 교훈
inotify는 파일시스템의 변화를 감지할 수 있어서 굉장히 편리하지만 잘못 사용하면 과도한 시스템 콜 호출로 성능 저하가 발생할 수 있다
