RAM 대신 FILE을 강제로 사용하는 도구

단일 프로그램의 관점에서는 의미가 없기 때문에 그러한 도구는 존재하지 않습니다.

CPU/HDD/RAM/스왑은 자원으로 간주될 수 있습니다. 운영 체제는 다양한 방식으로 프로세스, 사용자, 컨텍스트 등 간에 이러한 리소스를 공유할 수 있습니다.

운영 체제에 엄격한 제한을 적용하도록 지시하는 것이 적합한 특정 상황이 있습니다.

• 이 프로그램이 메모리의 60% 이상을 사용하지 않도록 하세요.
• 해당 사용자가 요구하는 경우 다른 사용자가 CPU 시간의 20% 이상을 사용하도록 허용하지 마십시오. 그렇지 않으면 100% CPU를 사용할 수 있습니다.
• 이 그룹의 사용자는 2개 이상의 코어를 사용할 수 없습니다.
• ...

이는 실제유연성: 관리자의 희망과 운영 체제의 준수 여부에 따라 사용자 간에 리소스를 공유합니다.

프로그램을 수동으로 스왑에 넣는 것이 좋지 않은 이유는 무엇입니까?

• 기본적으로 커널의 경험적 방법보다 더 낫다고 가정하고 있습니다. 커널은 이미 스왑 공간 자체를 처리합니다. 데몬이 오랫동안 활성화되지 않았고 운영 체제의 RAM이 부족하면 결국 스왑 상태가 됩니다.
• AFAIK, 스왑 영역은 실행 가능하지 않습니다. 실행하기 전에 스왑 영역의 내용을 RAM으로 검색해야 합니다. 따라서 RAM에서 첫 번째 유형의 프로그램을 실행하고 스왑에서 두 번째 유형의 프로그램을 실행하려는 경우 즉시 중지하면 작동하지 않습니다.
• "예, 하지만 특정 데몬은 한 달에 두 번씩 호출됩니다. RAM에서는 필요하지 않습니다." 이것이 사실이라면 RAM이 부족하면 커널이 스왑 상태가 됩니다.
• "메모리가 부족할 때까지 기다려야 하는 이유는 무엇입니까?" 스왑에 물건을 넣고 빼는 것은 특히 일반 하드 드라이브의 경우 비용이 많이 듭니다. 시스템이 모든 것을 RAM에 보관할 수 있다면 그렇게 하는 것이 가장 좋습니다. 일시적으로 무언가를 강제로 교환하면 시스템의 반응성이 떨어집니다. 다른 "일급" 데몬도 일부 HDD IO를 수행할 가능성이 높으므로 이들 데몬도 속도가 느려집니다. "두 번째 유형" 데몬이 깨어나 RAM에 배치되어야 할 때에도 동일한 일이 발생합니다.

이제 사용자는 왜 마법 명령줄을 사용하여 프로그램을 스왑에 넣을 수 없습니까?

• 사용자 공간(비커널) 관점에서 보면 스왑에 무엇을 넣어야 하는지 명확하지 않습니다. 귀하의 프로그램은 에 연결되어 있습니다 libmylib.so. 이 프로그램도 교환해야 합니까? 그래서 뭐 libc.so?
• 실제로 예상되는 동작은 무엇입니까? 데몬을 스왑에 직접 넣기를 원하십니까? 하지만 일부 초기화 작업을 수행해야 합니다. 그렇죠? 그런 다음 로드하면 다시 RAM으로 돌아갑니다.
• 데몬이 더 이상 사용되지 않으며 안전하게 다시 스왑할 수 있다는 것을 어떻게 계속 알 수 있습니까?
• 스왑 영역으로 직접 다시 보내야 합니까, 아니면 기다려야 합니까? 그렇지 않으면 데몬이 잠들 때마다 스왑에 들어가고 깨어날 때마다 다시 RAM에 저장됩니다. 예를 들어, 데몬이 컴퓨터의 시계를 업데이트하는 경우 몇 시간의 교체 시간에 대비하세요.
• ...

간단히 말해서, 이를 처리하려면 코어가 필요하며 이것이 바로 코어가 수행하는 작업입니다. 대부분의 요구 사항에 대해 교환성을 조정하는 것만으로도 반응형 시스템을 얻을 수 있습니다.

이제 정말로 원한다면
_{(원천:Freakoutnation.com)} , 커널은 를 사용하여 작동합니다 cgroups. 에서 데몬에 대해 max mem 및 max mem+swap을 설정하여 원하는 것을 얻을 수 있습니다 cgroups. 각 프로그램의 교환성을 설정하면 보다 합리적인 결과를 얻을 수 있습니다. 하지만 어느 쪽이든 그것은 좋은 생각이 아니며 더 이상 진행하지 않을 것입니다.이것설명으로.

