Rsync가 단일 50GB 파일에서 Linux OOM 킬러를 트리거함

Question 1

이제 oom-killer 출력을 읽고 거기에서 무엇을 배울 수 있는지 살펴보겠습니다.

OOM 킬러 로그를 분석할 때 로그를 촉발한 원인을 살펴보는 것이 중요합니다. 로그의 첫 번째 줄은 몇 가지 단서를 제공합니다.

[커널] [1772321.850644] clamd가 oom-killer를 호출했습니다.gfp_mask=0x84d0, 순서=0

order=0얼마나 많은 메모리가 요청되고 있는지 알려줍니다. 커널의 메모리 관리는 2의 거듭제곱으로만 페이지 번호를 관리할 수 있으므로 clamd는 2 ⁰ 페이지의 메모리 또는 4KB를 요청했습니다.

GFP_MASK(무료 페이지 마스크 가져오기)의 가장 낮은 두 비트는 소위 말하는 것을 구성합니다.존 마스크 메모리를 가져올 영역을 할당자에게 알려줍니다.:

Flag            value      Description
                0x00u      0 implicitly means allocate from ZONE_NORMAL
__GFP_DMA       0x01u      Allocate from ZONE_DMA if possible
__GFP_HIGHMEM   0x02u      Allocate from ZONE_HIGHMEM if possible

메모리 존주로 호환성을 이유로 만들어진 개념입니다. 단순화된 보기에는 x86 커널에 대한 세 가지 영역이 있습니다.

Memory range   Zone       Purpose 

0-16 MB        DMA        Hardware compatibility (devices)
16 - 896 MB    NORMAL     space directly addressable by the Kernel, userland 
> 896 MB       HIGHMEM    userland, space addressable by the Kernel via kmap() calls

귀하의 경우 zonemask는 0입니다. 이는 clamd가 ZONE_NORMAL.

다른 플래그는 다음과 같이 해결됩니다.

/*
 * Action modifiers - doesn't change the zoning
 *
 * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
 * _might_ fail.  This depends upon the particular VM implementation.
 *
 * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
 * cannot handle allocation failures.
 *
 * __GFP_NORETRY: The VM implementation must not retry indefinitely.
 */
#define __GFP_WAIT      0x10u   /* Can wait and reschedule? */
#define __GFP_HIGH      0x20u   /* Should access emergency pools? */
#define __GFP_IO        0x40u   /* Can start physical IO? */
#define __GFP_FS        0x80u   /* Can call down to low-level FS? */
#define __GFP_COLD      0x100u  /* Cache-cold page required */
#define __GFP_NOWARN    0x200u  /* Suppress page allocation failure warning */
#define __GFP_REPEAT    0x400u  /* Retry the allocation.  Might fail */
#define __GFP_NOFAIL    0x800u  /* Retry for ever.  Cannot fail */
#define __GFP_NORETRY   0x1000u /* Do not retry.  Might fail */
#define __GFP_NO_GROW   0x2000u /* Slab internal usage */
#define __GFP_COMP      0x4000u /* Add compound page metadata */
#define __GFP_ZERO      0x8000u /* Return zeroed page on success */
#define __GFP_NOMEMALLOC 0x10000u /* Don't use emergency reserves */
#define __GFP_NORECLAIM  0x20000u /* No realy zone reclaim during allocation */

에 따르면리눅스 MM 문서GFP_ZERO, 따라서 귀하의 요청에는 , GFP_REPEAT, 및 에 GFP_FS대한 플래그가 있으므로 특별히 까다롭지는 않습니다.GFP_IOGFP_WAIT

그래서 무슨 일이야 ZONE_NORMAL? 일부 일반 통계는 OOM 출력에서 더 자세히 확인할 수 있습니다.

[커널] [1772321.850770] 일반무료:8056kB 최소:8048kB 낮음:10060kB높음:12072kB active_anon:0kB inactive_anon:0kB active_file:248kB inactive_file:388kB 제거 불가능:0kB 격리(anon) :0kB 격리(파일):0kB 존재:890008kB

