Khi nào nên nâng cấp VPS, khi nào nên tối ưu ứng dụng trước?

Khi website tải chậm hoặc phản hồi chập chờn, việc tăng gấp đôi CPU và RAM trên bảng điều khiển đám mây chưa chắc đã giải quyết được vấn đề nếu điểm nghẽn (bottleneck) nằm ở một câu truy vấn database thiếu index, một tiến trình xử lý đơn luồng hoặc thời gian chờ phản hồi từ API bên thứ ba. Ngược lại, việc cố gắng tối ưu mã nguồn suốt nhiều tuần trong khi máy chủ đã cạn kiệt RAM và liên tục kích hoạt OOM Killer cũng là một hướng xử lý thiếu thực tế.

Để đưa ra quyết định chuẩn xác và tiết kiệm chi phí, bạn nên phân loại bài toán theo 3 kịch bản:

• Nâng cấp tài nguyên ngay: Tài nguyên phần cứng tương ứng (CPU, RAM, Disk) đã chạm ngưỡng bão hòa kéo dài, người dùng đang bị ảnh hưởng trực tiếp (lỗi kết nối, timeout) và khối lượng công việc (workload) có khả năng tận dụng ngay phần tài nguyên bổ sung này.
• Tối ưu ứng dụng trước: VPS vẫn còn nhiều khoảng trống tài nguyên dự phòng (headroom) nhưng một câu truy vấn SQL chậm, một thuật toán nặng, hiện tượng tranh chấp tài nguyên (database lock) hoặc kết nối mạng bên ngoài đang làm nghẽn toàn bộ luồng xử lý.
• Nâng cấp tạm để dập lửa, sau đó tối ưu tận gốc: Hệ thống đang ở bờ vực sụp đổ trong các khung giờ cao điểm kinh doanh. Giải pháp thực tế nhất là tạm thời nâng cấp cấu hình VPS để tạo khoảng đệm an toàn cho dịch vụ, sau đó bắt tay vào khoanh vùng tối ưu nguyên nhân gốc rễ và đánh giá lại cấu hình (rightsizing) khi hệ thống đã ổn định.

Bắt đầu từ trải nghiệm người dùng, không bắt đầu từ con số phần trăm CPU

Một sai lầm rất phổ biến là nhìn vào biểu đồ CPU thấy đạt 80% - 90% rồi vội vàng kết luận máy chủ bị quá tải. Thực tế, con số tải phần cứng chỉ có ý nghĩa khi được đối chiếu với trải nghiệm của người dùng cuối:

• Luồng nghiệp vụ cốt lõi nào đang bị chậm: trang chủ, tìm kiếm sản phẩm, giỏ hàng hay thao tác thanh toán?
• Độ trễ phản hồi (latency) tăng cao ở toàn bộ người dùng hay chỉ xảy ra ở phân vị p95, p99 (những yêu cầu đặc thù xử lý nặng)?
• Tỷ lệ lỗi (error rate) và số lượng yêu cầu bị timeout (mã HTTP 502, 504) có tăng đột biến không?
• Sự cố xảy ra liên tục hay chỉ xuất hiện vào những thời điểm cố định: khung giờ chạy cronjob sao lưu, thời điểm import dữ liệu hay khi có chiến dịch quảng cáo?

Chỉ số độ trễ trung bình (average latency) có thể tạo cảm giác đánh lừa: một website có độ trễ trung bình 200ms vẫn có thể khiến 5% khách hàng quan trọng nhất phải chờ đợi từ 5 đến 10 giây ở trang thanh toán. Do đó, hãy luôn quan sát độ trễ ở phân vị p95 và p99 kết hợp cùng tỷ lệ lỗi.

Khi đã có bức tranh rõ ràng về thời điểm xảy ra sự cố, bạn mới đối chiếu dòng thời gian đó với các chỉ số CPU, RAM, Disk I/O và Database. Nếu độ trễ người dùng tăng vọt nhưng mức sử dụng CPU vẫn dưới 30% trong khi hàng đợi đọc ghi đĩa (disk wait) hoặc hàng đợi kết nối database tăng cao, việc chi thêm tiền để nâng cấp vCPU sẽ hoàn toàn vô nghĩa.

