저는 90년대 후반부터 오픈 소스 IRC 봇의 개발자/유지관리자로 활동해 왔습니다. 목표는 항상 작은 메모리 공간 내에서 최대한 다양하고 유용하게 만드는 것입니다.
2000년대에는 유용한 프로그램을 4kB RSS로 압축한 개념 증명 코드도 작성했는데, 이는 2.4 커널에서 구현하기 어렵지 않았습니다. 나는 init와 Agetty를 사용하여 이를 달성했습니다. 즉, 단일 4kB 메모리 페이지 내에서 상주하여 실행되도록 했습니다.
이제 어느 날 봇에게 메모리 사용량을 보고하도록 요청했을 때 봇은 다음과 같이 응답했습니다.
[Mar 27 2018] <bot> VM 1000 kB (Max 2988 kB), RSS 4 kB [ Code 212 kB, Data 68 kB, Libs 556 kB, Stack 132 kB ]
커널 2.4에서 4kB RSS를 얻으려면 모든 코드, rodata 및 스택 세그먼트를 동일한 페이지에 매핑해야 합니다. 봇을 사용하여 이 작업을 수행하는 것이 아니므로 이론적 한계도 12kB여야 합니다. 하지만 이후 커널의 경우 추가 가속기 매핑이 있는 것으로 보이므로 스택과 rodata가 매핑 해제되더라도 여전히 12kB의 매핑이 남아 있습니다.
봇은 libmusl과 연결되어 있으므로 54kB의 "일반적인" 표준 RSS 크기로 실행됩니다. 함수를 거의 사용되지 않는 핵심 필수 청크로 재정렬하기 위해 ld 스크립트를 만들었지만 이론상으로도 4kB는 여전히 의미가 없습니다. 시스템은 물리적 메모리가 풍부하고 스와핑 및 시스템 로드가 없는 Xeon이므로 페이지를 스와핑해야 한다는 부담이 없습니다.
여기서 무슨 일이 일어나고 있는지 아시나요? 나는 여전히 모든 것을 하나의 4kB 페이지로 다시 매핑할 수 있는 가능성에 관심이 있습니다. 하지만 지금까지는 재생 가능한 경우 12kB, 재생 불가능한 경우에는 8kB까지만 줄였습니다.
봇은 /proc에서 RSS를 읽고 읽은 내용 중 변경되지 않은 내용만 보고합니다. ps aux
봇이 보고한 것과 동일한 VSZ 및 RSS를 표시합니다.
답변1
이것은 대답이 아닙니다.(댓글로 편집하기에는 텍스트가 너무 복잡함)
귀하의 질문에 답하려면 먼저 시리즈 4에서 RSS로 보고된 값이 정확히 무엇을 의미하는지에 대한 정확한 설명이 필요하다고 생각합니다. 그것은 정확히 무엇을 나타내는가?
2.4 이후 미적분학이 (크게) 변경되었다고 확신하기 때문입니다.
내가 기억하는 첫 번째 변화는 Andrew Morton과 Al이 RSS에 일부 RLIMIT를 구현하려고 했던 2.6 시대였습니다.
버전:
- io 지도 장치 영역
- 비선형 매핑
- 거대한 기억력
- 공유 일반 메모리
- SysV-IPC 공유 메모리
- 공유되는 공통 메모리 없음
제 기억으로는 VM_IO 부분을 더 이상 고려하지 말아야 한다는 점에 모두가 동의했고, 공유 라이브러리의 전체 크기를 고려하지 말아야 한다는 압박감도 컸습니다.
다른 부분(HugetLB 및 Shared Normal Memory)은 동의하기 어렵기 때문에 여러 하위 범주로 나누어야 합니다.
내가 잘 이해하지 못했던 일종의 털복숭이 개 이야기. 단지 4에서 RSS의 의미가 2.4에서 RSS의 의미와 확실히 다르기 때문에 동일한 실행 파일에 대해 보고된 값이 매우 다를 수 있다는 점을 지적하고 싶었습니다.
행운을 빌어요.
물론 좋은 답변이 게시되면 이 게시물을 삭제하겠습니다.