khi nào và tại sao `fstrim` lại giúp phục hồi hiệu năng server dùng SSD

Ở bài trước mình có chia sẻ Làm sao “dọn rác ẩn” cho SSD trên Linux (fstrim) có bạn trong nhóm facebook hỏi bài toán thực tế của nó ra sao thì nay mình chia sẻ trong bài này nhé 😀

`fstrim` đã cứu một server SSD như thế nào

Trong thời đại SSD trở thành mặc định trên nhiều máy chủ Linux (cả vật lý lẫn Cloud), không ít người vẫn tin rằng SSD không cần bảo trì chỉ cần lắp vào là chạy :D. Nhưng thực tế trong vận hành, có những tình huống “lạ” tưởng như đến từ ứng dụng hoặc lỗi kernel, nhưng lại xuất phát từ việc… SSD bị “rác” chiếm dụng âm thầm.

Đây là một câu chuyện thực tế từ hệ thống cũng chỉ ở môi trường staging thôi nhưng nó cũng là usecase thực tế.

Tình huống

Một server staging chạy Ubuntu 22.04, sử dụng ổ SSD NVMe 500GB, filesystem là ext4, dùng để test CI/CD pipeline tự động. Sau hơn 4 tháng hoạt động liên tục:

Dung lượng còn trống vẫn khoảng 150GB (hoặc ít hơn mình không nhớ lắm thường cron cho nó dọn).
Không swap nhiều, RAM vẫn dư.
CPU không cao.
Nhưng: ứng dụng bị chậm rõ rệt, đặc biệt ở bước ghi file log hoặc cache.

Anh em Dev kêu là build mất gấp đôi thời gian bình thường và npm install dường như bị “đơ” từng nhịp.

Điều tra

Đầu tiên mình check:

iotop: Disk write có lúc spike lên 100%, rồi tụt xuống.
iostat -x 1: Thấy await cao hơn 40ms, đôi lúc chạm 80ms.
smartctl: SSD vẫn “healthy”, không lỗi phần cứng.
df -h: Dung lượng trống thoải mái.

Nhưng sau khi ghi nhiều, tốc độ write giảm mạnh giống hiện tượng “SSD đã bị ghi đầy và không còn vùng trống sạch để ghi nhanh”.

Nhận ra vấn đề

Mình nghi ngờ nguyên nhân là do TRIM không được thực hiện SSD không được thông báo vùng dữ liệu đã xóa, nên firmware không thể chuẩn bị block sạch để ghi.

Kiểm tra discard trong /etc/fstab thì không có. Check systemd timer:

systemctl status fstrim.timer

Kết quả: inactive (dead)

Thử nghiệm phục hồi bằng `fstrim`

Đầu tiên mình chạy thủ công:

sudo fstrim -v /

Kết quả:

/: 97.3 GiB (104497315840 bytes) trimmed

Sau đó, tốc độ ghi cải thiện tức thì:

dd if=/dev/zero of=testfile bs=1M count=1024:
- Trước khi fstrim: ~120 MB/s
- Sau fstrim: ~480 MB/s (gần tốc độ tối đa của ổ)
CI/CD build trở lại bình thường
Thời gian ghi file log trong app chỉ còn 1/3

Giải thích kỹ thuật

SSD cần block sạch để ghi mới. Khi xóa file, OS chỉ “bỏ ghi nhận” block vẫn tồn tại trên firmware SSD.

Nếu không có TRIM:

SSD phải đọc – xoá – ghi lại → gây chậm
Firmware không thể dọn dẹp vùng không dùng đến
Gây hiện tượng write amplification → làm chậm và giảm tuổi thọ ổ đĩa

Giải pháp lâu dài

Như bài trước mình cũng đã có nói là bật systemd timer:

sudo systemctl enable --now fstrim.timer

Hoặc, nếu không có systemd, thêm cron job:

@weekly fstrim -a

Không dùng discard mount option mặc định nếu workload ghi nhiều vì mỗi lần xóa file sẽ TRIM ngay, có thể gây giảm hiệu năng ghi liên tục.

Tổng kết

Dù fstrim là lệnh đơn giản, nhưng trong môi trường SSD-heavy (như CI/CD pipelines, hệ thống ghi log nặng, server staging/test…), việc không thực hiện TRIM định kỳ có thể khiến hệ thống “lảo đảo” một cách khó đoán.

Trong usecase mình gặp thì một cú fstrim duy nhất đã giải cứu server khỏi việc đánh giá sai rằng SSD đã “già”, và tiết kiệm thời gian xử lý hơn cả tiếng debug ứng dụng. Cái này thì chủ yếu do kinh nghiệm thực tế anh em gặp phải thôi. Nên là mình chia sẻ anh em hiểu và áp dụng trong công việc là ok rồi.