Cách kiểm tra và tối ưu tài nguyên VPS khi gặp sự cố

Website đang chạy bình thường thì bất ngờ chậm hẳn. SSH vào VPS cũng lag, thao tác gì cũng phản hồi chậm. Kiểm tra nhanh, bạn phát hiện RAM đã lên 95% hoặc CPU liên tục ở mức 90% nhưng lại không biết chính xác tiến trình nào đang gây ra vấn đề.

Đây là tình huống khá phổ biến khi vận hành VPS. Tuy nhiên, việc biết RAM hoặc CPU đang đầy mới chỉ là bước đầu. Quan trọng hơn là phải xác định nguyên nhân, tìm đúng tiến trình hoặc service đang gây tải và xử lý theo từng trường hợp.

Trong bài viết này, chúng ta sẽ đi thẳng vào cách xử lý khi VPS gặp sự cố về tài nguyên: từ RAM, CPU, port, service đang chạy cho đến log và lịch sử đăng nhập. Mục tiêu là giúp bạn biết cần kiểm tra gì, xử lý ra sao và khi nào việc tối ưu không còn đủ mà nên nâng cấp VPS.

Chúng ta bắt đầu nhé!

VPS đầy RAM – Nguyên nhân & Cách xử lý

RAM VPS đầy thường xuất phát từ ba nguyên nhân phổ biến.

Thứ nhất, VPS đang chạy quá nhiều website hoặc service cùng lúc. Đúng như nhiều người thắc mắc, càng nhiều web trên VPS thì càng tốn RAM. Mỗi website có thể phát sinh thêm các tiến trình PHP-FPM, MySQL, Node riêng, vì vậy lượng RAM tiêu thụ sẽ tăng lên chứ không phải chỉ là cảm giác.

Thứ hai, một tiến trình có thể gặp tình trạng memory leak. Khi đó, RAM sẽ tăng dần theo thời gian dù lượng truy cập không thay đổi. Đây là trường hợp khác với việc RAM tăng do traffic thực tế.

Thứ ba, VPS chưa có swap nên không có vùng đệm khi RAM tạm thời chạm trần. Ngoài ra, cấu hình ban đầu có thể quá thấp so với nhu cầu thực tế. Ví dụ, một VPS chỉ có 0.6GB RAM nhưng lại cài hệ điều hành có giao diện đồ họa (GUI) thì gần như chắc chắn sẽ thiếu RAM ngay từ đầu. Mức RAM này chỉ nên sử dụng với Linux server tối giản (không GUI) hoặc Windows Server Core.

Khi phát hiện RAM đầy, việc đầu tiên cần làm là tìm tiến trình đang chiếm nhiều RAM nhất, sau đó kill hoặc restart service đó. Cách liệt kê tiến trình theo %MEM đã được trình bày chi tiết trong bài Kiểm Tra Tài Nguyên VPS nên không nhắc lại ở đây.

Nếu VPS chưa có swap, hãy thêm ngay một vùng swap tạm thời (hướng dẫn cụ thể ở phần sau).

Với câu hỏi giảm RAM VPS DigitalOcean hay các nhà cung cấp khác, đây thường là nhu cầu giảm lượng RAM mà một service cụ thể đang sử dụng, tức tối ưu cấu hình để service đó dùng ít RAM hơn. Còn nếu muốn giảm RAM vật lý của gói đang thuê thì cần resize droplet/gói ngay trên control panel của nhà cung cấp.

Một trường hợp riêng là RAM VPS Windows không đúng. Đôi khi dung lượng RAM hiển thị trong Task Manager không khớp với RAM của gói đã mua. Nguyên nhân thường liên quan đến driver hoặc giới hạn của phiên bản hệ điều hành đang cài. Hãy kiểm tra lại bằng System Information (msinfo32) để đối chiếu chính xác dung lượng RAM thực được cấp. Nếu vẫn có sự chênh lệch, đây là lúc nên liên hệ nhà cung cấp thay vì tự tìm nguyên nhân.

Nếu đã kill tiến trình thừa, thêm swap và tối ưu từng service nhưng RAM vẫn đầy trở lại chỉ sau vài giờ, đó là dấu hiệu cho thấy VPS thực sự đang thiếu RAM so với nhu cầu. Đây không còn đơn thuần là vấn đề cấu hình. Phần tối ưu sâu hơn và cách tính lượng RAM cần thiết sẽ được đề cập ở mục tiếp theo.

