"swappiness"와 같은 토론은 왜 한 번에 한 곳에서만 가능합니까?

Question

필자는 Linux의 "swappiness"튜너 블을 읽고 있는데, 이는 커널이 사용되지 않을 때 디스크의 응용 프로그램 메모리를 얼마나 적극적으로 바꾸는지를 제어합니다. Google에이 용어를 사용하면 this과 같은 많은 페이지가 장단점을 논의합니다. 간단히 말해, 논증은 다음과 같습니다 :

swappiness가 너무 낮 으면 비활성 프로그램이 다른 프로그램에서 사용하려는 모든 시스템 메모리를 소모합니다.

swappiness가 너무 높으면 비활성 응용 프로그램을 깨울 때 상태가 디스크에서 다시 읽혀지기 때문에 큰 지연이 발생할 수 있습니다.

이 인수는 나에게 이해가되지 않습니다. 많은 양의 메모리를 사용하는 비활성 응용 프로그램이있는 경우 왜 커널이 메모리를 디스크에 페이징하지 않고 해당 데이터의 다른 복사본을 메모리에 남겨 두지 않습니까? 이는 다른 응용 프로그램이 메모리를 필요로하는 경우 물리적 RAM을 즉시 소유 할 수 있고 디스크의 다른 복사본이 디스크에 있으므로 쓰기가 시작될 수 있으며 비활성 응용 프로그램이 깨어 났을 때 다시 스왑 될 수 있습니다 쪽으로. 그리고 원래 응용 프로그램이 깨어 난 후에도 RAM에 남아있는 페이지는 디스크에서 꺼내지 않고도 그대로 사용할 수 있습니다.

아니면 뭔가 빠졌습니까?

Answer 1

정확하게 리눅스가하는이 1에 따르면.

나는 아직도 많은 것을 이해하려고 노력하고 있으므로 어떤 권위있는 링크도 인정 될 것입니다.

Answer 2

응용 프로그램 메모리를 디스크에 저장하고 메모리에 유지하더라도 응용 프로그램을 언제 "비활성"으로 간주해야하는지 결정해야하며 이는 스왑이 제어하는 ​​것입니다. 디스크 페이징은 IO 측면에서 비용이 많이 들고 너무 자주 수행하지 않으려 고합니다. 이 방정식에는 또 다른 변수가 있습니다. Linux가 나머지 메모리를 디스크 버퍼/캐시로 사용한다는 사실입니다.

Answer 3

많은 메모리를 사용하는 비활성 응용 프로그램이있는 경우 왜 커널이 메모리를 디스크에 페이지하지 않고 해당 데이터의 다른 복사본을 메모리에 남겨 두지 않습니까?

우리는 그렇게했다고합니다. 우리는 디스크에 페이지를 썼지 만 메모리에 남겨 두었습니다. 잠시 후 다른 프로세스에 메모리가 필요하므로 첫 번째 프로세스에서 페이지를 차감하고 싶습니다.

디스크에 쓰여진 첫 번째 프로세스가 페이지를 수정했는지 여부를 절대적으로 알고 있어야합니다. 있다면, 다시 써야합니다. 우리가 이것을 추적하는 방법은 처음 페이지를 디스크에 쓸 때 페이지의 쓰기 권한을 빼앗는 것입니다. 프로세스가 다시 페이지에 쓰려고하면 페이지 오류가 발생합니다. 커널은 쓰기 권한을 복원하고 응용 프로그램을 계속 진행하기 전에 프로세스가 페이지를 더럽 혔음을 알 수 있습니다 (따라서 다시 작성해야합니다).

거기에 문제가 있습니다. 페이지에서 쓰기 권한을 없애는 것은 실제로 다소 비쌉니다. 특히 다중 프로세서 시스템에서는 비용이 많이 듭니다. 모든 CPU가 페이지 변환 캐시를 제거하여 쓰기 권한을 없애는 것이 중요합니다.

프로세스가 페이지에 쓰는 경우 페이지 폴트를받는 것이 훨씬 더 비쌉니다. 나는이 페이지의 중요하지 않은 수가 메모리에 남겨 둠으로써 우리가 찾고 있던 이익을 먹는 것으로 끝날 것이라고 생각할 것입니다.

