Bài 52 — Performance Tuning — Profiling

Mở đầu — vì sao bài này quan trọng

Trong đời làm DevOps, bạn sẽ gặp một loại "cuộc gọi lúc 2 giờ sáng" đặc biệt khó chịu: hệ thống không sập, nhưng chậm. API vẫn trả về 200, dashboard vẫn xanh, không có lỗi nào trong log — nhưng người dùng phàn nàn app quay vòng vòng, checkout mất 8 giây, và bộ phận kinh doanh đang gào lên vì tỷ lệ bỏ giỏ hàng tăng vọt. Đây là lúc kỹ năng performance tuning (tối ưu hiệu năng) tách một kỹ sư giỏi khỏi một người chỉ biết restart service và cầu nguyện.

Vấn đề lớn nhất khi tuning hiệu năng không phải là thiếu công cụ, mà là đoán mò. Rất nhiều kỹ sư nhìn thấy hệ thống chậm liền vội vàng: "Chắc do CPU, nâng instance lên đi", "Chắc do database, thêm read replica", "Chắc do thiếu RAM". Họ đổ tiền vào hạ tầng, và một tuần sau vấn đề vẫn còn nguyên vì thủ phạm thật là một cái mutex lock hoặc một truy vấn thiếu index.

Bài này dạy bạn cách tiếp cận có phương pháp thay vì đoán. Chúng ta sẽ tập trung vào hai trụ cột: phương pháp USE để khoanh vùng nhanh tài nguyên nào đang là nút thắt cổ chai, và profiling để soi vào bên trong ứng dụng xem code đang tiêu tốn thời gian ở đâu. Đây là kỹ năng nền tảng mà bất kỳ ai muốn tiến xa trong DevOps/SRE tại Việt Nam đều cần nắm vững, đặc biệt khi các công ty ngày càng chú trọng chi phí cloud và trải nghiệm người dùng.

Khái niệm cốt lõi

Tuning là một vòng lặp, không phải một cú đánh

Trước hết cần định hình tư duy: tối ưu hiệu năng là một vòng lặp khoa học — Đo (measure) → Đặt giả thuyết (hypothesize) → Thay đổi (change) → Đo lại (re-measure). Bạn không bao giờ được thay đổi thứ gì mà không đo trước và sau. Nếu không có số liệu baseline, bạn không thể biết mình đang cải thiện hay đang làm mọi thứ tệ hơn.

Có một quy tắc kinh điển của Donald Knuth mà mọi kỹ sư nên khắc cốt: "Premature optimization is the root of all evil" — tối ưu quá sớm là gốc rễ của mọi tai họa. Đừng tối ưu chỗ mà bạn nghĩ là chậm; hãy tối ưu chỗ mà số liệu chứng minh là chậm. 80% thời gian thực thi thường nằm ở 20% code — nhiệm vụ của bạn là tìm đúng 20% đó.

Phương pháp USE — bản đồ khoanh vùng nút thắt

USE là phương pháp do Brendan Gregg (kỹ sư hiệu năng huyền thoại, từng làm ở Netflix) đề xuất, cực kỳ hiệu quả để chẩn đoán nhanh vấn đề hạ tầng. Với mỗi tài nguyên (CPU, memory, disk I/O, network, thậm chí cả connection pool của database), bạn kiểm tra ba chỉ số:

• Utilization (Mức sử dụng) — phần trăm thời gian tài nguyên đó bận. Ví dụ CPU chạy 90% thời gian, disk bận đọc/ghi 70% thời gian. Utilization cao chưa chắc xấu, nhưng gần 100% liên tục là dấu hiệu cảnh báo.
• Saturation (Mức bão hòa) — lượng công việc đang xếp hàng chờ vì tài nguyên không xử lý kịp. Đây là chỉ số quan trọng nhất mà nhiều người bỏ qua. Ví dụ: run-queue của CPU (load average vượt số core), độ dài queue của disk, số request đang chờ trong connection pool. Một tài nguyên có thể chỉ 70% utilization nhưng đã bão hòa nghiêm trọng nếu công việc đến theo cụm.
• Errors (Lỗi) — số lượng sự kiện lỗi liên quan tài nguyên: gói tin bị drop trên network, lỗi ECC của memory, disk I/O errors, OOM kills. Lỗi thường nên kiểm tra đầu tiên vì chúng dễ nhìn và thường là nguyên nhân trực tiếp.

