LINUX.ORG.RU
ФорумAdmin

Тормозит dmcrypt


0

1

Странная хренотень творится. Есть сервер, проц E5-2620, на чистом шифровании (с dmzero бэкендом) выдает:

# echo "0 2147483648 zero" | dmsetup create zerodisk
# cryptsetup --cipher=aes-cbc-essiv:sha256 --hash=sha256 create testcrypto /dev/mapper/zerodisk

Пишем:
# echo 3 > /proc/sys/vm/drop_caches
# dd if=/dev/zero of=/dev/mapper/testcrypto bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 15.6629 s, 686 MB/s

Читаем:
# echo 3 > /proc/sys/vm/drop_caches
# dd of=/dev/null if=/dev/mapper/testcrypto bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 23.1772 s, 463 MB/s
То, что чтение в полтора раза медленне записи - это нормально, там мультитрединг лучше при записи распараллеливает по ядрам.

Так же на этом сервере есть рейд-массив, который выдает:

# echo 3 > /proc/sys/vm/drop_caches
# dd if=/dev/sdc of=/dev/null bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 14.5746 s, 737 MB/s

# echo 3 > /proc/sys/vm/drop_caches
# dd of=/dev/sdc if=/dev/zero seek=1000 bs=1M count=32768
32768+0 records in
32768+0 records out
34359738368 bytes (34 GB) copied, 42.6876 s, 805 MB/s

А теперь самое интересное. Если навесить cryptsetup на этот массив, то получаем:

Читаем:
# echo 3 > /proc/sys/vm/drop_caches 
# dd if=/dev/mapper/CRYPT_RAID6 of=/dev/null bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 58.4221 s, 184 MB/s

Пишем:
# echo 3 > /proc/sys/vm/drop_caches
# dd of=/dev/mapper/CRYPT_RAID6 if=/dev/zero bs=1M count=10240      
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 68.5209 s, 157 MB/s

При этом ksoftirqd жрёт почти 100% одного ядра, похоже проблема в нём. Я подозреваю что страдает шедулинг и оно постоянно прыгает по разным ядрам.

# cat /proc/interrupts
...
RES:    1433131    2849086     613016      57347     305756     195228   Rescheduling interrupts
...

Куда копать, комрады?

Да, ядро 3.0.32

Косяк может быть в том, что для записи блока, не выровненного по границе блоков шифрования, нужно сначала прочитать данные с диска.

Deleted ()
Ответ на: комментарий от Deleted

Да, я тоже об этом думал. Попробую проверить. Сейчас у LUKS девайса стоит payload offset = 4096, а RAID6 сделан из 8 дисков с размером страйпа 128k.

Как в данном случае правильно посчитать payload offset? Как (N-2)*размер страйпа или N*размер страйпа?

blind_oracle ★★★★★ ()
Ответ на: комментарий от Deleted

Тут проблема еще в том, что чтение тоже идёт медленно. Хотя выравнивание тоже может играть роль...

blind_oracle ★★★★★ ()
Ответ на: комментарий от Deleted

Да, похоже проблема оказалась в выравнивании. Выровнял раздел по 6*128k и LUKS еще на столько же дальше и скорость стала ~288MB/s на чтение и 360 на запись.

blind_oracle ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.