여기서 눈에 띄는 점은free에서 불과 8K 거리에 있어요min그리고 훨씬 아래에low. 이는 호스트의 메모리 관리자가 다소 어려움을 겪고 있으며 kswapd가 이미 페이지를 교체해야 함을 의미합니다.노란색아래 그래프의 단계:

영역의 메모리 조각화에 대한 추가 정보는 다음과 같습니다.

[커널] [1772321.850795] 일반: 830*4kB 80*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 8056kB

기본적으로 4MB의 단일 연속 페이지가 있고 나머지는 주로 4KB 페이지로 크게 조각화되어 있음을 나타냅니다.

그럼 요약하자면 다음과 같습니다.

메모리를 가져오는 사용자 영역 프로세스( clamd)가 있는 ZONE_NORMAL반면, 권한이 없는 메모리 할당은 일반적으로 다음에서 수행됩니다.ZONE_HIMEM
메모리 관리자는 이 단계에서 요청된 4K 페이지를 제공할 수 있어야 합니다. 하지만 상당한 메모리 부족이 있는 것 같습니다.ZONE_NORMAL
시스템 kswapd은 의 규칙에 따라~해야 한다ZONE_NORMAL일부 페이징 활동을 미리 보았지만 의 메모리 부족에도 불구하고 명백한 원인 없이 아무것도 교체되지 않습니다.
위의 어느 것도 왜 oom-killer호출되었는지 에 대한 명확한 이유를 제공하지 않습니다.

이 모든 것은 다소 이상해 보이지만 적어도 다음에 설명된 내용과 관련이 있습니다.John O'Gorman의 훌륭한 "Linux 가상 메모리 관리자 이해" 책의 섹션 2.5:

커널이 사용할 수 있는 주소 공간(ZONE_NORMAL)은 크기가 제한되어 있으므로 커널은 대용량 메모리 개념을 지원합니다. [...] 1GiB와 4GiB 범위 사이의 메모리에 액세스하기 위해 커널은 kmap()을 사용하여 임시로 높은 메모리의 페이지를 ZONE_NORMAL로 매핑합니다. [...]

즉, 1GiB 메모리를 설명하려면 약 11MiB의 커널 메모리가 필요합니다. 따라서 16GiB에서는 176MiB의 메모리가 소비되어 ZONE_NORMAL에 상당한 부담을 줍니다. ZONE_NORMAL을 사용하는 다른 구조를 고려하기 전까지는 이는 그리 나쁘지 않은 것 같습니다. PTE(페이지 테이블 항목)와 같은 매우 작은 구조라도 최악의 경우 약 16MiB가 필요합니다.이로 인해 x86에서 사용 가능한 실제 메모리 Linux의 실제 한계는 16GiB가 됩니다..

(강조는 제가 했습니다)

3.2는 2.6에 비해 메모리 관리 측면에서 많은 발전을 이루었기 때문에 이것이 확실한 대답은 아니지만 먼저 추구하고 싶은 매우 강력한 힌트입니다. mem=커널 매개변수를 사용하거나 서버에서 DIMM의 절반을 추출하여 호스트의 사용 가능한 메모리를 최대 16G로 줄입니다 .

궁극적으로,64비트 커널을 사용하세요.

친구야 벌써 2015년이구나

Answer

이제 oom-killer 출력을 읽고 거기에서 무엇을 배울 수 있는지 살펴보겠습니다.

OOM 킬러 로그를 분석할 때 로그를 촉발한 원인을 살펴보는 것이 중요합니다. 로그의 첫 번째 줄은 몇 가지 단서를 제공합니다.

[커널] [1772321.850644] clamd가 oom-killer를 호출했습니다.gfp_mask=0x84d0, 순서=0

order=0얼마나 많은 메모리가 요청되고 있는지 알려줍니다. 커널의 메모리 관리는 2의 거듭제곱으로만 페이지 번호를 관리할 수 있으므로 clamd는 2 ⁰ 페이지의 메모리 또는 4KB를 요청했습니다.