Cách tối ưu/tăng RAM cho VPS

Cần phân biệt rõ hai việc: tối ưu RAM VPS, tức sử dụng hiệu quả hơn lượng RAM hiện có, và tăng RAM, tức bổ sung thêm RAM thật bằng cách nâng cấp gói dịch vụ.

Riêng với câu hỏi cách tăng VRAM cho VPS, cần hiểu rằng VRAM là bộ nhớ riêng của card đồ họa (GPU). VPS thông thường không có GPU riêng nên không tồn tại khái niệm VRAM để tăng, trừ khi bạn đang thuê đúng loại VPS GPU chuyên dụng.

Để sử dụng RAM VPS hiệu quả hơn, có ba việc nên ưu tiên thực hiện.

  • Bật OPcache cho PHP để không phải biên dịch lại code ở mỗi request.
  • Sử dụng Redis hoặc Memcached để cache dữ liệu hoặc các truy vấn lặp lại thay vì phải tính toán lại từ đầu.
  • Giới hạn số lượng worker process phù hợp với lượng RAM thực tế.

Ví dụ với PHP-FPM, nếu đặt pm.max_children quá cao so với lượng RAM đang có, hệ thống sẽ cố spawn thêm tiến trình cho đến khi sử dụng hết RAM, thay vì chủ động từ chối bớt request.

Khi VPS đã được tối ưu nhưng vẫn chưa có swap để làm vùng đệm, bạn có thể tạo swap 2GB trên Linux bằng các lệnh sau. Các lệnh này được chạy tuần tự:

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

Trên Windows Server, thành phần tương đương với swap là pagefile (bộ nhớ ảo). Bạn vào System Properties → Advanced → Performance Settings → tab Advanced → Virtual Memory → Change, sau đó đặt kích thước tùy chỉnh (Custom size) thay vì để hệ thống tự quản lý. Thông thường, kích thước được đặt bằng 1.5-2 lần lượng RAM thực có.

Với câu hỏi chỉnh crontab để giải phóng RAM VPS, đây là một giải pháp tạm thời hữu ích khi một service có dấu hiệu memory leak nhẹ nhưng chưa thể khắc phục tận gốc. Bạn có thể đặt một cron job để tự động restart service đó vào thời điểm ít truy cập nhất trong ngày, chẳng hạn 3-4 giờ sáng. Cách này giúp giải phóng lượng RAM tích lũy do leak theo định kỳ, trước khi nó kịp gây ra sự cố, thay vì chờ đến lúc RAM đầy rồi mới xử lý thủ công.

Còn với cách tính RAM cho VPS cần bao nhiêu là đủ, bạn có thể cộng lượng RAM hệ điều hành khi nghỉ (khoảng 300-500MB với Linux bản tối giản), cộng RAM ước tính của từng service đang chạy như database, web server, ứng dụng, sau đó cộng thêm 20-30% dự phòng cho những thời điểm traffic tăng đột biến. Cách tính này giúp tránh tình trạng vừa tối ưu xong nhưng RAM lại đầy chỉ vì cấu hình ban đầu đã thiếu, thay vì do cấu hình sai.

Cách giảm tải CPU khi VPS chạy quá 80%

CPU VPS lớn hơn 80% liên tục có gì không? Có, nếu đây là mức sử dụng được duy trì trong thời gian dài, từ nhiều phút đến hàng giờ, chứ không phải chỉ tăng đột biến vài giây rồi nhanh chóng hạ xuống. CPU cao kéo dài có thể khiến hệ thống lag, request bị timeout, thậm chí service tự crash nếu vượt ngưỡng quá lâu.

Ba nguyên nhân phổ biến khiến nhiều request làm tăng CPU VPS gồm: lượng truy cập tăng thực tế, chẳng hạn traffic tăng đột biến hoặc bị bot/crawler quét liên tục, thậm chí là DDOS (xem thêm cách nhận biết tại Cách nhận biết server hay VPS bị DDOS và cách khắc phục); một tiến trình bị lỗi vòng lặp, khiến CPU chạy 100% dù không có request nào cần xử lý; hoặc cron job nặng vô tình chạy trùng vào thời điểm cao điểm.

