나는 그것이 Linux의 디스크 캐시라고 생각하지 않습니다. 에서는 htop메모리 스틱이 녹색(캐시 주황색이 아님)이고 zram에 저장된 파일을 삭제했습니다. 어떤 프로세스도 많은 메모리를 사용하지 않는 것 같습니다.
로드는 소프트웨어를 컴파일하고 빌드 파일은 zram( 젠투 PORTAGE_TMPDIR의 경우 /var/tmp/portage)에 저장되며 스왑 파일도 zram에 저장됩니다. 메모리가 부족할 때 디스크에 쓰도록 zram 쓰기 저장을 구성합니다.
2개의 소프트웨어를 컴파일했는데 1개 이후에도 여전히 메모리의 약 1/2을 사용하는 것 같습니다. zramctl은 사용된 총 데이터가 0G에 가깝고 어떤 프로세스도 너무 많은 메모리를 사용하지 않고 있으며 Linux 디스크 캐시는 문제가 되지 않는다고 말합니다. .
kswapd의 CPU 사용률이 지속적으로 100%에 도달하면 커널 OOM이 너무 많은 RAM을 소비하는 프로세스를 종료했습니다. 그 후에도 여전히 RAM이 사용되고 있지만 이를 사용하고 있는 항목은 찾을 수 없습니다. 디스크 캐시의 경우 커널은 메모리를 소비하는 프로세스에 공간을 넘겨줍니다. 하지만 그렇지 않았으므로 디스크 캐시 문제가 아닐 가능성이 높습니다. 컴퓨터를 다시 시작했고 두 번째 소프트웨어는 문제 없이 빠르게 컴파일되었습니다!
무슨 일이 일어나고 있는지, 무엇이 메모리를 사용하고 있는지 더 자세히 확인할 수 있는 방법을 아는 사람이 있습니까?
답변1
짧은 답변:파일 시스템을 마운트하거나 Zram 장치에 생성된 스왑 영역을 열 때 드롭 마운트 옵션을 사용하십시오.
확장:discard마운트 옵션으로 사용하기 위해 파일 시스템을 마운트하는 경우 옵션 사이에 공백 없이 -o마운트 옵션을 구분하여 사용하여 마운트 옵션을 설정할 수 있습니다. ,대부분의 Linux 파일 시스템은 이를 지원해야 하며 Btrfs에서 사용하고 있습니다. 그렇지 않으면 파일 시스템 이 마운트된 디렉토리에서 주기적으로 실행할 수 있지만 출력에서 볼 수 있듯이 -d이는 swapon필요 하지 않으며 마운트 옵션이면 충분합니다.fstrimzramctldiscard
편집하다:fstrim실제로 몇 가지 추가 테스트를 거친 후 정기적으로 Zram 마운트에서 실행하는 것이 좋은 생각이라고 생각합니다. Zram의 빌드 디렉터리를 사용하여 Firefox를 컴파일한 후 메모리 사용량은 약 1.1GB입니다. 설치 옵션이 없는 것만큼 나쁘지 는 않지만 discard개선의 여지가 있습니다. Zram 마운트 fstrim(실행하는 데 몇 초 밖에 걸리지 않음)에서 실행하면 RAM 사용량이 400MB에 도달했는데 이는 정상적인 현상입니다. 크론 작업에 넣거나 포티지 컴파일 후에 넣을 수도 있습니다.
설명하다:Zram은 파일이 삭제될 때 해당 공간이 더 이상 데이터에 사용되지 않는다는 알림을 받지 않기 때문에 메모리의 압축된 페이지를 삭제하지 않습니다. 폐기 옵션은 파일 삭제 시 폐기를 수행합니다. 폐기 설치 옵션을 사용하는 경우 Zram은 사용되지 않은 페이지에 대해 알림을 받고 이에 따라 크기가 조정됩니다.