Linux는 다른 작업을 수행하기 전에(예: 전체 스왑 전) 캐시된 ext4 로그 쓰기에서 쓸모 없는 "버퍼"가 회수되도록 어떻게 보장합니까?

/proc/meminfo내 노트북은 일반적으로 free -w -h약 256MB의 메모리("버퍼"로 계산)를 사용하여 약 8GB의 RAM에서 실행됩니다.

메모리 사용량에 관심이 있습니다. 때로는 너무 많이 사용하여 문제가 발생할 수 있습니다. ~256MB "버퍼" 사용량은 걱정되지 않지만 궁금합니다.

나는 어떤 소프트웨어가 그것을 사용하는지 알아냈고, 그 사용법은 (거의 완전히?) 불필요한 것 같습니다 8-). 두 개의 ext4 파일 시스템이 마운트되어 있으며 각각의 로그 크기는 128MB입니다. ~256MB "버퍼" 사용량은 기본적으로 ext4 로그에서 캐시된 모든 쓰기입니다..

각 파일 시스템에 대해 전체 로그 파일을 캐시할 필요는 없다고 생각합니다. (대부분의 경우 소수의 저널에만 "실시간 데이터"가 있습니다! 저는 사용하지 않습니다 data=journalled.) 나는 "버퍼"의 불필요한 특정 사용에 관심이 있습니다. 나는 다른 용도가 있을 수 있다는 것을 알고 있으며 그 중 일부는 더 필요할 수 있습니다. 예를 들어, 로그의 일부를 캐시하는 것이 유용할 수 있다는 것을 이해합니다.하다현재 실시간 데이터를 저장하는 중입니다.

조사한 결과, 소규모 시스템에서는 "버퍼"가 물리적 RAM의 30%를 차지하는 것으로 나타났습니다.

내 질문은 메모리가 요청될 때 Linux가 이러한 불필요한 "버퍼"를 많이 삭제하도록 어떻게 보장하는가입니다.어느페이지 캐싱을 포함한 다른 용도로 사용하시나요? 귀하의 믿음의 근거가 되는 증거를 인용해 주십시오.

나는 역사적 차이점에는 특별히 관심이 없으며 "현재" 시스템의 동작에만 관심이 있습니다. 관심이 있으시다면 제 노트북은 현재 Fedora 28, 커널 버전 4.18.16-200.fc28.x86_64를 실행하고 있습니다. (또는 더 작은 시스템에서는 Debian 9, 커널 버전 4.9.0-8-marvell을 실행하고 있습니다).

Linux 페이지 캐싱에 대한 세부정보

Cached나는 "버퍼"의 동작보다 페이지 캐싱의 개념에 더 익숙합니다./proc/meminfofree -w -h

나는 최근에 이 주제를 다시 읽었습니다.운영 체제 파일 캐싱을 위해 Linux 커널에서 어떤 페이지 교체 알고리즘이 사용됩니까?

캐시되지 않은 파일을 복사할 때 읽기 및 쓰기와 같이 캐시되지 않은 파일 페이지에 대한 액세스는 "비활성" LRU 목록에 캐시됩니다. 페이지 캐시에서 메모리를 회수할 때 커널은 가장 최근에 사용된 "비활성" 페이지부터 시작하는 것을 선호합니다. 비록 오래되었음에도 불구하고 여러 번 방문한 페이지인 "활성" 페이지보다 이러한 페이지를 선호합니다.

특히 이를 통해 실행 중인 모든 프로그램을 교체하지 않고도 임의로 대용량 파일 복사본을 실행할 수 있습니다. 중요한 페이지는 여러 번 액세스되기 때문에 실행 중인 프로그램의 모든 중요한 메모리 페이지는 "활성" 목록에 있습니다.

이는 Linux 메모리 관리의 복잡성에 대한 첫 번째 근사치입니다. 나는 이러한 복잡성에 대한 전문가가 아니기 때문에 여기서 "좋아요"와 같은 모호한 단어를 사용하고 있습니다.

이상적으로는, 페이지 캐시를 회수하기 전에 불필요한 "버퍼"를 먼저 회수하고 싶습니다. (페이지 캐시의 일부로 "버퍼"를 계산하는 경우 캐시된 일반 파일보다 불필요한 "버퍼"가 재활용되기를 원한다는 점을 이해해야 합니다.)

그래서 궁금해요. "비활성" 페이지가 캐시되기 전에 불필요한 "버퍼"가 재활용됩니까? 아니면 "활성" 페이지가 캐시되기 전에 재활용되는 경향이 있다고 말할 수 있습니까? 아니면 페이지 캐싱과 비교하기 전에 더 자세한 내용을 설명해야 합니까?