설명하신 상황은 다음과 같습니다. 프로세스에서 사용하는 RAM(가상 메모리가 아닌 RAM)의 양을 제한하는 기능이 있습니다. 이 RLIMIT_RSS제한은 프로그램의 상주 세트 크기, 즉 프로세스가 상주하는 메모리 부분(스왑 아웃과 반대)에 대한 상한을 설정합니다. 그러나 Linux에서는 구현되지 않습니다.

RLIMIT_RSS일부 오래된 Unix 시스템(BSD만?)에 존재하지만 많은 최신 시스템에서는 제거되었습니다. 존재하다리눅스, 2.4 시리즈에만 존재합니다(완전히 작동하지도 않음). 솔라리스에서는떨어지다먼 과거 어느 시점( Solaris SunOS가 BSD에서 System V로 전환했을 때?).FreeBSD더 많은 것 같습니다.

RLIMIT_RSS왜 삭제됐는지 모르겠네요앨런 콕스2006년에 그는 이런 말을 한 적이 있다.

Linux의 원래 버전에서는 계산 비용이 많이 들지 않는 RSS를 추적할 수 있는 방법이 없었기 때문에 이를 시행하지 않았습니다. 현재 mms는 RSS 조절을 구현할 수 있지만 사용자가 RSS 제한을 더 낮게 설정하고 스왑 스래싱을 ​​많이 발생시키는 경우 이것이 어떤 영향을 미칠지는 의문입니다.

효과적으로 수행할 수 있는 방법을 찾을 수 있다면 그렇게 하십시오.

이 주제는 그 이후로 여러 차례 언급됐지만, 제가 아는 한 Linux 커널은 아직 어떤 패치도 승인하지 않았습니다.

프로세스의 물리적 메모리 사용량에 제한을 가하는 이유 중 하나는 프로세스가 사용하는 물리적 메모리의 양을 정의하기 어렵기 때문입니다. 자, 스택과 힙(교환되지 않은 부분)을 세어봅시다. 메모리 매핑 파일은 어떻습니까? 프로세스의 물리적 메모리 사용량을 측정하려면 매핑되는 파일에서 사용하는 캐시를 계산해야 합니다. 공유 라이브러리 및 기타 공유 매핑은 어떻습니까? 단일 프로세스에서 사용하는 경우 당연히 계산해야 하지만 여러 프로세스에서 사용하는 경우 어떤 프로세스가 어떤 부분을 사용하는지 알기 어려울 수 있습니다.

단일 프로세스의 물리적 메모리 사용량을 제한하는 것은 의미가 없습니다. 리소스 제한이 상속된다는 점을 감안할 때 각 하위 항목은 가능한 한 많은 실제 메모리를 사용할 수 있습니다. 프로세스 그룹의 물리적 메모리에 대한 제한을 허용하는 것이 더 합리적입니다. Linux에는 이 기능이 내장되어 있습니다.cgroup, 프로세스와 그 하위 항목이 컨테이너에서 실행되는 부분적으로 가상화된 시스템으로, 자체 파일 시스템 루트, 자체 네트워크 컨트롤러, 자체 리소스 제한 등을 가질 수 있습니다.cgroup 메모리 사용량제한( RAM 및 스왑 영역 사용 제어)은 memory.limit_in_bytes매개변수를 통해 수행할 수 있습니다 . memory.memsw.limit_in_bytes문서에서는 그룹 간에 공유되는 페이지가 다소 임의적인 방식으로 할당된다는 점을 경고합니다("공유 페이지는 첫 번째 터치 방법을 기반으로 계산됩니다. 페이지를 먼저 터치하는 cgroup이 페이지를 계산합니다."). 거기다른 방법일 수도 있습니다제한 사항은 엄격하게 적용되지 않습니다.

요구 사항의 다른 부분은 프로세스에 대한 전용 스왑 파일을 갖는 것입니다. 이를 위해서는 상당히 복잡한 커널이 필요합니다. 두 프로세스에 서로 다른 스왑 공간이 할당되면 페이지를 공유할 수 있다는 점을 기억하세요. 어떤 스왑 파일이 사용됩니까? 반면에 이 기능은 프로세스 측면에서 매우 쉽게 달성할 수 있습니다. 즉, 파일을 메모리에 매핑합니다. 공유 페이지의 경우 여전히 파일이 있습니다. 또 다른 이점은 프로세스의 다양한 영역에서 다양한 "스왑 공간"을 사용할 수 있다는 것입니다.