CIFS 캐쉬 관련해서 검색을 해보니까 방법이 있긴 있군요...

제가 생각했던대로 CIFS는 근본적인 문제때문에 캐쉬가 동작하지 않습니다.

제아무리 연결된 네트웍이 빠르더라도 캐쉬가 동작하지 않으면

현실적으로 백업 이상으론 쓸 수준이 못되겠지요.. HDD에서 캐쉬는 절대적입니다.

다만 파일에 대해서 oplock을 걸면 해당 파일만 캐쉬가 동작한다는데

크게 의미가 있는 수준은 아닌듯 보입니다.

다만 옵션으로 이 캐쉬 제한을 풀 수 있습니다.

mount.cifs를 할때 cache=loose 옵션을 주면 그냥 위험을 감수하고

강제로 캐쉬를 적용할 수 있다고 합니다. (뭐 혼자 쓰는거라면 딱히 위험할 것도 없죠)

이 옵션을 적용하고 간단한 테스트 결과 캐쉬가 된 상태에서는

안된 상태보다 10배 정도 속도가 향상되는걸 확인할 수 있었습니다.

100MB 648개의 파일을 로컬로 복사해올때 캐쉬가 없는 상태에선

1.2MB/s 정도의 속도가, 캐쉬가 히트된 상태에선 12MB/s 정도의

속도가 나왔습니다.

(네트웍 상태 때문은 아닙니다. 기가 단위의 큰 파일을

전송하면 45MB/s 정도 나옵니다.)

다만 그럼에도 불구하고 많이 느리긴 합니다. 

캐쉬가 된다고 해도 완전히 로컬에서만 처리하는건 아니고