Ngoài ra, còn một nguyên nhân nằm ngoài khả năng kiểm soát trực tiếp của người dùng: cấp phát quá tải CPU máy chủ ảo hóa (oversell). Khi nhà cung cấp gán quá nhiều VPS lên cùng một CPU vật lý vượt tỷ lệ an toàn, VPS của bạn có thể bị chậm dù tải không tăng, do phải tranh chấp tài nguyên với các VPS khác trên cùng máy chủ vật lý. Đây cũng là lý do nên lựa chọn nhà cung cấp minh bạch về tỷ lệ phân bổ tài nguyên.

Cách giảm CPU cho VPS sau khi đã xác định đúng tiến trình gây tải là kill hoặc restart tiến trình lỗi. Nếu nguyên nhân đến từ ứng dụng tự viết, cần tối ưu lại code hoặc câu truy vấn database. Bên cạnh đó, có thể bổ sung cache để giảm số request phải xử lý và tính toán lại từ đầu. Kinh nghiệm xử lý thực tế khi CPU chạy full kéo dài có thể tham khảo thêm tại Kinh nghiệm xử lý VPS/Server CPU chạy Full CPU.

Riêng câu hỏi tản nhiệt CPU VPS cần được hiểu đúng về mặt kỹ thuật. VPS là máy ảo và chạy trên phần cứng vật lý của nhà cung cấp. Tài nguyên CPU mà bạn nhìn thấy là tài nguyên được ảo hóa, không phải một con chip vật lý riêng để bạn có thể lắp quạt hoặc tản nhiệt. Việc làm mát phần cứng vật lý thuộc trách nhiệm của nhà cung cấp tại trung tâm dữ liệu.

Vì vậy, khi nói “CPU VPS nóng”, thực chất chỉ đang mô tả tình trạng CPU chạy ở mức cao trong thời gian dài. Cách xử lý đúng là giảm tải bằng cache và tối ưu tiến trình như đã đề cập ở trên, chứ không phải tìm cách tản nhiệt vật lý.

Nếu muốn theo dõi CPU VPS thế nào theo thời gian thực ngay trên terminal mà không phải chuyển qua lại giữa nhiều cửa sổ, bạn có thể sử dụng htop. Công cụ này có biểu đồ %CPU trực quan cho từng tiến trình. Chi tiết cách đọc các chỉ số đã được trình bày trong bài Kiểm Tra Tài Nguyên VPS.

Nếu cần theo dõi tổng quan nhiều VPS cùng lúc thay vì mở riêng từng máy, công cụ monitor tập trung được đề cập ở mục cuối bài sẽ phù hợp hơn.

Cách kiểm tra Port đang mở & Services đang chạy

Khi RAM hoặc CPU đầy nhưng chưa rõ có tiến trình lạ nào đang âm thầm chạy ngầm hay không, chẳng hạn một service cũ quên tắt hoặc nghiêm trọng hơn là mã độc đào coin đội lốt tiến trình hệ thống, bước loại trừ nhanh là kiểm tra các port đang mở và những service đang chạy.

Để xem các port đã mở trên VPS bằng Linux, sử dụng lệnh:

ss -tulnp

Để xem các service đang chạy trên VPS đối với hệ thống sử dụng systemd:

systemctl list-units --type=service --state=running

Nếu muốn tìm service chạy ngốn RAM trên VPS trong danh sách trên, có thể kết hợp với lệnh ps aux --sort=-%mem | head để sắp xếp các tiến trình theo mức RAM tiêu thụ từ cao xuống thấp. Cách đọc chi tiết từng cột đã được trình bày trong bài Kiểm Tra Tài Nguyên VPS nên không nhắc lại ở đây.

Để kiểm tra nhanh VPS đã cài Node.js chưa, sử dụng node -v. Nếu hệ thống báo lỗi “command not found” thì có nghĩa là Node.js chưa được cài.

Với quản lý thread trên VPS, nếu nghi ngờ một tiến trình cụ thể tạo ra quá nhiều thread gây tốn CPU, có thể dùng top -H. Lệnh này hiển thị theo từng thread thay vì gộp theo tiến trình.

Cách xem Log & lịch sử User trên VPS

Nếu RAM/CPU cho biết “cái gì” đang đầy, thì log chính là nơi giúp trả lời “vì sao”. Chẳng hạn, log web server có thể cho biết IP nào đang gửi request nhiều bất thường, trong khi log hệ thống cho biết tiến trình nào từng bị kernel tự kill do hết RAM (OOM killer).

