해결할 수 없는 컴퓨터 정지 문제가 있습니다. 나는 세 대의 동일한 컴퓨터를 가지고 있습니다. 모두 맞춤형으로 제작되었으며 i7 및 64GB RAM이 장착되어 있습니다. OS 드라이브는 512GB NVME 드라이브입니다. 이들은 각각 커널 v3.10과 함께 CentOS v7.8.2003을 실행합니다. 저는 대량의 데이터를 저장하고 처리한 다음 다시 저장하는 맞춤형 소프트웨어를 실행하고 있습니다.
관련될 수 있는 운영 체제에 대해 수행된 사용자 정의 구성을 표시합니다.
사용자 정의 fstab:
UUID=xxxxxx / ext4 noatime,nodiratime,discard 1 1
UUID=xxxxxx swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults,noatime,mode=1777 0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
LABEL=drive1 /data/drive1 auto noatime,nodiratime,discard,nofail 0 0
LABEL=drive2 /data/drive2 auto noatime,nodiratime,discard,nofail 0 0
LABEL=drive3 /data/drive3 auto noatime,nodiratime,discard,nofail 0 0
LABEL=drive4 /data/drive4 auto noatime,nodiratime,discard,nofail 0 0
LABEL=drive5 /data/drive5 auto noatime,nodiratime,discard,nofail 0 0
LABEL=drive6 /data/drive6 auto noatime,nodiratime,discard,nofail 0 0
사용자 정의 sysctl.conf:
vm.swappiness=1
vm.vfs_cache_pressure=50
소프트웨어에 대해 너무 자세히 설명하고 싶지는 않지만 중요한 점은 데이터를 매우 빠르게 수신한다는 것입니다. 데이터는 마더보드에 직접 연결된 5개의 SATA SSD에 저장됩니다. (5개를 병렬로 쓰는 것이 데이터 유입을 따라 쓰기 속도를 유지할 수 있는 유일한 방법입니다.) 데이터는 큰 청크(파일)로 저장하고 나중에 처리한 다음 여섯 번째 SATA SSD에 저장합니다. 일부 소프트웨어가 어떻게 작동하는지 자세히 알지 못하지만 일부 프로세스가 공유 메모리의 큰 부분을 사용한다는 것은 알고 있습니다.
문제: 새로운 데이터 덩어리가 들어올 때 PC가 정지되는 경우가 있습니다. 이 동결은 복구할 수 없으며 하드 재부팅이 필요합니다. 발생 시간은 무작위이지만 항상 새 데이터 수집이 시작될 때 발생합니다. 소프트웨어 매개변수를 변경하고 특정 프로세스를 활성화/비활성화하면 정지 발생 빈도에 영향을 줄 수 있습니다. 하지만 이는 특정 프로세스와 관련이 없는 것 같아서 범위를 좁힐 수는 없습니다. 이러한 일이 발생할 가능성을 높이는 몇 가지 구성이 있습니다. 문제를 일관되게 재현할 수 있는 특정 구성을 찾았으므로 적어도 테스트에는 도움이 됩니다.
소프트웨어를 작성한 개발자와 협력했지만 컴퓨터를 정지시킬 수 있는 문제를 찾을 수 없었습니다. 또한 소프트웨어의 메모리 누수를 테스트했지만 아무 것도 찾을 수 없었습니다.
제가 보기엔 이 모든 것이 메모리 문제를 가리키는 것 같습니다. 그러나 실제로 메모리 문제를 찾을 수 없습니다. Gnome의 명령줄과 시스템 모니터에서 top과 free를 사용했지만 메모리 문제의 징후는 없습니다. CPU 부하도 그리 높지 않고 PC는 64GB RAM의 절반도 사용하지 않습니다. 이것이 메모리 문제라면 뭔가 빠졌거나 모니터링하고 로깅하기에는 너무 빠르게 발생하고 있는 것입니다.
이제 문제의 핵심으로 넘어가겠습니다. 절박한 마음에 제 파트너 중 한 명이 이렇게 했습니다.
vm.overcommit_memory=2
vm.overcommit_ratio=80
이렇게 하면 문제가 해결되는 것 같습니다. 더 이상 정지 상태를 재현할 수 없습니다. 문제를 재현하기 위한 단계를 수행하는 동안 메모리를 모니터링해 보면 이상한 점은 발견되지 않습니다. 어떤 프로세스도 충돌하지 않았으며 소프트웨어는 단순히 설계된 대로 수행되었습니다. 이로 인해 정지 원인은 소프트웨어가 아니라 PC의 비정형 사용과 관련하여 운영 체제가 구성되는 방식이라고 생각됩니다.
문서를 읽었지만 overcommit_memory 변경이 시스템의 다른 부분에 어떤 영향을 미치는지 또는 변경하려는 시기에 대한 예를 제공하는 것은 도움이 되지 않습니다. 더 많은 정보를 얻기 위해 포럼을 살펴봤지만 대부분 "무슨 일을 하고 있는지 모르면 건드리지 마세요"라는 내용을 발견했습니다. 또한 너무 많은 메모리가 요청되면 OOM이 중요한 프로세스를 종료할 수도 있다는 점도 걱정됩니다.
overcommit_memory 설정을 언제 변경하고 싶은지 알려주실 수 있나요? 내 상황이 당신이 바꿔야 할 상황인가요? 그렇다면 시스템의 다른 측면에 어떤 영향을 미치는지 알아야 합니까?
답변1
먼저, 내가 할게OOM에 대한 참조가 있는지 로그를 확인하세요.. 너무 늦을 때까지 메모리 소비의 증가를 보지 못할 수도 있고, 프로그램이 갑자기 한 번에 많은 메모리를 소비하려고 한다면 너무 늦을 수도 있습니다.
두번째,시스템이 정지된 경우 원인을 분석하는 가장 좋은 방법은 다음을 활성화하는 것입니다.커널 크래시 덤프전진, 그런 다음 사용SysRq 매직 키(이 경우 ALT-SysRq-c키보드의 조합을 사용하십시오.) 추후 분석을 위해 커널의 코어 덤프를 생성하십시오.
에 대해 다음 overcommit_memory에서 읽을 수 있습니다 man 5 proc.
/proc/sys/vm/overcommit_memory
이 파일에는 커널 가상 메모리 계산 모델이 포함되어 있습니다. 값은 다음과 같습니다.
0: heuristic overcommit (this is the default) 1: always overcommit, never check 2: always check, never overcommit모드 0에서
mmap(2), 호출은MAP_NORESERVE확인되지 않으며 기본 확인은 매우 약합니다.프로세스가 "OOM 종료"될 위험이 있습니다.모드 2(Linux 2.6부터 사용 가능)에서 할당 가능한 총 가상 주소 공간( 의 CommitLimit
/proc/mem‐info)은 다음과 같이 계산됩니다.CommitLimit = (total_RAM - total_huge_TLB) * overcommit_ratio / 100 + total_swap
많은 프로그램은 커널이 허용하는 만큼의 메모리를 할당하려고 시도하며( overcommit기본값이 0인 경우 매우 클 수 있음) 해당 메모리가 실제로 물리적으로 사용 가능한지 여부를 확인하지 않고 사용합니다 OOM-killer. 발동될 위험이 있습니다. 2 인 경우 커널은 RAM의 전체 크기, 스왑 영역 및 값을 기반으로 애플리케이션이 할당(매핑)할 수 있는 overcommit메모리 양을 제한합니다.overcommit_ratio줄이다OOM을 실행할 가능성이 있습니다.
메모리를 올바르게 관리하는 많은 응용 프로그램은 커널이 요청을 따르지 못 mmap(2)하더라도 죽지 않으며 커널이 할당하도록 허용한 메모리만 사용합니다.
꼭 읽어보시길 권합니다이 문서의 섹션 9.6 - "과잉 커밋 및 OOM"overcommit2로 변경하면 테스트 코드의 동작에 어떤 영향을 미치고 OOM에 의해 종료되는 것을 방지하는 실제 예입니다.