☰

이상한 I/O 지연이 전체 데스크탑에 영향을 미침

tag-icon • tag-icon io delay
이상한 I/O 지연이 전체 데스크탑에 영향을 미침

최근 하드웨어 마이그레이션 후 데스크탑 Debian Stretch 시스템에 영향을 미치는 이상한 I/O 일시 중지를 경험하기 시작했습니다. 각 정지 중에 발생하는 일반적인 증상은 다음과 같습니다.

  • 웹 브라우저 Chromium과 상호작용할 수 없습니다. 아무 것도 작동하지 않습니다: 웹 페이지 스크롤(보통 이것이 일시 정지를 확인하는 방법입니다), 탭 전환 등. 웹이나 Chromium UI에서는 마우스 오버 동작도 없습니다.

  • 가상 터미널 내에서는 더 이상 새 프로세스를 실행할 수 없습니다. 예를 들어, 새 탭을 열었 mate-terminal지만 쉘이 표시되지 않고 커서만 깜박입니다. 중지되기 전에 셸이 열려 있던 터미널에서 명령을 입력할 수 있지만 일반적으로 시작되지 않습니다 sudo something.

  • RStudio와 같은 다른 프로그램은 디스크에 아무것도 저장할 수 없으며 저장하려고 할 때 종종 중단됩니다.

  • journald -f일시 중지가 충분히 길면 journald자동으로 다시 시작된다는 것을 로그에서 볼 수 있습니다 . 예를 들면 다음과 같습니다.

      sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Main process exited, code=killed, status=6/ABRT
  sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Unit entered failed state.
  sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Failed with result 'watchdog'.
  sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Service has no hold-off time, scheduling restart.
  sty 30 14:03:54 liori-pc systemd[1]: Stopped Flush Journal to Persistent Storage.
  sty 30 14:03:54 liori-pc systemd[1]: Stopping Flush Journal to Persistent Storage...
  sty 30 14:03:54 liori-pc systemd[1]: Stopped Journal Service.
  sty 30 14:03:54 liori-pc systemd[1]: Starting Journal Service...
  sty 30 14:03:54 liori-pc systemd-journald[23935]: Journal started
  sty 30 14:03:54 liori-pc systemd-journald[23935]: System journal (/var/log/journal/2318080f60e357aaf765e98d0000035c) is 2.1G, max 4.0G, 1.8G free.

  • dm_crypt를 사용할 때 하나의 dmcrypt_write프로세스가 단일 CPU 코어의 100%를 차지하기 시작했습니다. 이후 이 시스템에서 dm_crypt를 제거했지만 정지 현상이 계속 발생합니다.

  • 나는 /proc/meminfo이 Dirty숫자가 몇 메가바이트를 초과하지 않는다는 것을 관찰했습니다. 정지 중에 이 숫자가 변경되지 않는다는 점은 주목할 가치가 있습니다.

  • 드문 경우지만 "정보: "일부 프로세스" 작업이 120초 이상 차단되었습니다"라는 형식의 커널 메시지를 받기도 합니다. 여기서 "일부 프로세스"는 일반적으로 mdX_raid5, chromium 또는 해당 스레드 중 하나입니다.로그 예시.

처음에 내 설정은 단일 1TB 드라이브(현재) 파티션에 단일 600GB ext4 파일 시스템이었습니다 /dev/sdd. 그런 다음 LVM 기반 raid5, bcache(캐시가 SSD 드라이브에 있음), dm_crypt를 사용하여 3×6TB 드라이브( )로 옮겼습니다 /dev/sd{b,c,e}. 이때 정체가 시작되었습니다. 디버깅하는 동안 LVM-raid5로 단순화했으며 bcache나 dm_crypt는 여전히 중단되지 않지만 지금은 덜 자주 발생하는 것 같습니다.

