`vm.swappiness=100`에도 불구하고 민트 시스템이 정지되고 스왑 영역이 충분히 활용되지 않음

Question 1

분명히 여기에는 두 가지 문제가 있습니다.

REISUB 시퀀스가 작동하지 않는 것은 SysRq가 활성화되지 않은 마법으로 인해 발생할 수 있습니다. 이것을 확인하세요

cat /proc/sys/kernel/sysrq

# List of possible values in /proc/sys/kernel/sysrq:

#  0 - disable sysrq completely
#  1 - enable all functions of sysrq
#    >1 - bitmask of allowed sysrq functions (see below for detailed function description):
#      2 - enable control of console logging level
#      4 - enable control of keyboard (SAK, unraw)
#      8 - enable debugging dumps of processes etc.
#     16 - enable sync command
#     32 - enable remount read-only
#     64 - enable signalling of processes (term, kill, oom-kill)
#    128 - allow reboot/poweroff
#    256 - allow nicing of all RT tasks

클래식 REISUB의 경우 4(R) + 64(E,I) + 16(S) + 32(U) + 128(B) = 244가 필요합니다(효과는 얇은 코끼리 버전과 동일합니다. BUSIER는 철자를 거꾸로 쓴 것입니다).

시스템의 교환성의 경우:예상대로 작동합니다. 이러한 동작의 이유는 많은 메모리(아마도 얻는 메모리의 95%에 해당)를 사용하고 있기 때문입니다.그 다음에무엇기타많은 새로운 RAM이 요청되어 95%의 대부분이 계속 교체하고 싸워야 합니다.

가장 좋은 방법은 더 많은 메모리를 설치하는 것입니다. 그렇지 않으면 소규모 프로세스를 95%로 길들일 수 있는지, 아니면 추가로 40-50%를 소비하는 대규모 프로세스를 확인할 수 있는지 확인하세요. 이 top유틸리티가 도움이 될 수 있습니다.

멋진 솔루션으로 명확한 교환성을 추가하고 시스템을 모니터링하고 큰 돼지가 실행되지 않고 메모리 공간이 너무 큰 경우 엄청난 양의 메모리를 할당 및 해제하기 시작하는 일부 프로세스를 사용하여 미노우를 "절단"할 수 있습니다. 남은 모든 메모리에 64M를 더해 64M의 소형 메모리를 캐시에 넣은 다음 할당 지연이 지정된 시간 임계값을 초과하거나 대용량 메모리가 실행되기 시작할 때까지 +128M을 캐시에 넣습니다.

이 답변정말로 이 일을 하고 싶다면, 이것이 좋은 시작이 될 수 있습니다.

Answer

분명히 여기에는 두 가지 문제가 있습니다.

REISUB 시퀀스가 작동하지 않는 것은 SysRq가 활성화되지 않은 마법으로 인해 발생할 수 있습니다. 이것을 확인하세요

cat /proc/sys/kernel/sysrq

# List of possible values in /proc/sys/kernel/sysrq:

#  0 - disable sysrq completely
#  1 - enable all functions of sysrq
#    >1 - bitmask of allowed sysrq functions (see below for detailed function description):
#      2 - enable control of console logging level
#      4 - enable control of keyboard (SAK, unraw)
#      8 - enable debugging dumps of processes etc.
#     16 - enable sync command
#     32 - enable remount read-only
#     64 - enable signalling of processes (term, kill, oom-kill)
#    128 - allow reboot/poweroff
#    256 - allow nicing of all RT tasks

클래식 REISUB의 경우 4(R) + 64(E,I) + 16(S) + 32(U) + 128(B) = 244가 필요합니다(효과는 얇은 코끼리 버전과 동일합니다. BUSIER는 철자를 거꾸로 쓴 것입니다).

시스템의 교환성의 경우:예상대로 작동합니다. 이러한 동작의 이유는 많은 메모리(아마도 얻는 메모리의 95%에 해당)를 사용하고 있기 때문입니다.그 다음에무엇기타많은 새로운 RAM이 요청되어 95%의 대부분이 계속 교체하고 싸워야 합니다.

가장 좋은 방법은 더 많은 메모리를 설치하는 것입니다. 그렇지 않으면 소규모 프로세스를 95%로 길들일 수 있는지, 아니면 추가로 40-50%를 소비하는 대규모 프로세스를 확인할 수 있는지 확인하세요. 이 top유틸리티가 도움이 될 수 있습니다.

멋진 솔루션으로 명확한 교환성을 추가하고 시스템을 모니터링하고 큰 돼지가 실행되지 않고 메모리 공간이 너무 큰 경우 엄청난 양의 메모리를 할당 및 해제하기 시작하는 일부 프로세스를 사용하여 미노우를 "절단"할 수 있습니다. 남은 모든 메모리에 64M를 더해 64M의 소형 메모리를 캐시에 넣은 다음 할당 지연이 지정된 시간 임계값을 초과하거나 대용량 메모리가 실행되기 시작할 때까지 +128M을 캐시에 넣습니다.

이 답변정말로 이 일을 하고 싶다면, 이것이 좋은 시작이 될 수 있습니다.

Question 2

요컨대,교체해도 도움이 되지 않습니다, 이 문제를 해결하는 가장 효과적인 방법은메모리 확장시스템 환경을 그대로 유지한다면.

이제 방금 언급한 질문에 답해 보겠습니다.

1. "vm.swappiness=100"의 메모리가 스왑아웃되지 않는 이유는 무엇입니까?

먼저, Linux에서 스왑이 어떻게 작동하는지 이해해야 합니다. 커널이 메모리가 부족하다고 느낄 때 상황을 완화하기 위해 메모리를 회수하는 두 가지 방법이 있습니다.

익명 페이지 교환
캐시된 페이지 재활용

'vm.swappiness'는 단순히 커널이 메모리 페이지를 얼마나 적극적으로 스왑하는지 제어합니다(더 많은 익명 페이지 스왑 또는 더 많은 캐시된 페이지 회수).

그렇다면 또 다른 질문이 생깁니다. 커널은 교환할 익명 페이지를 어떻게 결정합니까? 전략은 더 복잡합니다. 코드를 참조할 수 있습니다.여기커널 버전에 따라 다릅니다. 전략을 한 문장으로 요약하고 활동이 가장 적은 페이지를 교환하세요. 커널이 스왑 가능하다고 생각하는 비활성 페이지가 없으면 어떻게 됩니까?

이것이 바로 시스템이 생각만큼 많은 메모리를 교체하지 않는 이유입니다.

2. 메모리 교환을 강제하는 것이 도움이 됩니까?

아니요. 그리고 스왑 메모리를 강제로 적용하는 일반적인 방법은 없으며 커널이 이를 대신합니다.

Answer