여러 가상 머신을 실행하는 워크스테이션(Intel Xeon 시리즈 CPU 2개 및 128GiB RAM)이 있고, 결합된 CPU 사용량이 30% 미만인 반면 로드 평균은 20~25입니다. 예를 들어, 명령을 실행하면 tar -xzvf vm_data.tgz --directory vm4/ --strip-components=1프로세스는 gzipI/O에서 90% - 99%의 시간 동안 차단되고 명령을 완료하는 데 시간이 오래 걸립니다.
반면에 디스크에 대한 실제 읽기 및 쓰기는 SATA 3.0이나 SSD에 비해 매우 낮습니다(저는 단일킹스턴 SA400S37960GSSD) 하드웨어 제한 사항.
gzip실제 디스크 읽기 및 쓰기가 매우 낮은 것처럼 보이는데 프로세스(제 예에서는)가 I/O 이후 대기하게 만드는 원인은 무엇입니까 ? 내 첫 번째 생각은 시스템 인터럽트가 매우 높아 I/O가 차단되는 이유일 수도 있지만 /proc/interrupts매우 빠르게 증가하는 카운터가 없기 때문에 그렇지 않은 것 같습니다.
답변1
~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의 답변을 참조하세요.
답변2
몇 년 전, 저는 프로덕션 MySQL 데이터베이스에서 매우 유사한 문제에 직면했습니다. 파일이 너무 조각화되어 백업하면 다른 모든 디스크 작업이 완료되지 않는 것으로 나타났습니다.
다음 출력을 게시하십시오.
find vm4 -type f | while read filename; do sudo filefrag "$filename" | egrep -v ": 1 extent|: 0 extents"; done | sort
이 문제를 해결하려면 제 추측이 맞다면 가상 머신 파일의 조각 모음을 수행해야 합니다.
답변3
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가 설명하는 동작은 실제이지만 최근에 도입된 것 같습니다.