我希望了解container_memory_working_set_bytes與process_resident_memory_bytes與total_rss（container_memory_rss）+file_mapped以便更好地配備系統來警報OOM的可能性。這似乎違背了我的理解（現在讓我感到困惑），因為如果一個容器/pod正在運行一個進程，執行用Go編寫的編譯程序。為什么兩者之間的差異如此之大（幾乎是10倍以上）container_memory_working_set_bytesprocess_resident_memory_bytes另外，和之間的關系在這里很奇怪，這是我沒想到的，讀完這里后container_memory_working_set_bytescontainer_memory_rss + file_mapped匿名和交換緩存內存的總量（它包括透明的大頁面），它等于來自 memory.status 文件的total_rss值。這不應與 cgroup 使用的真實駐留集大小或物理內存量相混淆。rss + file_mapped將為您提供 c 組的常駐集大小。它不包括換出的內存。它確實包括來自共享庫的內存，只要這些庫中的頁面實際上在內存中。它確實包括所有堆棧和堆內存。因此，總駐留集大小是此值如何小于在給定 c 組中運行的容器cgrouprss + file_mappedcontainer_working_set_bytes這讓我覺得這個統計數據我是不正確的。以下是用于構建上圖的 PROMQLprocess_resident_memory_bytes{container=“sftp-downloader”}container_memory_working_set_bytes{container=“sftp-downloader”}go_memstats_heap_alloc_bytes{container=“sftp-downloader”}container_memory_mapped_file{container=“sftp-downloader”} + container_memory_rss{container=“sftp-downloader”}