Cấu hình bộ nhớ Java cho Jenkins chuẩn Container/Kubernetes: Tránh OOMKill, chạy ổn định hơn

Trong nhiều năm, tối ưu Jenkins thường gắn liền với một danh sách dài JVM flags: tăng heap, ép GC, đặt pause target,… Tuy nhiên, từ Java 17 trở lên, cơ chế JVM ergonomics đã hoàn thiện hơn rất nhiều, đến mức việc can thiệp theo thói quen hoặc sao chép cấu hình từ nơi khác có thể khiến hiệu năng kém ổn định hơn thay vì cải thiện.

Bài viết này DevOps VietNam sẽ tổng hợp thực tế khi nào nên giữ mặc định, khi nào nên can thiệp, và cấu hình gợi ý để Jenkins chạy tốt hơn, đặc biệt trong môi trường container hay Kubernetes.

Vì sao Java 17+ ít cần tuning theo cách truyền thống?

Với Java 17, JVM có nhiều cải tiến quan trọng cho môi trường hiện đại:

Container-aware: nhận biết giới hạn tài nguyên trong container (RAM/CPU) và tự chọn heap hoặc threads phù hợp.
Tối ưu GC theo hành vi runtime nhờ heuristics và telemetry tốt hơn so với các phiên bản cũ.
Quản lý cấp phát bộ nhớ và tối ưu nội bộ tốt hơn.
G1GC là mặc định, thường cho hành vi ổn định và dễ dự đoán hơn so với các lựa chọn đời cũ trong đa số workload.

Điểm mấu chốt là thay vì cố định -Xms và -Xmx theo một cấu hình áp dụng chung, cách tiếp cận hiện đại thường là để JVM tự điều chỉnh theo memory limit của container và sử dụng các tham số theo tỷ lệ để kiểm soát phạm vi heap.

Tư duy mới về heap trong container: dùng phần trăm thay vì số cố định

Trong môi trường container, việc đặt heap kiểu -Xmx8g có thể gây nhiều vấn đề:

Pod thay đổi kích thước dẫn tới cấu hình cũ không còn phù hợp.
Heap chiếm quá gần RAM limit dẫn tới rủi ro OOMKill, vì tổng bộ nhớ tiến trình không chỉ gồm heap.

Cần lưu ý, ngoài heap còn có off-heap và các thành phần như metaspace, thread stacks, native memory, direct buffers, thư viện native, và phần bộ nhớ của hệ điều hành.

Vì vậy, khuyến nghị phổ biến hiện nay là chuyển sang:

-XX:MaxRAMPercentage đặt heap tối đa theo phần trăm RAM container
-XX:InitialRAMPercentage đặt heap ban đầu theo phần trăm RAM container

Cách này giúp heap tự điều chỉnh theo giới hạn container và giảm nhu cầu phải thay đổi cấu hình riêng cho từng môi trường triển khai.

Giải thích nhanh các tham số quan trọng

1. G1GC

G1GC chia heap thành nhiều region và thu gom theo từng phần, nhằm giữ GC pause ổn định. Đây là lựa chọn mặc định của Java 17+ và phù hợp với nhiều cấu hình heap trung bình đến lớn.

2. `-XX:MaxRAMPercentage`

Xác định tỷ lệ RAM container mà JVM dùng làm max heap. Ví dụ 60.0 nghĩa là heap tối đa khoảng 60% RAM limit. Ưu điểm là khi pod thay đổi giới hạn RAM thì heap cũng thay đổi theo mà không cần sửa cấu hình.

3. `-XX:InitialRAMPercentage`

Xác định heap ban đầu theo tỷ lệ. Heap ban đầu thấp hơn có thể giảm áp lực RAM lúc startup và để JVM tăng dần theo nhu cầu.

Cấu hình gợi ý cho Java 17/21+ (Jenkins controller và agent)

1. Jenkins Controller (instance lớn, nhiều job, nhiều users, nhiều plugins)

Mục tiêu là ổn định, chừa RAM cho OS và off-heap.

JAVA_OPTS="
  -XX:+UseG1GC
  -XX:MaxRAMPercentage=60.0
  -XX:InitialRAMPercentage=20.0
"

Giải thích: 60% là mức tương đối an toàn để giảm nguy cơ OOMKill do thiếu headroom cho off-heap, vì controller thường có nhiều hoạt động nền và chạy liên tục trong thời gian dài.

2. Jenkins Agent/Worker (nhỏ hơn, workload ổn định hơn, ít plugin và không có UI)

Có thể dùng heap tỷ lệ cao hơn vì tiến trình thường có ít thành phần nền hơn controller.

JAVA_OPTS="
  -XX:+UseG1GC
  -XX:MaxRAMPercentage=75.0
  -XX:InitialRAMPercentage=50.0
