VPS Ninja School Online 2026: Native Memory Tracking Giúp Tìm RAM Java “Mất Tích” Thế Nào?
Hướng dẫn dùng Native Memory Tracking và jcmd để phân tích RAM ngoài heap khi chạy source NSO trên VPS: thread stack, metaspace, code cache, native memory và cách tránh OOM.
Tiêu chí đánh giá
Từ khóa chính: VPS Ninja School Online 2026.
Từ khóa phụ: source NSO, Native Memory Tracking, JDK 25, jcmd, native memory Java, thread stack, metaspace, VPS source NSO.
VPS Ninja School Online 2026 chạy source NSO thường gặp một tình huống rất dễ gây hiểu nhầm: trong JVM, heap mới dùng khoảng 2–3 GB nhưng Task Manager hoặc Linux top lại cho thấy process Java đang chiếm 5–6 GB RAM. Người vận hành nhìn vào Xmx rồi nghĩ “Java bị leak”, trong khi phần chênh lệch có thể nằm ở thread stack, metaspace, code cache, direct buffer, GC metadata hoặc các vùng native memory khác mà heap chart không thể hiện.
Đây là lúc Native Memory Tracking, viết tắt NMT, trở nên cực kỳ hữu ích. Oracle tài liệu hóa NMT trong Java 25 như một tính năng của HotSpot dùng để theo dõi các vùng native memory mà JVM sử dụng. NMT có thể tạo báo cáo dạng summary hoặc detail, hỗ trợ đặt baseline rồi so sánh theo thời gian bằng jcmd. Điều này giúp người quản trị trả lời câu hỏi rất cụ thể: phần RAM ngoài heap đang nằm ở đâu và có tăng bất thường hay không.
Với source game Java, vấn đề này đặc biệt quan trọng vì server thường có nhiều thread, socket, class, buffer và thư viện. Nếu chỉ nhìn heap mà bỏ qua native memory, bạn có thể tăng Xmx sai hướng, làm VPS thiếu headroom và cuối cùng bị OOM hoặc swap. Bài viết dưới đây tập trung vào cách dùng NMT đúng cách, cách đọc report, giới hạn của công cụ và cách áp dụng trên VPS source NSO thực tế.
Mục lục
- Native memory trong Java là gì?
- NMT theo dõi được những vùng nào?
- NMT không theo dõi được gì?
- Cách bật NMT khi khởi động source NSO
- Cách dùng jcmd summary, detail và baseline
- Phân tích Thread, Class, Code, GC và Compiler
- Ví dụ thực tế khi RSS cao hơn heap
- Cách phân biệt heap leak và native leak
- Liên hệ source NRO, source HSO
- Xu hướng Java 2026–2027
- Lợi ích, rủi ro và FAQ
Native memory trong Java là gì?
Khi nói “Java dùng RAM”, nhiều người chỉ nghĩ tới heap. Heap là nơi object Java thông thường được cấp phát và được garbage collector quản lý. Nhưng JVM còn cần nhiều vùng memory khác nằm ngoài heap.
Các vùng phổ biến gồm thread stacks, metaspace chứa metadata class, code cache chứa mã máy do JIT compiler sinh ra, cấu trúc của garbage collector, symbol table, arena nội bộ, native library và bộ nhớ cấp phát bởi một số API trực tiếp.
Vì vậy tổng RSS của process Java gần như luôn lớn hơn heap used. Chênh lệch nhỏ là bình thường; chênh lệch lớn hoặc tăng liên tục mới cần điều tra.
NMT theo dõi được những gì?
Oracle cho biết NMT tập trung vào bộ nhớ native mà JVM/HotSpot sử dụng. Báo cáo thường chia thành các nhóm như Java Heap, Class, Thread, Code, GC, Compiler, Internal, Symbol, Native Memory Tracking và một số category khác tùy phiên bản JVM.
Điều này cho phép bạn thấy ví dụ: heap 3 GB, thread stack 600 MB, class metadata 250 MB, code cache 180 MB, GC structures 300 MB. Khi cộng lại, con số gần với RSS hơn và bạn hiểu RAM “đi đâu”.
NMT không theo dõi hoàn toàn third-party native memory
Oracle nêu rõ NMT không theo dõi toàn bộ allocation từ third-party native code hoặc mọi thư viện JDK. Nếu source NSO dùng JNI, driver native hoặc library ngoài JVM, NMT có thể không thấy toàn bộ phần memory đó. Vì thế NMT rất hữu ích nhưng không phải ảnh chụp tuyệt đối của mọi byte RSS.
Cách bật NMT khi khởi động source NSO
NMT mặc định tắt. Bạn phải bật ngay khi JVM khởi động bằng tùy chọn:
-XX:NativeMemoryTracking=summary
hoặc:
-XX:NativeMemoryTracking=detail
summary cho tổng hợp theo category và thường đủ cho production diagnostic ban đầu. detail cung cấp dữ liệu chi tiết hơn nhưng có thêm overhead. Với VPS nhỏ, nên bắt đầu summary.
Ví dụ lệnh khởi động:
java -XX:NativeMemoryTracking=summary -Xms2g -Xmx4g -jar nso-server.jar
Không thể bật NMT sau khi JVM đã chạy
Đây là điểm quan trọng. Oracle cho biết bạn có thể dừng NMT bằng jcmd nhưng không thể bắt đầu hoặc restart NMT trong một JVM đã chạy nếu ban đầu chưa bật. Vì vậy nếu đang điều tra sự cố lâu dài, hãy chuẩn bị staging hoặc maintenance window rồi restart với NMT.
Dùng jcmd để xem report
Trước tiên xác định PID Java:
jcmd
Sau đó lấy summary:
jcmd <PID> VM.native_memory summary
Báo cáo sẽ liệt kê tổng reserved, committed và từng nhóm memory. Reserved là vùng địa chỉ JVM giữ chỗ; committed mới gần với memory thực tế đã được cấp.
Reserved không đồng nghĩa RAM đã dùng
Nhiều người nhìn thấy reserved rất lớn rồi lo lắng. Trên hệ điều hành 64-bit, JVM có thể reserve address space lớn mà chưa commit toàn bộ. Khi đánh giá áp lực RAM, hãy tập trung committed, RSS và working set.
Baseline và diff
NMT hỗ trợ baseline, rất hữu ích khi source NSO chạy vài giờ rồi RAM tăng. Sau warm-up, bạn tạo baseline:
jcmd <PID> VM.native_memory baseline
Một giờ sau hoặc lúc memory tăng, chạy:
jcmd <PID> VM.native_memory summary.diff
Bạn sẽ thấy category nào tăng so với baseline. Đây là cách tìm hướng điều tra nhanh hơn rất nhiều so với chỉ nhìn tổng RSS.
Phân tích nhóm Thread
Nếu category Thread tăng mạnh, hãy xem số lượng thread. Mỗi platform thread có stack native. Với hàng nghìn thread, chỉ riêng stack có thể tốn hàng trăm MB hoặc hơn.
Source NSO cũ đôi khi tạo thread cho từng module hoặc connection mà không dọn đúng. Nếu thread count tăng theo số người online rồi không giảm, có thể có thread leak hoặc executor lifecycle sai.
Xss ảnh hưởng thế nào?
-Xss kiểm soát kích thước stack mỗi Java thread ở mức nhất định. Giảm Xss có thể tiết kiệm memory nhưng nếu quá thấp sẽ gây StackOverflowError. Không nên tinh chỉnh chỉ dựa vào lời khuyên trên mạng; hãy xem call depth và thread count thật.
Phân tích nhóm Class/Metaspace
Metaspace chứa metadata class. Nếu source dùng nhiều classloader, plugin reload hoặc dynamic proxy, class metadata có thể tăng theo thời gian. Nếu classloader không được giải phóng, bạn có thể gặp classloader leak.
NMT cho biết Class category tăng nhưng để xác định classloader cụ thể, có thể cần JFR, class histogram hoặc heap dump. NMT giúp bạn khoanh vùng trước.
Phân tích Code Cache
JIT compiler biến bytecode thành mã máy và lưu vào code cache. Code category tăng khi JVM compile nhiều method. Đây thường là behavior bình thường trong warm-up rồi ổn định.
Nếu source chạy lâu và code cache chạm giới hạn, JVM có thể giảm khả năng JIT thêm code. Tuy nhiên trong đa số source game nhỏ, đây ít khi là nút thắt đầu tiên.
Phân tích GC memory
Mỗi garbage collector cần cấu trúc dữ liệu riêng. G1, ZGC, Shenandoah có mức metadata khác nhau. Nếu bạn đổi collector, native overhead có thể thay đổi ngay cả khi heap Xmx giữ nguyên.
Do đó khi benchmark collector, đừng chỉ so heap used; hãy so tổng RSS và NMT category.
Direct buffer và off-heap
Các thư viện network như Netty có thể dùng direct buffer ngoài heap. NMT có thể phản ánh một phần qua category phù hợp, nhưng tùy allocation path. Nếu source NSO dùng NIO/direct ByteBuffer nhiều, off-heap memory cần được theo dõi riêng.
Có thể dùng -XX:MaxDirectMemorySize trong trường hợp cần giới hạn, nhưng không nên đặt quá thấp gây lỗi network buffer.
Ví dụ thực tế: heap 2,5 GB nhưng process 5 GB
Giả sử VPS có 8 GB RAM, Xmx 4 GB. JFR cho thấy heap used 2,5 GB, nhưng process RSS 5 GB. Người dùng tưởng Java leak 2,5 GB.
NMT summary cho thấy: heap committed 3,5 GB, Thread 700 MB do 1.400 thread, Class 250 MB, GC 300 MB, Code 180 MB và các category khác. Hóa ra vấn đề lớn nhất là số lượng thread quá cao.
Sau khi sửa executor và giảm thread idle, RSS giảm hơn 500 MB mà không phải hạ Xmx.
Ví dụ thực tế: metaspace tăng sau mỗi lần reload
Một source có chức năng reload plugin/module. Mỗi lần reload, Class category tăng 30–50 MB và không giảm. Baseline diff cho thấy memory class metadata tăng đều.
Điều này gợi ý classloader cũ không được giải phóng. Đội dev kiểm tra static reference giữ plugin classloader, sửa lifecycle và memory ổn định lại.
Phân biệt heap leak và native leak
Nếu heap used sau Full GC liên tục tăng, nghi heap retention. Nếu heap ổn nhưng RSS tăng, xem NMT. Nếu NMT cũng không giải thích phần tăng, có thể third-party native allocation, memory-mapped file hoặc kernel buffer cần công cụ hệ điều hành sâu hơn.
Đây là lý do không nên kết luận “Java leak” chỉ từ Task Manager.
NMT có overhead không?
Có. Oracle cho biết NMT có overhead về memory và hiệu năng. Summary nhẹ hơn detail. Với production nhạy latency, nên benchmark trước; khi không còn cần điều tra có thể tắt NMT trong lần restart tiếp theo.
Kết hợp NMT với JFR
NMT trả lời “native memory ở category nào”, còn JFR trả lời nhiều câu hỏi runtime như allocation, GC, thread contention và CPU. Dùng cả hai giúp nhìn đầy đủ hơn.
SOURCEGAMEZ.COM đã có bài về JFR cho source NSO. Kết hợp NMT + JFR là bộ công cụ rất mạnh cho VPS Java.
Liên hệ source SOURCEGAMEZ.COM
Bạn có thể tham khảo source NSO, source NRO và source HSO. NMT áp dụng cho tất cả backend HotSpot Java tương thích, không riêng NSO.
Xu hướng Java 2026–2027
Java hiện đại ngày càng tối ưu cho cloud, container và observability. Native memory trở thành chủ đề lớn vì trên cloud, giới hạn memory thường cứng. Một container OOMKilled dù heap chưa đầy là tình huống rất phổ biến nếu người vận hành không hiểu off-heap/native memory.
Dự đoán các từ khóa như “Native Memory Tracking source NSO”, “Java RSS cao hơn heap”, “VPS source NSO leak RAM” sẽ tăng khi nhiều source được nâng lên JDK mới và chạy Docker.
Lợi ích
- Biết RAM ngoài heap nằm ở đâu.
- Phát hiện thread stack tăng bất thường.
- Theo dõi metaspace, code cache và GC metadata.
- So baseline/diff theo thời gian.
- Giảm việc hạ/tăng Xmx sai nguyên nhân.
Rủi ro và hạn chế
- NMT có overhead.
- Phải bật từ lúc JVM khởi động.
- Không theo dõi toàn bộ third-party native allocation.
- Detail mode có thể nặng hơn summary.
- NMT không thay heap dump/JFR trong mọi tình huống.
Câu hỏi thường gặp
NMT có sẵn trong JDK 25 không?
Có. Oracle tài liệu hóa NMT trong Java 25 HotSpot VM.
NMT có tìm memory leak không?
Nó giúp khoanh vùng category native memory tăng. Để tìm object hoặc native allocation cụ thể có thể cần thêm công cụ khác.
Có bật NMT sau khi server đang chạy được không?
Không. NMT phải được bật khi JVM khởi động.
Summary hay detail?
Bắt đầu summary. Chỉ dùng detail khi cần dữ liệu sâu hơn và đã chấp nhận overhead.
Xem source NSO ở đâu?
Xem source NSO tại SOURCEGAMEZ.COM.
Kết luận
VPS Ninja School Online 2026 chạy source NSO muốn tối ưu RAM đúng cách cần nhìn xa hơn heap. Native Memory Tracking giúp giải thích phần memory của thread, metaspace, code cache, GC và nhiều cấu trúc JVM khác, từ đó tránh kết luận sai khi RSS cao.
Tham khảo thêm source NSO, source NRO, source HSO và kho source SOURCEGAMEZ.COM.