Hiệu năng Jenkins

Hiệu năng Jenkins không phải một con số CPU hay số executor. Một build chậm có thể đang đợi trong queue, bị nghẽn ở controller, tranh chấp disk trên agent, hoặc chờ SCM, registry và test service bên ngoài. Tài liệu này hướng dẫn biến triệu chứng đó thành số đo, giả thuyết và thay đổi có thể đảo ngược.

Mục lụcCopy Anchor Link

• Mục tiêu và mô hình hiệu năng
  • Luồng và ranh giới bottleneck
• Lập baseline và SLI
  • Các chỉ số cần ghi
  • Dashboard và query khởi điểm
• Phân tích bottleneck
  • Controller: điều phối, JVM và storage
  • Agent và build: executor, workspace và mạng
  • Pipeline, log và plugin
• Tuning theo vòng lặp an toàn
  • Các thay đổi thường có ích
  • Thay đổi cần tránh
• Dữ liệu build và retention
• Capacity planning
• Lab sandbox với mock workload
  • Chuẩn bị và chạy
  • Kết quả mong đợi và cleanup
• Troubleshooting
• Checklist vận hành
• Nguồn Jenkins chính thức
• Đọc tiếp

Mục tiêu và mô hình hiệu năngCopy Anchor Link

Sau bài này, bạn có thể đặt baseline cho dịch vụ CI, phân biệt nơi chậm, và thực hiện một thay đổi nhỏ với tiêu chí thành công cùng rollback rõ ràng. Đọc Kiến trúc Jenkins trước nếu controller, queue, executor và workspace còn mới.

Luồng và ranh giới bottleneckCopy Anchor Link

direction: down
trigger: Trigger
controller: Controller
queue: Build Queue
agent: Agent/executor
build: Build, test, publish
control_cost: "HTTP/UI, scheduling\nJVM heap/GC/threads\nJENKINS_HOME I/O"
queue_cost: "Queue wait, label, lock\nprovisioning"
agent_cost: "CPU, RAM, disk I/O\nworkspace, cache"
external: "SCM, registry, artifact store\nnetwork"
trigger -> controller -> queue -> agent -> build
controller -> control_cost
queue -> queue_cost
agent -> agent_cost
build -> external

Controller bottleneck xuất hiện khi UI/API chậm, queue được xử lý chậm, JVM có GC pause dài, thread bị chặn hoặc filesystem JENKINS_HOME chậm. Controller điều phối và giữ metadata; nó không phải nơi chạy build production. Đặt built-in node là 0 executors để không để workload cạnh tranh trực tiếp với controller.

Agent/build bottleneck xuất hiện khi queue chỉ tăng ở một pool label, executor bận, workspace đầy, I/O wait cao, cache cold, hoặc một stage chờ dịch vụ ngoài. Executor rảnh ở windows không giúp Pipeline cần linux && docker. Cách đọc labels, queue và executor theo pool nằm trong Labels & Executors.

Lập baseline và SLICopy Anchor Link

Baseline là ảnh chụp hành vi bình thường trong một cửa sổ đại diện, ví dụ hai tuần có giờ cao điểm, cache warm/cold và loại workload rõ ràng. Đừng trộn hotfix nhỏ với nightly integration lớn. Gắn mỗi số đo với controller, pool label, job class và phiên bản Jenkins/plugin để so sánh sau thay đổi có ý nghĩa.

SLI (service level indicator) là phép đo outcome; SLO là mục tiêu được đội chịu trách nhiệm đồng thuận. Ví dụ: “p95 queue wait của hotfix-linux dưới 5 phút trong 28 ngày” có ích hơn “queue phải bằng 0”. Nó mô tả pool, percentile và cửa sổ đo.

Các chỉ số cần ghiCopy Anchor Link

Theo dõi metrics và dashboard theo hướng dẫn Monitoring & Metrics; log controller, agent và Console Output cần được đối chiếu theo thời điểm tại Logs & Diagnostics. Metrics chỉ cho biết cái gì xấu đi; log và build URL giúp tìm vì sao.

Dashboard và query khởi điểmCopy Anchor Link

Một dashboard vận hành tối thiểu có hàng controller (availability, HTTP, heap/GC, threads, JENKINS_HOME), hàng queue/executor theo pool, hàng agent (online, CPU/RAM/disk/I/O) và hàng Pipeline (queue wait, runtime, result, stage chậm). Dashboard cần cho drill-down từ pool sang Nodes, Build Queue và build URL; không dùng một tổng số executor toàn hệ thống làm capacity.

Query sau là điểm bắt đầu minh họa cho Prometheus Metrics Plugin với namespace ci. Xem /prometheus/ của instance sandbox để xác nhận tên metric và labels trước; không sao chép query hoặc threshold vào production nếu metric không tồn tại.

