☰

지속적인 순차 쓰기 시 엄청난 성능 저하

tag-icon • tag-icon linux performance hard-drive io
지속적인 순차 쓰기 시 엄청난 성능 저하

데이터를 LUKS 파티션으로 마이그레이션하는 중입니다. 이제 운영 체제 드라이브가 LUKS에서 실행되고 있으므로 데이터 드라이브 마이그레이션을 시작하려고 했습니다. 그런 다음 서버가 응답을 멈췄습니다.

이 LUKS 장치가 열렸습니다:

cryptsetup luksOpen /dev/sdc data1

그리고 다음 명령 중 하나가 서버를 교살했습니다.

pv /dev/zero > /dev/mapper/data1
pv /dev/zero > /dev/sdc

즉시는 아니지만 몇 초 만에 서버가 사용할 수 없을 정도로 느려졌습니다. I/O에서 차단된 모든 것:

root@node51 [~]# ps aux | awk '{if($8~"D"||$8=="STAT"){print $0}}' 
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      1197  0.0  0.0      0     0 ?        D    06:39   0:00 [jbd2/dm-1-8]
root      1687  0.1  0.0      0     0 ?        D    11:15   0:12 [kworker/u96:5]
root     13057  2.0  0.0      0     0 ?        D    13:10   0:01 [dmcrypt_write]
root     13644 10.9  0.0   7452   784 pts/1    D+   13:10   0:08 pv /dev/zero
root     14159  0.0  0.0  98256  6836 ?        DNs  13:10   0:00 sshd: root [priv]
root     14772  0.0  0.0  29008    92 ?        D    13:11   0:00 /usr/sbin/CRON -f
root     14773  0.0  0.0  98256  6748 ?        DNs  13:11   0:00 sshd: root [priv]
root     15411  0.0  0.0  98256  6876 ?        DNs  13:11   0:00 sshd: root [priv]
root     16009  0.1  0.0  98256  6840 ?        DNs  13:11   0:00 sshd: root [priv]
root     16632  0.5  0.0  98256  6892 ?        DNs  13:11   0:00 sshd: root [priv]
root     16900  0.0  0.0   5448   356 pts/3    D+   13:11   0:00 awk {if($8~"D"||$8=="STAT"){print $0}}
root     28553  0.6  0.0      0     0 ?        D    12:12   0:21 [txg_sync]

참고로 약 2초 pv동안 2GiB/s. 이는 후기입 캐시와 더티 페이지가 모두 채워지는 것입니다(모니터링을 통해 발견 /proc/meminfo).

이후에는 pv정상적인 쓰기 속도를 기록했지만 다시 쓰기 캐시에서는 여전히 200MiB/s속도가 앞섰습니다 .2GiB3GiB

모든 I/O 차단으로 인해 서버 로드 평균이 10.00을 넘어 급등했습니다.

pv쓰기 테스트를 중단하는 데에는 Write-back 캐시를 비워야 하기 때문에 시간이 좀 걸리지만 , 테스트가 중단된 직후에는 서버 성능이 정상으로 돌아왔습니다.

흥미롭게도 다음 명령은 서버 지연을 유발하지 않습니다.

# Reads from dm-crypt block device
pv /dev/mapper/data1 > /dev/zero
# Reads from the raw block device
pv /dev/sdc > /dev/zero

# Writes to a control disk of a different model
pv /dev/zero > /dev/sdi
# Reads from a control disk
pv /dev/sdi > /dev/zero

# Writes to a file on a dm-crypt ext4 filesystem on a solid-state drive
pv /dev/zero > /tmp/empty
# Reads from that same solid-state drive
pv /dev/sda > /dev/zero

다음과 같은 질문이 있습니다.

  1. 이 데이터 디스크에 대한 지속적인 순차 쓰기가 서버 속도를 크게 저하시키는 이유는 무엇입니까?
  2. 특정 디스크 또는 몇 개의 디스크에 쓸 때 다른 디스크의 정체를 방지하려면 어떻게 해야 합니까?
  3. 이런 종류의 하드 드라이브는 성능 문제를 일으키지만 다른 드라이브는 그렇지 않은 이유는 무엇입니까?

암호화할 동일한 모델의 디스크 6개( /dev/sdc, /dev/sdd, /dev/sde, /dev/sdf, /dev/sdg및 /dev/sdh)가 있고 앞으로 순차적 쓰기 작업 부하가 발생하므로 서버가 이 문제로 인해 중단되는 것을 원하지 않습니다.

추가 정보

간단한 정보들

섬기는 사람: 델 파워엣지 T320

핵심: Linux node51 4.4.0-22-generic #39-Ubuntu SMP Thu May 5 16:53:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

운영 체제: Ubuntu 서버 16.04 LTS Xenial Xerus 64비트

문제가 있는 하드 드라이브: 도시바 PH3500U-1I72

저는 이 디스크 중 6개를 가지고 있는데 모두 정상인 것으로 알려져 있으며 그 중 2개를 테스트한 결과 두 디스크 모두에서 서버 전체 I/O 성능 저하를 경험했습니다. 그들은 200MiB/s처음 부분 에 읽고 씁니다 .