GFP_MASK(무료 페이지 마스크 가져오기)의 가장 낮은 두 비트는 소위 말하는 것을 구성합니다.존 마스크 메모리를 가져올 영역을 할당자에게 알려줍니다.:

Flag            value      Description
                0x00u      0 implicitly means allocate from ZONE_NORMAL
__GFP_DMA       0x01u      Allocate from ZONE_DMA if possible
__GFP_HIGHMEM   0x02u      Allocate from ZONE_HIGHMEM if possible

메모리 존주로 호환성을 이유로 만들어진 개념입니다. 단순화된 보기에는 x86 커널에 대한 세 가지 영역이 있습니다.

Memory range   Zone       Purpose 

0-16 MB        DMA        Hardware compatibility (devices)
16 - 896 MB    NORMAL     space directly addressable by the Kernel, userland 
> 896 MB       HIGHMEM    userland, space addressable by the Kernel via kmap() calls

귀하의 경우 zonemask는 0입니다. 이는 clamd가 ZONE_NORMAL.

다른 플래그는 다음과 같이 해결됩니다.

/*
 * Action modifiers - doesn't change the zoning
 *
 * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
 * _might_ fail.  This depends upon the particular VM implementation.
 *
 * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
 * cannot handle allocation failures.
 *
 * __GFP_NORETRY: The VM implementation must not retry indefinitely.
 */
#define __GFP_WAIT      0x10u   /* Can wait and reschedule? */
#define __GFP_HIGH      0x20u   /* Should access emergency pools? */
#define __GFP_IO        0x40u   /* Can start physical IO? */
#define __GFP_FS        0x80u   /* Can call down to low-level FS? */
#define __GFP_COLD      0x100u  /* Cache-cold page required */
#define __GFP_NOWARN    0x200u  /* Suppress page allocation failure warning */
#define __GFP_REPEAT    0x400u  /* Retry the allocation.  Might fail */
#define __GFP_NOFAIL    0x800u  /* Retry for ever.  Cannot fail */
#define __GFP_NORETRY   0x1000u /* Do not retry.  Might fail */
#define __GFP_NO_GROW   0x2000u /* Slab internal usage */
#define __GFP_COMP      0x4000u /* Add compound page metadata */
#define __GFP_ZERO      0x8000u /* Return zeroed page on success */
#define __GFP_NOMEMALLOC 0x10000u /* Don't use emergency reserves */
#define __GFP_NORECLAIM  0x20000u /* No realy zone reclaim during allocation */

에 따르면리눅스 MM 문서GFP_ZERO, 따라서 귀하의 요청에는 , GFP_REPEAT, 및 에 GFP_FS대한 플래그가 있으므로 특별히 까다롭지는 않습니다.GFP_IOGFP_WAIT

그래서 무슨 일이야 ZONE_NORMAL? 일부 일반 통계는 OOM 출력에서 더 자세히 확인할 수 있습니다.

[커널] [1772321.850770] 일반무료:8056kB 최소:8048kB 낮음:10060kB높음:12072kB active_anon:0kB inactive_anon:0kB active_file:248kB inactive_file:388kB 제거 불가능:0kB 격리(anon) :0kB 격리(파일):0kB 존재:890008kB

여기서 눈에 띄는 점은free에서 불과 8K 거리에 있어요min그리고 훨씬 아래에low. 이는 호스트의 메모리 관리자가 다소 어려움을 겪고 있으며 kswapd가 이미 페이지를 교체해야 함을 의미합니다.노란색아래 그래프의 단계:

영역의 메모리 조각화에 대한 추가 정보는 다음과 같습니다.

[커널] [1772321.850795] 일반: 830*4kB 80*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 8056kB

기본적으로 4MB의 단일 연속 페이지가 있고 나머지는 주로 4KB 페이지로 크게 조각화되어 있음을 나타냅니다.

그럼 요약하자면 다음과 같습니다.

