Docker for mac의 파일 시스템 성능

파일 시스템은 통상적으로 매우 복잡하다. 이것은 우리가 사전에 명확한 성명을 필요로 하는 것이다.
POSIX 파일 시스템 (대부분의 알고 좋아하는 파일 시스템) 은 더욱 그렇다. 왜냐하면 POSIX는 특정한 조작을 실행하는 데 어떤 보증이 있는지, 그리고 이러한 요구는 상당히 엄격하기 때문이다.
현대의 계산 시대에는 소수의 몇 개의 파일 시스템이 있는데 가장 흔히 볼 수 있는 기능은 많든 적든 이미 융합되었고 예전처럼 그렇게 많은 혁신이 없었다. 우리 대다수 사람들에게 있어서 이것은 매우 좋았다.SSD(Solid State Drive)는 매우 빠른 속도로 인해 파일 시스템은 일반적으로 기본 기술 때문에 앞으로 10년 동안 마술 범위로 밀려납니다.
이 글은 파일 시스템과 우리가 기대하는 성능 특징에 대한 몇 가지 생각에 대한 빠른 시도입니다. 구체적으로 말하면 개발 환경을 위한 공유 파일 시스템, Docker입니다.
Linux의 Docker는 cGroup과 커널 이름 공간의 매우 얇은 포장기로서 그 성능은 하부 파일 시스템과 하부 하드웨어의 본체 성능에 매우 가깝고 토론할 만한 것이 거의 없다.이 경우 파일 시스템 스택은 다음과 같습니다.