Sức mạnh của USE nằm ở tính hệ thống: bạn lập một bảng ma trận (tài nguyên × ba chỉ số) rồi điền số vào. Chỗ nào có con số bất thường, đó là nghi phạm. Cách này giúp bạn không bỏ sót và không đoán mò.

Profiling — soi vào bên trong ứng dụng

USE khoanh vùng được "tầng hạ tầng nào" đang nghẽn, nhưng khi vấn đề nằm trong code ứng dụng (ví dụ CPU 100% nhưng do một vòng lặp ngớ ngẩn), bạn cần profiling. Profiler trả lời câu hỏi: "Hàm nào, dòng nào đang ngốn CPU/memory/thời gian?".

Có vài loại profiling chính:

• CPU profiling — lấy mẫu (sampling) call stack nhiều lần mỗi giây để biết code đang "đứng" ở hàm nào nhiều nhất. Kết quả thường được vẽ dưới dạng flame graph (biểu đồ ngọn lửa) — trục ngang là tỷ lệ thời gian, trục dọc là độ sâu call stack. Cột nào rộng = tốn nhiều CPU.
• Memory profiling — xem hàm nào cấp phát bộ nhiều nhất (allocation), phát hiện rò rỉ bộ nhớ (memory leak).
• Wall-clock / off-CPU profiling — đo cả thời gian chờ (chờ I/O, chờ lock, chờ network), không chỉ thời gian dùng CPU. Rất quan trọng vì nhiều khi app chậm không phải vì bận, mà vì đang chờ.
• Continuous profiling — profiling liên tục trên production với overhead thấp (công cụ như Parca, Pyroscope, Google Cloud Profiler), giúp bạn nhìn lại lịch sử thay vì phải tái hiện sự cố.

Latency vs Throughput — hai mặt của hiệu năng

Đừng nhầm lẫn hai khái niệm: latency (độ trễ — một request mất bao lâu) và throughput (thông lượng — bao nhiêu request/giây). Tối ưu cái này đôi khi hại cái kia. Batch nhiều request lại giúp tăng throughput nhưng làm tăng latency của từng request. Luôn xác định rõ bạn đang tối ưu cho mục tiêu nào, và nhớ nhìn percentile (p95, p99) chứ không chỉ trung bình — trung bình che giấu những khách hàng đang chịu 5 giây chờ đợi.

Tình huống thực tế

Tình huống 1 — Sàn TMĐT chậm giờ cao điểm mà CPU vẫn thấp

Một công ty thương mại điện tử tầm trung ở TP.HCM (gọi là ShopVietGo) gặp sự cố: mỗi tối 8–10 giờ, trang danh mục sản phẩm tải mất 4–6 giây, nhưng CPU của cả web server lẫn database chỉ quanh 40%. Đội vận hành theo phản xạ đã nâng gấp đôi số instance EC2, tốn thêm khoảng 18 triệu đồng/tháng, mà không cải thiện gì.

Một kỹ sư mới áp dụng USE một cách bài bản. Ma trận cho thấy: CPU utilization 40% (bình thường), memory ổn, disk ổn. Nhưng ở tầng database connection pool, chỉ số saturation cực cao — pool chỉ có 20 connection, giờ cao điểm có tới 150 request xếp hàng chờ một connection rảnh. Utilization của pool là 100%, saturation ngập tràn. Thủ phạm không phải hạ tầng thiếu, mà là connection pool quá nhỏ và một số truy vấn giữ connection quá lâu.

Sau khi tăng pool lên 60 và tối ưu vài truy vấn giữ transaction lâu, thời gian tải xuống còn 800ms. Họ cũng giảm số instance về mức cũ, tiết kiệm lại chi phí. Bài học: utilization thấp không có nghĩa là mọi thứ ổn — saturation mới là thứ tố cáo nút thắt. Nếu chỉ nhìn CPU, họ đã đốt tiền vô ích mãi mãi.

Tình huống 2 — Dịch vụ Go ngốn CPU vì một dòng log

Một startup fintech ở Singapore vận hành microservice thanh toán viết bằng Go. Sau một đợt release, CPU của service tăng từ 30% lên 85% dù lượng traffic không đổi. Không có lỗi, không có alert nghiêm trọng, nhưng chi phí cloud tăng và latency p99 nhích từ 120ms lên 400ms.

Thay vì đoán, đội SRE bật pprof (profiler tích hợp sẵn của Go) trên một pod production trong 30 giây, xuất ra flame graph. Cột rộng nhất khiến ai cũng bất ngờ: gần 45% CPU nằm ở việc serialize JSON để ghi log debug. Trong lúc release, một lập trình viên đã vô tình để lại một dòng log ở mức DEBUG ghi lại toàn bộ payload request cho mỗi giao dịch, kèm reflection nặng nề.