# Saturation executor trên từng pool nếu collector có label pool.
sum by (pool) (ci_jenkins_executors_busy)
/ clamp_min(sum by (pool) (ci_jenkins_executors_online), 1)

# Queue hiện tại; lọc pool/label theo labels thực tế của exporter.
sum by (pool) (ci_jenkins_executors_queue_length)

# Tốc độ build hoàn tất trong 15 phút, chỉ hợp lệ khi counter này có trên instance.
sum(increase(ci_jenkins_builds_successful_build_count[15m]))

Ghi tên query, interval scrape, label filters và nguồn dữ liệu cùng baseline. Đối với queue wait và runtime không có metric chuẩn phù hợp, dùng dữ liệu build đã chuẩn hóa hoặc dashboard plugin được phê duyệt; không bịa metric để làm dashboard trông đầy đủ.

Phân tích bottleneckCopy Anchor Link

Bắt đầu từ thay đổi so với baseline: queue p95 tăng nhưng runtime giữ nguyên là dấu hiệu scheduling/capacity; runtime tăng trong khi queue ổn định thường nằm ở agent, Pipeline hay dependency. Cùng lúc kiểm tra một thay đổi gần đây về Jenkins LTS, Java, plugin, image agent, SCM hoặc artifact storage.

Controller: điều phối, JVM và storageCopy Anchor Link

JVM heap là vùng nhớ Java, không phải dung lượng disk. Tăng -Xmx chỉ hợp lý khi số đo cho thấy memory pressure và host vẫn còn RAM headroom. Heap quá lớn có thể tăng thời gian GC; heap vượt RAM có thể dẫn đến swap/OOM. Chỉ dùng JVM options đã được Java và Jenkins LTS hiện tại hỗ trợ, lưu cấu hình cũ để rollback và thay đổi trong sandbox trước.

Thread dump hoặc heap dump có thể chứa URL, tên job, tham số, environment, đường dẫn và đôi khi dữ liệu nhạy cảm do plugin giữ trong bộ nhớ. Thu thập ở phạm vi tối thiểu, chỉ khi owner đã phê duyệt, lưu mã hóa với ACL hẹp và review/redact trước khi chia sẻ. Không dán dump vào ticket công khai hay console log. Xem Logs & Diagnostics để xử lý diagnostic bundle và log theo quy trình an toàn.

Agent và build: executor, workspace và mạngCopy Anchor Link

Nếu controller ổn định nhưng runtime stage tăng, mở Console Output của vài build đại diện và đối chiếu node, workspace, CPU/RAM, I/O wait, free inodes, cache hit/miss và network. Một executor chỉ là slot scheduler; nó không thêm CPU core, RAM, IOPS, Docker daemon, port hay license.

• Queue wait cao, executor bận: kiểm tra pool label, build dài, fan-out và policy lock/throttle. Thêm agent tương đương thường cô lập tốt hơn nhồi nhiều executor lên một host.
• Runtime tăng khi tăng concurrency: CPU throttling, RAM pressure/swap, disk I/O hoặc network/registry có thể đang tranh chấp. Hạ concurrency và đo lại từng tài nguyên.
• Workspace/cache đầy hoặc checkout chậm: đo dung lượng/inodes và I/O trên agent; xóa dữ liệu theo retention đã phê duyệt, không xóa workspace đang chạy.
• Agent offline/reconnect: so log agent, controller Remoting, DNS/TLS và network loss theo timestamp. Restart controller không sửa quota cloud, image agent hay route mạng.

Đặt agent ở cấp Pipeline hoặc stage một cách có chủ đích. Chọn agent cho Pipeline giải thích allocation/workspace; Parallel và Matrix giúp ước lượng fan-out trước khi một commit xin hàng chục executor cùng lúc.

Pipeline, log và pluginCopy Anchor Link

Pipeline CPS (Continuation Passing Style) lưu trạng thái để Pipeline có thể tiếp tục sau restart. CPS có chi phí trên controller, đặc biệt khi script Groovy thao tác collection lớn, lặp hàng nghìn bước nhỏ, giữ object lớn hoặc tạo fan-out quá rộng. Giữ logic nặng trong tool trên agent, chia stage hợp lý, và tránh biến Jenkinsfile thành bộ xử lý dữ liệu lớn.

Pipeline durability quyết định mức độ thường xuyên Pipeline lưu checkpoint và độ chịu lỗi khi controller bị gián đoạn. Durability cao hơn có thể tăng I/O/controller overhead; durability thấp hơn có thể mất nhiều tiến trình hơn khi sự cố. Chọn preset theo mức quan trọng và recovery objective của workload, xác minh tên/ý nghĩa setting trên Jenkins LTS và Pipeline: Job plugin đang dùng, rồi thử restart simulation chỉ trong sandbox. Không đổi durability toàn cục để chữa một build chậm mà không có bằng chứng.