"

Lý do: agent chủ yếu tập trung vào build và test, thường ít gánh các thành phần như indexing, quản trị, và tác vụ nền của controller.

Nếu vẫn đang chạy Java 11 hoặc cũ hơn

Với Java 11 trở xuống, mức độ container-aware có thể khác nhau theo bản build và môi trường, nên cách tiếp cận thường vẫn là:

Ưu tiên -Xms và -Xmx theo giá trị tuyệt đối.
Thường đặt -Xms gần hoặc bằng -Xmx để tránh heap expansion gây biến động.

Ví dụ (container 8GB, heap 4GB):

-Xms4G -Xmx4G -XX:+UseG1GC

Các nguyên nhân phổ biến khiến Jenkins chậm hoặc hay restart

1. Không để đủ headroom cho off-heap

Không nên cấu hình heap sát với RAM limit. Dù heap chưa đầy, tiến trình vẫn có thể vượt RAM limit vì off-heap tăng theo thời gian chạy, số lượng thread, plugin, và native libs.

Gợi ý thực hành: nếu controller hay bị OOMKill, hãy giảm MaxRAMPercentage trước, sau đó mới phân tích sâu hơn.

2. Trộn `-Xmx/-Xms` với `MaxRAMPercentage/InitialRAMPercentage`

Nếu đặt đồng thời hai nhóm, JVM có thể ưu tiên nhóm này và bỏ qua nhóm kia, khiến kết quả khó kiểm soát. Nên chọn một hướng nhất quán, hoặc heap theo phần trăm RAM container, hoặc heap cố định bằng -Xms/-Xmx.

3. Thêm GC flags nâng cao khi chưa có số liệu

Các tham số như -XX:MaxGCPauseMillis, -XX:G1HeapRegionSize có thể hữu ích trong một số trường hợp đặc thù, nhưng nếu áp dụng theo thói quen hoặc sao chép, chúng có thể làm hệ thống kém ổn định. Cách đúng là đo trước, điều chỉnh sau, và thay đổi từng bước.

4. Không nên bỏ qua cảnh báo JVM trong log

Nếu JVM cảnh báo liên quan tới container detection, memory limit, hoặc flags không được áp dụng, đó thường là dấu hiệu cấu hình không khớp với môi trường chạy thực tế. Nên xử lý các cảnh báo này trước khi tối ưu sâu.

Theo dõi và kiểm chứng: tuning tốt phải thể hiện trên số liệu

1. GC: đo GC pause và tần suất Full GC

Các điểm quan sát quan trọng:

GC pause có ổn định không
Full GC có xuất hiện thường xuyên không
heap có xu hướng tăng dần theo thời gian không, có thể liên quan tới memory leak hoặc giữ tham chiếu lâu

2. Xác nhận JVM nhận đúng flags

Có thể dùng:

jcmd 
<pid> VM.command_line

Hoặc kiểm tra command line của process trong container hoặc host.

3. Bật GC log tối thiểu để phân tích

JAVA_OPTS="
  -XX:+UseG1GC
  -XX:MaxRAMPercentage=60.0
  -XX:InitialRAMPercentage=20.0
  -XX:+PrintGCDetails
  -XX:+PrintGCDateStamps
  -Xloggc:/var/log/jenkins/gc.log
"

Sau đó theo dõi gc.log để phát hiện GC pause bất thường hoặc Full GC lặp lại.

Checklist nhanh cho Jenkins trên Java 17+

Controller: heap khoảng 50 đến 65% RAM limit.
Agent/Worker: có thể 70 đến 75% nếu workload phù hợp.
Luôn chừa headroom cho off-heap và OS.
Bắt đầu với cấu hình an toàn, sau đó tăng dần nếu còn dư RAM và GC ổn định.
Giám sát trước khi tối ưu sâu, nhiều vấn đề vận hành liên quan tới sizing và headroom hơn là thiếu JVM flags.

Khi nào cần phân tích sâu hơn ngoài G1GC và RAMPercentage?

Nếu bạn đã đặt heap tỷ lệ hợp lý, có GC log, và vẫn gặp spike GC pause, UI chậm, agent disconnect, thì lúc đó mới nên phân tích sâu hơn, ví dụ nguyên nhân Full GC, pressure từ metaspace, thread stacks, direct buffers, hoặc hành vi plugin và workload.

Kết luận

Với Java 17/21+, tối ưu Jenkins hiệu quả thường bắt đầu từ ba việc: dùng G1GC, cấu hình heap theo phần trăm RAM container, và chừa đủ headroom cho off-heap và OS. Khi đã có dữ liệu từ GC log và theo dõi memory thực tế, bạn mới nên can thiệp sâu hơn vào các GC flags nâng cao để tránh thay đổi khó kiểm soát.