Quy trình giám sát đa tầng từ trải nghiệm bên ngoài vào bên trong máy chủ đã được hướng dẫn chi tiết trong bài Nên monitoring những gì trên một VPS chạy website?.

Khi nào CPU thực sự là điểm nghẽn?

Mức sử dụng CPU cao chỉ phản ánh đúng điểm nghẽn khi nó kéo dài liên tục, trùng khớp với thời điểm người dùng truy cập đông và đi kèm với sự suy giảm tốc độ phản hồi. Một đợt tăng vọt CPU (spike) trong vài chục giây do tác vụ nén file backup hay xoay vòng file log là hoàn toàn bình thường và không phải lý do để nâng cấp VPS.

Các dấu hiệu cho thấy CPU thực sự đã quá tải:

• Toàn bộ các lõi CPU (cores) hoạt động hết công suất kéo dài trong suốt khung giờ cao điểm.
• Hàng đợi tác vụ (CPU load average / run queue) vượt quá số lượng core hiện có, khiến các tiến trình phải xếp hàng chờ đợi được cấp phát thời gian xử lý.
• Độ trễ phản hồi của website tăng tỷ lệ thuận với mức độ bão hòa của CPU.
• Bạn đã xác định rõ tiến trình gây tải (PHP-FPM, Node.js, Nginx) là lưu lượng truy cập thực tế của khách hàng, không phải do bot quét rác hay vòng lặp vô tận (infinite loop) trong code.

Nếu ứng dụng có kiến trúc đa tiến trình (multi-process) hoặc đa luồng (multi-threaded) và đang chịu tải cao từ lượng người dùng thật, việc nâng cấp thêm vCPU sẽ mang lại hiệu quả tức thì. Ngược lại, nếu máy chủ có 4 core nhưng chỉ có đúng 1 core chạy 100% còn 3 core còn lại gần như rảnh rỗi, vấn đề nằm ở ứng dụng xử lý đơn luồng hoặc bị khóa tài nguyên. Thêm vCPU trong trường hợp này không giúp tăng tốc độ xử lý.

Ngoài ra, cần phân biệt rõ thời gian CPU xử lý logic ứng dụng với chỉ số iowait (CPU phải dừng lại chờ đĩa cứng phản hồi) và chỉ số steal time (máy chủ vật lý bên dưới của nhà cung cấp bị quá tải khiến VPS bị chiếm dụng tài nguyên). Bài viết VPS CPU 100%: cách tìm tiến trình gây tải mà không vội reboot phân tích sâu cách điều tra từng trường hợp này.

Bộ nhớ RAM: Quan sát áp lực bộ nhớ thay vì chỉ nhìn dung lượng trống

Cơ chế quản lý bộ nhớ của nhân Linux là luôn tận dụng tối đa lượng RAM nhàn rỗi để làm bộ nhớ đệm trang (Page Cache) nhằm tăng tốc độ truy xuất tệp tin. Do đó, việc nhìn thấy dung lượng RAM trống (Free RAM) ở mức vài chục megabyte là trạng thái hoàn toàn bình thường, không đồng nghĩa với việc máy chủ sắp hết RAM.

Để đánh giá chính xác tình trạng bộ nhớ, bạn cần theo dõi:

• MemAvailable: Lượng bộ nhớ thực tế hệ thống có thể thu hồi ngay lập tức để cấp cho ứng dụng mà không cần phải đẩy dữ liệu vào phân vùng swap.
• Hoạt động của phân vùng Swap: Tốc độ hoán đổi dữ liệu giữa RAM và đĩa cứng (swap in/out). Nếu swap liên tục tăng cao và đĩa cứng phải đọc ghi swap dồn dập (swap thrashing), hệ thống sẽ rơi vào tình trạng phản hồi cực kỳ chậm chạp.
• Áp lực bộ nhớ (PSI - Pressure Stall Information): Tỷ lệ thời gian các tiến trình phải tạm dừng hoạt động chỉ để chờ cấp phát bộ nhớ.
• Sự can thiệp của OOM Killer: Kiểm tra log hệ thống (dmesg hoặc journalctl) xem kernel có buộc phải dừng đột ngột (kill) các tiến trình lớn như MySQL hay PHP-FPM để cứu máy chủ hay không.

