저는 커널 4.3.3-hardened-r4를 사용하여 Gentoo Hardened AMD64를 실행하고 있습니다. 내 시스템은 wpa_supplicant, cron 또는 DHCP와 같은 일부 기본 데몬만 실행했고 X 세션은 Windowmaker, GKrellM 및 xterm만 열었기 때문에 시간이 지남에 따라 Linux는 약 8~8시까지 점점 더 많은 RAM을 소비하기 시작했습니다. RAM 및 커널 패닉 유발. 이는 Linux가 버퍼 및 파일 시스템 캐시에 대한 RAM 사용량을 보고하는 것과는 아무런 관련이 없습니다. 왜냐하면 top, htop 및 GKrellM은 모두 이를 고려하고 프로세스에서 실제로 얼마나 많은 RAM이 사용되는지 표시하기 때문입니다. 최근까지 나는 이것이 내 Bitcoin Core 클라이언트에 연결되어 있다고 생각했지만 그렇지 않았습니다. (저는 Linux 시스템이 시작될 때 실수로 응용 프로그램을 실행했습니다.)
emerge -NDu --with-bdeps=y @world어떤 경우에는 전체 업데이트가 릴리스되었을 때 RAM 사용량이 갑자기 정상으로 돌아오는 것을 볼 수 있었지만 () 이 해결 방법을 재현할 수 없었습니다.
지금까지 다음 수정 사항을 시도했습니다.
vm.zone_reclaim_mode=1내 커널에서 NUMA 지원을 컴파일하고(Gentoo의 genkernel은 기본적으로 이를 활성화하지 않음) 내 sysctl에 추가합니다 . 쓸모 없는.- 내 sysctl에 추가되지
vm.drop_caches=1않았습니다. - tmpfs 설치가 꽉 찼는지 확인하세요. 내 tmpfs 마운트는 1MB가 넘는 파일 시스템 사용량을 거의 기록하지 않습니다.
이 동작에 대한 증거는 다음 스크린샷에서 볼 수 있습니다.
부록 I:그 중에서 실행되는 유일한 메모리 소비 프로세스는 Firefox, GKrellm 및 X였으며 Linux는 거의 3GB의 코어를 소비했습니다. 노트:여기서는 스왑 공간을 활성화하지 않았습니다(내부 하드 드라이브가 오래되고 느리기 때문에 USB 3.0 외장 하드 드라이브에 있습니다). 그러나 스왑 공간이 활성화되어 있어도 Bitcoin Core를 8시간 이상 켜둔 후에도 여전히 OOM이 발생합니다. 커널 패닉 달린다.
첨부 B:htop과 GKrellm에 결함이 있는 경우 top으로 다시 확인했습니다. 같은 결과.
첨부 C:내 tmpfs 마운트 사용 통계, 내 출력 free및 내 콘텐츠/proc/meminfo 여기에서 찾을 수 있습니다.
이 게시물은 최근 조사 결과를 반영하기 위해 많이 편집되었습니다. 오래된 게시물은 다음에서 찾을 수 있습니다.이 페이스트빈이 여기 있어요.
답변1
메모리 지원과 같은 SHM 기반 설치 가 있습니까 /tmp? /var/tmp프로세스가 종료된 후에도 임시 파일이 생성될 수 있으며 이러한 파일은 메모리를 소비합니다. 이러한 파일은 삭제되거나 시스템이 다시 시작될 때까지 메모리에 남아 있습니다. 마운트 /etc/fstab및 mounttmpfs 항목을 확인하십시오.
또한 임시 디렉터리에 큰 파일이 생성될 수 있으므로 로그 회전을 확인하세요. systemd를 사용하는 경우 로그를 지우는 것이 좋습니다. 예를 들어:
journalctl --vacuum-size=500M
답변2
그것들을 추가하세요:
- 비트코인 클라이언트를 사용한 후 충돌이 발생할 때까지 메모리를 먹기 시작합니다.
- (뭔가 이상한 일을 하기 전까지는) 메모리를 반환하지 않습니다.
첫 번째는 일반적인 메모리 누수처럼 보입니다. Checker의 성능 및 메모리 관리를 사용할 수 있지만 valgrind이로 인해 프로그램 속도가 크게 느려집니다.
두 번째 질문은 첫 번째 질문의 후손일 수 있습니다. 왜 이런 일이 발생하는지 모르겠지만 메모리 문제(또는 막대한 메모리 소비, 또는 프로세스가 D 상태에 멈춰 있는 것과 같은 다른 버그) 때문이라고 추측할 수 있습니다. 다른 응용 프로그램에서는 동일한 동작을 나타내지 않기 때문에 시스템이 아닌 Bitcoin 소프트웨어에 문제가 있는 것 같습니다.
따라서 이 문제를 해결하기 위해 우리가 하는 모든 일은 해킹이 될 것입니다. 성공적인 해킹이 있을 수 있지만 여전히 최선의 접근 방식은 아닙니다. 소스 코드에 액세스할 수 있고 일부 프로그래밍 지식을 알고 있는 경우 일부 정적 코드 분석기를 실행하여 수정해야 할 "간단한" 버그가 있는지 확인할 수 있습니다. . valgrind이러한(코드/기술)이 없으면 개발자에게 피드백을 제공하는 것이 마지막으로 할 수 있는 일입니다. 버그 추적기, 포럼 또는 메일링 리스트 등이 있을 수 있습니다. 그렇게 하면 누군가가 문제를 조사하고 문제를 확인하고 해결하기를 바랍니다.
답변3
그래서 이 문제로 거의 두 달 동안 혼란을 겪은 후에 저는 sysctl 옵션을 활성화하고 다른 값을 사용하여 몇 가지 작업을 수행하는 방법을 물어보기로 결정했습니다. vm.zone_reclaim_mode그리고 보라, 문제가 해결되었습니다.
해결책:
CONFIG_NUMA내 커널 구성을 활성화 하고 다시 빌드했습니다.vm.zone_reclaim_mode = 7sysctl.conf에 넣으세요
이제 내 시스템은 마침내 24시간 이상 그대로 유지됩니다.
커널 문서에 NUMA와 그러한 공격적인 영역 회수 설정으로 인해 속도가 느려질 수 있다고 나와 있기 때문에 성능 저하에 대해 조금 걱정했지만 이제 시스템이 마침내 작동합니다.