왜 "교환성"에 대한 논의는 정보가 한 번에 한 곳에만 있을 수 있는 것처럼 행동합니까?

Question

나는 애플리케이션이 사용되지 않을 때 애플리케이션의 메모리를 디스크로 교체하는 것에 대해 커널이 얼마나 공격적인지를 제어하는 ​​Linux의 "swappiness" 조정 가능 항목을 읽어 왔습니다.Google에서 해당 용어를 검색하면 다음과 같은 페이지가 많이 나타납니다. 이것 장점과 단점을 논의합니다.간단히 말해서 그 주장은 다음과 같습니다.

스왑 성능이 너무 낮으면 비활성 응용 프로그램이 다른 프로그램에서 사용하려는 시스템 메모리를 모두 차지하게 됩니다.

스왑 가능성이 너무 높으면 비활성 응용 프로그램을 깨울 때 디스크에서 해당 상태를 다시 읽을 때 큰 지연이 발생합니다.

이 주장은 나에게 이해가 되지 않습니다.엄청난 양의 메모리를 사용하는 비활성 애플리케이션이 있는 경우 커널이 해당 메모리를 디스크에 페이지하고 해당 데이터의 다른 복사본을 메모리에 남겨 두지 않는 이유는 무엇입니까?이것은 두 세계의 장점을 모두 제공하는 것 같습니다.다른 애플리케이션에 해당 메모리가 필요한 경우 물리적 RAM을 즉시 요청하고 여기에 쓰기 시작할 수 있습니다. 왜냐하면 다른 애플리케이션이 디스크에 있고 비활성 애플리케이션이 깨어날 때 다시 교체할 수 있기 때문입니다.그리고 원래 앱이 깨어나면 아직 RAM에 있는 페이지를 디스크에서 꺼내지 않고도 그대로 사용할 수 있습니다.

아니면 내가 뭔가를 놓치고 있는 걸까?

Answer 1

이것에 따르면 1 그것이 바로 Linux가하는 일입니다.

나는 여전히 많은 것을 이해하려고 노력하고 있으므로 권위있는 링크에 감사 할 것입니다.

Answer 2

메모리 톤을 사용하는 비활성 응용 프로그램이있는 경우 커널이 메모리를 디스크로 표시하고 해당 데이터의 다른 사본을 메모리에 남겨 두지 않는 이유는 무엇입니까?

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

첫 번째 프로세스가 페이지가 디스크에 기록 된 이후 페이지를 수정했는지 여부를 절대적으로 확실하게 알아야합니다. 그렇다면 다시 써야합니다. 우리가 이것을 추적하는 방법은 우리가 처음 디스크에 그것을 썼을 때 프로세스의 쓰기 권한을 페이지에 다시 가져 오는 것입니다. 프로세스가 페이지에 다시 쓰려고하면 페이지 오류가 발생합니다. 커널은 프로세스가 쓰기 권한을 복원하고 응용 프로그램을 계속할 수 있도록 페이지를 먼지 (따라서 다시 작성해야 함)에 주목할 수 있습니다.

거기에는 문제가 있습니다. 페이지에서 쓰기 권한을 제거하는 것은 실제로 다중 프로세서 머신에서 다소 비싸다. 모든 CPU가 페이지 변환의 캐시를 제거하여 쓰기 권한을 제거하는 것이 중요합니다.

프로세스가 페이지에 쓰는 경우 페이지 결함을 취하는 데 훨씬 비쌉니다. 나는이 페이지들의 사소한 수가 결국 그 잘못을 취할 것이라고 가정합니다. 그것은 우리가 기억에 남겨 두어 우리가 찾고 있던 이익에 들어갑니다.

그래서 그만한 가치가 있습니까? 솔직히 모르겠습니다. 나는 왜 메모리에 페이지를 떠나는 것이 왜 그런 소리처럼 승리가 아닌지 설명하려고 노력하고 있습니다.

