# Vấn đề tăng CPU ở prod

Mọi vấn đề đều xuất phát từ những thứ đơn giản nhất

## Vấn đề gặp phải

Tại 1 web (giấu tên), prod báo về là bị CPU nhảy do chạy job => Điều tra nguyên nhân + hướng khắc phục

## Các dữ kiện được cung cấp

1. Về việc phát sinh nhảy CPU là sau ngày x, trước ngày x các tác vụ vẫn bình thường
2. Phân tích log cho thấy slow-query ở 1 câu query Y => nhưng khi xử lý chạy câu query ở môi trường local không vấn đề gì cả
3. Khi job của mình chạy, thì có các job khác cũng chạy đồng thời

## Giải quyết vấn đề

**Dự đoán ban đầu**:
Việc tăng CPU khả năng cao là do việc query vào database lâu => từ đó dẫn đến CPU tăng đột ngột, nhưng tại sao, lại chỉ sau ngày x mới bị hiện tượng này, mà không phải bị từ đầu??

## Điều tra

1. Từ (3) => thử cô lập tắt job của mình đi, xem còn có hiện tượng tăng CPU không => kết quả không còn tăng. Tương tự, thử tắc các job khác đi, giữ nguyên job của mình => thấy CPU vẫn tăng. Từ đó rút ra kết luận => Vấn đề xuất phát từ job của bên mình

2. Kiểm tra coding tương ứng (xem có thay đổi gì không), thì chỉ có 1 sự thay đổi: Bỏ 1 chiếc index ở bảng xử lý (nhưng index đó đã không dùng nữa) => không có sự phát sinh coding ảnh hưởng tới phần logic, query mình xử lý ở job

  ```sql
  # (1, 2, 3, 4, 5) là dynamic, phụ thuộc vào một vài điều kiện khác - truy vấn lấy id ở bảng khác theo thời gian phù hợp
    ...
    a INNER  JOIN b
      where b.column1 IN (1, 2, 3, 4, 5)
    ...
  ```

3. Từ (1), (2) => Lấy lại câu query gây slow => để kiểm tra chi tiết

 - Explain => thì thấy bảng b đang sử dụng partrition => khả năng dẫn đến chậm => nhưng vì nếu chậm thì phải chậm từ đầu => nên khả năng này bỏ ra khỏi nguyên nhân chính

 - Debug từng dòng, từng `column1  IN` => thì thấy phát sinh hiện tượng, rất lâu ở 1 `ID`, nhưng ngoài `ID` đó thì chạy vẫn bình thường => dự đoán khả năng là do phát sinh vấn đề ở đây

4. Kiểm tra lại điều kiện sinh ra `(1, 2, 3, 4, 5)` thì thấy phát sinh 1 bản ghi (bị chậm) mới được thay đổi điều kiện để có thể chạy job (tức là xuất hiện ở trong tệp `column1  IN`)
  
  => Kết luận: Bản thân câu query đã chậm rồi, nhưng vì việc lấy dữ liệu ban đầu chưa gặp phải `column1 IN` nào có dữ liệu lớn => do đó chưa phát sinh vấn đề, nhưng nếu có dữ liệu lớn vào => slow query ngay lập tức

5. Kiểm tra lại kết luận, thật vậy, thử update lại điều kiện để không sinh ra `ID` lớn trong `column1 IN` => thì thấy job chạy bình thường, CPU không nhảy đột biến.


Kết: Chúng ta cần phải khoanh vùng vấn đề, sau đó từ từ loại bỏ các dữ kiện không hợp lý => Sau đó cuối cùng, chúng ta cần confirm lại kết quả điều tra 1 lượt, để khẳng định tính đúng đắn. (Cách khắc phục update sau)