Nếu khối lượng công việc hợp lệ của bạn (lượng người dùng thật) liên tục đẩy MemAvailable về mức cạn kiệt, gây swap thrashing hoặc kích hoạt OOM Killer, việc nâng cấp thêm RAM là quyết định bắt buộc và cần thực hiện ngay lập tức. Đừng lãng phí thời gian đi tìm "lỗi rò rỉ bộ nhớ" (memory leak) trong khi máy chủ đơn giản chỉ là đang gánh lượng dữ liệu vượt quá cấu hình phần cứng.

Ngược lại, nếu mức chiếm dụng RAM tăng đều đặn theo thời gian từ ngày này qua ngày khác và không bao giờ giảm xuống ngay cả trong lúc nửa đêm vắng khách, bạn đang đối mặt với lỗi memory leak. Nâng cấp thêm RAM lúc này chỉ giúp trì hoãn thời điểm sập máy chứ không giải quyết được gốc rễ vấn đề.

Để nắm rõ các dấu hiệu cảnh báo bộ nhớ, bạn có thể tham khảo bài VPS hết RAM và OOM Killer: dấu hiệu, kiểm tra và phòng ngừa.

Ổ đĩa cứng: Phân biệt giữa hết dung lượng lưu trữ và nghẽn tốc độ I/O

Một máy chủ có thể còn trống hàng chục gigabyte ổ cứng nhưng website vẫn chạy chậm chạp vì ổ đĩa bị nghẽn thông lượng (throughput) hoặc chạm trần số lượng phép đọc ghi mỗi giây (IOPS). Ngược lại, ổ đĩa sắp đầy dung lượng chưa chắc đã làm chậm tốc độ xử lý I/O.

Khi nào nên tăng dung lượng ổ đĩa:

• Dữ liệu database, tệp tin upload của người dùng hoặc tài nguyên website tăng trưởng tự nhiên và đều đặn theo quy mô kinh doanh.
• Cần thêm không gian đệm an toàn để thực hiện việc sao lưu dữ liệu cục bộ trước khi đồng bộ lên Cloud Storage.
• Trên một số nhà cung cấp đám mây (như AWS EBS gp3/gp2), hiệu năng IOPS và băng thông đọc ghi được cấp phát tăng dần theo kích thước dung lượng ổ đĩa được mua.

Khi nào nên dọn dẹp và tối ưu trước:

• Ổ đĩa bị đầy do tệp tin log không được cấu hình xoay vòng (logrotate) đúng cách, tích tụ hàng chục gigabyte log rác.
• Tệp tin tạm (/tmp), cache của ứng dụng hoặc các image Docker cũ không được dọn dẹp định kỳ.
• Các bản backup cũ bị lưu trữ trùng lặp trên cùng ổ đĩa chính của VPS thay vì được chuyển ra ngoài.

Nâng cấp dung lượng ổ cứng để chứa tệp log phình to mất kiểm soát chỉ là biện pháp dời thời điểm gặp sự cố sang một tuần tiếp theo. Trước khi chi tiền mua thêm ổ đĩa, hãy rà soát theo bài Quản trị VPS hàng tháng để dọn dẹp các tệp tin thừa thãi.

Điều tra nghẽn I/O trước khi đổ lỗi cho CPU:

Nếu các câu lệnh xử lý của website chạy chậm nhưng chỉ số iowait trên CPU rất cao, điểm nghẽn thực sự nằm ở tốc độ đọc ghi của ổ đĩa. Hãy tìm xem tiến trình nào đang ghi đĩa dồn dập bằng công cụ iotop. Một câu truy vấn database quét toàn bộ bảng (Full Table Scan) hàng triệu dòng buộc ổ đĩa phải liên tục đọc từ phân vùng lưu trữ thay vì từ RAM cache chính là thủ phạm hàng đầu gây nghẽn I/O.

Database: Thủ phạm gây nghẽn phổ biến nhất

