이 문제에 대한 나의 견해는 개발자 측입니다. 저는 엔터프라이즈 시스템의 여러 시스템 중 하나로 실행되는 RHEL 가상 머신에 배치되는 코드를 작성합니다. 사용 중인 파일 시스템은 원격 네트워크 연결 저장 장치입니다.
일괄 처리 중에 간단한 명령에 대한 변동성이 다소 높았습니다. 그래서 우리는 더 많은 정보를 얻기 위해 테스트를 준비했지만 지금은 우리가 무엇을 발견했는지 모르겠습니다.
30분마다 다음 명령을 실행하고 출력을 기록했습니다. 6GB 파일의 복사본입니다. 내가 보는 것은 시스템이 많은 작업을 실행 중이고 이 테스트 명령의 CPU 시간이 낮아질 때 경과 시간이 11초에서 190초로 점프하는 것입니다.
내가 볼 수 있는 것은 CPU가 낮을 때 열 "I"(파일 시스템 입력)가 채워지고 높을 때는 채워지지 않는다는 것입니다. 열 "w"(비자발적 스왑)도 훨씬 더 높습니다.
제 질문은 CPU 시간이 줄어들 때 너무 오래 실행되도록 하는 이 작업/명령에 무슨 일이 일어나고 있는 걸까요? 스왑 인/아웃은 훨씬 느린 다른 장치에 해당 데이터를 모두 저장합니까? 일반적으로 스왑 인/아웃 중에는 어떤 일이 발생합니까?
실행 중인 명령:
/usr/bin/time -a -o filename.txt cp file.txt fileCopy.txt
| 날짜 | 시간 | 이자형 | 에스 | 유 | 피 | 씨 | 승 | 나 | 영형 |
|---|---|---|---|---|---|---|---|---|---|
| 2022년 3월 14일 | 5:19:02 | 64.9 | 16.23 | 1.03 | 26% | 3005 | 29210 | 12000016 | 12000000 |
| 2022년 3월 14일 | 5:49:02 | 12.7 | 11.63 | 0.79 | 97% | 2069 | 76 | 0 | 12000000 |
| 2022년 3월 14일 | 6:19:02 | 100.39 | 14.74 | 0.78 | 15% | 1034 | 29925 | 12000136 | 12000000 |
| 2022년 3월 14일 | 6:49:24 | 191.32 | 18.86 | 0.94 | 10% | 3374 | 36164 | 12001024 | 12000000 |
| 2022년 3월 14일 | 7:19:02 | 71.61 | 15.61 | 0.88 | 23% | 1610 | 30316 | 12000296 | 12000000 |
| 2022년 3월 14일 | 7:49:02 | 70.73 | 17.5 | 0.91 | 26% | 1408 | 29540 | 12000072 | 12000000 |
| 2022년 3월 14일 | 8:19:02 | 10.95 | 9.89 | 0.7 | 96% | 1709년 | 75 | 0 | 12000000 |
| 2022년 3월 14일 | 8:49:02 | 11.01 | 10.22 | 0.73 | 99% | 239 | 85 | 0 | 12000000 |
/usr/bin/time 매뉴얼 페이지의 열 설명
e Elapsed real time (in seconds).
S Total number of CPU-seconds that the process spent in kernel mode.
U Total number of CPU-seconds that the process spent in user mode.
P Percentage of the CPU that this job got, computed as (%U + %S) / %E.
c Number of times the process was context-switched involuntarily (because the time slice expired).
w Number of waits: times that the program was context-switched voluntarily, for instance while waiting for an I/O operation to complete.
I Number of filesystem inputs by the process.
O Number of filesystem outputs by the process.
답변1
이 맥락에서 P는 총 경과 시간에 대한 이 작업의 CPU 시간 비율을 의미합니다. 100%에 가깝다는 것은 CPU에 있었던 거의 모든 시간을 의미하므로 해당 실행에 대해 CPU가 제한되었습니다. 다른 것이 제한 요소인 다른 실행과는 대조적입니다. I/O가 많은 작업의 일반적인 경우처럼 시스템 시간보다 시스템(커널이라고도 함) 시간이 더 많습니다.
워크로드가 6GB 파일을 복사한 경우 11초 실행이 초당 평균 0.5GB 이상의 쓰기를 수행했다고 추론할 수 있습니다. O 열은 단일 파일 복사 프로세스와 일치하여 매번 동일한 쓰기 수를 확인합니다.
그러나 입력 열에는 큰 변화가 있습니다. 느린 실행은 쓰기와 거의 동일한 읽기를 수행합니다. 그러나 빠른 실행에서는 읽기가 수행되지 않습니다! 파일이 마지막으로 읽혀졌을 때부터 여전히 RAM에 캐시되어 있다고 가정합니다. DRAM은 솔리드 스테이트 스토리지보다 훨씬 빠릅니다. 이는 메모리 부족으로 인해 OS가 캐시된 데이터를 삭제하고 느린 저장소에서 다시 읽어야 할 때까지 속도가 크게 향상되었습니다.
따라서 이는 200초 작업이며 때로는 12초가 걸릴 수도 있습니다. Linux 페이지 캐시 때문일 수 있습니다.
성능 문제의 근본 원인을 찾으려면 특정 지표 세트를 넘어 전체 시스템에 대한 더 깊은 이해가 필요한 경우가 많습니다.
사용 중인 파일 시스템은 원격 네트워크 연결 저장 장치입니다.
복사본은 네트워크로 연결된 저장소를 통해 있으므로 원격 시스템이나 그 사이의 네트워크에 있는 모든 것일 수도 있습니다. 원격 스토리지 성능. 네트워크(아마도 IP) 속도 및 활용도. 또는 게스트가 인프라에서 실행되는 다른 모든 항목과 리소스를 놓고 경쟁하는 이 VM에 로컬일 수도 있습니다.
사물이 어떻게 작동하는지 더 깊이 파고드는 것이 항상 가능합니다. 네트워크 스토리지(NFS?)가 전혀 중요합니까, 아니면 로컬 디스크에서도 이것을 볼 수 있습니까? 0.7초의 사용자 CPU 시간은 실제로 상당한 작업입니다. 많은 시스템 호출을 관리하는 데 얼마나 많은 시간이 소요됩니까? 대부분의 CPU가 느린 메모리와 매우 느린 스토리지를 기다리고 있을 때 CPU 사용량이 실제로 무엇을 의미합니까? 대답하기 쉬운 질문은 아니지만 일단 작업이 적절하게 수행되면 너무 깊게 파고들 필요는 없을 것입니다.