Xóa dòng log đó, CPU về lại 30%, p99 về 120ms. Toàn bộ quá trình chẩn đoán mất chưa tới 15 phút nhờ profiling, trong khi nếu ngồi đọc code review lại có thể mất cả ngày. Bài học: flame graph cho bạn "sự thật trần trụi" về nơi CPU thực sự bị tiêu. Những thủ phạm hiệu năng thường là những thứ tưởng vô hại như logging, serialization, hay một regex.

Tình huống 3 — Rò rỉ bộ nhớ âm thầm trên dịch vụ Java

Một ngân hàng số tại Hà Nội chạy một service Java xử lý báo cáo. Cứ khoảng 3–4 ngày, pod bị Kubernetes OOM-kill và restart, gây gián đoạn ngắn. Đội vận hành ban đầu chỉ tăng memory limit từ 2GB lên 4GB — nó chỉ kéo dài chu kỳ từ 3 ngày lên 6 ngày, tức là chỉ trì hoãn chứ không chữa.

Áp dụng tư duy USE cho tài nguyên memory: utilization tăng tuyến tính theo thời gian không bao giờ giảm (dấu hiệu điển hình của leak). Họ dùng memory profiling (heap dump + phân tích) và phát hiện một static HashMap dùng làm cache nhưng không bao giờ evict — mỗi báo cáo tạo một entry và giữ mãi. Thay bằng một cache có giới hạn (LRU với TTL), memory ổn định phẳng, không còn OOM. Bài học: với memory, đường xu hướng theo thời gian quan trọng hơn giá trị tức thời. Tăng limit chỉ là mua thêm thời gian cho một quả bom hẹn giờ; phải profiling để tìm gốc rễ.

Hướng dẫn từng bước

Đây là quy trình chuẩn khi bạn nhận một sự cố "hệ thống chậm":

• Xác định và định lượng vấn đề. Đừng bắt đầu bằng "app chậm". Hãy hỏi: chậm ở đâu (endpoint nào), chậm bao nhiêu (p95/p99 là bao nhiêu, so với baseline), từ khi nào, ảnh hưởng bao nhiêu % người dùng. Không có con số thì không có gì để tối ưu.

• Chạy ma trận USE trên các tài nguyên chính. Với CPU, memory, disk, network, và các tài nguyên logic (connection pool, thread pool, queue), điền ba chỉ số Utilization / Saturation / Errors. Dùng các công cụ có sẵn: top/htop, vmstat, iostat, sar, ss, và metrics từ Prometheus. Khoanh vùng tài nguyên nào có con số bất thường.

• Kiểm tra Errors trước. Lỗi thường rẻ để kiểm tra và hay là nguyên nhân trực tiếp (packet drop, OOM kill, disk error). Loại bỏ nhóm này trước khi đào sâu.

• Nếu nút thắt nằm trong ứng dụng, bật profiler. Dùng đúng công cụ cho ngôn ngữ: pprof cho Go, py-spy cho Python, async-profiler cho Java/JVM, Node.js inspector cho Node, perf ở tầng OS cho mọi ngôn ngữ. Ưu tiên profiler có thể chạy trực tiếp trên production với overhead thấp.

• Đọc flame graph. Tìm cột rộng nhất — đó là nơi tốn nhiều thời gian/CPU nhất. Đừng bị đánh lừa bởi những hàm ở đáy stack; hãy nhìn phần tự thân (self time) của mỗi hàm.

• Đặt một giả thuyết duy nhất và thực hiện một thay đổi duy nhất. Đừng sửa năm thứ cùng lúc — bạn sẽ không biết cái nào có tác dụng. Khoa học yêu cầu biến đối chứng.

• Đo lại và so sánh với baseline. Nếu cải thiện, giữ lại và ghi chép. Nếu không, revert và thử giả thuyết khác. Lặp lại vòng lặp.

• Chốt bằng load test. Trước khi tuyên bố xong, chạy load test để xác nhận cải thiện đúng dưới tải thực tế, không chỉ trên môi trường nhàn rỗi.

Lỗi thường gặp & mẹo

