충돌이 발생하고 있습니다(하루에 약 0.5회). 메모리 사용량이 약 40%에서 100%까지 올라가고 1~2초 동안 아무 것도 부팅되지 않고 시스템이 정지됩니다. 나는 반응할 시간이 없었다. 스왑은 사용되지 않습니다. 이 문제의 원인을 확인하기 위해 로그를 보고 싶지만 격리된 프로세스에 대한 메모리 사용량 로그를 어디서 찾을 수 있는지 잘 모르겠습니다.
답변1
이는 메모리 사용량이 급격히 증가하는 일부 서버에서 데이터를 수집하기 위해 몇 년 전에 수행한 작업입니다. 내 서버는 이 작업을 몇 분 만에 수행했기 때문에 기술이 데이터를 캡처할 수 있었습니다. 단 몇 초 만에 메모리 사용량이 급증한다면 그다지 유용하지 않을 수 있습니다.
나는 top
배치 모드를 사용하고 메모리 사용량에 따라 15초마다 처음 30개의 프로세스를 파일에 씁니다. 이 파일은 메모리 급증 이벤트 이후 메모리 사용량이 증가한 프로세스와 대략 다음과 같이 메모리 사용량이 얼마나 빨리 증가했는지 보여줍니다.
LINES=30 COLUMNS=160 top -b -c -o RES -d 15 -n 40 -w >> /path/to/output.txt
옵션:
top
보고하는 프로세스 수와 프로세스당 표시하는 명령줄 수를 처리하는 방법에는 몇 가지 특이한 점이 있습니다. COLUMNS
변수도 ROWS
그 일부입니다. -w
마지막 옵션으로 설명하겠습니다.
-b
라인의 요약 블록 및 프로세스당 라인의 출력이 강조 표시되거나 페이지 지정되지 않아 출력 파일에 적절하게 추가되는 배치 모드를 선택하십시오.-c
각 프로세스 라인의 명령 표시를 전환합니다. 일반적으로 각 프로세스에 대한 기본 명령(예: )을top
표시하도록 구성되며 인수(예: )가 포함된 전체 명령줄을 표시하도록 변경됩니다 . 이것은 나처럼 서버에 2~3개의 Java 프로세스가 있고 그 중 어느 프로세스가 메모리 급증을 겪고 있는지 알아야 하는 경우에 유용합니다.unattended-upgrades
-c
/usr/bin/python3 /usr/share/unattended-upgrades/...
-o RES
메모리 사용량을 기준으로 각 프로세스의 행을 가장 큰 것부터 가장 작은 것까지 정렬합니다. 메모리는 KiB 단위로 측정됩니다. 또 다른 접근 방식은-o %MEM
메모리 사용량을 전체 메모리의 백분율로 제공하는 것입니다.-d 15
각 검사 프로세스(및 출력 라인 버스트) 사이에는 15초의 지연이 있습니다. 이는top
분당 4번의 검사를 의미합니다.-n 40
40개의 샘플을 선택하면top
명령이 종료됩니다. 총 40개의 샘플(분당 4개)은 최대 실행 시간 10분과 종료를 의미합니다.-w
명령 매개변수가 잘리지 않도록 각 프로세스에 대해 "넓은"(긴) 행을 선택하십시오.-w
열을 지정하는 매개변수를 허용할 수 있지만 이렇게 하면top
한 줄이 작성됩니다 .모두프로세스는 처음 30개 프로세스뿐만 아니라 명령을 단순하게 유지 하고 top에 넓은 줄을 표시하고 메모리 사용량이 가장 높은 30개의 프로세스만 표시하도록 접두사-w
를 붙입니다 . 매뉴얼 페이지에는 변수 설정 시 이 옵션이 필요하지 않다고 나와 있지만 무시되고 모든 프로세스에 출력되는 것으로 보입니다. 이 옵션은 뒤에 다른 옵션이 있는 경우 top이 유효하지 않은 인수에 대해 불평하기 때문에 마지막에 배치됩니다. 필요에 따라 합계 값과 합계 수를 조정합니다.top
LINES=30 COLUMNS=160
-w
LINES
COLUMNS
top
LINES
-w
LINES
COLUMNS
-d
-n
유용할 수 있는 다른 옵션:
-E
요약 행에서 메모리 비율을 변경합니다.-E m
MiB를 선택한 다음-E g
GiB를 선택합니다. 그러나 각 프로세스에 대한 행이 아닌 요약 행만 있습니다.-u username
각 프로세스 라인을 사용자로 실행되는 라인으로 제한username
-p pid,pid
각 프로세스 행을 목록의 프로세스 ID로 제한합니다.
매뉴얼 페이지는 옵션에 대한 추가 필드 이름을 top
포함하여 위 옵션에 대한 자세한 정보를 제공합니다 ( 필드 이름의 빠른 목록을 보려면 실행).-o
top -O
top 명령을 사용하여 스크립트를 작성하고 10분마다 cron에서 스크립트를 호출했습니다. 장기 실행 백그라운드 프로세스로 작동하기 위해 셸 스크립트를 작성할 필요는 없지만 이미 실행 중인 프로세스에서 발생하는 메모리 스파이크를 포착하는 이점을 얻을 수 있습니다.
각 샘플에는 요약 정보가 포함된 라인 블록, 1~2개의 빈 라인 및 30개의 프로세스 라인이 있으므로 출력 파일은 소프트웨어로 쉽게 구문 분석할 수 없습니다. 하지만 당시에는 수동으로 파일을 확인하는 것만으로도 충분했습니다. 작은 승리: 요약 줄에는 타임스탬프가 내장되어 있어 피크 이벤트 직전에 파일의 일부를 찾는 데 매우 유용합니다.
Linux 시스템에서 개별 프로세스의 메모리 소비를 캡처하는 다른 방법이 있을 수 있으며 이 방법보다 더 나을 수도 있습니다. 나는 단지 나에게 맞는 방법을 전달하는 것뿐입니다. 그것이 당신에게도 효과가 있기를 바랍니다.