(*)이 모든 것은 Copy-on-write라는 메커니즘과 매우 유사하며, 이는 프로세스 포크 () s 일 때 사용됩니다. 아동 프로세스는 몇 가지 지침 만 실행하고 exec ()를 호출 할 가능성이 높으므로 모든 부모 페이지를 복사하는 것이 어리석은 일입니다. 대신 쓰기 허가가 사라지고 아이는 단순히 달리기를 허용했습니다. 페이지 결함은 거의 취하지 않기 때문에 복사-온-쓰레기는 승리입니다. 아이는 거의 항상 exec ()에게 즉시 전화합니다.

Answer 3

앱 메모리를 디스크에 페이징하고 메모리에 유지하더라도 애플리케이션이 "비활성"으로 간주되어야 하는 시점을 결정해야 하며 이것이 바로 스왑성을 제어하는 ​​것입니다.디스크로 페이징하는 것은 IO 측면에서 비용이 많이 들기 때문에 너무 자주 수행하고 싶지 않습니다.이 방정식에는 또 다른 변수가 있는데, 이는 Linux가 남은 메모리를 디스크 버퍼/캐시로 사용한다는 사실입니다.

Answer 4

VM이 가장 먼저 하는 일은 페이지를 정리하고 이를 정리 목록으로 이동하는 것입니다.
익명 메모리(실제 파일 백업 저장소가 없는 것, /proc//maps에서 익명이고 그 뒤에 파일 시스템 vnode 저장소가 없는 세그먼트를 볼 수 있음)를 정리할 때 VM이 가장 먼저 할 일은 다음과 같습니다. "더러운" 페이지를 가져와 "정리"한 다음 페이지의 내용을 교환하여 작성합니다.이제 VM에 ​​완전히 사용 가능한 메모리가 부족하고 사용할 새 사용 가능한 페이지를 부여하는 능력이 걱정되는 경우 '클린' 페이지 목록을 살펴보고 해당 페이지가 얼마나 최근에 사용되었는지, 어떤 종류의 메모리를 기반으로 하는지 확인할 수 있습니다. 해당 페이지를 무료 목록으로 이동하는 것입니다.

메모리 페이지가 사용 가능 목록에 배치되면 더 이상 이전에 있던 내용과 연관되지 않습니다.프로그램이 이전에 페이지가 제공했던 메모리 위치를 참조하는 경우 프로그램은 심각한 오류를 일으키고 (대부분 완전히 다른) 페이지가 사용 가능 목록에서 가져오고 데이터는 디스크에서 페이지로 읽혀집니다.이 작업이 완료되면 페이지는 수정되지 않았으므로 실제로는 여전히 '깨끗한' 상태입니다.VM이 RAM의 다른 페이지에 대한 교체 시 해당 페이지를 사용하기로 선택하면 페이지가 다시 '더티'되거나, 앱이 해당 페이지에 쓴 경우 '더티'됩니다.그런 다음 프로세스가 다시 시작됩니다.

또한 비즈니스/트랜잭션/온라인/대기 시간에 민감한 환경의 서버 애플리케이션에서는 스왑 핀이 매우 끔찍합니다.많은 브라우저와 GUI를 실행하지 않는 16GB RAM 상자가 있는 경우 일반적으로 모든 앱이 거의 메모리에 고정되기를 원합니다.내 RAM의 대부분은 내가 사용하는 8~10GB의 Java 힙인 경향이 있습니다. 절대 디스크에 페이징하고 싶고 사용 가능한 잔인함은 mingetty와 같은 프로세스입니다(그러나 거기에서도 해당 앱의 glibc 페이지는 다른 앱에서 공유되고 실제로 사용되므로 쓸모 없는 프로세스의 RSS 크기도 대부분 공유되고 사용됩니다) 페이지).일반적으로 교체하기 위해 실제로 정리된 16GB 중 몇 10MB 이상이 표시되지 않습니다.서버에 대한 스왑 가능성은 매우 낮거나 스왑 가능성이 0이라고 조언하고 싶습니다. 사용되지 않은 페이지는 전체 RAM의 작은 부분이어야 하며 버퍼 캐시를 위해 상대적으로 작은 양의 RAM을 회수하려고 하면 응용 프로그램 페이지를 스왑하고 대기 시간이 걸릴 위험이 있습니다. 실행중인 앱.