시스템 부하가 높을 때 I/O로 인해 프로세스가 차단되는 이유는 무엇입니까?

~40G를 보여주는 보고서로 시작하세요.무료기억(정확히는 아닌 것으로 알고 있습니다.쓸 수 있는메모리 하지만 빠르고 복잡한 계산을 위해 40G를 사용하도록 합시다. 버퍼/캐시는 12G를 차지했으며 세부 정보가 제공되지 않았으므로 더티 데이터로 가득 차 있음을 인정합니다.

vm.dirty_ratio의 기본값은 20%이고 20%는 40G = 8G < 12G이기 때문입니다...

귀하의 시스템이 자체적으로 다시 쓰기하는 명령 프로세스의 한계를 초과하여 실행되고 있는 것 같습니다. 즉, 이슈차단하다썼다.

그런 다음 시스템의 실제 한계가 무엇인지 확인합니다.

$ sysctl -a | grep dirty

vm.dirty_ratio가 실제로 기본값인 경우 이를 늘리십시오. (80%까지 쉽게 올라갈 수 있으므로 걱정할 필요가 없습니다. 제 기억이 맞다면 Oracle은 항상 이 값을 권장합니다.)

이렇게 하면 일반적으로 기본값이 10인 동반 항목(vm.dirty_Background_ratio)도 낮출 수 있습니다. 저지연 시스템에서는 가능한 가장 낮은 값(1)을 권장하며 개인적으로 3으로 설정했습니다. 이렇게 하면 쓰기 저장 데몬이 더 빠르게 작동할 수 있어 캐시가 dirty_ratio 고정 제한을 초과하는 지점이 지연됩니다.

디렉토리 구조의 해당 항목에 값을 반영하여 임시 변경을 할 수 있습니다 /proc/sys/vm/. 이러한 변경 사항을 영구적으로 적용하려면(재부팅 후) 편집할 수 있습니다./etc/sysctl.conf

이것이 프로세스 차단의 직접적인 원인이며 장치에 쓰기가 너무 느려서 캐시 채우기가 dirty_ratio 제한을 초과하는 이유입니다. artem-s-tashkinov의 답변을 참조하세요.

몇 년 전, 저는 프로덕션 MySQL 데이터베이스에서 매우 유사한 문제에 직면했습니다. 파일이 너무 조각화되어 백업하면 다른 모든 디스크 작업이 완료되지 않는 것으로 나타났습니다.

다음 출력을 게시하십시오.

find vm4 -type f | while read filename; do sudo filefrag "$filename" | egrep -v ": 1 extent|: 0 extents"; done | sort

이 문제를 해결하려면 제 추측이 맞다면 가상 머신 파일의 조각 모음을 수행해야 합니다.

Centos7(3.10.0.1062)에서 ElRepo kernel-ml(5.11.6)으로 전환한 후 이 사실을 발견했습니다. 쓰기 저장 속도가 약 10배(2Mb/초에서 20Mb/초로) 증가했지만 Samsung NVMe 400G 드라이브를 사용하고 있었습니다. 2000Mb/sec 이상을 처리할 수 있으므로 더 좋을 것으로 예상했습니다. 그런 다음 ext4 마운트를 "nodelalloc,dioread_nolock"으로 전환했고 이제 쓰기 저장 속도가 1500Mb/초를 넘었습니다. RAM이 512GB이고 dirty_Background_ratio = 10, dirty_ratio = 20이므로 중간 크기(30-50kb) 파일이 많은 대용량 폴더의 압축을 풀면 더티 페이지가 50GB 이상으로 늘어납니다(속도는 약 500Mb/초, 내 소스에 따라 제한됨). HDD RAID 속도) 갑자기 쓰기 저장이 약 35초 동안 1500+Mb/초로 발생합니다. 35초 이상의 쓰기 저장 기간 동안 tar 작업은 CPU 0% 및 IO 0%로 떨어졌습니다. 커널 스레드에 다시 쓰기에 대한 작업에는 잠금이 필요하며 이는 tar 쓰기 시스템 호출에서도 필요하며 이 동작은 Centos7(3.10.0.1062)에서는 전혀 존재하지 않습니다.

따라서 OP가 설명하는 동작은 실제이지만 최근에 도입된 것 같습니다.