Trong hầu hết các ứng dụng web thông thường, phần lớn thời gian phản hồi của request là thời gian ứng dụng phải nằm chờ kết quả trả về từ database. Một câu truy vấn thiếu index, một giao dịch (transaction) giữ khóa bảng quá lâu hoặc cấu hình số lượng kết nối tối đa (connection pool) quá nhỏ sẽ khiến toàn bộ các request khác bị xếp hàng ùn tắc, trong khi CPU của máy chủ vẫn ở mức rất thấp.

Đối với MySQL/MariaDB, bạn nên kích hoạt tính năng ghi log câu truy vấn chậm (Slow Query Log) để xác định đích danh những câu lệnh chạy mất nhiều thời gian. Sau đó, sử dụng lệnh EXPLAIN để xem cơ chế thực thi và đánh giá việc bổ sung index phù hợp.

Dấu hiệu cho thấy bạn nên tối ưu database trước khi nâng cấp VPS:

• Chỉ có một vài câu truy vấn phức tạp chiếm tới 80% tổng thời gian thực thi của database.
• Tỷ lệ số dòng phải quét (rows examined) lớn gấp hàng nghìn lần số dòng thực tế trả về (rows sent) — dấu hiệu rõ ràng của việc thiếu index.
• Hiện tượng chờ khóa (lock wait) tăng đột biến vào giờ cao điểm do nhiều tiến trình cùng cố gắng ghi vào một bảng dữ liệu.
• Dung lượng bộ nhớ đệm dữ liệu (như innodb_buffer_pool_size) được cấu hình quá thấp so với dung lượng RAM thực tế của máy chủ.

Tuy nhiên, nếu bạn đã tối ưu index hoàn chỉnh nhưng kích thước tập dữ liệu hoạt động thường xuyên (working set) của database đã lớn hơn nhiều so với dung lượng RAM khả dụng, buộc database phải liên tục đọc từ đĩa cứng, thì việc nâng cấp RAM để tăng kích thước buffer pool là quyết định hoàn toàn đúng đắn.

Kiểm tra tầng bộ nhớ đệm (Cache) và các API bên ngoài

Đôi khi điểm nghẽn không nằm ở phần cứng máy chủ cũng như cấu hình database, mà xuất phát từ các thành phần phụ trợ:

• Tỷ lệ trúng bộ nhớ đệm (Cache Hit Ratio) sụt giảm: Nếu hệ thống sử dụng Redis hoặc Memcached, việc tỷ lệ cache hit bị giảm đột ngột (do cấu hình thời gian sống TTL quá ngắn hoặc thuật toán xóa key bị quá tải) sẽ đẩy toàn bộ lưu lượng truy cập thẳng xuống database, khiến tải của máy chủ tăng vọt gấp nhiều lần. Hãy kiểm tra hiệu năng cache trước khi quyết định nâng cấp phần cứng.
• Hàng đợi công việc (Job Queue) bị ứ đọng: Nếu hàng đợi xử lý tác vụ nền (như gửi email, tạo hóa đơn, chuyển đổi ảnh) bị dồn ứ, hãy kiểm tra xem worker có đang bị nghẽn bởi tốc độ mạng hay không. Việc tăng số lượng worker một cách mù quáng có thể làm database bị nghẽn kết nối nhanh hơn.
• Phụ thuộc vào các dịch vụ bên ngoài (Third-party API): Một request gọi tới cổng thanh toán trực tuyến, dịch vụ gửi SMS hay máy chủ DNS bị chậm sẽ kéo theo toàn bộ tiến trình web server phải treo giữ kết nối chờ đợi. Dù bạn có nâng cấp VPS lên cấu hình mạnh nhất, website vẫn sẽ chậm nếu dịch vụ bên ngoài chưa phản hồi. Trong tình huống này, giải pháp là thiết lập thời gian timeout hợp lý, cơ chế thử lại (retry) có giới hạn và chuyển các tác vụ này sang xử lý bất đồng bộ ở chế độ nền (asynchronous background job).

Tình huống này được phân tích sâu hơn trong bài Website chậm nhưng CPU thấp: nên kiểm tra gì tiếp theo?.