제어(문제 없음) 하드 드라이브: 삼성 SP1614C

이 디스크의 지속 쓰기 속도는 입니다 50MiB/s. 문제가 있는 디스크가 너무 빠른 것은 아닐까?

디스크 컨트롤러: 델 PERC H310

2개의 솔리드 스테이트 드라이브와 6개의 문제가 있는 하드 드라이브가 이 컨트롤러에 연결되어 있으며 모두 AHCI로 직접 전달됩니다. 제어 디스크는 마더보드에 내장된 SATA 포트에 연결됩니다.

I/O 스케줄러

root@node51 [/tmp]# tail -n +1 /sys/block/sd*/queue/scheduler 
==> /sys/block/sda/queue/scheduler <==
noop [deadline] cfq 

==> /sys/block/sdb/queue/scheduler <==
noop [deadline] cfq 

==> /sys/block/sdc/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sdd/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sde/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sdf/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sdg/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sdh/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sdi/queue/scheduler <==
noop [deadline] cfq

스케줄러를 에서 로 변경하면 눈 /dev/sdc에 띄는 차이가 없습니다. 스케줄러를 변경하면 지연이 다소 줄어든 것처럼 보였지만 다른 디스크의 I/O 작업에는 여전히 어려움이 있었습니다.noopdeadlinecfq

vm.dirty*커널 매개변수

root@node51 [~]# sysctl -a | grep 'vm.dirty'
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200

속도 저하가 감지되어 기록된 예/var/log/syslog

ZFS 트랜잭션 그룹 동기화:

May 11 19:28:44 node51 kernel: [ 4080.179688] INFO: task txg_sync:3179 blocked for more than 120 seconds.
May 11 19:28:44 node51 kernel: [ 4080.179905]       Tainted: P           O    4.4.0-22-generic #39-Ubuntu
May 11 19:28:44 node51 kernel: [ 4080.180110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 11 19:28:44 node51 kernel: [ 4080.180357] txg_sync        D ffff88060b68baa8     0  3179      2 0x00000000
May 11 19:28:44 node51 kernel: [ 4080.180362]  ffff88060b68baa8 ffff880616a96d00 ffff8806133ea940 ffff880603dc2940
May 11 19:28:44 node51 kernel: [ 4080.180366]  ffff88060b68c000 ffff880616ad6d00 7fffffffffffffff ffff88056cb8c508
May 11 19:28:44 node51 kernel: [ 4080.180368]  0000000000000001 ffff88060b68bac0 ffffffff818211f5 0000000000000000
May 11 19:28:44 node51 kernel: [ 4080.180372] Call Trace:
May 11 19:28:44 node51 kernel: [ 4080.180381]  [<ffffffff818211f5>] schedule+0x35/0x80
May 11 19:28:44 node51 kernel: [ 4080.180385]  [<ffffffff81824315>] schedule_timeout+0x1b5/0x270
May 11 19:28:44 node51 kernel: [ 4080.180390]  [<ffffffff810abe52>] ? default_wake_function+0x12/0x20
May 11 19:28:44 node51 kernel: [ 4080.180395]  [<ffffffff810c33b2>] ? __wake_up_common+0x52/0x90
May 11 19:28:44 node51 kernel: [ 4080.180398]  [<ffffffff81820744>] io_schedule_timeout+0xa4/0x110
May 11 19:28:44 node51 kernel: [ 4080.180412]  [<ffffffffc05afbec>] cv_wait_common+0xbc/0x140 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180416]  [<ffffffff810c3a70>] ? wake_atomic_t_function+0x60/0x60
May 11 19:28:44 node51 kernel: [ 4080.180423]  [<ffffffffc05afcc8>] __cv_wait_io+0x18/0x20 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180487]  [<ffffffffc071320e>] zio_wait+0x10e/0x1f0 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180528]  [<ffffffffc069ce66>] dsl_pool_sync+0x2c6/0x430 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180573]  [<ffffffffc06b85b6>] spa_sync+0x366/0xb30 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180576]  [<ffffffff810abe52>] ? default_wake_function+0x12/0x20
May 11 19:28:44 node51 kernel: [ 4080.180623]  [<ffffffffc06c9a4a>] txg_sync_thread+0x3ba/0x630 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180669]  [<ffffffffc06c9690>] ? txg_delay+0x180/0x180 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180676]  [<ffffffffc05aae31>] thread_generic_wrapper+0x71/0x80 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180682]  [<ffffffffc05aadc0>] ? __thread_exit+0x20/0x20 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180686]  [<ffffffff810a0588>] kthread+0xd8/0xf0
May 11 19:28:44 node51 kernel: [ 4080.180688]  [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
May 11 19:28:44 node51 kernel: [ 4080.180692]  [<ffffffff8182568f>] ret_from_fork+0x3f/0x70
May 11 19:28:44 node51 kernel: [ 4080.180694]  [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0

ext4 저널:

May 11 20:46:46 node51 kernel: [ 6000.186474] INFO: task jbd2/dm-2-8:1148 blocked for more than 120 seconds.
May 11 20:46:46 node51 kernel: [ 6000.193164]       Tainted: P           O    4.4.0-22-generic #39-Ubuntu
May 11 20:46:46 node51 kernel: [ 6000.199950] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 11 20:46:46 node51 kernel: [ 6000.208323] jbd2/dm-2-8     D ffff88060a6e7c98     0  1148      2 0x00000000
May 11 20:46:46 node51 kernel: [ 6000.208330]  ffff88060a6e7c98 0000000000000246 ffff8806133eb700 ffff88060b561b80
May 11 20:46:46 node51 kernel: [ 6000.208333]  ffff88060a6e8000 ffff88060aeb68b8 ffff88060a6e7d88 ffff88060a6e7d70
May 11 20:46:46 node51 kernel: [ 6000.208336]  ffff88060b561b80 ffff88060a6e7cb0 ffffffff818211f5 ffff8805fd6af900
May 11 20:46:46 node51 kernel: [ 6000.208339] Call Trace:
May 11 20:46:46 node51 kernel: [ 6000.208355]  [<ffffffff818211f5>] schedule+0x35/0x80
May 11 20:46:46 node51 kernel: [ 6000.208361]  [<ffffffff812ea0e0>] jbd2_journal_commit_transaction+0x240/0x1870
May 11 20:46:46 node51 kernel: [ 6000.208365]  [<ffffffff810b6be1>] ? dequeue_entity+0x431/0xa80
May 11 20:46:46 node51 kernel: [ 6000.208368]  [<ffffffff810b774a>] ? dequeue_task_fair+0x51a/0x8a0
May 11 20:46:46 node51 kernel: [ 6000.208372]  [<ffffffff810c3a70>] ? wake_atomic_t_function+0x60/0x60
May 11 20:46:46 node51 kernel: [ 6000.208378]  [<ffffffff810ec5fe>] ? try_to_del_timer_sync+0x5e/0x90
May 11 20:46:46 node51 kernel: [ 6000.208381]  [<ffffffff812ef32a>] kjournald2+0xca/0x250
May 11 20:46:46 node51 kernel: [ 6000.208384]  [<ffffffff810c3a70>] ? wake_atomic_t_function+0x60/0x60
May 11 20:46:46 node51 kernel: [ 6000.208387]  [<ffffffff812ef260>] ? commit_timeout+0x10/0x10
May 11 20:46:46 node51 kernel: [ 6000.208391]  [<ffffffff810a0588>] kthread+0xd8/0xf0
May 11 20:46:46 node51 kernel: [ 6000.208394]  [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
May 11 20:46:46 node51 kernel: [ 6000.208397]  [<ffffffff8182568f>] ret_from_fork+0x3f/0x70
May 11 20:46:46 node51 kernel: [ 6000.208399]  [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
May 11 20:46:46 node51 kernel: [ 6292.776357] perf interrupt took too long (2539 > 2500), lowering kernel.perf_event_max_sample_rate to 50000

답변1

제어 디스크는 마더보드에 내장된 SATA 포트에 연결됩니다.

명시된 바와 같이 저널 플러시 시간 초과 문제가 발생한 디스크는 '문제가 있는' Toshiba가 연결된 것과 동일한 컨트롤러인 PERC에 연결됩니다.

PERC 310은 기본적인 하드웨어 RAID 카드일 뿐입니다. CPU가 쉽게 압도당하거나 펌웨어 버그가 있을 수 있습니다. 직접 AHCI는 일반적으로 사용되지 않습니다.

IO가 OS가 아닌 PERC에서 잠기는 것을 제안합니다.

답변2

이것은 소화해야 할 것이 많습니다.

ZFS를 사용하고 있으므로 풀의 5TB 디스크 및 잠재적으로 풀 설정에 문제가 있을 가능성이 높습니다.

이는 4k 섹터 디스크일 수 있으므로 이를 고려하여 ZFS 설정에서 일부 조정이 이루어져야 합니다.

df -h, fdisk -l, 및 출력 zpool list을 제공할 수 있습니까 ?zpool status -vzfs list

답변3

블록 장치 속도에 비해 쓰기 캐시가 너무 큰 것 같습니다. 나는 다음을 제안합니다:

vm.dirty_background_bytes = 50000000
vm.dirty_bytes = 200000000
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 20

절대로 둘 다 설정하지 마십시오 *_bytes. *_ratio마지막으로 설정된 것이 승리하기 때문입니다. 또한 일부 Linux 커널 버전에는 설정이 *_ratio의도한 대로 작동하지 않는 버그가 있을 수 있습니다. *_bytes매번 사용하는 것이 좋습니다 .

불행하게도 내가 아는 한 쓰기 캐시 설정은 전역적입니다. 결과적으로 일부 느린 장치로 인해 전역 쓰기 캐시 크기를 줄여야 할 때 더 빠른 장치에 대한 처리량이 약간 저하됩니다.

관련 정보