용량이 작은파일에 개수가 엄청 많을 때 disk io가 많은 이유

집구석   
   조회 10267   추천 0    

 

안녕하세요


용량이 작은파일에 개수가 많으면(예를 들어 한 디렉토리에 3kb 또는 3mb짜리 파일이 10만개 있는경우) disk io가 심해지는? 높아지는 이유가 뭔지 알 수 있을까요?


용량이 큰 파일과 작은파일에 따라 뭔가 차이점이 있는건가요?


그리고 nas 구축했다고 가정했을 시 nas 서버의 메모리, 네트워크 속도에 따라 disk io 영향도가 궁금합니다...

짧은글 일수록 신중하게.
DarknessAng… 2021-01
애초에 현존하는 모든 파일 시스템과 디스크가 파일 개수 많을수록 급격하게 성능이 하락됩니다

NVMe로 연속 성능 300메가 뽑으면 전체 성능의 10% 쓰는거지만, 4k에서 300메가 뽑으면 거의 최대 성능 다 쓰는겁니다

램 용량이 클수록 일단 저런것 쓰기할때 디스크 부하가 줄어듭니다 (읽기는 케쉬 히트해야하니 2번째 이후만 효과있음)

네트워크 속도에 비례해서 부하 걸리는건 너무 당연한 애기입니다

참고로 NAS에 접근하는 프로토콜에 따라 저런경우 성능과 부하 천지 차이가 있습니다
     
집구석 2021-01
감사합니다 죄송하지만 조금 쉽게 설명해주실 수 있을까요?
제가 아직 지식이 부족해서요

램 용량이 클수록, 네트워크 속도가 높을수록 왜 부하가 적어지는지 궁금합니다
          
박문형 2021-01
NAS라는게

네트워크와 스토리지 달린 서버에 NAS OS를 구해 재대로 셋팅하면 NAS가 됩니다..

컴퓨터는 퍼포먼스를 올리기 위해서 혹은 속도 차이가 심한 디바이스 사이에 속도 차를 줄이기 위해서 캐쉬라는 기법을 사용하는데

NAS OS에서는 보통 캐쉬에 사용 되는 메모리를 서버의 시스템 메모리를 사용하고 이 메모리가 크면 클수록 컴퓨터에서 재일 느린 디바이스 중에

하나인 하드디스크의 데이터를 더 많이 캐쉬메모리(디바이스 중에서 속도가 빠른) 로 불러들여서 속도(퍼포먼스)를 높이게 됩니다..

이 캐쉬 메모리는 마냥 크다고 좋은 것은 아닙니다..
시도니 2021-01
하드 디스크 구조 때문입니다.

HDD는 랜덤기록방식으로 돌다가 비어있는 곳에 기록하는 방식입니다.

그래서 쓰기 상태의 경우에 HDD의 공간이 아주 많이 남아있다면 쓰기속도의 저하는 일어나지만 읽기속도처럼 형편 없어지지는 않습니다.

그런데 읽기는 좀 다른데 읽어야 하는 데이터가 많으면 일단 어디 있는지 찾는데도 엄청나게 시간이 많이 걸립니다.

물론, 모든 대이터를 다 읽어 들이는 것이 아니라 inode라는 인덱스를 검색하는 데.. 이 inode상에 실제 데이터 주소가 나와 있습니다. 그런데 작은파일이 많아지게 되면 이 inode 상에 데이터를 읽는데만도 한세월 걸립니다.

요즘은 hdd를 포멧할때 블럭사이즈를 신경안쓰고 포멧하지만, 이렇게 파일이 작은 용량의 파일이 엄청나게 많은 경우 블럭 사이즈를 크게하고 단편화를 최소화(이를테면 조각모음)을 하면 읽기 성능에 이득을 볼 수 있습니다.

하지만, HDD로는 어느정도 물리적인 한계가 있기 때문에 이런것은 SSD나 플래시스토리지가 딱 알맞죠.
     
집구석 2021-01
읽을 주소가 많아지니 그만큼 시간이 오래걸리는거군요
이런 파일들은 복붙해야할때도 일단 복사할 파일을 읽어야하니 시간이 오래걸리는 거겠죠?
          
엠브리오 2021-01
어느 파일시스템이든 마찬가지입니다.
파일 갯수가 많아지면 특정 파일을 찾는데 시간이 오래걸리는게 당연한거죠.

디렉토리 한개당 적당한 파일 갯수는 3천개 ~ 5천개 정도입니다.

한 디렉토리 안에 파일이 10만개가 들어 있다면 파일시스템이 엄청나게 느려집니다.

적당히 분류시켜서 서브 디렉토리를 만들고 서브디렉토리 하나당 파일 갯수가 5천개 이하가 되도록 관리해야 합니다.
Qsup 2021-01
일상의 예를 들면
1천가구가 있는 아파트에 500g짜리 택배를 차에서 1개씩 꺼내서 배달하는것과
50kg짜리 택배 1개를 내려서 관리실까지만 배달하는것의 차이입니다.
     
장동건2014 2021-01
비유를 알아듣기 쉽게 알려주시네요.~
박문형 2021-01
비유하자면

1미터짜리 김밥 써는데 1센티 간격으로 써는 것과

5센티간격으로 써는 것과 어느게 더 힘이 많이 들어가느냐 의 차이 정도로 보면 됩니다..
박문형 2021-01
스토리지 장비의 퍼포먼스는 이런 상태일때

이만큼 되어야 돼 라는게 붙으면

테스트 장비를 구축해서  BMT 및 옵티마이징을

해보시고 결과를 내시기 바랍니다..

테스트 장비는 꼭 구매할 필요는 없습니다..


그런데 장비 운용하시면서 무슨 문제가 있나요??

저런 질문은 지식으로 알기 위한 질문 같아 보이지 않아서요..
     
집구석 2021-01
네... 지금 벌어지고 있는 상황을 조금 축소하여 질문드렸습니다
정의석 2021-01
파일 하나를 복사한다고 할때 실질적인 파일 복사 전/후로 준비/완료작업이 진행 됩니다. 흔히 오버헤드라고 불리지요.
이 오버헤드는 작은파일 1개든 큰파일1개든 똑같습니다. 그래서 작은파일(1MB) 1000개 복사할 때와 큰파일(1GB) 1개 복사할때 시간차이가 나게 됩니다. 물론 이 오버헤드만의 문제는 아닙니다.
그런데, 이런 작업이 NAS로 가게되면 또다른 오버헤드가 발생합니다. 더구나 NAS는 블럭전송도 아니고 패킷전송이라 더 느려지게 되고요.(이런면에서는 오버헤드가 적고 블럭전송이 가능한 SAN이 빠르다고 할 수 있겠죠.)
작은 파일이 많이 있는 경우에는 압축을 해서 복사를 하는게 빠른 경우([압축시간 + 압축파일 복사시간] < [작은 파일을 그냥 복사하는 시간])도 있습니다.


QnA
제목Page 5067/5710
2015-12   1692111   백메가
2014-05   5157871   정은준1
2003-07   10069   김형진
2003-06   10070   이창석
2013-09   10070   해피버그
2009-12   10070   푸릉이
2003-07   10070   박규현
2003-10   10070   문추기
2003-03   10070   이호열
2003-12   10071   김광환
2010-08   10071   정은준1
2003-09   10072   김강수
2003-06   10072   박인호
2010-09   10072   6툴
2003-07   10072   신원호
2003-12   10072   문병채
2003-06   10072   김현호
2016-02   10073   해피버그
2011-05   10073   현진
2003-10   10074   김영수
2010-04   10075   인치준
2013-08   10075   chis