dm-mapper를 사용하려고 하는데 파일을 허용하지 않습니다. 그래서 장치가 필요해요.
그래서 ram(ramfs 파일 시스템)의 /dev/shm/f에 1500M 파일을 생성하고 이를 (lostup을 통해) /dev/loop0에 매핑했습니다.
하지만 루프 장치에서의 성능은 파일에 비해 약 4위입니다.
램 벤치마크 파일:
# dd if=/dev/shm/f of=/dev/null bs=16k
96000+0 records in
96000+0 records out
1572864000 bytes (1.6 GB, 1.5 GiB) copied, 0.379551 s, 4.1 GB/s
루프백 장치 벤치마크:
# dd if=/dev/loop0 of=/dev/null bs=16k
96000+0 records in
96000+0 records out
1572864000 bytes (1.6 GB, 1.5 GiB) copied, 1.62812 s, 966 MB/s
장치에 파일을 쓰는 더 좋은 방법이 있습니까?
그렇지 않은 경우 루핑 장치를 더 빠르게 만들려면 어떻게 해야 합니까?
편집 1: 시스템 사양: ram ddr2 667 및 CPU e5500
램디스크와 /dev/shm/f를 만들어 보았습니다.무작위 데이터테스트를 위해 bs=16k를 bs=512k로 변경합니다. 결과를 들어보세요:
- ramfs에 직접 io가 없는 파일(직접 플래그는 허용되지 않음) 3.5GB:
# dd if=/dev/shm/f of=/dev/null bs=512K status=progress
2048+0 records in
2048+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.3091 s, 3.5 GB/s
- 직접 IO가 있거나 없는 램디스크(1GB/s 및 3.4GB/s):
# dd if=/dev/ram0 of=/dev/null bs=512K status=progress
937951232 bytes (938 MB, 894 MiB) copied, 1.00036 s, 938 MB/s
2048+0 records in
2048+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.22576 s, 876 MB/s
# dd if=/dev/ram0 of=/dev/null bs=512K status=progress iflag=direct
2048+0 records in
2048+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.319873 s, 3.4 GB/s
3) 직접 루프 장치가 있거나 없는 경우(954MB/s 및 2.5GB/s):
# dd if=/dev/loop0 of=/dev/null bs=512k status=progress
2048+0 records in
2048+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.1009 s, 975 MB/s
# dd if=/dev/loop0 of=/dev/null bs=512k status=progress iflag=direct
2048+0 records in
2048+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.436886 s, 2.5 GB/s
- 장치 매퍼의 램디스크(920MB/s 및 2.4GB/s)
mount /dev/mapper/ram-snap /mnt/sta1
cat /dev/urandom >/mnt/sta1/tst
# dd if=/mnt/sta1/tst of=/dev/null bs=512K count=1500 status=progress conv=sync
1500+0 records in
1500+0 records out
786432000 bytes (786 MB, 750 MiB) copied, 0.850705 s, 924 MB/s
# dd if=/mnt/sta1/tst of=/dev/null bs=512K count=1500 status=progress iflag=direct conv=sync
1500+0 records in
1500+0 records out
786432000 bytes (786 MB, 750 MiB) copied, 0.327174 s, 2.4 GB/s
- DM의 루프 장치, 직접 사용 및 사용 안 함(950MB/s 및 1.7GB/s)
# dd if=/mnt/sta1/tst of=/dev/null bs=512K count=1500 status=progress
1500+0 records in
1500+0 records out
786432000 bytes (786 MB, 750 MiB) copied, 0.827005 s, 951 MB/s
# dd if=/mnt/sta1/tst of=/dev/null bs=512k count=1500 status=progress iflag=direct
1500+0 records in
1500+0 records out
786432000 bytes (786 MB, 750 MiB) copied, 0.451071 s, 1.7 GB/s
대략적으로 말하면 직접 플래그를 사용할 수 있더라도 성능은 약 30% 정도 저하되지만(사례 3, 4, 5) 실제 경우에는 직접 플래그를 제어할 수 없으므로 실제 성능은 60% 정도 저하됩니다. 70%(내 시스템에서는 직접 읽기 없이 약 800-1000MB/s입니다).
일부 SSD의 읽기 속도가 동일한 것을 고려하면 뭔가 잘못된 것 같습니다.
기본적으로 루프 장치(루프 장치에 연결된 루프 파일이 아님)에서 직접 읽을 수 있는 방법이 있습니까?
답변1
블록 장치 지원 파일을 생성하기 위해 파일 시스템을 RAM에 넣는 것은 다소 이상합니다. 또한 ramfs는 최근 몇 년 동안 인기가 떨어지면서 더 나은 조정 가능한 tmpfs로 대체되었습니다. 커널 hugepage 지원을 통해 속도에 큰 차이가 없어야 한다고 생각합니다. 그러나 ramfs는 여전히 상대적으로 느리고 일반적으로 ramfs는 tmpfs보다 빠르며 내 tmpfs(구식 DDR3!)는 동일한 bs입니다. 상자 >6GB/s.
ramfs/tmpfs를 사용하는 대신 하나만 생성하세요.메모리 디스크. 여기에 있는 지침 중 상당수는 약간 오래된 것입니다. 즉석에서 사용할 수 있는 장치(또는 ram1, 2...)를 brd생성하려면 커널 모듈이 필요할 수도 있고 필요하지 않을 수도 있습니다. /dev/ram0나는 추천하고 싶다이것답변:
sudo modprobe brd rd_nr=1 rd_size=$((4 * 1048576))
또한 반면에 16k는 정말 작습니다. 512k 또는 1M 블록에서 작업하는 것이 더 빠를 수도 있습니다. "그러나" 당신은 "내 DM이 16k 블록을 사용할 것이기 때문에 이것은 현명하지 않습니다!"라고 말합니다.
글쎄요, 그것은 당신이 그 위에 무엇을 하느냐에 따라 영향을 미칠 수 있는 것입니다 md. 또한 여기서는 사용자 공간 속도가 중요하지 않을 수 있습니다. 복사 속도는 커널과 사용자 공간 간의 컨텍스트 전환 횟수에 따라 크게 영향을 받습니다.
얼마나 빨리 얻을 수 있는지 미리 보려면 iflag=direct램디스크에서 dd 호출을 추가해 보세요.
sudo dd if=/dev/ram0 of=/dev/null iflag=direct bs=16k
262144+0 records in
262144+0 records out
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 0,457708 s, 9,4 GB/s
sudo dd if=/dev/ram0 of=/dev/null iflag=direct bs=1M
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 0,220438 s, 19,5 GB/s
답변2
루프 장치를 읽는 데는 오버헤드가 있는데, 이는 특히 메모리 속도를 벤치마킹할 때 명백하게 드러납니다. 루프된 장치가 직접 전송만큼 빠르기를 기대한다면 이는 커널이 여러 추상화 계층을 거치더라도 내부적으로 데이터를 여러 번 복사하는 것이 허용되지 않음을 의미합니다. 추가 시스템 호출. 분명히 커널 구현이 충분하지 않습니다.
일반적인 오버헤드 외에도 tmpfs 파일의 루프 장치에는 부작용이 있을 수 있습니다. 따라서 파일 생성 방식에 따라 성능이 저하될 수 있습니다.
# truncate -s 1500M /dev/shm/f
# du /dev/shm/f
0 /dev/shm/f
truncate실제로 공간을 차지하지 않도록 파일을 드물게 만듭니다 .
파일을 직접 읽을 때 아무 것도 변경되지 않습니다.
# cat /dev/shm/f > /dev/null
# du /dev/shm/f
0 /dev/shm/f
그러나 루프 장치의 경우에는 동일하다고 말할 수 없습니다.
# losetup --find --show /dev/shm/f
/dev/loop1
# cat /dev/loop1 > /dev/null
# du /dev/shm/f
1536000 /dev/shm/f
따라서 루프 장치를 읽으면 tmpfs 파일이 할당됩니다. 이는 RAM이 할당되어 있으므로 다른 RAM을 해제해야 할 수도 있음을 의미합니다. 스왑 공간이 있는 경우 프로세스에 스왑이 포함될 수도 있습니다.
이는 잠재적으로 의도하지 않은 부작용입니다.
루프 장치와 함께 tmpfs를 사용하는 대신 적절한 램디스크 장치를 사용해 볼 수 있으며 파일 루프보다 오버헤드가 적기를 바랍니다.