%EC%9D%B4%20%EB%B3%B4%EA%B3%A0%EB%90%98%EC%97%88%EC%8A%B5%EB%8B%88%EB%8B%A4..png)
문제에 대한 간략한 설명:Intel Core-2 Q6600의 64비트 젠투는 재부팅 후 총 메모리 8GB 중 약 3GB가 사용되었다고 보고합니다. 이 메모리는 어떤 프로세스에서도 점유되지 않으며 버퍼/캐시에서도 사용되지 않습니다.
문맥:emerge소스에서 Octave를 빌드하려고 시도하는 동안 OOM이 프로세스를 종료한 후 처음으로 이 동작을 발견했습니다. 시스템이 다시 응답했을 때 어떤 프로세스에서도 사용되지 않는 약 3GB의 메모리가 여전히 남아 있었습니다. (처음에는 이것이 실제로 그랬다고 확신할 수는 없습니다. 아마도 이전에 눈치채지 못했을 수도 있습니다.)
OOM 문제에 대해 잘 몰라서 재부팅을 해보았으나, 메모리가 다시 사용되고 있다고 합니다.
그런 다음 Memcheck86+를 시도했는데 3246.3MB에서 "실패한 주소" 오류가 보고되었습니다(5회 반복 테스트). RAM 주파수를 낮췄더니 오류가 사라졌습니다(3번 테스트 반복).
그러나 내 젠투에는 뚜렷한 설명 없이 3GB가 사용된다는 지속적인 보고가 있습니다(아래 진단 보고서 참조).
나는 또한 라이브 배포판(Parted Magic)을 시도했는데 분명히 정상적으로 작동했습니다(시작 후 약 수백 개의 램을 사용했습니다).
가능한 원인이나 해결책에 대한 제안이 있으십니까?
편집하다: 이제 이 문제를 극복할 수 있지만 여전히 설명할 수는 없습니다. 지금까지 내가 추적한 내용을 설명하겠습니다.
- 단일 사용자 모드로 시작할 때는 3GB의 메모리가 사용되지 않습니다.
부팅
iptables결과 3GB 사용량이 발생하고 dmesg는 다음을 보고합니다.nf_conntrack: vmalloc으로 대체
후속 중지에서는
iptables프로세스가 재개되지 않으며 메모리는 계속 사용됩니다.
nf_conntrack그런 다음 더 이상 내장되지 않고 모듈로 로드되도록 커널 구성을 변경했습니다 . 재부팅 후 시작 시 메시지가 나타나지 iptables않으며 falling back to vmalloc3GB가 소모되지 않습니다.
어떻게 설명해야 할지 모르겠습니다. 일부 커널 개발자가 이 동작의 원인이 정확히 무엇인지 설명하는 데 도움을 줄 수 있을까요?
관련 보고서:
답변1
이 문제는 연결 추적 테이블 및 해시 테이블에 대한 최대 크기 설정이 잘못되어 발생할 수 있습니다. Linux 커널은 iptables nf_conntrack 모듈의 연결 테이블을 추적하기 위해 연속 페이지를 할당하려고 시도합니다. conntrack은 물리적 메모리 부족으로 인해 vmalloc으로 장애 복구됩니다.
테이블은 설정된 연결을 기반으로 동적으로 생성되지 않지만 일부 커널 매개변수를 기반으로 완전히 할당됩니다.
일부 추가 증상이 대량으로 발견될 수 있습니다.nf_conntrack: vmalloc으로 대체합니다./var/log/messages(또는 /var/log/kern.log 또는 둘 다)의 메시지입니다.
이 문제는 연결된 트랙 테이블을 간단히 조정하고 크기를 줄임으로써 쉽게 해결할 수 있습니다. 시스템 사용량에 따라 적절한 조정이 이루어져야 합니다. 본 시스템에서 전용 네트워크 방화벽을 운영하고 있다면 연결 추적 테이블이 높아야 하지만, 단순히 네트워크 침입으로부터 보호하기 위해 iptables를 사용한다면 연결 추적 테이블은 훨씬 낮아질 수 있습니다.
연결 추적 조정에 대한 자세한 내용은 다음을 참조하세요.https://wiki.khnet.info/index.php/Conntrack_tuning
conntrack -L시스템 값을 미세 조정하려면 먼저 (또는) 을 실행하여 시스템이 열어둔 연결 수를 평가할 수 있습니다 /sbin/sysctl net.netfilter.nf_conntrack_count. 더 좋은 점은 시간 경과에 따른 연결을 추적하는 통계를 유지하는 것입니다(무닌잘하셨습니다) 추적된 최대 연결 수를 기준으로 사용하세요. 이 정보를 기반으로 /etc/sysctl.conf를 적절하게 구성할 수 있습니다.
미세 조정 시 추적 테이블에 연결이 유지되는 기간도 확인하세요. 때로는 네트워크 구성 오류나 오류로 인해 conntrack 테이블에 가짜 데이터 연결이 포함되는 경우가 있습니다. 예를 들어, 서버가 절대 닫히지 않는 SYN 연결을 수신하거나 클라이언트가 갑자기 연결을 끊고 오랫동안 소켓을 열어 두는 경우가 있습니다.
둘째, conntrack 항목이 올바른지 확인하십시오. 때로는 일부 네트워크 또는 방화벽 구성이 잘못되어 conntrack 테이블이 쓰레기로 채워지는 경우가 있습니다. 일반적으로 이는 완전히 설정되지 않은 연결 항목입니다. 예를 들어 서버가 들어오는 연결에 대한 SYN 패킷을 받았지만 서버 응답이 항상 네트워크 어딘가에서 손실되는 경우 이런 일이 발생할 수 있습니다.
달리기를 하면 이러한 값을 미세 조정할 때 sysctl -a | grep conntrack | grep timeout몇 가지 통찰력을 얻을 수 있습니다 . 기본값은 매우 보수적입니다. 일반적인 시간 초과의 경우 600(10분), 설정된 TCP 연결(5일)은 432000입니다. 시스템 사용량 및 네트워크 동작에 따라 conntrack 테이블의 활성 연결 수를 줄이기 위해 이를 미세 조정해야 할 수도 있습니다. 이는 더 낮은 값을 정의하는 데 도움이 됩니다.
그러나 conntrack 테이블의 크기를 너무 많이 줄이지 않도록 주의하십시오. 그렇지 않으면 반대 효과가 발생할 수 있습니다. 연결은 추적할 수 없기 때문에 iptables에 의해 삭제되고 다음과 같은 메시지가 로그 파일에 나타나기 시작합니다."커널: ip_conntrack: 테이블이 꽉 차서 패킷이 삭제됩니다."
이것이 문제인지 확인하려면 다음 출력을 제공하십시오.
cat /proc/sys/net/ipv4/ip_conntrack_max
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_buckets