Tại sao máy ảo “khủng” lại chạy chậm? Bài học từ thực tế
Bạn đã bao giờ cấp tới 32 vCPU và 128GB RAM cho một máy ảo SQL Server nhưng kết quả nhận lại là sự chậm chạp đến khó hiểu? Mình từng gặp ca oái oăm này: các máy ảo nhỏ chạy mượt mà, còn “con quái vật” kia lại phản hồi rất chậm. Kiểm tra CPU Ready hay Disk Latency đều xanh mướt, nhưng thực tế hiệu suất lại giảm tới 30%. Thủ phạm chính là NUMA Topology bị lệch pha.
Khi build những máy ảo lớn (Wide VM) có số vCPU hoặc RAM vượt quá khả năng của một socket vật lý, cấu hình mặc định của VMware thường không còn tối ưu. Đây là lúc chúng ta cần can thiệp vào Virtual NUMA (vNUMA) để đưa mọi thứ trở lại quỹ đạo.
Hiểu về NUMA: Đừng để CPU phải “đi mượn” RAM
NUMA vật lý là gì?
Hãy tưởng tượng một máy chủ 2 CPU Intel Xeon. Mỗi CPU quản lý trực tiếp một vùng RAM riêng, gọi là Local Memory. Nếu CPU 1 cần lấy dữ liệu từ RAM của CPU 2, nó phải đi nhờ qua đường cao tốc (như UPI của Intel hoặc Infinity Fabric của AMD). Việc truy cập Remote Memory này làm tăng độ trễ (latency) từ 60ns lên đến hơn 100ns, khiến ứng dụng bị khựng lại.
Vai trò của Virtual NUMA (vNUMA)
vNUMA giúp phơi bày cấu trúc vật lý này vào bên trong máy ảo (Guest OS). Nhờ đó, Windows hay Linux biết rõ CPU nào đi kèm với vùng RAM nào. Hệ điều hành sẽ ưu tiên sắp xếp các tiến trình (process) nằm gọn trong một node, tránh việc phải “đi mượn” RAM xuyên socket gây nghẽn cổ chai.
Cách kiểm tra sơ đồ NUMA trên Host vật lý
Đừng đoán mò, hãy nhìn vào con số cụ thể. Anh em cần biết chính xác host của mình có bao nhiêu NUMA node. Cách nhanh nhất là SSH vào ESXi và gõ lệnh esxtop, sau đó nhấn m để xem bộ nhớ.
Hoặc dùng lệnh trực tiếp trong ESXi Shell để lấy thông số nhanh:
# Đếm số NUMA node trên host
esxcli hardware memory get | grep "NUMA Node Count"
# Xem chi tiết phân bổ core
localcli hardware cpu list | grep "Node ID" | sort -uGiả sử host có 2 Socket, mỗi Socket 16 nhân. Vậy bạn có 2 NUMA node vật lý, mỗi node nắm giữ 16 core.
Thực hành: Cấu hình vNUMA sao cho chuẩn?
Theo mặc định, VMware tự động kích hoạt vNUMA khi máy ảo có từ 9 vCPU trở lên. Tuy nhiên, thuật toán này đôi khi bị “lạc quẻ” với các dòng CPU hiện đại như AMD EPYC vốn có cấu trúc chiplet phức tạp.
1. Quy tắc “Căn chỉnh” (Alignment)
Điểm mấu chốt là: Một vNUMA node của máy ảo phải nằm gọn trong một NUMA node vật lý.
Nếu host có 16 core/socket nhưng bạn tạo VM 20 vCPU, VMware buộc phải chia máy thành 2 vNUMA node. Nếu chia không đều (ví dụ node 4 vCPU và node 16 vCPU), hiệu suất sẽ trồi sụt thất thường.
2. Chỉnh Cores per Socket (Lưu ý từ vSphere 6.5+)
Trước đây, dân kỹ thuật thường chỉnh Cores per Socket để ép vNUMA. Từ bản 6.5, VMware đã thông minh hơn khi tách biệt topology hiển thị và cấu trúc vNUMA bên dưới. Tuy nhiên, thông số này vẫn cực kỳ quan trọng cho việc License phần mềm như SQL Server Standard (vốn giới hạn số socket nhận diện).
- Lời khuyên: Hãy để
Cores per Socket = 1mặc định. Chỉ thay đổi khi phần mềm yêu cầu giới hạn Socket, và hãy đảm bảo số core này là ước số của số core vật lý trên một node.
3. Tinh chỉnh Advanced Parameters
Để trở thành “phù thủy” tối ưu, anh em vào Edit Settings > VM Options > Advanced > Edit Configuration và chú ý hai thông số sau:
numa.autosize.once = FALSE
Mặc định là TRUE, nghĩa là vNUMA chỉ tính toán một lần lúc tạo VM. Nếu bạn vMotion máy ảo sang một host khác có cấu hình CPU khác đời, vNUMA sẽ bị lệch. Chuyển sang FALSE giúp máy ảo tự tính toán lại mỗi khi khởi động để khớp với phần cứng mới.
numa.vcpu.preferHT = TRUE
Dùng khi bạn muốn nhồi nhét một máy ảo lớn vào ít NUMA node hơn bằng cách tận dụng luồng (Hyper-Threading). Ví dụ: VM 24 vCPU nhét gọn vào một node vật lý 16 core/32 threads. Độ trễ RAM sẽ giảm đáng kể, dù sức mạnh tính toán thuần túy có thể giảm nhẹ.
Kiểm tra thành quả
Sau khi khởi động lại, hãy kiểm tra xem Guest OS đã hiểu đúng ý bạn chưa. Với Linux, dùng lệnh numactl --hardware. Với Windows, hãy tải công cụ Coreinfo của Sysinternals và chạy:
coreinfo.exe -nNếu các vCPU được gom nhóm chuẩn xác và RAM chia đều cho các node, bạn đã thành công.
Kinh nghiệm thực chiến: Case study SAP HANA
Mình từng xử lý một hệ thống SAP HANA chạy trên CPU AMD EPYC. Ban đầu, query chạy rất chậm do hiện tượng “Memory Slop”. Sau khi can thiệp vào tham số numa.nodeCount để khớp chính xác với số L3 Cache của AMD, tốc độ xử lý query đã tăng vọt 20%. Điều tuyệt vời là kết quả này đạt được mà không tốn thêm một xu nâng cấp phần cứng nào.
Kết luận
Tối ưu vNUMA không dành cho các máy ảo nhỏ (dưới 8 vCPU). Nhưng với Database, ERP hay các hệ thống Big Data, đây là bước sống còn. Cấu hình vNUMA càng khớp với vật lý, độ trễ càng thấp, ứng dụng chạy càng mượt. Chúc anh em tối ưu hệ thống thành công!
