답변:
리눅스는 기본적으로 다소 뇌 손상을 입힌 메모리 관리 개념을 가지고 있습니다. 시스템보다 많은 메모리를 할당 한 다음 문제가 발생했을 때 무작위로 프로세스를 쏴 버립니다. (살해되는 것의 실제 의미는 그보다 더 복잡합니다. Google "Linux OOM Killer"는 그것이 좋은지 나쁜지에 대한 많은 세부 사항과 인수를 제공합니다.)
온전한 유사성을 메모리 관리로 복원하려면 :
vm.oom-kill = 0/etc/sysctl.conf에 넣기 )vm.overcommit_memory = 2/etc/sysctl.conf에 넣기 ) 이러한 설정은 Linux를 전통적인 방식으로 작동하게합니다 (프로세스가 사용 가능한 것보다 많은 메모리를 요청하면 malloc ()이 실패하고 메모리를 요청하는 프로세스가 해당 실패에 대처할 것으로 예상됩니다).
컴퓨터를 재부팅하여 다시로드 /etc/sysctl.conf하거나 proc파일 시스템을 사용하여 재부팅하지 않고 즉시 활성화하십시오.
echo 2 > /proc/sys/vm/overcommit_memory
/etc/sysctl.conf하면 다음에 다시 부팅 할 때만 적용됩니다. 지금 변경 하려면 sysctl루트 권한을 가진 명령을 사용해야합니다.sudo sysctl vm.overcommit_memory=2
초과 커밋을 비활성화 할 수 있습니다 ( http://www.mjmwired.net/kernel/Documentation/sysctl/vm.txt#514 참조) .
서버의 짧은 대답은 더 많은 RAM을 구입하여 설치하는 것입니다.
일상적으로 충분한 OOM (메모리 부족) 오류가 발생하고 Linux 커널에서 VM (가상 메모리) 관리자의 초과 커밋 sysctl 옵션 외에는 서버가 좋지 않습니다.
스왑 크기 (커널 메모리 관리자가 디스크로 페이징 한 가상 메모리)를 사용하면 현재 값이 낮을 때 도움이되며 사용량에는 하나 또는 몇 개가 아닌 이러한 많은 양의 메모리가 필요한 많은 작업이 사용됩니다 사용 가능한 총 가상 메모리 (RAM + 스왑)를 요청하는 각 프로세스.
스왑으로 2 배 이상의 RAM을 할당하는 많은 응용 프로그램의 경우 스왑으로서의 RAM 양은 개선에 대한 수익 감소를 제공합니다. 일부 대규모 계산 시뮬레이션에서는 속도 저하가 견딜 수있는 경우에 적합 할 수 있습니다.
RAM (ECC 여부)이 적당한 양, 예를 들어 4-16GB에 비해 상당히 저렴하기 때문에 오랫동안이 문제를 직접 경험하지 못했습니다.
메모리 사용 패턴에 대한 가장 일반적인 두 가지 빠른 평가로 메모리 사용을 기준으로 정렬 된 free및 사용을 포함하여 메모리 소비를 보는 기본 사항 top. 따라서 최소한 해당 명령의 출력에서 각 필드의 의미를 이해해야합니다.
특정 응용 프로그램 (예 : 데이터베이스, 네트워크 서비스 서버, 실시간 비디오 처리) 및 서버 사용 (몇몇 고급 사용자, 100-1000 사용자 / 클라이언트 연결)이 없으면 처리와 관련된 일반적인 권장 사항을 생각할 수 없습니다 OOM 문제.
실제 메모리의 양을 늘리는 것이 모든 상황에서 효과적인 응답은 아닙니다.
이를 확인하는 한 가지 방법은 'atop'명령입니다. 특히이 두 줄.
이것은 건강했을 때 서버가 아닙니다.
MEM | tot 23.7G | free 10.0G | cache 3.9G | buff 185.4M | slab 207.8M |
SWP | tot 5.7G | free 5.7G | | vmcom 28.1G | vmlim 27.0G |
제대로 작동하지 않을 때 (그리고 overcommit_memory를 50에서 90으로 조정하기 전에 50G를 초과하는 vmcom의 동작, 몇 초마다 붐 킬러 프로세스가 폭발하고 NFSd 자식 프로세스가 날아가서 부하가 급격히 튀어 오릅니다. 지속적으로 다시 만들고.
최근 다중 사용자 Linux 터미널 서버가 가상 메모리 할당을 과도하게 커밋하지만 실제로 요청 된 페이지가 거의 사용되지 않는 경우가 중복되었습니다.
이 정확한 경로를 따르는 것은 좋지 않지만 오버 커밋 메모리는 기본 50에서 90으로 조정되어 일부 문제가 완화되었습니다. 우리는 모든 사용자를 다른 터미널 서버로 옮기고 다시 시작해야 전체 이점을 볼 수있었습니다.
이 버그 와 관련된 비슷한 문제가 있었고 해결책은 이전 / 최신 (고정) 커널을 사용하는 것이 었습니다.
그러나 당시 내 컴퓨터를 재부팅 할 수 없었기 때문에 어떤 종류의 추악한 해결책은 다음 명령으로 루트로 로그인하고 시스템 캐시를 지우는 것입니다.
echo 3 > /proc/sys/vm/drop_caches
@ voretaq7 linux는 두뇌 손상을 입은 메모리 관리 개념을 가지고 있지 않습니다. 기본적으로 vm.overcommit_ratio는 0입니다.
0 - Heuristic overcommit handling. Obvious overcommits of
address space are refused. Used for a typical system. It
ensures a seriously wild allocation fails while allowing
overcommit to reduce swap usage. root is allowed to
allocate slightly more memory in this mode. This is the
default.
이런 식으로 4GB의 램이 있고 가상 메모리의 malloc으로 4.2GB를 할당하려고하면 할당이 실패합니다.
vm.overcommit_ratio = 1 인 경우
1 - Always overcommit. Appropriate for some scientific
applications. Classic example is code using sparse arrays
and just relying on the virtual memory consisting almost
entirely of zero pages.
vm.overcommit_ratio = 2로
2 - Don't overcommit. The total address space commit
for the system is not permitted to exceed swap + a
configurable percentage (default is 50) of physical RAM.
Depending on the percentage you use, in most situations
this means a process will not be killed while accessing
pages but will receive errors on memory allocation as
appropriate.
Useful for applications that want to guarantee their
memory allocations will be available in the future
without having to initialize every page.
따라서 기본적으로 리눅스는 오버 커밋하지 않습니다. 애플리케이션에 더 많은 메모리가 있다면 코드가 버그 일 수 있습니다