Xem log trên VPS nhanh nhất là theo dõi log hệ thống theo thời gian thực. Trên Ubuntu/Debian, log nằm tại /var/log/syslog, còn khi kiểm tra VPS CentOS, đường dẫn tương ứng là /var/log/messages:

tail -f /var/log/syslog

Kiểm tra lịch sử user trên VPS để xem ai từng đăng nhập SSH gần đây và có phiên đăng nhập lạ nào hay không, sử dụng lệnh last để xem lịch sử đăng nhập thành công và lastb để xem lịch sử đăng nhập thất bại.

Nếu nhận thấy mức sử dụng SSH VPS tăng bất thường, đồng thời có nhiều dòng trong lastb đến từ các IP lạ, đây có thể là dấu hiệu VPS đang bị dò mật khẩu (brute-force). Khi đó, cần đổi port SSH mặc định hoặc bật thêm lớp chặn brute-force.

Một vài lệnh gộp nhanh cho các nhu cầu cùng nhóm như lệnh kiểm tra VPS, check thông tin VPS, theo dõi tình trạng VPS, cách xem dung lượng VPS, kiểm tra bộ nhớ VPS bằng command về bản chất đều quy về các bộ lệnh free, top/htop, df đã được trình bày chi tiết trong bài Kiểm Tra Tài Nguyên VPS.

Ngoài ra, có thể kết hợp thêm hai lệnh dưới đây cho hai nhu cầu riêng: xem toàn bộ gói phần mềm đã cài (xem tất cả các thứ cài trong VPS) và kiểm tra ổ cứng đang sử dụng là HDD hay SSD (kiểm tra cấu hình VPS ổ cứng HDD hay SSD):

dpkg -l
lsblk -d -o name,rota

Lệnh dpkg -l áp dụng cho Debian/Ubuntu, còn CentOS sử dụng rpm -qa tương đương. Với lsblk, nếu cột rota trả về giá trị 1 thì đó là HDD, còn giá trị 0 là SSD.

Với một vài VPS riêng lẻ, việc gõ tay từng lệnh trên mỗi lần nghi ngờ có sự cố là đủ. Tuy nhiên, nếu đang quản lý nhiều VPS cùng lúc, việc mở từng máy và chạy lại đúng bộ lệnh này mỗi lần kiểm tra sẽ bắt đầu tốn thời gian, đồng thời dễ bỏ sót sự cố.

Đây là vấn đề mà một số công cụ monitor VPS tập trung giải quyết. Một cái tên đáng chú ý theo hướng này là OneDash, với dashboard giám sát RAM/CPU real-time cho nhiều server cùng lúc và log tập trung, tức gom log của toàn bộ VPS về một nơi thay vì phải mở từng máy để chạy tail log riêng như cách trên.

Điểm cần cân nhắc là nền tảng này còn khá mới nên chưa có nhiều đánh giá dài hạn từ cộng đồng. Nếu quy trình gõ lệnh thủ công hiện tại vẫn đang hoạt động tốt với số lượng VPS bạn đang quản lý thì chưa chắc cần thay đổi ngay. Hướng này chỉ thực sự đáng cân nhắc khi số lượng VPS đã đủ nhiều khiến việc tự theo dõi từng máy bắt đầu dễ bỏ sót sự cố.

Câu hỏi thường gặp

Có giới hạn RAM cho hosting VPS được không?

Có. RAM là tài nguyên chung của cả VPS nên không được “cấp phát cứng” theo từng hosting/website giống như trên shared hosting. Tuy nhiên, nếu muốn giới hạn một service cụ thể không được chiếm quá X RAM để tránh service đó sử dụng hết tài nguyên chung, có thể đặt giới hạn bằng cgroups, chẳng hạn cấu hình MemoryMax= trong systemd cho đúng service đó.

Xử lý RAM/CPU đầy bằng cách kill tiến trình, thêm swap hoặc tối ưu cache chỉ giải quyết được phần ngọn nếu VPS thực sự đang thiếu tài nguyên so với nhu cầu thực tế.

Nếu sau khi áp dụng đầy đủ các bước trên mà RAM hoặc CPU vẫn thường xuyên chạm ngưỡng chỉ sau vài giờ, đó là tín hiệu rõ ràng cho thấy nên nâng cấp lên gói VPS có RAM/CPU cao hơn, thay vì tiếp tục xử lý tạm thời mỗi khi sự cố lặp lại.

Leave a Reply