메모리를 가져오는 사용자 영역 프로세스( clamd)가 있는 ZONE_NORMAL반면, 권한이 없는 메모리 할당은 일반적으로 다음에서 수행됩니다.ZONE_HIMEM
메모리 관리자는 이 단계에서 요청된 4K 페이지를 제공할 수 있어야 합니다. 하지만 상당한 메모리 부족이 있는 것 같습니다.ZONE_NORMAL
시스템 kswapd은 의 규칙에 따라~해야 한다ZONE_NORMAL일부 페이징 활동을 미리 보았지만 의 메모리 부족에도 불구하고 명백한 원인 없이 아무것도 교체되지 않습니다.
위의 어느 것도 왜 oom-killer호출되었는지 에 대한 명확한 이유를 제공하지 않습니다.

이 모든 것은 다소 이상해 보이지만 적어도 다음에 설명된 내용과 관련이 있습니다.John O'Gorman의 훌륭한 "Linux 가상 메모리 관리자 이해" 책의 섹션 2.5:

커널이 사용할 수 있는 주소 공간(ZONE_NORMAL)은 크기가 제한되어 있으므로 커널은 대용량 메모리 개념을 지원합니다. [...] 1GiB와 4GiB 범위 사이의 메모리에 액세스하기 위해 커널은 kmap()을 사용하여 임시로 높은 메모리의 페이지를 ZONE_NORMAL로 매핑합니다. [...]

즉, 1GiB 메모리를 설명하려면 약 11MiB의 커널 메모리가 필요합니다. 따라서 16GiB에서는 176MiB의 메모리가 소비되어 ZONE_NORMAL에 상당한 부담을 줍니다. ZONE_NORMAL을 사용하는 다른 구조를 고려하기 전까지는 이는 그리 나쁘지 않은 것 같습니다. PTE(페이지 테이블 항목)와 같은 매우 작은 구조라도 최악의 경우 약 16MiB가 필요합니다.이로 인해 x86에서 사용 가능한 실제 메모리 Linux의 실제 한계는 16GiB가 됩니다..

(강조는 제가 했습니다)

3.2는 2.6에 비해 메모리 관리 측면에서 많은 발전을 이루었기 때문에 이것이 확실한 대답은 아니지만 먼저 추구하고 싶은 매우 강력한 힌트입니다. mem=커널 매개변수를 사용하거나 서버에서 DIMM의 절반을 추출하여 호스트의 사용 가능한 메모리를 최대 16G로 줄입니다 .

궁극적으로,64비트 커널을 사용하세요.

친구야 벌써 2015년이구나

Question 2

몇 가지 ...

스왑 공간에 대한 나의 경험 법칙은 물리적 RAM 양의 최소 2배를 확보하는 것이었습니다. 이를 통해 페이지/스왑 데몬이 메모리를 효율적으로 재구성할 수 있습니다.

Server_B에는 32GB의 RAM이 있으므로 64GB의 스왑으로 구성해 보세요. IMO, 서버에 있는 2GB의 스왑 공간은 다음과 같습니다.방법특히 서버의 경우 너무 낮습니다.

스왑 파티션으로 만들 수 있는 추가 파티션이 없다면 파일을 생성하고 이를 스왑 파티션으로 마운트하여 테스트할 수 있습니다[느리게 됩니다]. 보다https://www.maketecheasier.com/swap-partitions-on-linux/

server_B에는 충분한 디스크 공간이 있으므로 --inplace는 필요하지 않으며 rsync가 32GB를 사용하게 만드는 원인이 될 수 있으므로 바람직하지 않을 수 있습니다. --inplace는 파일 시스템 공간이 부족하거나[그렇지 않은] 특별한 성능 요구 사항이 있는 경우에만 정말 유용합니다.

내 생각엔 rsync가 현재 옵션에 50GB의 RAM(파일 크기)을 사용하기를 원할 것입니다. 일반적으로 rsync는 작업을 수행하는 데 그렇게 많은 메모리가 필요하지 않으므로 하나 이상의 옵션이 문제가 될 수 있습니다. 나는 문제없이 정기적으로 200GB 파일을 전송합니다.

