운영 체제가 실패한 드라이브에 계속 쓰려고 하지 않도록 IO 대기 시간과 재시도를 어떻게 줄일 수 있습니까?
저는 데모 컨텐츠의 복사본을 만들어 고객에게 빌려주고 일반 SATA 데스크탑 하드 드라이브에 저장하는 시스템을 보유하고 있습니다. SAS를 통해 여러 드라이브를 동시에 연결하고 스크립트를 사용하여 콘텐츠를 복사합니다.
드라이브를 대여했기 때문에 때로는 일부 드라이브가 손상되기도 하지만 손상되었는지 알 수 없으므로 다음에 드라이브를 복사 작업에 재사용할 때 시스템이 해당 드라이브에 대한 IO를 다시 시도하면 속도가 느려집니다. 다른 드라이브 속도. 때로는 손상된 드라이브를 발견하고 삭제하는 데 몇 시간이 걸릴 수도 있습니다. 드라이브를 제거한 후 나머지 드라이브는 정상 속도로 쓰기 시작했습니다.
불량 드라이브를 복구하는 데는 관심이 없습니다. 다른 모든 것의 속도를 늦추지 않도록 그것들을 지우기만 하면 됩니다.
또한 배드 블록과 smartmontools도 살펴보고 글을 쓰기 전에 드라이브를 사전 점검하는 것도 고려하고 있습니다.
운영 체제: Ubuntu Linux(12.04lts)
답변1
이전에 이 조정 가능 항목을 사용한 적이 없지만 조정하고 싶을 수도 있습니다.uh_timeout(오류 처리 시간 초과) 드라이브 문제:
[root@localhost device]# cat /sys/block/sda/device/eh_timeout
10
[root@localhost device]#
위의 표시는 sda10초로 설정되어 있습니다. Red Hat 기술 자료에서:
일부 저장소 구성(예: LUN이 많은 구성)에서는 SCSI 오류 처리 코드가 응답하지 않는 저장소 장치에 TEST UNIT READY와 같은 명령을 실행하는 데 많은 시간을 소비할 수 있습니다. 새로운 sysfs 매개변수 eh_timeout이 SCSI 장치 객체에 추가되었습니다. 이를 통해 SCSI 오류 처리 코드에서 사용되는 TEST UNIT READY 및 REQUEST SENSE 명령에 대한 시간 초과 값을 구성할 수 있습니다. 이렇게 하면 응답하지 않는 장치를 확인하는 데 소요되는 시간이 줄어듭니다. eh_timeout의 기본값은 10초이며, 이 기능이 추가되기 전에 사용된 제한 시간 값이었습니다.
답변2
/sys/block/<dev>/stat관심 있는 디바이스를 모니터링하여 10번째 파라미터(io_ticks)를 비교해 보세요.
예를 들어,ticks = io_ticks - prev_ticks / seconds_deltatime / 10
이는 디스크 io가 사용 가능해질 때까지 디스크가 대기하는 데 소비한 시간의 백분율입니다.
물론 100%에 가까워지는 것은 확인해 볼 가치가 있고, 정말 현명하게 모든 디스크의 평균과 비교하여 평균보다 높은 디스크를 선택하는 것도 가치가 있습니다.
보다블록 수준 통계 문서.
아니면 무닌(Munin) 같은 것을 이용해 그래프로 그려보세요. Munin이 임계값(예: 90% 또는 차트에 좋은 경고 숫자로 표시되는 모든 항목)을 초과하는 경우 경고를 발생시키도록 할 수 있습니다.
예를 들어, /dev/sdi를 확인해야 함을 보여주는 두 개의 Munin 다이어그램을 참조하세요. 이 예에서 /dev/sdi가 배열의 일부인 경우 전체 배열이 영향을 받습니다.
주간 차트를 보면 /dev/sdc도 느려질 수 있음을 알 수 있습니다.
위의 /dev/sdi는 손상되지 않았다는 점을 덧붙여야 합니다. 이는 단지 느린 디스크(실제로는 누군가 기업용 SATA 디스크 어레이에 추가한 녹색 디스크)일 뿐이며 어레이 속도를 늦추고 있습니다. 실제 고장난 디스크는 엄지 손가락처럼 튀어 나올 것입니다.
전체적으로 시간이 있다면 아마도 스크립트를 사용할 것입니다. 그러나 빠른 솔루션을 원하고 서버에 연결하기 쉬운 경우에는 Munin이 그 트릭을 수행할 것입니다.