☰

md(raid1)/crypt(luks)/lvm의 쓰기 성능에 비해 읽기 성능이 매우 낮습니다.

tag-icon • tag-icon performance lvm md
md(raid1)/crypt(luks)/lvm의 쓰기 성능에 비해 읽기 성능이 매우 낮습니다.

내 경험은 끔찍했어요읽다성능은 raid1/crypt/lvm보다 좋습니다. 동시에 동일한 설정에서 쓰기 속도는 약 2배 빠릅니다. 동일한 시스템의 다른 raid1 설정에서는 정상적인 읽기 속도를 얻습니다(아마도 cryptsetup을 사용하지 않기 때문일 것입니다).

운영 체제 관련 디스크: sda + sdb. 두 개의 디스크가 있는 raid1 구성이 있으며 두 디스크가 모두 제자리에 있습니다. RAID에서 LVM을 사용하고 있습니다. 암호화가 없습니다. 두 디스크 모두 WD Green, 5400rpm입니다.

이 raid1의 IO 테스트 결과:

dd if=/dev/zero of=/tmp/output.img3 bs=8k count=256k conv=fsync
 - 2147483648 bytes (2.1 GB) copied, 22.3392 s, 96.1 MB/s

sync
echo 3 > /proc/sys/vm/drop_caches
dd if=/tmp/output.img3 of=/dev/null bs=8k
 - 2147483648 bytes (2.1 GB) copied, 15.9 s, 135 MB/s

이것은 (동일한 컴퓨터에서) 문제의 설정입니다. 현재 소프트웨어 raid1 + crypt(luks, serpent-xts-plain) + lvm으로 구성된 하나의 sdc(WD Green, 5400rpm)만 있습니다. 내일 다른 디스크(sdd)를 연결하여 이 두 개의 디스크 raid1 설정을 완료하겠습니다.

이번 raid1의 IO 테스트 결과는 다음과 같습니다.

dd if=/dev/zero of=output.img3 bs=8k count=256k conv=fsync
2147483648 bytes (2.1 GB) copied, 17.7235 s, 121 MB/s

sync
echo 3 > /proc/sys/vm/drop_caches
dd if=output.img3 of=/dev/null bs=8k
2147483648 bytes (2.1 GB) copied, 36.2454 s, 59.2 MB/s

읽기 성능이 매우 좋지 않다는 것을 알 수 있습니다(암호화 없는 경우 135MB/s에 비해 59MB/s). 벤치마크 중에는 디스크를 사용한 것이 없습니다. 이는 iostat와 dstat를 확인해 봤기 때문에 확인할 수 있습니다.

하드웨어 세부정보:

  • 디스크: 전체 WD 그린, 5400rpm, 64mb 캐시.
  • CPU: FX-8350, 기본 속도
  • 메모리: 4x4GB, 1066Mhz.

이 소프트웨어의 세부사항:

  • 운영 체제: Debian Wheezy 7, amd64
  • mdadm: v3.2.5 - 2012년 5월 18일
  • LVM 버전: 2.02.95(2) (2012-03-06)
  • LVM 라이브러리 버전: 1.02.74(2012-03-06)
  • LVM 드라이버 버전: 4.22.0
  • 비밀번호 설정: 1.4.3

느린 raid1+crypt+lvm 설정을 구성하는 방법은 다음과 같습니다.

별도의 /dev/sdc

  1. MK 태그 GPT
  2. 유형: ext4
  3. 시작 시간: 2048초
  4. 끝: -1

이제 raid, crypt 및 lvm 구성은 다음과 같습니다.

  1. mdadm --create /dev/md1 --level=1 --raid-disks=2 /dev/sdc 누락
  2. cryptsetup --cipher serpent-xts-plain luksFormat /dev/md1
  3. cryptsetup luksOpen /dev/md1 md1_crypt
  4. vgcreate vg_sql /dev/mapper/md1_crypt
  5. lvcreate -l 100%VG vg_sql -n lv_sql
  6. mkfs.ext4 /dev/mapper/vg_sql-lv-sql
  7. 마운트 /dev/mapper/vg_sql-lv_sql /sql

그럼 여러분, 원인을 찾아 해결하도록 도와주실 수 있나요? 암호화가 없는 다른 설정(sda+sdb)에서는 읽기 속도 저하가 없으므로 cryptsetup과 관련이 있어야 합니다. 하지만 어떻게 해야할지 모르겠습니다.

감사해요!

답변1

분명히 암호화는 상당한 오버헤드를 추가하지만 이를 무시하십시오.

또한 AES가 아닌 암호화를 사용합니다. 즉, 프로세서에서 가속(AES 하드웨어 가속)을 얻지 못합니다. 또한 데스크탑 품질의 프로세서를 사용합니다.그리고소비자 드라이브는 매우 느립니다.

이 설정이 바로 성능이 좋지 않은 이유입니다. 서버 품질 프로세서(이것이 서버인가요?)와 함께 괜찮은 드라이브를 추가하고 LUKS에 AES를 사용하십시오.

답변2

테스트가 올바르게 완료되지 않는 경우가 많습니다. 8k 읽기 작업으로 Linux 소프트웨어 RAID를 로드하는 것은 성능 저하를 요구하는 방법입니다. 더 큰 것을 사용해 보세요 bs.

cryptsetup benchmark아래 댓글에 for ppl의 출력도 추가했습니다.

#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   476.6 MiB/s  1891.3 MiB/s
 serpent-cbc   128b    79.1 MiB/s   222.6 MiB/s
 twofish-cbc   128b   135.0 MiB/s   158.7 MiB/s
     aes-cbc   256b   194.7 MiB/s   892.5 MiB/s
 serpent-cbc   256b    46.2 MiB/s   211.4 MiB/s
 twofish-cbc   256b   144.6 MiB/s    93.3 MiB/s
     aes-xts   256b  1542.0 MiB/s  1727.0 MiB/s
 serpent-xts   256b   114.0 MiB/s   200.2 MiB/s
 twofish-xts   256b   111.4 MiB/s   131.7 MiB/s
     aes-xts   512b   573.6 MiB/s   829.3 MiB/s
 serpent-xts   512b   199.8 MiB/s   191.1 MiB/s
 twofish-xts   512b    81.8 MiB/s   107.3 MiB/s

-- (항상 그런 것은 아니지만 자주) 해독이 더 빠르다는 것을 분명히 알 수 있습니다.

관련 정보