옵션 없이 몇 가지 테스트를 실행해 보세요. 10GB와 같이 더 작은 파일에 대해 이 작업을 수행합니다. 이렇게 하면 커널 패닉을 방지할 수 있지만 여전히 문제를 일으키는 동작을 모니터링할 수 있습니다. rsync의 메모리 사용량을 모니터링합니다.

점차적으로 옵션을 한 번에 하나씩 다시 추가하여 어떤 옵션[또는 옵션 조합]으로 인해 rsync가 RAM에서 피그아웃을 시작하는지 확인합니다(예: 전송이 진행되는 동안 rsync의 램 사용량은 전송된 파일 데이터의 양에 비례하여 증가합니다. 등.).

rsync가 일부 RAM 내 파일 이미지를 유지하도록 하는 옵션이 정말로 필요한 경우 추가 스왑 공간이 필요하며 이에 따라 최대 파일 크기가 제한됩니다.

몇 가지 추가 사항 [업데이트됨]:

(1) 커널 스택 추적은 rsync가 mmap 영역에서 페이지 폴트를 일으켰음을 보여줍니다. 아마도 파일을 mmaping하고 있는 것 같습니다. mmap은 디스크에 플러시된다는 보장이 없습니다.~까지파일은 즉시 FS 블록 캐시로 이동하는 [읽기/쓰기와는 달리] 닫힙니다 [여기서 플러시됩니다]

(2) 전송 크기가 RAM 크기에 도달하면 커널 충돌/패닉이 발생합니다. 확실히 rsync는 malloc이나 mmap을 통해 fscache가 아닌 메모리를 많이 확보하고 있습니다. 다시 한번, 지정한 옵션을 사용하면 rsync는 50GB 파일을 전송하기 위해 50GB의 메모리를 할당합니다.

(3) 24GB 파일을 전송합니다. 아마도 효과가 있을 것입니다. 그런 다음 mem=16G로 커널을 부팅하고 24GB 파일 테스트를 다시 수행합니다. 32GB가 아닌 16GB에서 터질 것입니다. 그러면 rsync에 실제로 메모리가 필요하다는 것이 확인됩니다.

(4) 스왑을 추가하는 것이 말도 안된다고 말하기 전에 [파일로 스왑 방법을 통해] 일부를 추가해 보십시오. 이는 스왑이 필요하지 않은 방법에 대한 모든 학문적 주장보다 수행하고 테스트하기가 훨씬 쉽습니다. 해결책이 아니더라도 그로부터 뭔가를 배울 수 있습니다. 나는 mem=16G 테스트가 패닉/충돌 없이 성공할 것이라고 확신합니다.

(5) rsync가 발생할 가능성이 있습니다.~이다스왑을 시도했지만 OOM이 시작되어 rsync를 종료하기 전에 top으로 확인하기에는 너무 빠릅니다. rsync가 32GB에 도달할 때쯤이면 특히 유휴 상태인 경우 다른 프로세스가 강제로 스왑됩니다. 아마도 "무료"와 "상위"를 조합하면 더 나은 그림을 얻을 수 있을 것입니다.

(6) rsync가 종료된 후 mmap을 FS로 플러시하는 데 시간이 걸립니다. OOM에 비해 속도가 충분히 빠르지 않으며 다른 작업을 죽이기 시작합니다. [일부는 분명히 미션 크리티컬합니다.] 즉, mmap 플러시와 OOM이 경쟁하고 있습니다. 또는 OOM에 버그가 있습니다. 그렇지 않으면 충돌이 발생하지 않습니다.

(7) 내 경험에 따르면 시스템이 "메모리 벽에 도달"하면 Linux는 완전히 복구하는 데 오랜 시간이 걸립니다. 그리고 때로는 제대로 복구되지 않는 경우도 있으며 이를 해결하는 유일한 방법은 재부팅하는 것입니다. 예를 들어, RAM이 12GB입니다. 40GB의 메모리를 사용하는 작업(대규모 작업을 수용할 수 있는 120GB의 스왑 공간이 있음)을 실행한 후 종료하면 시스템이 정상 응답 상태로 돌아가는 데 약 10분이 걸립니다(디스크 표시등이 항상 켜진 상태에서). .