• Tối ưu khi chưa đo. Đây là lỗi kinh điển. Đừng cache, đừng thêm goroutine, đừng viết lại thuật toán trước khi profiler chỉ ra chỗ nghẽn. Bạn sẽ tốn công vào chỗ chỉ chiếm 2% thời gian.
• Chỉ nhìn giá trị trung bình. Trung bình che giấu sự thật. Một hệ thống có latency trung bình 100ms nhưng p99 là 3 giây nghĩa là 1% người dùng — có thể hàng nghìn người — đang chịu đựng cực khổ. Luôn nhìn percentile.
• Bỏ qua saturation. Nhìn utilization mà quên saturation là lý do phổ biến nhất khiến người ta "nâng cấp hạ tầng vô ích". Queue length mới nói lên tài nguyên có đang bị quá tải hay không.
• Profiling trên môi trường sai. Profiling trên máy dev nhàn rỗi hoặc staging không có traffic thật thường cho kết quả lệch hoàn toàn với production. Nếu có thể, hãy profiling ngay trên production (với continuous profiling overhead thấp).
• Sửa nhiều thứ cùng lúc. Mất khả năng quy kết nguyên nhân. Một thay đổi, một lần đo.
• Quên chi phí là một chiều của hiệu năng. Ở Việt Nam, tối ưu để một service chạy tốt trên instance nhỏ hơn có thể tiết kiệm hàng chục triệu đồng/tháng — đây là giá trị kinh doanh trực tiếp, hãy đưa vào báo cáo của bạn.

Mẹo vàng: Hãy tạo và lưu baseline cho các service quan trọng khi chúng đang khỏe mạnh (p50/p95/p99, CPU, memory, throughput). Khi sự cố xảy ra, bạn có ngay điểm so sánh thay vì phải phỏng đoán "bình thường nó bao nhiêu nhỉ".

Bài tập thực hành

• Lập ma trận USE. Chọn một service bất kỳ bạn đang chạy (hoặc dựng một app demo bằng Docker). Vẽ một bảng với các dòng là CPU, Memory, Disk, Network, Connection Pool và các cột là Utilization / Saturation / Errors. Dùng htop, iostat, ss và metrics để điền càng nhiều ô càng tốt. Ghi lại tài nguyên nào bạn không có cách đo — đó là lỗ hổng observability cần vá.

• Tạo và đọc một flame graph. Viết một chương trình nhỏ (Go hoặc Python) cố tình có một hàm chậm (ví dụ một vòng lặp tính toán nặng hoặc một regex tồi). Dùng pprof (Go) hoặc py-spy (Python) để tạo flame graph, rồi xác định cột rộng nhất. Sửa hàm đó, profiling lại, và so sánh.

• Điều tra một leak giả lập. Viết một service giữ dữ liệu trong một map toàn cục không bao giờ giải phóng. Chạy nó dưới tải nhẹ liên tục, quan sát đồ thị memory theo thời gian trên Grafana. Xác nhận đường đi lên tuyến tính, rồi sửa bằng cache có giới hạn và xác nhận đường phẳng lại.

• Viết một "runbook" tuning ngắn. Dựa trên quy trình 8 bước ở trên, viết một tài liệu một trang cho đội của bạn: khi có alert "latency cao", cần chạy lệnh gì, nhìn dashboard nào, theo thứ tự nào. Đây chính là loại tài liệu giúp bạn tỏa sáng khi sự cố xảy ra lúc nửa đêm.

Tóm tắt

Performance tuning không phải là nghệ thuật đoán mò của các "phù thủy hạ tầng", mà là một quy trình khoa học có thể học được: đo → giả thuyết → thay đổi → đo lại. Hai công cụ tư duy quan trọng nhất là:

• Phương pháp USE — với mỗi tài nguyên, kiểm tra Utilization (mức bận), Saturation (mức xếp hàng chờ) và Errors (lỗi). Chính saturation — chứ không phải utilization — thường tố cáo nút thắt thật, và đây là điều đa số người mới bỏ sót.
• Profiling — khi vấn đề nằm trong code, flame graph cho bạn sự thật trần trụi về nơi thời gian và CPU bị tiêu tốn, giúp bạn tìm thủ phạm trong vài phút thay vì vài ngày.

Hãy nhớ ba nguyên tắc: đừng bao giờ tối ưu khi chưa đo, luôn nhìn percentile chứ không nhìn trung bình, và mỗi lần chỉ thay đổi một thứ. Ở bối cảnh Việt Nam, kỹ năng này còn có giá trị kinh doanh trực tiếp — một service được tuning tốt vừa cho trải nghiệm mượt hơn, vừa cắt giảm hóa đơn cloud đáng kể. Đó là thứ khiến một DevOps engineer trở nên thực sự đáng giá.