Khi quản trị VM chạy trên host ảo hóa (VMWare ESXi hoặc Hyper-V) và phân tích vấn đề hiệu năng, thường gặp tình huống dung lượng bộ nhớ có sẵn trong guest OS nhỏ hơn nhiều so với hệ điều hành nhìn thấy (hoặc được gán cho nó). Ví dụ: 8 GB bộ nhớ được cấp cho VM, Task Manager hiển thị 1 GB trống trong khi tất cả tiến trình chạy tiêu thụ dưới 3 GB. 4 GB còn lại đâu rồi?
Thông thường, hành vi này do sử dụng tính năng memory overcommit trong hypervisor.
Memory overcommit là tính năng hypervisor cho phép cấp phát cho máy ảo nhiều bộ nhớ hơn so với bộ nhớ vật lý có sẵn trên host, nhưng không đảm bảo tất cả bộ nhớ yêu cầu có thể cấp phát tại một thời điểm cụ thể. Memory overcommit cho phép cấp phát VM dày đặc hơn nhờ phân phối bộ nhớ động giữa các VM tùy thuộc tải host hiện tại (tài nguyên VM rảnh có thể phân phối lại cho VM tải hơn).
Một trong các cơ chế triển khai memory overcommit trong VMWare là Memory Ballooning. Trên Hyper-V, tính năng tương tự được triển khai bằng Dynamic Memory.
Lưu ý. Cả VMWare và Microsoft đều sử dụng rộng rãi và hiệu quả nén bộ nhớ để tiết kiệm tài nguyên bộ nhớ (cũng là một triển khai của công nghệ memory overcommit).
Trên VMWare ESXi, memory overcommitment (virtual memory ballooning) được triển khai bởi driver vmmemctl.sys (bao gồm trong VMware Tools), có thể chiếm bộ nhớ vật lý bằng cách tạo tiến trình giả (như bơm bóng) trong nó nếu cần. Do đó, lượng bộ nhớ bị chiếm trở nên không khả dụng cho ứng dụng khác trong guest OS, và hypervisor có thể phân phối bộ nhớ trống giữa các VM khác. Trên Hyper-V Dynamic memory, dùng driver dmvsc.sys từ integration services (thành phần Dynamic Memory VSC). Cài đặt memory overcommitment do quản trị viên hypervisor quản lý.
Làm thế nào để phát hiện từ bên trong guest VM rằng nó thực sự có ít bộ nhớ vật lý khả dụng hơn so với những gì hệ điều hành guest nhìn thấy?
Xem cách phát hiện driver balloon trong guest Windows OS và kích thước của nó. Phân tích ví dụ này.
8 GB bộ nhớ cấp cho VM chạy guest Windows Server 2012 R2. Task Manager hiển thị 93% bộ nhớ được sử dụng (7.4 GB bị chiếm). Tuy nhiên, nếu tổng dung lượng bộ nhớ dùng bởi tất cả tiến trình chạy, kết luận bất ngờ chỉ 2.5 GB thực sự được dùng. 5 GB còn lại đâu? Cả Task Manager lẫn Resource Monitor không trả lời được.
Để hiểu chuyện gì xảy ra với bộ nhớ, cần dùng công cụ RamMap của Mark Russinovich (trước đây đã dùng công cụ này chẩn đoán sự cố sử dụng bộ nhớ cao bởi metafile trên Windows Server). Tải công cụ từ trang Microsoft (https://technet.microsoft.com/en-us/library/ff700229.aspx) và chạy với quyền admin. Trên tab Use Counts thấy hầu hết bộ nhớ (5.4 GB) được dùng bởi đối tượng Driver Locked.
Đây là bộ nhớ hypervisor đã chiếm và phân phối giữa các VM khác dùng driver balloon trong guest OS. Nghĩa là host hypervisor không đủ bộ nhớ hoặc quản trị viên hypervisor dùng chính sách giới hạn bộ nhớ cho VM này.
Thống kê bộ nhớ VM hiện tại trong Hyper-V có thể hiển thị bằng bộ đếm hiệu năng riêng trong Performance Monitor:
- Hyper-V Dynamic Memory → Guest Visible Memory
- Hyper-V Dynamic Memory → Physical Memory
Để tắt hành vi này, quản trị viên hypervisor phải tắt tùy chọn Enable Dynamic Memory trong cài đặt Hyper-V của VM (hoặc tăng giá trị dự trữ tối thiểu).
Nếu dùng host VMWare ESXi, có thể dự trữ thêm bộ nhớ cho VM này trong Resource Settings hoặc dự trữ toàn bộ bộ nhớ – Reserve all guest memory (All locked).