Large Console Output cũng là tải I/O, truyền dữ liệu và lưu metadata. Không in dependency tree, môi trường, payload API hay từng dòng progress vô ích. Giữ log đủ để điều tra lỗi, dùng mức log tool phù hợp và phát hiện dòng lặp. Không “tối ưu” bằng cách che lỗi hoặc tắt log cần cho audit.

Plugin có thể thêm listeners, UI/API calls, SCM polling, fingerprinting hay Pipeline step. Khi latency thay đổi gần thời điểm cài/nâng plugin, lập danh sách core, Java, plugin và dependency versions; đọc release notes, yêu cầu core và advisory. Nâng hoặc gỡ plugin chỉ sau backup/rollback plan và kiểm thử sandbox. Lập kế hoạch nâng cấp theo Nâng cấp Jenkins, không dùng bản Java mới hoặc plugin mới ngoài compatibility range của Jenkins LTS.

Tuning theo vòng lặp an toànCopy Anchor Link

Mọi tuning nên đi theo cùng một thứ tự để một cải thiện cục bộ không tạo regression khó truy vết:

1. Đo: chốt baseline, scope controller/pool/job và SLI success criteria. Giữ bản sao dashboard/query, thời gian và phiên bản.
2. Đặt giả thuyết: ví dụ “pool linux-docker bão hòa; queue p95 tăng vì hai build image cùng tranh disk”, không phải “Jenkins cần nhiều executor”.
3. Thay đổi nhỏ: chỉ đổi một biến có thể đảo ngược, chẳng hạn thêm một agent cùng label hoặc giảm log của một tool.
4. Load test/sandbox: chạy workload đại diện, bao gồm concurrency và cache state có liên quan. Không benchmark trên production hay dùng build release làm test.
5. Verify hoặc rollback: so p50/p95, throughput, error rate và CPU/RAM/I/O trước/sau trong cửa sổ đủ dài. Roll back ngay nếu SLI xấu hơn, lỗi tăng hoặc headroom biến mất; ghi kết quả kể cả khi giả thuyết sai.

Các thay đổi thường có íchCopy Anchor Link

Thay đổi cần tránhCopy Anchor Link

• Không tăng executors chỉ vì queue dài. Xác định label, lock, CPU/RAM, disk I/O và external dependency trước.
• Không tăng heap để che memory leak, GC issue hay swap; không sao chép JVM flags từ Internet hoặc từ Java khác version.
• Không cài, gỡ hay nâng plugin trực tiếp trên production để thử hiệu năng. Plugin/version mới có thể đổi serialization, metrics hoặc compatibility.
• Không restart controller để giải quyết agent offline, storage đầy hay registry chậm. Tạo backup và kiểm tra quy trình Backup & Restore trước thay đổi có rủi ro dữ liệu.

Dữ liệu build và retentionCopy Anchor Link

JENKINS_HOME thường giữ cấu hình, build records, Pipeline state, Console Output và metadata. Agent giữ source checkout, workspace và cache. Artifact có thể ở controller filesystem, object store hoặc repository manager. Phân biệt nơi lưu giúp tránh “dọn disk Jenkins” nhưng lại xóa sai loại dữ liệu.

External artifact storage giảm áp lực disk controller nhưng không miễn phí: đo upload/download latency, error rate, egress, lifecycle policy và quyền đọc/ghi. Không cấu hình scan toàn bộ bucket/repository hoặc retention ngắn hơn nghĩa vụ audit chỉ để dashboard xanh. Sau mọi thay đổi retention, xác minh artifact/build cần thiết còn truy cập được và backup/restore vẫn khả thi.

Capacity planningCopy Anchor Link

Capacity planning dùng baseline để dự đoán peak, không phải phản ứng sau khi SLO đã vỡ. Với từng pool, ghi arrivals theo giờ, queue wait p95, runtime p95, concurrency, CPU/RAM/I/O/network headroom, provisioning delay và giới hạn bên ngoài như registry, license hoặc quota cloud.

Một phép ước lượng thô: nếu một pool nhận 12 build/giờ và runtime p95 là 10 phút, workload có thể yêu cầu khoảng 12 × 10 / 60 = 2 executor-phút/phút ở peak trung bình. Đây không phải sizing cuối cùng: burst, retry, fan-out, cache cold và headroom làm nhu cầu cao hơn. Xác minh bằng load test đại diện, rồi đặt trigger cảnh báo trước khi queue p95 vi phạm SLO.