Ma trận quyết định nhanh

Quy trình 5 bước đo lường trước và sau khi thay đổi

Bất kể bạn lựa chọn giải pháp nâng cấp phần cứng hay tối ưu mã nguồn, hãy luôn áp dụng quy trình kiểm chứng có cơ sở dữ liệu:

1. Chọn khung thời gian đại diện: Thu thập số liệu trong khung giờ có tải thực tế đại diện (ví dụ khung giờ cao điểm bán hàng). Không so sánh hiệu năng giữa buổi tối có chiến dịch khuyến mãi với buổi sáng ít người truy cập.
2. Ghi lại các chỉ số nền tảng (Baseline): Lưu lại các con số cụ thể gồm: số lượng request/giây, tỷ lệ lỗi, độ trễ p95/p99, mức sử dụng CPU theo core, lượng MemAvailable, tỷ lệ I/O wait và thời gian thực thi câu truy vấn chậm.
3. Thực hiện thay đổi đơn lẻ: Chỉ thay đổi một biến số duy nhất tại một thời điểm (ví dụ: chỉ thêm index cho database, hoặc chỉ nâng cấp RAM). Tránh việc vừa thêm RAM, vừa đổi phiên bản PHP, vừa chỉnh lại Nginx cùng một lúc vì bạn sẽ không thể biết thay đổi nào mang lại kết quả tích cực hay gây thêm lỗi mới.
4. Kiểm tra cùng một luồng nghiệp vụ: Thử nghiệm lại đúng các trang và tính năng từng bị chậm trong cùng điều kiện lưu lượng tương đương.
5. Theo dõi liên tục sau thay đổi: Một đợt deploy thành công sau 15 phút chưa chứng minh hệ thống đã hết lỗi. Hãy quan sát qua ít nhất một chu kỳ tải đầy đủ (24 giờ hoặc 1 tuần) để khẳng định tính ổn định lâu dài.

Checklist kiểm tra trước khi quyết định nâng cấp VPS

• ☐ Đã xác định rõ luồng tính năng nào của website đang bị chậm và ảnh hưởng cụ thể tới người dùng.
• ☐ Đã kiểm tra độ trễ ở phân vị p95, p99 và tỷ lệ lỗi HTTP 5xx thay vì chỉ nhìn vào mức trung bình.
• ☐ Đã đối chiếu dòng thời gian bị chậm với biểu đồ CPU, RAM, Disk I/O và Database.
• ☐ Đã loại trừ khả năng tải tăng đột biến do bot cào dữ liệu, tấn công từ chối dịch vụ hoặc vòng lặp vô hạn trong mã nguồn.
• ☐ Đã xác định rõ ứng dụng có khả năng tận dụng phần tài nguyên tăng thêm (ví dụ hỗ trợ đa luồng để dùng thêm core).
• ☐ Nếu quyết định nâng cấp VPS: đã kiểm tra kế hoạch gián đoạn dịch vụ (thời gian khởi động lại máy khi resize), sao lưu dữ liệu dự phòng và chi phí duy trì hàng tháng.
• ☐ Nếu quyết định tối ưu ứng dụng: đã xác định được đích danh câu truy vấn, endpoint hoặc tiến trình cần sửa và metric đo lường kết quả.
• ☐ Đã chuẩn bị sẵn sàng phương án hoàn tác (rollback) nếu thay đổi không mang lại hiệu quả như kỳ vọng.

Quyết định đầu tư vào tài nguyên máy chủ hay công sức tối ưu mã nguồn luôn là sự cân bằng giữa chi phí hạ tầng và thời gian kỹ thuật. Hãy để các số liệu giám sát thực tế dẫn đường, thay vì đưa ra quyết định dựa trên cảm tính hoặc sự phỏng đoán.

Nguồn tham khảo

• Linux Kernel Documentation — Pressure Stall Information (PSI)
• Brendan Gregg — Systems Performance: Enterprise and the Cloud
• MySQL Documentation — Optimization and Indexes
• PostgreSQL Documentation — Performance Tips
• Google Cloud Architecture Framework — Performance Optimization