(8) rsync 실행없이옵션. 이것은 작동합니다. 작업할 기본 예제를 얻으세요. 그런 다음 --inplace를 다시 추가하고 다시 테스트하세요. 그런 다음 대신 --append-verify를 수행하십시오. 그런 다음 둘 다 시도해 보세요. 거대한 mmap을 수행하는 rsync를 가져오는 옵션을 알아보세요. 그런 다음 그것 없이도 살 수 있는지 결정하십시오. --inplace가 원인이라면 디스크 공간이 충분하므로 생각할 필요도 없습니다. 옵션이 있어야 한다면 rsync가 수행할 malloc/mmap을 수용할 수 있는 스왑 공간을 확보해야 합니다.

두 번째 업데이트:

위에서 mem= 및 더 작은 파일 테스트를 수행하십시오.

핵심 질문: OOM에 의해 rsync가 종료되는 이유는 무엇입니까? 씹는 기억이란 누구/무엇입니까?

시스템이 32비트라는 내용을 읽었지만 [잊었습니다]. 따라서 나는 rsync가 직접적인 책임이 없을 수도 있고(malloc/mmap을 통해 -glibc는 익명/개인 mmap을 통해 대규모 malloc을 구현함) rsync의 mmap 페이지 오류가 우연히 OOM을 트리거할 뿐이라는 점에 동의합니다. 그런 다음 OOM은 rsync가 직접 및 간접적으로(FS 캐시, 소켓 버퍼 등) 소비하는 총 메모리를 계산하고 이것이 주요 후보인지 결정합니다. 따라서 총 메모리 사용량을 모니터링하는 것이 도움이 될 수 있습니다. 파일 전송과 같은 속도로 속도가 빨라지는 것 같습니다. 분명히 그렇게해서는 안됩니다.

모든 것을 모니터링할 수 있는 빠른 루프(bash 스크립트는 아마도 세계 종말 이벤트에 비해 충분히 빠르지 않을 것임)의 Perl 또는 Python 스크립트를 통해 /proc 또는 /proc/rsync_pid에서 모니터링할 수 있는 몇 가지 사항 다음은 수백 번/초입니다. rsync보다 더 높은 우선순위로 실행할 수 있으므로 RAM에 계속 유지되어 실행되므로 충돌 직전과 OOM 중에 상황을 모니터링하여 OOM이 미친 이유를 확인할 수 있습니다.

/proc/meminfo -- "충격 지점"에서 스왑 사용량을 더 자세히 알아봅니다. 실제로 총 RAM이 얼마나 사용되고 있는지에 대한 최종 수치를 얻는 것이 더 유용할 수 있습니다. top이 이를 제공하지만 "빅뱅" 직전(예: 마지막 10밀리초) 직전의 우주 상태를 표시할 만큼 빠르지는 않을 수 있습니다.

/proc/rsync_pid/fd 디렉토리. 심볼릭 링크를 읽으면 대상 파일에서 어떤 fd가 열려 있는지 식별할 수 있습니다(예: /proc/rsync_pid/fd/5 --> target_file의 읽기 링크). fd 번호를 얻으려면 이 작업을 한 번만 수행하면 됩니다. [고정된 상태로 유지되어야 합니다.]

fd 번호를 알고 있으면 /proc/rsync_pid/fdinfo/fd를 살펴보십시오. 다음과 같은 텍스트 파일입니다.

위치: <파일_위치>
플래그: 어쩌구 저쩌구
mnt_id: 어쩌구 저쩌구

"마지막 파일 위치"가 유용할 수 있으므로 "pos" 값을 모니터링하는 것이 도움이 될 수 있습니다. 다양한 크기와 mem= 옵션을 사용하여 여러 테스트를 수행하는 경우 마지막 파일 위치가 이러한 항목을 [그리고 어떻게] 추적합니까? 일반적인 용의자: 파일 위치 == 사용 가능한 RAM

