Quan điểm đó có thể rất sai lệch trong một số trường hợp thực tế.
Hạt nhân hiện cung cấp một ước tính cho bộ nhớ khả dụng, trong MemAvailabletrường. Giá trị này khác biệt đáng kể với MemFree + Cached.
/ Proc / meminfo: cung cấp bộ nhớ khả dụng ước tính [mô tả thay đổi kernel, 2014]
Nhiều chương trình cân bằng tải và khối lượng công việc đặt chương trình kiểm tra / Proc / meminfo để ước tính dung lượng bộ nhớ còn trống. Họ thường làm điều này bằng cách thêm "miễn phí" và "lưu vào bộ nhớ cache", điều này vẫn ổn mười năm trước, nhưng ngày nay được đảm bảo là sai.
Điều đó là sai bởi vì Bộ nhớ đệm bao gồm bộ nhớ không thể giải phóng được như bộ đệm trang, ví dụ như các phân đoạn bộ nhớ được chia sẻ, tmpfs và ramfs và nó không bao gồm bộ nhớ bản có thể lấy lại được, có thể chiếm một phần lớn bộ nhớ hệ thống trên các hệ thống hầu hết không hoạt động với rất nhiều tập tin.
Hiện tại, dung lượng bộ nhớ khả dụng cho một khối lượng công việc mới, mà không đẩy hệ thống vào trao đổi, có thể được ước tính từ MemFree, Active (tệp), Không hoạt động (tệp) và SReclaimable, cũng như các hình mờ "thấp" từ / Proc / khuinfo. Tuy nhiên, điều này có thể thay đổi trong tương lai và không gian người dùng thực sự không nên mong đợi biết các phần bên trong hạt nhân để đưa ra ước tính về dung lượng bộ nhớ trống. Sẽ thuận tiện hơn khi cung cấp ước tính như vậy trong / Proc / meminfo. Nếu mọi thứ thay đổi trong tương lai, chúng ta chỉ phải thay đổi nó ở một nơi.
...
Tài liệu / hệ thống tập tin / Proc.txt:
...
MemAv Available: Ước tính dung lượng bộ nhớ khả dụng để bắt đầu các ứng dụng mới mà không cần trao đổi. Được tính toán từ MemFree, SReclaimable, kích thước của danh sách LRU tệp và các hình mờ thấp ở mỗi vùng. Ước tính có tính đến việc hệ thống cần một số bộ đệm trang để hoạt động tốt và không phải tất cả các tấm có thể thu hồi sẽ được thu hồi, do các mục đang được sử dụng. Tác động của các yếu tố đó sẽ thay đổi tùy theo hệ thống.
1. Chi tiết có sẵn
Như đã nói ở trên, tmpfs và Shmembộ nhớ khác không thể được giải phóng, chỉ được chuyển sang trao đổi. Cachedtrong /proc/meminfocó thể rất sai lệch, do bao gồm Shmembộ nhớ có thể hoán đổi này . Nếu bạn có quá nhiều tệp trong một tmpfs, nó có thể chiếm nhiều bộ nhớ của bạn :-). Shmemcũng có thể bao gồm một số phân bổ bộ nhớ đồ họa , có thể rất lớn.
MemAvailablecố tình không bao gồm bộ nhớ có thể trao đổi. Trao đổi quá nhiều có thể gây ra sự chậm trễ lâu. Bạn thậm chí có thể đã chọn chạy mà không có không gian trao đổi, hoặc chỉ cho phép một số lượng tương đối hạn chế.
Tôi đã phải kiểm tra lại cách thức MemAvailablehoạt động. Thoạt nhìn, mã dường như không đề cập đến sự khác biệt này.
/*
* Not all the page cache can be freed, otherwise the system will
* start swapping. Assume at least half of the page cache, or the
* low watermark worth of cache, needs to stay.
*/
pagecache = pages[LRU_ACTIVE_FILE] + pages[LRU_INACTIVE_FILE];
pagecache -= min(pagecache / 2, wmark_low);
available += pagecache;
Tuy nhiên, tôi thấy nó được coi Shmemlà bộ nhớ "đã sử dụng" một cách chính xác . Tôi đã tạo một số tệp 1GB trong một tmpfs. Mỗi lần tăng 1GB Shmemgiảm MemAvailablethêm 1GB. Vì vậy, kích thước của "danh sách LRU tệp" không bao gồm bộ nhớ dùng chung hoặc bất kỳ bộ nhớ có thể tráo đổi nào khác. (Tôi nhận thấy số lượng trang tương tự này cũng được sử dụng trong mã tính toán "giới hạn bẩn" ).
Tính MemAvailabletoán này cũng giả định rằng bạn muốn giữ ít nhất đủ bộ đệm tệp để bằng với "hình mờ thấp" của hạt nhân. Hoặc một nửa bộ đệm hiện tại - cái nào nhỏ hơn. (Nó đưa ra giả định tương tự cho các tấm có thể thu hồi là tốt). "Hình mờ thấp" của hạt nhân có thể được điều chỉnh, nhưng nó thường chiếm khoảng 2% RAM hệ thống . Vì vậy, nếu bạn chỉ muốn một ước tính sơ bộ, bạn có thể bỏ qua phần này :-).
Khi bạn đang chạy firefoxvới khoảng 100 MB mã chương trình được ánh xạ trong bộ đệm trang, bạn thường muốn giữ 100 MB đó trong RAM :-). Nếu không, tốt nhất là bạn sẽ phải chịu sự chậm trễ, tệ nhất là hệ thống sẽ dành toàn bộ thời gian để đập giữa các ứng dụng khác nhau. Vì vậy, MemAvailablecho phép một tỷ lệ nhỏ RAM cho việc này. Nó có thể không cho phép đủ, hoặc nó có thể quá hào phóng. "Tác động của các yếu tố đó sẽ thay đổi tùy theo hệ thống".
Đối với nhiều khối lượng công việc của PC, điểm về "nhiều tệp" có thể không liên quan. Mặc dù vậy, hiện tại tôi có bộ nhớ phiến 500 MB có thể phục hồi trên máy tính xách tay của mình (hết 8GB RAM). Điều này là do ext4_inode_cache(hơn 300K đối tượng). Nó xảy ra bởi vì gần đây tôi đã phải quét toàn bộ hệ thống tập tin, để tìm những gì đang sử dụng không gian đĩa của tôi :-). Tôi đã sử dụng lệnh df -x / | sort -n, nhưng ví dụ: Trình phân tích sử dụng đĩa Gnome sẽ làm điều tương tự.
2. [sửa] Bộ nhớ trong các nhóm điều khiển
Cái gọi là "Linux container" được xây dựng từ namespaces, cgroupsvà các tính năng khác nhau theo sở thích :-). Họ có thể cung cấp một môi trường đủ thuyết phục để chạy một cái gì đó gần giống như một hệ thống Linux đầy đủ. Dịch vụ lưu trữ có thể xây dựng các container như thế này và bán chúng dưới dạng "máy chủ ảo" :-).
Các máy chủ lưu trữ cũng có thể xây dựng "máy chủ ảo" bằng các tính năng không có trong dòng chính Linux. OpenVZ chứa các nhóm chính tuyến trước ngày trước hai năm và có thể sử dụng "beancounters" để giới hạn bộ nhớ. Vì vậy, bạn không thể hiểu chính xác các giới hạn bộ nhớ đó hoạt động như thế nào nếu bạn chỉ đọc tài liệu hoặc đặt câu hỏi về nhân Linux chính. cat /proc/user_beancounterscho thấy việc sử dụng hiện tại và giới hạn. vzubctrình bày nó trong một định dạng thân thiện hơn một chút. Các trang chính trên beancounters tài liệu tên hàng.
Các nhóm điều khiển bao gồm khả năng đặt giới hạn bộ nhớ cho các quy trình bên trong chúng. Nếu bạn chạy ứng dụng của mình trong một nhóm như vậy, thì không phải tất cả bộ nhớ hệ thống sẽ có sẵn cho ứng dụng :-). Vì vậy, làm thế nào chúng ta có thể thấy bộ nhớ có sẵn trong trường hợp này?
Giao diện cho điều này khác nhau theo một số cách, tùy thuộc vào việc bạn sử dụng cgroup-v1 hay cgroup-v2 .
Cài đặt máy tính xách tay của tôi sử dụng cgroup-v1. Tôi có thể chạy cat /sys/fs/cgroup/memory/memory.stat. Các tập tin cho thấy các lĩnh vực khác nhau bao gồm total_rss, total_cache, total_shmem. shmem, bao gồm tmpfs, tính vào giới hạn bộ nhớ. Tôi đoán bạn có thể xem total_rssnhư là một tương đương nghịch đảo MemFree. Và cũng có tập tin memory.kmem.usage_in_bytes, đại diện cho bộ nhớ kernel bao gồm các tấm. (Tôi giả sử memory.kmem.cũng bao gồm memory.kmem.tcp.và bất kỳ tiện ích mở rộng nào trong tương lai, mặc dù điều này không được ghi lại rõ ràng). Không có bộ đếm riêng biệt để xem bộ nhớ tấm có thể thu hồi. Tài liệu cho cgroup-v1 nói rằng việc đạt các giới hạn bộ nhớ không kích hoạt việc lấy lại bất kỳ bộ nhớ sàn nào. (Tài liệu cũng có tuyên bố từ chối trách nhiệm rằng nó "lỗi thời vô vọng" và bạn nên kiểm tra mã nguồn hiện tại).
cgroup-v2 thì khác. Tôi nghĩ rằng nhóm gốc (cấp cao nhất) không hỗ trợ kế toán bộ nhớ. cgroup-v2 vẫn có một memory.stattập tin. Tất cả các trường tổng hợp trên các nhóm con, vì vậy bạn không cần phải tìm các total_...trường. Có một filelĩnh vực, có nghĩa là điều tương tự cacheđã làm. Khó chịu là tôi không thấy một lĩnh vực tổng thể như rssbên trong memory.stat; Tôi đoán bạn sẽ phải thêm các lĩnh vực riêng lẻ. Có các số liệu thống kê riêng cho bộ nhớ bản có thể thu hồi và không thể phục hồi; Tôi nghĩ rằng một nhóm v2 được thiết kế để lấy lại các tấm khi nó bắt đầu cạn kiệt bộ nhớ.
Các nhóm Linux không tự động ảo hóa /proc/meminfo(hoặc bất kỳ tệp nào khác trong /proc), do đó sẽ hiển thị các giá trị cho toàn bộ máy. Điều này sẽ gây nhầm lẫn cho khách hàng VPS. Tuy nhiên, có thể sử dụng các không gian tên để thay thế /proc/meminfobằng một tệp được làm giả bởi phần mềm chứa cụ thể . Các giá trị giả hữu ích như thế nào, sẽ phụ thuộc vào phần mềm cụ thể đó làm gì.
systemdtin rằng cgroup-v1 không thể được ủy quyền một cách an toàn, ví dụ như cho các container. Tôi nhìn vào bên trong một systemd-nspawncontainer trên hệ thống cgroup-v1 của mình. Tôi có thể thấy nhóm được đặt bên trong và bộ nhớ kế toán trên đó. Mặt khác, bộ chứa systemdkhông thiết lập các nhóm trên mỗi dịch vụ thông thường cho kế toán tài nguyên. Nếu kế toán bộ nhớ không được kích hoạt trong nhóm này, tôi cho rằng container sẽ không thể kích hoạt nó.
Tôi giả sử nếu bạn đang ở trong một thùng chứa cgroup-v2, nó sẽ trông khác với gốc của hệ thống cgroup-v2 thực sự và bạn sẽ có thể thấy bộ nhớ chiếm cho nhóm cấp cao nhất của nó. Hoặc nếu nhóm bạn có thể thấy không kích hoạt tính năng kế toán bộ nhớ, hy vọng bạn sẽ được ủy quyền để bạn có thể kích hoạt tính toán bộ nhớ trongsystemd (hoặc tương đương).
MemAvailable, nó đã được thêm vào 3.14.