Bài này m note lại tình huống khi MySQL chiếm dụng CPU do query chậm.
Query chậm do đánh Index sai (thừa) cho một bảng khá to cỡ x100K rows.
Trạng thái: - Server treo,
MySQL chiếm CPU -
Apache2 tầm 150 child process -
Swap đầy dần lên 70-80%
Thông số: VPS giá rẻ 500MB RAM, 1G Swap Traffic và website: ...
Quá trình khắc phục:
Đầu tiên soi MySQL, show processlist không thấy j (cái này phải đợi nó mới hiện ra).
Do show processlist ko có j nên quay ra search tunning
Apache mà cái này ít được can thiệp on-fly. Cuối cùng rất may trong 1 lần show processlist nữa thì thấy 1 đống log query đang chờ. => Do 1 bảng liên quan đến lượng view (khi view tăng) thì index nó mới lộ rõ bug. Sau khi xóa index thừa restart thì mọi việc có vẻ ok. Mysql vẫn chiếm CPU khá nhiều tầm 25-55% nhưng swap thì chỉ tầm 100MB/1000MB. Lỗi này xuất hiện 1-2 lần 1 ngày sau khi restart MySQL thì hết. Cho đến 1 hôm thì restart rất nhiều lần và vẫn đơ.
Cập nhật:
Tổng hợp sau khi theo dõi tiếp thì nguyên nhân chính vẫn là do code lởm. Khi lượng view tăng lên thì bảng views cũng tăng rows theo. Việc count view tính toán cho nhiều mục đích như trending ... sẽ tốn công hơn.
Ngoài ra nguyên nhân thứ 2 là site khá nặng về lượng ảnh nên mỗi lần load page của client tốn khá nhiều memory cho 1 apache process (or child process). cỡ 1.7 -> 2.5% RAM (~17 -> 25MB).
Như vậy chỉ với 100 user online lượng memory cần đã quá 1GB RAM (sau khi nâng cấp). Mặc dù swap chưa thấy động đến (có thể do caching) nhưng rõ ràng với tình trạng page load như vậy thì chỉ cần trên 200 user access đồng thời là oẳng.
=> Rõ ràng cần phải tunning apache + code.
- Code fix cứng để cho mysql tối giản (đã thử) và ok nhưng apache vẫn ngốn memory như cũ. Vì dù mysql có ko dùng thì apache vẫn dùng ngần đấy ram.
Ngoài ra là tunning js, css cũng rất khó chịu với font-awesome, bootstrap css jquery ...
Trạng thái: - Server treo,
MySQL chiếm CPU -
Apache2 tầm 150 child process -
Swap đầy dần lên 70-80%
Thông số: VPS giá rẻ 500MB RAM, 1G Swap Traffic và website: ...
Quá trình khắc phục:
Đầu tiên soi MySQL, show processlist không thấy j (cái này phải đợi nó mới hiện ra).
Do show processlist ko có j nên quay ra search tunning
Apache mà cái này ít được can thiệp on-fly. Cuối cùng rất may trong 1 lần show processlist nữa thì thấy 1 đống log query đang chờ. => Do 1 bảng liên quan đến lượng view (khi view tăng) thì index nó mới lộ rõ bug. Sau khi xóa index thừa restart thì mọi việc có vẻ ok. Mysql vẫn chiếm CPU khá nhiều tầm 25-55% nhưng swap thì chỉ tầm 100MB/1000MB. Lỗi này xuất hiện 1-2 lần 1 ngày sau khi restart MySQL thì hết. Cho đến 1 hôm thì restart rất nhiều lần và vẫn đơ.
Cập nhật:
Tổng hợp sau khi theo dõi tiếp thì nguyên nhân chính vẫn là do code lởm. Khi lượng view tăng lên thì bảng views cũng tăng rows theo. Việc count view tính toán cho nhiều mục đích như trending ... sẽ tốn công hơn.
Ngoài ra nguyên nhân thứ 2 là site khá nặng về lượng ảnh nên mỗi lần load page của client tốn khá nhiều memory cho 1 apache process (or child process). cỡ 1.7 -> 2.5% RAM (~17 -> 25MB).
Như vậy chỉ với 100 user online lượng memory cần đã quá 1GB RAM (sau khi nâng cấp). Mặc dù swap chưa thấy động đến (có thể do caching) nhưng rõ ràng với tình trạng page load như vậy thì chỉ cần trên 200 user access đồng thời là oẳng.
=> Rõ ràng cần phải tunning apache + code.
- Code fix cứng để cho mysql tối giản (đã thử) và ok nhưng apache vẫn ngốn memory như cũ. Vì dù mysql có ko dùng thì apache vẫn dùng ngần đấy ram.
Ngoài ra là tunning js, css cũng rất khó chịu với font-awesome, bootstrap css jquery ...
Comments
Post a Comment