그러나 가장 간단한 방법은 "rsync local_file server:remote_file"로 시작하여 작동하는지 확인하는 것입니다. "ssh server rsync file_a file_b"(먼저 50GB file_a를 생성해야 함)를 수행하면 유사하지만 더 빠른 결과를 얻을 수 있습니다. file_a를 생성하는 간단한 방법은 scp local_system:original_file server:file_a이며 이는 그 자체로 흥미로울 수 있습니다(예: rsync가 충돌할 때 이 작업이 작동합니까? scp가 작동하지만 rsync가 실패하면 이는 rsync를 가리킵니다. scp가 실패하면 이는 다음을 가리킵니다. NIC 드라이버와 같은 다른 것으로). ssh rsync를 수행하면 NIC가 방정식에서 제외되므로 도움이 될 수 있습니다. 그것이 시스템에 물을 공급한다면 뭔가 정말 잘못된 것입니다. 성공하면 [내가 언급한 대로] 옵션을 하나씩 다시 추가하기 시작합니다.

요점을 자세히 설명하고 싶지는 않지만 파일로 스왑을 통해 일부 스왑을 추가하면 충돌 동작이 변경/지연될 수 있으며 진단 도구로 유용할 수 있습니다. 예를 들어 16GB의 스왑을 추가하면 [메모리 사용량 또는 대상 파일 위치로 측정된] 충돌이 32GB에서 46GB로 지연된다면 이는 의미가 있을 것입니다.

특정 프로세스가 아니라 메모리를 씹는 잘못된 커널 드라이버일 수 있습니다. 커널의 내부 vmalloc은 물건을 할당하고 교체할 수 있습니다. IIRC는 모든 상황에서 주소 지정 가능성에 구속되지 않습니다.

분명히 OOM은 혼란스럽거나 당황하고 있습니다. 즉, rsync를 종료하지만 제때에 메모리가 해제되는 것을 보지 못하고 다른 피해자를 찾으러 갑니다. 그 중 일부는 시스템 작동에 매우 중요할 수 있습니다.

malloc/mmap은 제쳐두고, 이는 플러시되지 않은 FS 캐시로 인해 오랜 시간이 걸릴 수 있기 때문에 발생할 수 있습니다(예: 플러시되지 않은 데이터가 30GB이고 디스크 속도가 300MB/초라고 가정하면 플러시하는 데 100초가 걸릴 수 있음). 그런 속도에서도 OOM은 너무 성급할 수 있습니다. 또는 OOM 종료 rsync가 FS 플러시를 충분히 빠르게 시작하지 않거나 전혀 시작하지 않습니다. 또는 FS 플러시가 충분히 빠르게 발생하지만 여유 풀로 페이지를 "지연" 릴리스합니다. FS 캐시 동작을 제어하기 위해 설정할 수 있는 /proc 옵션이 몇 가지 있습니다. [무엇인지 기억이 나지 않습니다.]

mem=4G 또는 다른 작은 숫자로 부팅해 보십시오. 이렇게 하면 FS 캐시가 줄어들고 플러시 시간이 단축되어 OOM이 종료할 다른 항목을 찾지 않게 됩니다(예: 플러시 시간이 100초에서 1초 미만으로 단축됨). 또한 32비트 시스템 등에서 4GB가 넘는 물리적 RAM을 처리할 수 없는 OOM 버그를 밝혀낼 수도 있습니다.

또한 중요한 점은 루트가 아닌 사용자로 실행한다는 것입니다. 루트 사용자는 리소스를 씹을 것으로 예상되지 않으므로 더 관대한 제한이 제공됩니다(예: 루트가 아닌 사용자의 경우 메모리 99% 대 95%). 이는 OOM이 이러한 상태에 있는 이유를 설명할 수 있습니다. 또한 이는 OOM et. 알. 메모리 회수 작업을 수행할 수 있는 여유 공간이 더 많습니다.

Answer