Plan gồm capacity thường trực cho workload quan trọng, buffer cho peak, quota/provisioning có kiểm thử cho agent động, và ngày review khi số job, kích thước artifact hay fan-out thay đổi. Scale controller và storage theo số liệu riêng; thêm agent không làm JENKINS_HOME nhanh hơn.

Lab sandbox với mock workloadCopy Anchor Link

Lab này kiểm tra mối quan hệ giữa executor saturation và queue. Cần controller sandbox, một agent Linux tách biệt có labels linux và perf-lab, đúng một executor, và không có credential/repository thật. Không chạy trên built-in node production.

Chuẩn bị và chạyCopy Anchor Link

1. Ghi baseline trước lab: trạng thái agent, số executor, queue trống, CPU/RAM/disk/inodes. Tạo Pipeline tạm sandbox/performance-queue với Jenkinsfile sau.

pipeline {
  agent none

  stages {
    stage('Mock CPU-light workload') {
      agent { label 'linux && perf-lab' }
      steps {
        sh 'printf "build=%s node=%s\\n" "$BUILD_NUMBER" "$NODE_NAME"'
        sh 'sleep 60'
      }
    }
  }
}

2. Trigger build #1. Khi Console Output hiển thị sleep 60, trigger build #2 của cùng job.
3. Trong 60 giây đó, mở Build Queue, Nodes và dashboard agent. Ghi queue wait của #2, executor busy/online, CPU và disk; không đổi executor hay label trong khi quan sát.
4. Khi cả hai build hoàn thành, chỉ trên sandbox, có thể thêm một executor hoặc một agent cùng label và lặp lại một lần. So sánh đúng các số đã ghi, rồi trả cấu hình về trạng thái ban đầu.

Kết quả mong đợi và cleanupCopy Anchor Link

Với một executor duy nhất, #1 chạy còn #2 chờ trong queue khoảng thời gian #1 giữ slot; CPU và disk hầu như không tăng vì workload chỉ sleep. Điều đó chứng minh queue có thể do concurrency, không chứng minh host cần thêm CPU. Khi có hai slots hợp lệ, hai build có thể chạy song song; vẫn phải kiểm tra resource của workload thật trước khi giữ thay đổi.

Cleanup: đợi các build kết thúc hoặc abort chỉ các build lab nếu cần; xóa job sandbox/performance-queue, trả số executor/agent label về giá trị đã ghi và xác nhận queue không còn item lab. Không lưu Console Output hoặc dashboard export có metadata nội bộ ở nơi công khai.

TroubleshootingCopy Anchor Link

Checklist vận hànhCopy Anchor Link

• Baseline có window, controller, pool label, job class, Jenkins/Java/plugin versions và SLI p50/p95 rõ ràng.
• Dashboard tách controller, queue/executor, agent, Pipeline và storage; metric/query đã xác minh từ instance thật.
• Queue được điều tra bằng lý do chờ, label, lock/throttle và provisioning trước khi tăng executor.
• Controller có theo dõi HTTP, CPU, JVM heap/GC/thread và JENKINS_HOME bytes/inodes/I/O; agent có CPU/RAM/disk/I/O/network riêng.
• CPS, durability, large log và plugin impact được xem xét khi controller hoặc Pipeline chậm.
• Workspace, artifact, fingerprint và build retention có owner, quota/lifecycle và kiểm thử restore phù hợp.
• Mọi tuning theo đo → giả thuyết → thay đổi nhỏ → sandbox/load test → verify hoặc rollback.
• Heap, executor, Java/Jenkins LTS và plugin change không được tăng/nâng mù; compatibility và rollback đã được review.
• Thread/heap dump, metrics export và logs được xem là dữ liệu nhạy cảm, có access control và retention ngắn.
• Capacity plan có peak, headroom, fan-out, dependency ngoài và provisioning/quota; lab đã được cleanup.

Nguồn Jenkins chính thứcCopy Anchor Link

• Jenkins Hardware Recommendations — nguyên tắc sizing và khuyến nghị không chạy build trên controller.
• Scaling Jenkins — controller, agent và các giới hạn khi mở rộng.
• Managing Nodes — agent, labels và executor.
• Pipeline Scalability Best Practice — CPS, Pipeline code và large logs.
• Pipeline Durability Settings — durability và trade-off checkpoint.
• Pipeline Syntax: buildDiscarder — đặt retention theo Pipeline và xác minh hành vi trên instance.
• Jenkins Backup — bảo vệ và khôi phục JENKINS_HOME.
• Jenkins LTS và Java Support Policy — chọn core/Java được hỗ trợ.

Đọc tiếpCopy Anchor Link