# Nâng cấp VPS: khi nào cần thêm CPU, RAM hay ổ đĩa

URL: https://cloudj.net/vi/blog/resize-vps-cpu-ram-disk
Published: 2026-11-11 · Updated: 2026-11-11

> Biết khi nào cần nâng cấp VPS dựa trên số liệu thực, cách đổi cấu hình CPU, RAM, ổ đĩa trong console, mở rộng filesystem và lên lịch bảo trì.

Quyết định nâng cấp VPS chủ yếu là chuyện đọc đúng tín hiệu. Website chậm không phải lúc nào cũng do CPU, và thêm RAM sẽ không cứu được một ổ đĩa đã đầy. Bài này chỉ cách xác định tài nguyên nào thực sự thiếu, cách đổi cấu hình CPU, RAM hoặc ổ đĩa trên máy chủ Cloudj, việc cần làm bên trong Linux sau khi ổ đĩa được mở rộng, và cách lên kế hoạch để người dùng gần như không nhận ra.

## Đọc tín hiệu trước khi trả thêm tiền

Bắt đầu với biểu đồ trên trang máy chủ trong [console Cloudj](https://app.cloudj.net), nơi hiển thị CPU, RAM và mạng theo thời gian. Sau đó xác nhận lại từ bên trong máy chủ. Mỗi loại tài nguyên có dấu hiệu riêng.

| Tài nguyên | Dấu hiệu thiếu | Lệnh kiểm tra |
|---|---|---|
| CPU | Load average thường xuyên cao hơn số vCPU; `%Cpu` gần 100 vào giờ cao điểm | `uptime`, `nproc`, `top` |
| CPU (shared) | Chỉ số `st` (steal) cao trong `top` dù mức dùng của bạn vừa phải | `top`, xem trường `st` |
| RAM | Bộ nhớ "available" còn rất ít, swap bị dùng liên tục, tiến trình bị OOM killer tắt | `free -h`, `journalctl -k -g oom` |
| Dung lượng ổ đĩa | Phân vùng root trên khoảng 85 phần trăm, hoặc tăng nhanh | `df -h`, `sudo du -sh /var/*` |
| I/O ổ đĩa | Chỉ số `wa` (I/O wait) cao trong `top`, truy vấn chậm khi ghi nhiều | `top`, `iostat -x 5` (gói `sysstat`) |

Vài nguyên tắc giúp bạn đọc số liệu đúng hơn:

- Một lần tăng đột biến chưa phải xu hướng. Hãy xem biểu đồ cả tuần, gồm cả ngày đông khách nhất, ví dụ ngày sale trên Shopee nếu bạn bán hàng.
- RAM bị page cache chiếm và hiện là "used" là bình thường. Hãy nhìn cột "available", không phải "free".
- Nếu OOM killer đã từng chạy dù chỉ một lần, bạn cần thêm RAM hoặc cần giới hạn bộ nhớ cho tiến trình đang phình to.
- Steal cao trên gói CPU shared nghĩa là bạn đang tranh core với người dùng khác. Chuyển sang CPU general purpose hoặc dedicated thường hiệu quả hơn thêm vCPU; bài so sánh [CPU shared và dedicated](https://cloudj.net/vi/blog/shared-vs-dedicated-cpu-vps) phân tích kỹ lựa chọn này.

Nếu muốn theo dõi liên tục thay vì kiểm tra từng lần, hãy cài các công cụ trong bài [giám sát tài nguyên VPS](https://cloudj.net/vi/blog/monitor-vps-resources).

## Xử lý những thứ rẻ trước

Trước khi nâng cấp, hãy loại trừ những vấn đề mà thêm phần cứng chỉ che đi:

- Tiến trình chạy mất kiểm soát hoặc rò rỉ bộ nhớ. `top` sắp xếp theo bộ nhớ (`Shift+M`) cho thấy ngay.
- Log làm đầy ổ đĩa. `sudo journalctl --vacuum-size=500M` thu gọn journal, còn log ứng dụng nên để `logrotate` xử lý.
- Docker image cũ và build cache. `docker system df` cho biết chúng chiếm bao nhiêu dung lượng.
- Cơ sở dữ liệu thiếu index phù hợp, trông giống như thiếu CPU hoặc I/O.

Nếu các mục trên đều ổn mà biểu đồ vẫn cho thấy quá tải, đó là lúc đổi cấu hình.

## Nâng cấp VPS: đổi CPU và RAM trong console

Cloudj cho phép đổi CPU và RAM của máy chủ hiện có ngay trên trang máy chủ trong console. Bạn có thể chuyển sang một gói có sẵn hoặc tự chọn tổ hợp vCPU và RAM, tới cấu hình tuỳ chỉnh 104 vCPU và 512 GB RAM.

1. Xem giá của cấu hình mới trên [trang bảng giá](https://cloudj.net/vi/pricing). Với thanh toán theo giờ, đơn giá mới áp dụng sau khi đổi; với gói trả trước, hãy kiểm tra cách tính phí trước khi xác nhận.
2. Lên lịch bảo trì ngắn. Hãy coi việc đổi cấu hình là thao tác sẽ khởi động lại máy chủ, và báo trước cho người dùng nếu dịch vụ quan trọng.
3. Tạm dừng các job ghi dữ liệu nhiều và tạo một bản sao lưu mới ra ngoài máy chủ. Xem bài [sao lưu VPS](https://cloudj.net/vi/blog/vps-backup-strategy).
4. Thực hiện đổi cấu hình trên trang máy chủ và chờ máy chủ chạy lại.
5. Kiểm tra cấu hình mới từ bên trong: `nproc` và `free -h`.

Phần lớn phần mềm tự dùng thêm core và RAM sau khi khởi động lại. Một số cần sửa cấu hình mới tận dụng được: kích thước buffer của database như `shared_buffers` của PostgreSQL hay `innodb_buffer_pool_size` của MySQL, số worker PHP-FPM, heap của Java (`-Xmx`), và số worker trong Node.js cluster.

## Mở rộng ổ đĩa, rồi mở rộng filesystem

Mở rộng ổ đĩa là một thao tác riêng trong console. Trên thực tế đây là thao tác một chiều: ổ đĩa chỉ tăng, không giảm, nên hãy thêm vừa đủ cho vài tháng tới thay vì thêm hết một lần.

Sau khi ổ đĩa được mở rộng, Linux thấy block device lớn hơn, nhưng phân vùng và filesystem vẫn giữ kích thước cũ. Nhiều cloud image tự mở rộng phân vùng root ở lần khởi động tiếp theo. Hãy kiểm tra trước:

```bash
lsblk
df -h /
```

Nếu `lsblk` cho thấy ổ đĩa lớn hơn phân vùng, bạn cần mở rộng thủ công. Tên thiết bị thường là `/dev/vda` hoặc `/dev/sda`; hãy đọc tên chính xác từ `lsblk` và thay vào:

```bash
sudo apt install -y cloud-guest-utils
sudo growpart /dev/vda 1
```

Sau đó mở rộng filesystem. Xem loại filesystem bằng `df -Th /`.

```bash
# ext4 (Ubuntu and Debian default)
sudo resize2fs /dev/vda1

# XFS (common on AlmaLinux and Rocky Linux)
sudo xfs_growfs /
```

Trên AlmaLinux và Rocky Linux, `growpart` nằm trong gói `cloud-utils-growpart`, cài bằng `dnf`. Nếu phân vùng root nằm trên LVM, hãy mở rộng physical volume và logical volume:

```bash
sudo pvresize /dev/vda3
sudo lvextend -r -l +100%FREE /dev/mapper/rl-root
```

Cả hai cách đều chạy được khi filesystem đang mount, không cần khởi động lại thêm lần nữa. Chạy lại `df -h /` để xác nhận.

## Khi nâng cấp không phải là lời giải

Nâng cấp theo chiều dọc có giới hạn, và đôi khi có hướng đi hợp lý hơn:

- **Người dùng ở xa.** Nếu máy chủ không quá tải nhưng trang vẫn chậm với khách ở nước khác, vấn đề là khoảng cách. Một máy chủ thứ hai gần người dùng hơn, chọn theo [hướng dẫn chọn vị trí VPS](https://cloudj.net/vi/blog/vps-locations-guide) và đo bằng [ping và mtr](https://cloudj.net/vi/blog/test-vps-latency-ping-mtr), sẽ hiệu quả hơn thêm core.
- **Một thành phần chiếm phần lớn tài nguyên.** Nếu database ngốn gần hết RAM, tách nó ra máy chủ riêng thường tốt hơn nhân đôi máy chủ ứng dụng.
- **Tải chỉ tăng theo đợt.** Với job xử lý ngắn hạn, một máy chủ tạm tính tiền theo giờ rồi xoá đi có thể rẻ hơn giữ một máy chủ lớn cả tháng.
- **Bạn muốn làm lại từ đầu.** Dựng máy chủ mới rồi chuyển ứng dụng sang đôi khi đơn giản hơn; xem bài [chuyển website sang VPS mới](https://cloudj.net/vi/blog/migrate-website-new-vps).

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

### Đổi cấu hình có làm mất dữ liệu không?

Việc đổi cấu hình không nhằm can thiệp vào dữ liệu, nhưng mọi thao tác khởi động lại máy chủ đều có thể làm lộ ra vấn đề như tắt máy không sạch. Lần nào cũng hãy sao lưu ra ngoài máy chủ trước.

### Sau này có thu nhỏ máy chủ được không?

CPU và RAM có thể đổi theo nhu cầu. Ổ đĩa thì chỉ tăng, nên nếu cần ổ nhỏ hơn, hãy tạo máy chủ mới đúng kích thước rồi chuyển dữ liệu sang.

### Vì sao ổ đĩa vẫn hiện dung lượng cũ?

Phân vùng và filesystem chưa được mở rộng. Chạy `growpart`, sau đó `resize2fs` hoặc `xfs_growfs` như hướng dẫn ở trên.

### Nhiều vCPU hơn có luôn nhanh hơn không?

Không. Ứng dụng đơn luồng chỉ dùng một core tại một thời điểm. Với loại ứng dụng này, chọn CPU dedicated hoặc general purpose có thể quan trọng hơn số lượng vCPU.

## Nâng cấp đúng với những gì bạn đo được

Hãy nâng cấp khi biểu đồ cả tuần khớp với những gì bạn thấy bên trong máy chủ, và đổi từng tài nguyên một để biết thay đổi nào có tác dụng. Các cấu hình hiện có và giá trực tiếp cho từng vị trí nằm trên [trang bảng giá](https://cloudj.net/vi/pricing), còn nút đổi cấu hình nằm trên trang của từng máy chủ trong [console Cloudj](https://app.cloudj.net).