컨테이너와 호스트 사이에 매핑된 Docker 공유 볼륨을 사용하면 크게 달라지지 않습니다. 컨테이너에서 볼 수 있는 파일 시스템 구역은 모두 내부 이름 공간의 마법이고 파일 시스템을 덮어쓰는 교묘하게 사용되기 때문입니다. 이것은 여러 개의 가능한 희소한 항목을 겹쳐서 창고의 모든 부분을 통합적으로 볼 수 있는 방법입니다.FROM someimage:latest을 만들고 파일을 용기에 불러오거나 복사하면 2층이나 3층의 깊이 창고를 만들 수 있습니다. Docker는 모든 부침개 층이 필요할 때 거기에 있는지 확인하는 역할을 합니다.
그러나 이것은 Linux와 Docker 파일 공유에 관한 이야기가 아닙니다. 이것은 Mac의 상황입니다. 아마도 Windows도 있을 것입니다.
macOS는 Linux가 아니기 때문에 Docker가 작업하는 cGroup과 명칭 공간 기능이 없기 때문에 Docker는 어떠한 비Linux 플랫폼에서도 본 컴퓨터를 실행할 수 없다. 이 제한을 극복하기 위해 Docker는 "보이지 않는"Linux 가상 컴퓨터만 관리할 수 있다.
이론적으로 말하자면 한 개 또는 다른 가상 기기 모니터링 프로그램을 선택할 이유가 없다.(하드웨어 가상화 기술(예: VMWare Fusion, Parallels, VirtualBox 등)
macOS에서 이것은 xhyve입니다. 제가 알기로는 xhyve는 특별한 점이 없습니다. 단지 이것은 기본적으로 애플asHypervisor.framework가 macOS의 일부분으로 묶은 것입니다. xhyve는 단지 그것을 사용합니다.
중요한 것은 호스트와 가상 시스템 간에 더 이상 자원을 공유하지 않는다는 것이다.만약 우리가 지금 디렉터리를 공유하고 싶다면, 우리는 macOS와 가상 기기 사이를 공유해야 한다. 가상 기기에서 Docker 용기까지.
더 심각한 것은 보이지 않는 가상 시스템(Linux)과 호스트가 서로 다른 파일 시스템(예를 들어 가상 시스템의 EXT4와 호스트의 HFS+)을 사용하기 때문에 모든 개념이 이식될 수 있는 것은 아니다.예를 들어 HFS+는 대소문자를 구분하지 않습니다(선택 사항). 파일 시스템 이벤트(파일 및 디렉터리 변경에 대한 알림)의 작업 방식이 완전히 같지 않습니다. 파일이 자동으로 바뀔 수 있는지, 아니면 여전히 열려 있는 상태에서 삭제할 수 있는지, 간혹 중요한 행위의 긴 말 중 다른 부분을 잊어버렸을 수도 있습니다.
다음은 두 개의 추가 수준의 VM 및 파일 공유에서 기존 스택의 모양입니다.

공유 파일 시스템 영역에서 Docker VM(및 실행 컨테이너)과 호스트 시스템 파일 시스템 간의 교량은 반드시 특정한 네트워크나 반네트워크 기반의 파일 시스템이어야 한다.
흔히 볼 수 있는 알려진 해결 방안은 NFS와 CIFS(Samba)이지만 Docker는 자신의 해결 방안osxfs(소스 코드 폐쇄)을 제공하고 가장자리 채널에 gRPC Fuse라는 해결 방안(폐쇄 소스 코드)을 제공한다.
흔히 볼 수 있는 파일 시스템 기준 테스트(광범위한 NFS 기준 테스트와 문서 조정 포함)는 주로 읽기와 쓰기의 최적화에 주목한다. 이것은 역사적으로 일리가 있고 자기 저장은 속도로 유명하지 않기 때문에 파일 시스템은 중대한 병목이 될 위험이 있다.
사실 파일 탐색 도구(Windows의 Explorer, macOS의 Finder, Gnome의 Nautilus 등)에 대해서는 일부 기준 테스트도 의미가 있다. 일반적으로 파일을 열고 읽으면 검색 아이콘이나 미리보기 등을 나타낸다. 파일 시스템의 실제 읽기와 쓰기 성능은 중요한 구동 요인이다.
그리고 Docker(Mac)의 컨텍스트에서 파일 시스템 성능을 분석했지만 원본 읽기/쓰기 성능이 아니라 낮은 수준이었습니다.
실제 파일을 읽기 전에 파일을 열어야 합니다. 심지어 열기 전에 메타데이터로 되돌아오는 특정 시스템 API를 호출해서 존재하는지 확인할 수 있습니다.
파일 시스템과 관련된'시스템 호출'(syscalls) 가족은 약 15가지 물건을 운행하고 있으며, open, read, write, stat, lstat, access, close, rename이 가장 자주 호출된다.symlink, open 등도 흔하다.
시스템 호출은 보통 파일을 읽는 데 걸리는 시간의 일부분만 차지한다.read 7ns가 필요할 수 있음
이 중 cat 1024 바이트를 읽는 데 20ns 정도가 걸릴 수 있습니다.
이것 봐, 10MB의 제로 파일을 생성한 후에 우리는 cat 그것을 인쇄하고 베이스 시스템의 호출을 추적할 수 있다. 이것은 리눅스에서만 작동하는 것을 주의할 수 있다. 그래서 나는 Docker에서, 나의 리눅스 기계에서, 그러나 파일 시스템을 공유하지 않는 알파인 용기에 있다.
open 및 close 에서 각각 0.000061 및 0.000011 초, sendfile 시스템이 파일과 내 터미널 사이에서 복사되도록 호출되고 있으며 reads 파일을 실행할 필요가 없으며 실제로 cat 파일의 인쇄 속도는 head 의 약 두 배입니다.

/ # strace -c -f cat 10meg
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.99    0.048492       24246         2           sendfile
  0.01    0.000004           4         1           close
  0.00    0.000000           0         1           open
  0.00    0.000000           0         2           mprotect
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1           getuid
  0.00    0.000000           0         1           arch_prctl
  0.00    0.000000           0         1           set_tid_address
------ ----------- ----------- --------- --------- ----------------
100.00    0.048496                    10           total
/ # strace -c -f head 10meg
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 64.48    0.051081           5      9757           writev
 35.29    0.027957           2      9767           readv
  0.07    0.000053          26         2           mprotect
  0.05    0.000036          36         1           open
  0.04    0.000028          28         1           execve
  0.02    0.000017          17         1           arch_prctl
  0.02    0.000016          16         1           ioctl
  0.02    0.000014          14         1           getuid
  0.02    0.000014          14         1           set_tid_address
  0.00    0.000003           3         1           close
------ ----------- ----------- --------- --------- ----------------
100.00    0.079219                 19533           total

그래, 길을 잃을 위험을 무릅쓰고 프로그래밍 언어, 개발 도구, 그리고 우리가 통상적으로 Docker에서 실행하는 것들에 대해 매우 구체적인 요구가 있다고 가정하자.