뭔가 네트웍으로 왔다갔다하면서 시간을 꽤 잡아먹는 것 같습니다.

  • profile

    이 내용은 조금 제가 회사에서 하는 주업무인것 같아서 참고하시라고 주저리 적어봅니다.

    웹서버와 디비서버를 분리했을때 가장 좋은 조합은 SAN 스토리지 조합입니다.

     

    웹서버 단독일 경우 사용하는 디스크가 제 아무리 빠르더라도 태생이 전문 하드가 아니라서 I/O(IOPS)성능이 그리 높지 않습니다. 하물며 클라우드에 사용하는 서버는 쉐어형이라 디스크에 동접이 많이 발생해서 처리속도가 느리죠. 그래서 많은 기업들이 서버와 디비를 분리합니다. (그런거 이미 알고 있어! 라면 죄송합니다.)

     

    그 다음이 전용 스토리지 조합입니다. 우리가 흔히 TCP/IP통신으로 디스크 마운트해서 사용하는거죠. 이 조합으로 효과를 내려면 스토리지가 어떤 스펙인지를 알아야 합니다. 저 같은 경우 5만 유저가 VDI 서비스로 동접 이용하기 때문에 4만 IOPS 이상을 발휘해야하는 요구조건이여서 EMC ISILON 9대를 클러스터링해서 제공한 적이 있습니다. 클라우드라면 아마존 같은 회사가 아니라면 2만 IOPS 정도가 일반 제공할 수 있는 한계 입니다. (스토리지는 netapp나 몇몇이 있는데 이부분은 생략하고..)

     

    스토리지는 기본적으로 내부 캐시가 동작합니다. 캐시가 동작한다고 다 좋은게 아니라 Overall cache Hit율이  80%~100% 사이로 유지되야 좋은 스토리지라 할 수 있지요. 그리고 요즘 스토리지는 10Gbps 제공을 기본으로 합니다. 스토리지, 서버, 네트웍중 하나라도 1Gbps 미만으로 접속 되어있다면 아무리 스토리지가 우수해도 성능 발휘할 수 없습니다.  (단비아빠님이 접속하려는 디스크가 어떤 스토리지를 기반으로 사용하는지에 모르지만 일단 환경이 중요하다는 겁니다.)

     

    마지막으로 프로토콜, 어플리케이션의 조합이 되겠네요. (현재 단비아빠님이 고민하시는 영역이네요.)

    CIFS는 SMB1, 2, 3 까지 있습니다. 서버 구성에 따라 다르지만 윈도우가 아니라면 기본 공유는 SMB1을 사용하게 됩니다. 요즘은 오래된 OS나 복합기 정도나 사용하는 오래된 프로토콜 입니다. 최근에는 SMB3을 사용하고 있고 SMB3은 multi channel이 지원되기 때문에 스토리지가 smb3 multi channel 옵션을 활성화 하면 데이터 전송을 동시에 복수개의 세션으로 전송하기 때문에 속도가 빠릅니다. (단 스토리지가 지원하지 않으면 역으로 속도가 엄청 떨어지게 됩니다.) 사용하시는 서버의 CIFS가 smb1으로 동작하고 있는지 확인하실 필요가 있습니다.

     

    그밖에는 기본적인 data block size, tcp window size의 튜닝이 있겠습니다. 일반 OS는 Tcp window size가 64k라서 세션 하나로는 성능의 한계가 있습니다. 스토리지나 전용 서버는 Tcp window size를 더 높여도 대응할 수 있기 때문에 OS의 값을 올려보시면 좋습니다. (요즘 윈도우 서버(2012, 2016)는 이런 TCP도 튜닝해서 상대방과의 통신 상황을 보고 Tcp window를 한계까지 올려서 전송하는 기능이 있지만 다른 벤더 간에서는 발휘하지 않습니다.)

     

    마지막으로 전송 블록사이즈인데 8k에서 16k 단위로 파일을 쪼개서 전송하는게 윈도우 CIFS의 기본인데 최대 64k 단위로 설정할 수 있습니다. 블록사이즈 값이 크다고 다 빠른건 아니고 그림 파일이나 대용량 정도의 파일을 불러올때나 효과가 나타나고 일반 DB호출해서 한줄 정도의 값 받아오는것에는 아무런 효과가 없습니다.

     

    100MB 648개의 파일을 로컬로 복사해올때 캐쉬가 없는 상태에선

    1.2MB/s 정도의 속도가, 캐쉬가 히트된 상태에선 12MB/s 정도의

    속도가 나왔습니다.

    12MB/s 면 100Mbps 나오신 건데 어쩌면 NIC이 1Gbps도 아니고 100Mbps로 제공되고 있을 가능성이 있습니다.

    그렇다면 아무리 디비서버를 나누고 튜닝해도 의미가 없습니다. 단일 서버로 사용하시는게 제일 빠를 겁니다.

     

    주저리 적어봤습니다..

     

  • profile ?

    아.. 그건 아닙니다. 클라우드 인스턴스고 10Gbps 네트웍입니다.
    저건 자잘한 파일 여러개로 테스트해서 그런거고 1기가짜리 큰 파일로 단일 전송하면 45MB/s 정도 나옵니다. 이것도 제쪽 네트웍 문제 때문은 아닌 것 같고 아마 스토리지 서버쪽에서 내보내는게 이정도가 한계인듯 합니다. 아마 스토리지 서버 쪽은 10Gbps가 아니라 1Gbps로 연결된 것 같습니다. 그쪽은 클라우드 관련 서비스가 아니라 백업이 주목적인듯 해서요...

    참고로 cache=loose 설정이 없더라도 같은 테스트를 반복할 경우 2회차 이후에선 전송속도가 1.2MB/s -> 2.4MB/s 정도로 올라갑니다. 이 경우엔 스토리지 서버쪽 디스크 캐쉬가 동작한걸로 보입니다.

  • ?

    CIFS는 포기했습니다. 캐쉬 켜도 성능은 처참하네요...

    CIFS 캐쉬가 디스크 캐쉬하고 뭔가 많이 틀리네요.. IOPS가 늘어나질 않습니다.