Jennifer Monitoring And Profiles

Jennifer Monitoring And Profiles

Mục tiêu

Jennifer là công cụ APM được sử dụng để trả lời hai câu hỏi quan trọng:

  1. Hệ thống đang hoạt động như thế nào?
  2. Tại sao hệ thống lại hoạt động như vậy?

Nhiều người chỉ theo dõi TPS hoặc CPU rồi kết luận nguyên nhân.

Trên thực tế phần lớn sự cố hiệu năng đều cần kết hợp nhiều chỉ số khác nhau để có cái nhìn chính xác.

Hai chức năng quan trọng

Monitoring

Monitoring trả lời:

Hệ thống đang xảy ra chuyện gì?

Các chỉ số thường được sử dụng:

  • TPS
  • Response Time
  • Active Service
  • JVM Heap
  • Garbage Collection
  • CPU Usage
  • Memory Usage

Monitoring cho phép xác định:

  • Thời điểm bắt đầu xảy ra sự cố
  • Mức độ nghiêm trọng
  • Xu hướng tăng giảm của tải hệ thống

Profiles

Profiles trả lời:

Thành phần nào đang gây ra vấn đề?

Monitoring cho thấy triệu chứng.

Profiles cho thấy nguyên nhân.

Ví dụ:

  • SQL nào chậm
  • Service nào chậm
  • External Call nào chậm
  • Hàm nào chiếm nhiều thời gian

Các chỉ số quan trọng nhất

TPS

Transaction Per Second.

Số lượng request xử lý trong một giây.

Ví dụ:

TPS = 50

có nghĩa hệ thống đang xử lý khoảng 50 request mỗi giây.

Lưu ý

TPS thấp không đồng nghĩa hệ thống khỏe.

Ví dụ:

TPS = 57
Active Thread = 100
Response Time = 622ms

Trong trường hợp này hệ thống vẫn có thể đang nghẽn.

Response Time

Thời gian phản hồi trung bình.

Ví dụ:

100ms

thường được xem là khá tốt với các giao dịch thông thường.

Khi Response Time tăng đột biến:

100ms
→ 300ms
→ 600ms
→ 1000ms

thì cần xác định nguyên nhân ngay.

Active Service

Đây là chỉ số quan trọng nhất khi điều tra nghẽn.

Active Service thể hiện:

Có bao nhiêu request đang được xử lý tại thời điểm hiện tại.

Nếu TPS không tăng nhiều nhưng Active Service tăng liên tục:

TPS = 50

Active Service
20
40
70
100
150

thì thường có dấu hiệu nghẽn ở đâu đó.

Active Thread

Cho biết số lượng thread đang hoạt động.

Ví dụ:

Thread Pool = 100

Active Thread = 100

Điều này có nghĩa:

  • Toàn bộ thread đều đang bận
  • Request mới phải chờ

Đây là tín hiệu rất đáng chú ý.

Quy trình điều tra sự cố

Bước 1

Xác định thời điểm phát sinh vấn đề.

Ví dụ:

14:20

Người dùng bắt đầu phản ánh chậm.

Bước 2

Xem Monitoring.

Quan sát:

  • TPS
  • Response Time
  • Active Service
  • Active Thread

Ví dụ:

TPS = 57

Response Time = 622ms

Active Thread = 100

Active Service = 100

Bước 3

Mở Profiles.

Cần trả lời:

Thread đang làm gì?

chứ không phải:

Thread đang có bao nhiêu?

Bước 4

Tìm service chiếm nhiều thời gian nhất.

Ví dụ:

AccountService

Tổng thời gian:
45%

Đây là ứng viên đầu tiên cần điều tra.

Bước 5

Phân tích chi tiết.

Thông thường thời gian sẽ nằm ở:

  • SQL
  • External Call
  • File IO
  • Lock

Phân tích SQL

Dấu hiệu:

Response Time tăng

TPS không tăng

Thread tăng

Khi mở Profile thường thấy:

SQL
70%

hoặc cao hơn.

Lúc đó cần kiểm tra:

  • Execution Plan
  • Missing Index
  • Full Table Scan
  • Wait Event

Phân tích External Call

External Call thường là nguyên nhân khó phát hiện.

Ví dụ:

A
|
→ B
|
→ C

Ứng dụng A không gặp lỗi.

Nhưng hệ thống C phản hồi chậm.

Kết quả:

Thread của A bị giữ lại.

Từ bên ngoài chỉ nhìn thấy:

TPS thấp

Response Time cao

Điều nên theo dõi

  • URL gọi đi
  • Thời gian gọi
  • Tỷ lệ timeout
  • Tỷ lệ lỗi

Trường hợp thực tế

Case

Dữ liệu thu thập:

Active Service = 100

Active Thread = 100

TPS = 57

Response Time = 622ms

Nhận định ban đầu

TPS không cao.

Tuy nhiên:

Thread Pool Full

cho thấy nút thắt không nằm ở số lượng request.

Các nguyên nhân khả nghi

SQL

Một hoặc nhiều query chạy quá lâu.

External Call

Hệ thống downstream phản hồi chậm.

Lock

Nhiều thread cùng chờ một tài nguyên.

Deadlock

Một nhóm thread chờ lẫn nhau.

Những sai lầm phổ biến

Chỉ nhìn CPU

CPU thấp không có nghĩa hệ thống khỏe.

Nhiều hệ thống nghẽn do chờ IO.

Chỉ nhìn TPS

TPS thấp không có nghĩa hệ thống rảnh.

TPS thấp đôi khi là hậu quả của việc hệ thống đang kẹt.

Chỉ nhìn Response Time

Response Time là kết quả cuối cùng.

Nguyên nhân thực sự thường nằm bên dưới.

Checklist Điều Tra Nhanh

Khi có phản ánh chậm:

  • Xác định thời gian xảy ra sự cố
  • Xem TPS
  • Xem Response Time
  • Xem Active Service
  • Xem Active Thread
  • Mở Profile
  • Kiểm tra SQL
  • Kiểm tra External Call
  • Thu thập Thread Dump
  • Xác định thành phần giữ thread lâu nhất

Lessons Learned

Monitoring giúp phát hiện vấn đề.

Profiles giúp xác định nguyên nhân.

Khi Active Thread đạt tối đa cấu hình, điều quan trọng nhất không phải là tăng thêm thread mà là tìm ra thành phần đang giữ thread quá lâu.

Trong phần lớn trường hợp production thực tế, nguyên nhân cuối cùng thường nằm ở:

  • SQL chậm
  • External Call chậm
  • Lock cạnh tranh tài nguyên

chứ hiếm khi do thiếu thread đơn thuần.