가치가 있습니까? 나는 정직하게 모른다. 나는 단지 메모리에 페이지를 남겨 두는 것이 왜 그렇게 분명하지는 않은지 설명하려고 노력하고있다.

(*)이 모든 것은 Copy-On-Write라는 메커니즘과 매우 유사합니다.이 메커니즘은 프로세스 fork()를 사용할 때 사용됩니다. 자식 프로세스는 명령어를 몇 개만 실행하고 exec()를 호출 할 가능성이 높기 때문에 모든 부모 페이지를 복사하는 것은 어리석은 일입니다. 그 대신에 쓰기 권한이 없어지고 아이는 단순히 달릴 수 있습니다. Copy-On-Write는 페이지 폴트가 거의 발생하지 않기 때문에 승리합니다. 아이는 거의 항상 exec()를 즉시 호출합니다.

Answer 4

VM이 수행하는 첫 번째 작업은 페이지를 정리하고 정리 목록으로 이동하는 것입니다.
익명 메모리를 정리할 때 (실제 파일 백업 저장소가없는 경우/proc// 맵에있는 세그먼트는 익명이고 그 뒤에 파일 시스템 vnode 저장소가 없습니다), VM이 가장 먼저 할 일은 "더티 (dirty)"페이지를 가져 와서 페이지의 내용을 쓰려면 스왑 (swap)하여 "clean (정리)"하십시오. 이제 VM에 ​​완전히 사용 가능한 메모리가 부족하고 새로운 사용 가능한 페이지를 사용할 수있는 권한이 있는지 걱정되면 '깨끗한'페이지 목록을 통해 사용 된 날짜와 사용 된 메모리 유형에 따라 이동할 수 있습니다 그들은 그 페이지들을 자유 목록으로 옮길 것입니다.

메모리 페이지가 비어있는 목록에 배치되면 더 이상 이전에 있던 내용과 연결되지 않습니다. 프로그램이 참조를 따라 온다면 페이지가 이전에 서비스하고 있던 메모리 위치가 프로그램에 중대한 오류를 일으키고 자유 목록에서 (대부분 다른 완전히 다른) 페이지가 잡히고 데이터가 디스크의 페이지로 읽혀집니다. 이 작업이 끝나면 페이지는 실제로 수정되지 않았으므로 여전히 '깨끗한'상태입니다. VM이 RAM에있는 다른 페이지의 스왑에 해당 페이지를 사용하도록 선택한 경우 페이지가 다시 '더티'가되거나 앱이 해당 페이지에 쓴다면 '더티'가됩니다. 그런 다음 프로세스가 다시 시작됩니다.

또한 비즈니스/트랜잭션/온라인/대기 시간에 민감한 환경에서 서버 응용 프로그램에 대한 swappinness는 매우 끔찍합니다. 필자가 브라우저와 GUI를 많이 사용하지 않는 16GB RAM 상자가 있으면 일반적으로 모든 앱이 메모리에 거의 고정되어 있어야합니다. 내 RAM의 대부분은 8 백 10 기가 바이트 자바 힙 경향이 내가 NEVER 디스크에 페이징 싶습니다, 그리고 cruft는 mingetty와 같은 프로세스입니다 (하지만 심지어 그 애플 리케이션의 glibc 페이지는 다른 애플 리케이션에 의해 공유됩니다 실제로 사용되기 때문에 쓸모없는 프로세스의 RSS 크기조차도 대부분 공유되고 사용 된 페이지입니다. 나는 대체로 실제로 청소 된 16GB 중 10MB 이상을 보지 못합니다. 나는 매우 낮은 swappiness 수 또는 서버 swappiness을 조언 할 것이다. 사용되지 않는 페이지는 전체 RAM의 작은 부분이어야하고 버퍼 캐시가 응용 프로그램 페이지를 스왑하고 지연 시간에 걸리는 위험을 감수하기 위해 비교적 적은 양의 RAM을 회수해야한다. 실행중인 앱.