이 실속은 하루에 여러 번 발생하며 일반적으로 몇 분 동안 지속됩니다. 나는 특정 디스크 작업을 명시적으로 요청하여 이를 깨뜨릴 수 있다는 것을 알아냈습니다. 때로는 원격 시스템에서 해당 시스템으로 SSH를 통해 연결하거나 (거의 항상) cat /dev/sdb >/dev/null또는 cat /dev/sdc >/dev/null(때로는 하나, 때로는 다른 하나가 작동하지 않음) 로 깨뜨릴 수 cat /dev/sde >/dev/null있습니다 . 도움이 됩니다). 그러자 멈춰 있던 모든 것이 갑자기 다시 움직이기 시작했습니다.

따라서 문제는 다음 중 하나 또는 상호 작용으로 인해 발생한 것으로 의심됩니다.

  • 하드 드라이브: 세 개의 하드 드라이브는 모두 Seagate Skyhawk ST6000VX0023입니다. 그 중 두 개는 이 설정에서 이전에 사용되지 않았으며 세 번째는 반년 된 것입니다( /dev/sdc).
  • 디스크 컨트롤러: 마더보드:Gigabyte Z68X-UD3H-B3두 개의 컨트롤러가 있습니다. Marvell 88SE9172드라이브 중 하나는 칩셋 내장 컨트롤러( Intel® Z68)에 연결되고 다른 두 개의 컨트롤러는 소프트웨어에서 확인할 수 있습니다(어느 것이 어디에 있는지 확인할 수 있습니까?).
  • 컨트롤러 커널 드라이버의 일부 버그.
  • LVM 또는 raid5의 일부 버그.

이것은 몇 가지 백포트된 패키지, 특히 커널이 설치된 Debian Stretch 시스템입니다 4.19.0-0.bpo.1-amd64. 인텔 코어 i7-2600k, 16GB RAM.

이 시점에서 나는 아이디어가 부족했습니다. 이 문제를 추가로 디버깅하려면 어떻게 해야 합니까?

편집: 4초마다 이 드라이브 중 하나에서 임의의 섹터를 읽는 스크립트를 시작했는데, 지금까지 중단 없이 2일이 지났습니다. 따라서 일부 시스템 구성 요소(LVM? raid?)가 필요할 때 일부 저전력 모드에서 장치를 제대로 깨우지 못하는 것 같습니다.

편집: 더 이상 이 시스템에 접근할 수 없으므로 더 이상 어떤 가설도 테스트할 수 없습니다. 제가 말할 수 있는 것은 이 스크립트를 실행한 후에는 더 이상 일시 중지가 발생하지 않는다는 것입니다. 그러나 디버깅하는 방법을 알고 싶습니다.

답변1

6TB 모델에서 Seagate Skyhawk 모델의 "준비 대기" 시간은 23~30초입니다. 1TB 모델의 경우 이 수치는 6밀리초입니다. 2TB로 전환하면 지연 시간이 크게 늘어납니다. 귀하의 드라이브가 유휴 상태로 전환되어 I/O만 버퍼링하고 드라이브에 쓰려고 하면 회전하는 동안 정지되는 것 같습니다.

드라이브는 활성, 유휴, 대기 및 절전의 4가지 전원 관리 모드를 지원합니다. 매뉴얼의 관련 부분설명하다:

"드라이브가 활성 기능(읽기, 쓰기 또는 탐색)을 수행할 때마다 대기 타이머가 다시 초기화되고 지정된 지연 시간부터 0까지 카운트다운이 시작됩니다. 드라이브 활동이 필요하기 전에 대기 타이머가 0에 도달하면 드라이브는 드라이브는 유휴 및 대기 모드에 있는 동안 대기 모드로 전환되고, 디스크 액세스가 필요할 때 활성 모드로 돌아갑니다."

Linux 내에서 대기 모드를 제거하기 위해 전원 관리 모드를 변경하는 것은 쉽지 않습니다. 드라이브 공급업체는 이러한 종류의 유틸리티를 제공하지만 일반적으로 ISO를 부팅하거나 Windows 전용 유틸리티를 사용해야 합니다. hdparm을 사용하여 대기 시간 초과를 조정하는 데 성공했습니다.시작하기 튜토리얼.

관련 정보