Bạn vừa đăng ký một gói VPS cao cấp sử dụng ổ cứng NVMe U.2 Enterprise. Bạn háo hức kiểm tra tốc độ bằng lệnh dd quen thuộc và nhận lại một kết quả thấp đến mức khó hiểu. Liệu nhà cung cấp có đang “treo đầu dê bán thịt chó”? Khoan hãy vội kết luận. Thực tế, việc sử dụng dd để đo hiệu năng của các ổ cứng công nghệ mới như NVMe là một sai lầm phổ biến về mặt kỹ thuật. Bài viết này sẽ đi sâu phân tích cơ chế hoạt động của ổ cứng và hệ điều hành Linux. InterData sẽ giúp bạn hiểu rõ 6 lý do tại sao lệnh này không còn chính xác. Đồng thời, chúng tôi sẽ hướng dẫn bạn cách đo tốc độ thực tế “chuẩn chuyên gia” để thấy được sức mạnh thật sự của hệ thống.
Lệnh dd và Phương Pháp Đo Tốc Độ Cơ Bản
Trước khi đi sâu vào các vấn đề kỹ thuật phức tạp, chúng ta cần hiểu rõ công cụ mà mọi người thường dùng này là gì. Tại sao lệnh dd lại trở thành tiêu chuẩn đo lường trong quá khứ và vì sao vị thế đó không còn đúng ở hiện tại?
Lệnh dd là gì?
Nhiều quản trị viên hệ thống thường sử dụng lệnh dd như một cách để đánh giá hiệu năng ổ cứng. Tuy nhiên, cách tiếp cận này chưa thực sự phản ánh đúng mục đích ban đầu của công cụ.
Chức năng chính của lệnh dd là sao chép và chuyển đổi file (sao lưu, nén, chuyển đổi định dạng), không phải công cụ đo hiệu năng chuyên dụng.
Tên gọi dd thường được hiểu là “Disk Dump” hoặc “Data Description”. Mục đích ra đời của lệnh này trên Unix/Linux là để sao chép dữ liệu từ vị trí này sang vị trí khác theo từng khối (block). Lệnh này cực kỳ hữu ích khi bạn muốn sao lưu toàn bộ ổ đĩa, tạo file ISO từ đĩa CD, hoặc tạo các file rỗng để test hệ thống.
Vì tính chất “đọc và ghi” dữ liệu của lệnh, người dùng bắt đầu tận dụng công cụ này để xem mất bao lâu để ghi một file dung lượng lớn. Từ đó, thói quen dùng dd để benchmark tốc độ ổ cứng hình thành. Nhưng với công nghệ lưu trữ hiện đại, phương pháp này đã trở nên lỗi thời và thiếu chính xác.
Các tham số thường dùng của dd
Để hiểu cách dd làm việc, bạn cần nắm được các tham số điều khiển lệnh này. Một sai sót nhỏ trong các tham số cũng có thể dẫn đến kết quả sai lệch hoàn toàn hoặc tệ hơn là mất dữ liệu.
Một số tham số thường dùng:
| Tham số | Chức năng |
|---|---|
| bs=Bytes | Đọc hoặc ghi dữ liệu với kích thước khối là BYTES (Block Size). Đây là lượng dữ liệu lệnh xử lý trong một lần đọc/ghi. |
| cbs=Bytes | Chuyển đổi dữ liệu với kích thước khối là BYTES. |
| conv=CONVs | Chuyển đổi dữ liệu với các chức năng cụ thể. Ví dụ: fdatasync để đảm bảo dữ liệu ghi xuống đĩa thật. |
| ascii | Chuyển từ EBCDIC sang ASCII. |
| ebcdic | Chuyển từ ASCII sang EBCDIC. |
| lcase | Chuyển chữ hoa thành chữ thường. |
| ucase | Chuyển chữ thường thành chữ hoa. |
| sync | Đồng bộ hóa dữ liệu và siêu dữ liệu, thêm null byte để đủ kích thước khối. |
| count=N | Chỉ định số lượng khối cần xử lý. |
| ibs=Bytes | Đọc dữ liệu với kích thước khối là BYTES (Input Block Size). |
| of=FILE | Ghi dữ liệu vào FILE đích (Output File). |
| if=FILE | Đọc dữ liệu từ FILE nguồn (Input File). |
| seek=N | Bỏ qua N khối ở đầu file đích. |
| skip=N | Bỏ qua N khối ở đầu file nguồn. |
Phương pháp đo dd tại Tocdo.io (Test 3 lần)
Một trong những công cụ benchmark nhanh phổ biến nhất trong cộng đồng sử dụng VPS Việt Nam là script từ Tocdo.io. Script này sử dụng chính lệnh dd để đưa ra đánh giá sơ bộ.
Tocdo.io sẽ sử dụng tuần tự 3 lần như nhau để đọc từ ổ đĩa. Dưới đây là lệnh test thủ công mô phỏng lại quá trình này mà bạn có thể tự chạy trên VPS của mình:
dd if=/dev/urandom of=/root/dd-test/testfile bs=1M count=10240 status=progress
rm -rf testfile #dọn dẹpChú thích chi tiết về lệnh trên:
if=/dev/urandom: Lấy dữ liệu ngẫu nhiên từ thiết bị ảo/dev/urandom. Việc này mô phỏng dữ liệu thật tốt hơn là dùng/dev/zero(toàn số 0), nhưng nó lại tiêu tốn CPU để tạo ra số ngẫu nhiên.of=/root/dd-test/testfile: File test sẽ được tạo tại đường dẫn này.bs=1M: Block size là 1 Megabyte. Mỗi lần lệnh sẽ đọc và ghi một cục dữ liệu 1MB.count=10240: Tổng số block cần ghi. Phép tính là: 10240 block × 1 MB = 10.240 MB (tương đương 10 GB dữ liệu).status=progress: Hiển thị thanh tiến trình để bạn biết lệnh đang chạy đến đâu.
Mục đích của việc thực hiện 3 Round (3 vòng test):
Tocdo.io đo dd đọc 3 lần mục đích là để xem sự thay đổi tốc độ và độ ổn định của hệ thống:
- Round 1: Tốc độ lần đầu khi cache chưa nóng. Hệ thống phải làm việc vất vả hơn để khởi tạo và ghi dữ liệu mới.
- Round 2: Tốc độ sau khi OS/SSD cache bắt đầu hoạt động. Lúc này, một phần dữ liệu hoặc metadata đã nằm trong RAM hoặc bộ đệm, nên tốc độ thường cao hơn.
- Round 3: Tốc độ khi cache nóng hoặc SSD bắt đầu giảm tốc do thermal throttling (quá nhiệt) hoặc full SLC cache (bộ đệm tốc độ cao bị đầy). Round này kiểm tra độ bền bỉ của ổ cứng.
Thực tế cho thấy, nhiều hệ thống VPS chất lượng cao vẫn có thể đạt kết quả tốt với lệnh này nếu được tối ưu hóa đúng cách.
- Kết quả speedtest VPS thực tế của InterData: Xem kết quả tại đây
- Kết quả speedtest VPS AMD NMVe U.2 thực tế của InterData: Xem kết quả tại đây
Ví Dụ Thực Tế Của VPS Mà InterData Đang Cung Cấp
Dù lệnh dd có thể cho thấy một phần bức tranh, nhưng với công nghệ NVMe (kể cả các loại U.2, U.3, M.2), tốc độ thực tế luôn cao hơn rất nhiều so với những gì dd đo được. InterData luôn khuyến nghị khách hàng nhìn vào hiệu năng thực tế khi chạy ứng dụng thay vì chỉ tin vào một dòng lệnh đơn giản.
Trước khi tìm hiểu lí do đo dd thấp thì hãy xem qua ví dụ thực tế của VPS mà InterData đang cung cấp như sau:
Để chứng minh sức mạnh của NVMe U.2, chúng ta sẽ sử dụng công cụ fio. Đây là công cụ chuẩn công nghiệp (Industry Standard) để benchmark hệ thống lưu trữ.
Sử dụng công cụ fio để đo (cài đặt bằng lệnh: apt install fio -y trên Ubuntu/Debian hoặc yum install fio -y trên CentOS).
Các lệnh có thể dùng để test Fio giống tocdo.io. Chúng ta sẽ test 2 trường hợp phổ biến: Block size 4K (đại diện cho xử lý database, file nhỏ) và Block size 64K (đại diện cho copy file lớn).
1. Test với Block Size 4K (Tùy chỉnh –rw=read hoặc write để test đọc hoặc ghi):
fio --name=bs4k --filename=/root/fio-test/testfile4k --rw=read --bs=4k --size=10G --numjobs=8 --iodepth=16 --direct=1 --runtime=10 --time_based --group_reportingĐể test ghi (Write), bạn thay --rw=read thành --rw=write.
2. Test với Block Size 64K (hoặc lớn hơn để đo băng thông):
fio --name=bs64k --filename=/root/fio-test/testfile64k --rw=read --bs=64k --size=10G --numjobs=8 --iodepth=16 --direct=1 --runtime=10 --time_based --group_reportingDọn dẹp sau test:
rm -rf /root/fio-testChú thích các tham số quan trọng:
--name=bs4k: Tên job, giúp bạn dễ dàng nhận diện kết quả trong log.--filename=/root/fio-test/testfile4k: Chỉ định rõ file sẽ được tạo ra để test, đảm bảo an toàn cho filesystem.--rw=read/--rw=write: Chọn chế độ test đọc hoặc ghi.--bs=4k: Block size 4K. Đây là kích thước quan trọng nhất để đo chỉ số IOPS (Input/Output Operations Per Second).--size=10G: File test 10GB. Kích thước này đủ lớn để làm bão hòa controller của NVMe, giúp kết quả chính xác hơn.--numjobs=8: Chạy 8 job song song. Tham số này cực kỳ quan trọng với NVMe để tận dụng khả năng xử lý đa luồng.--iodepth=16: Queue depth (hàng đợi) cao. NVMe được thiết kế để xử lý hàng ngàn lệnh trong hàng đợi cùng lúc.--direct=1: Bypass cache (bỏ qua cache của RAM/OS). Đây là cách duy nhất để đo tốc độ thực của ổ đĩa.--runtime=10 --time_based: Chạy test trong đúng 10 giây, giúp chuẩn hóa thời gian đo.--group_reporting: Gộp kết quả của các job lại để hiển thị tổng quan dễ hiểu.
Một số hình ảnh thực tế: Test trên VPS của InterData
Khi sử dụng phương pháp đo đúng bằng fio, kết quả nhận được rất ấn tượng và phản ánh đúng giá trị phần cứng:
Chuẩn 4K (Quan trọng cho Website, Database)
Kết quả đọc 4K đạt tới 99.000 IOPS. Con số này cho thấy VPS có thể xử lý gần 100.000 yêu cầu truy xuất dữ liệu nhỏ mỗi giây. Đây là yếu tố then chốt giúp website load nhanh mượt mà.
Tốc độ ghi 4K cũng đạt gần 90.000 IOPS, đảm bảo việc ghi dữ liệu vào database không bị nghẽn cổ chai.
Chuẩn 64K (Quan trọng cho sao lưu, download/upload file lớn)
Với các file lớn hơn, tốc độ băng thông (Throughput) lên tới 2GB/s cho cả đọc và ghi. Con số này cao gấp nhiều lần so với SSD SATA thông thường.
Lý do tại sao phải dùng fio mà không phải dd sẽ được trình bày chi tiết ngay trong nội dung bên dưới.
6 Lý Do Khiến Tốc Độ dd Thấp Hơn Thực Tế Của NVMe
Bạn đã thấy sự chênh lệch “một trời một vực” giữa kết quả của dd và fio. Vậy nguyên nhân sâu xa về mặt kỹ thuật là gì? Tại sao một lệnh phổ biến như dd lại “bất lực” trước NVMe?
1. Lệnh dd chỉ đo 1 luồng đọc/ghi tuần tự (Single-Threaded Sequential I/O)
Đây là nguyên nhân lớn nhất. NVMe (Non-Volatile Memory Express) là giao thức được thiết kế để khai thác khả năng xử lý song song (parallelism) của chip nhớ hiện đại. Một ổ NVMe có thể hỗ trợ tới 64.000 hàng đợi (queues), mỗi hàng đợi chứa 64.000 lệnh.
Ngược lại, lệnh dd hoạt động cực kỳ đơn giản: Nó chỉ chạy 1 luồng duy nhất (single thread), gửi 1 yêu cầu I/O (QD1) tại một thời điểm. Bạn có thể hình dung việc này giống như bạn đang sở hữu một đường cao tốc 64 làn xe (NVMe) nhưng chỉ cho phép đúng 1 chiếc xe (lệnh dd) chạy trên đó. Tốc độ đo được lúc này là tốc độ của chiếc xe đó, chứ không phải năng lực vận chuyển của cả con đường.
Kết quả là tốc độ đo được bằng dd thường chỉ phản ánh khoảng 10–30% năng lực thực sự của ổ cứng.
2. Tốc độ quảng cáo là Sequential trên nhiều Queue Depth (QD32/QD64)
Khi bạn xem thông số kỹ thuật của ổ cứng NVMe (ví dụ: Đọc 3500 MB/s, Ghi 3000 MB/s), các con số này được nhà sản xuất đo trong điều kiện lý tưởng nhất.
Số liệu quảng cáo (3-7 GB/s) được đo bằng công cụ chuyên dụng như CrystalDiskMark hoặc fio với thiết lập: Queue Depth cao (thường là 32 hoặc 64), nhiều Threads (8 hoặc 16) và I/O song song. Điều này có nghĩa là ổ cứng đang nhận hàng trăm lệnh đọc/ghi cùng lúc, giúp nó tối ưu hóa việc sắp xếp dữ liệu và đạt tốc độ tối đa.
Lệnh dd không làm được điều này. Nó không thể tạo đủ áp lực (load) để kích hoạt toàn bộ sức mạnh của controller NVMe.
3. dd bị ảnh hưởng bởi Cache và Kernel Linux
Linux có cơ chế quản lý bộ nhớ rất thông minh bao gồm Page Cache, Readahead và Write-back Buffer. Khi bạn chạy lệnh dd mà không có cờ direct (hoặc oflag=direct), dữ liệu thực chất chưa được ghi ngay xuống đĩa.
- Test Đọc: Nếu file test của bạn nhỏ hơn dung lượng RAM trống, Linux sẽ cache file đó vào RAM. Lần đọc tiếp theo, bạn thực chất đang đo tốc độ copy từ RAM ra, con số có thể lên tới hàng chục GB/s (ảo).
- Test Ghi: Dữ liệu được ghi vào RAM trước (Buffer). Lệnh
ddcó thể báo đã xong, nhưng Kernel vẫn đang âm thầm ghi dữ liệu từ RAM xuống đĩa (flush). Kết quả bạn thấy là tốc độ ghi vào RAM, không phải vào đĩa.
4. NVMe U.2 (Enterprise) tối ưu Random IOPS, không phải Sequential Speed
InterData sử dụng chuẩn U.2 Enterprise cho hệ thống VPS. Có một sự khác biệt lớn về triết lý thiết kế giữa ổ cứng Enterprise (U.2) và Consumer (M.2 PC cá nhân).
- Ổ M.2 Consumer: Tối ưu cho tốc độ tuần tự (Sequential Speed) cực cao (lên tới 7000 MB/s) để quảng cáo, nhưng độ bền thấp và tốc độ giảm nhanh khi chạy nặng liên tục.
- Ổ U.2 Enterprise: Ưu tiên độ bền (DWPD – Drive Writes Per Day), độ trễ thấp (Low Latency) và đặc biệt là Random IOPS cao.
Sequential Speed của U.2 thường chỉ ở mức ổn định 1.5–3 GB/s (có thể thấp hơn con số đỉnh của M.2 Consumer). Tuy nhiên, khả năng chịu tải hàng nghìn người truy cập cùng lúc (Random I/O) của nó lại vượt trội hoàn toàn. Lệnh dd chủ yếu đo Sequential, nên nó vô tình làm “dìm hàng” điểm mạnh nhất của dòng ổ cứng Enterprise.
5. dd không hề đo được “Tốc độ thật” của NVMe
Từ các lý do trên, có thể khẳng định dd không đo được tốc độ thật. Ngoài ra, việc dùng if=/dev/urandom cũng tạo ra một nút thắt cổ chai (bottleneck) tại CPU.
CPU phải tốn tài nguyên để tính toán và tạo ra dữ liệu ngẫu nhiên cho /dev/urandom. Nếu CPU của bạn xử lý việc này chậm hơn tốc độ ghi của ổ cứng, thì kết quả dd trả về chính là tốc độ của CPU, không phải của ổ cứng. Để khắc phục, các chuyên gia bắt buộc phải dùng fio để mô phỏng I/O song song và bỏ qua các giới hạn này.
6. Tốc độ ghi quảng cáo thường là “SLC Cache Speed”
Hầu hết các ổ cứng SSD hiện đại đều sử dụng công nghệ SLC Caching. Một phần dung lượng ổ cứng được cấu hình chạy ở chế độ SLC (1 bit per cell) cho tốc độ cực nhanh.
Tốc độ cao (ví dụ 3000 MB/s) bạn thường thấy chính là tốc độ ghi vào vùng SLC Cache này. Khi bạn thực hiện lệnh dd với dung lượng lớn (ví dụ ghi 50GB, 100GB), vùng cache này sẽ bị đầy. Lúc này, ổ cứng buộc phải ghi trực tiếp vào chip nhớ TLC hoặc QLC với tốc độ chậm hơn nhiều (thường chỉ còn 500–900 MB/s). Đây là đặc tính vật lý bình thường của bộ nhớ flash, không phải lỗi.
Giải Pháp: Sử Dụng Công Cụ fio để Đo Tốc Độ Thực Tế
Sau khi đã hiểu rõ nguyên nhân, giải pháp duy nhất để đánh giá đúng chất lượng VPS tại InterData là thay đổi công cụ đo lường.
Giới thiệu fio: Fio (Flexible I/O Tester) là công cụ chuyên dụng được phát triển bởi Jens Axboe – người bảo trì block layer của Linux Kernel. Nó cho phép mô phỏng chính xác các loại tải (workload) của server thực tế.
Hướng dẫn cài đặt nhanh:
apt install fio -y # Đối với Ubuntu/Debian
yum install fio -y # Đối với CentOS/RHELBạn có thể copy và chạy các lệnh mẫu dưới đây để tự kiểm chứng (đã được cấu hình an toàn để tạo file test riêng):
Test Random Read (Đọc ngẫu nhiên – Giả lập Database):
fio --name=randread --filename=testfile --rw=randread --bs=4k --iodepth=64 --numjobs=4 --size=4G --group_reporting --direct=1Test Sequential Write (Ghi tuần tự – Giả lập chép file):
fio --name=seqwrite --filename=testfile --rw=write --bs=1M --iodepth=16 --numjobs=1 --size=4G --group_reporting --direct=1Hãy chú ý đến dòng kết quả IOPS và BW (Bandwidth). Đó mới là con số phản ánh đúng sức mạnh chiếc “siêu xe” NVMe U.2 mà bạn đang sở hữu.
Kết luận
Việc thấy kết quả thấp khi dùng lệnh dd trên VPS NVMe U.2 là một hiện tượng kỹ thuật hoàn toàn bình thường và dễ giải thích. Lệnh dd là một công cụ sao chép đơn luồng, nó không được thiết kế để đo hiệu năng của các hệ thống lưu trữ song song hiện đại.
Để đánh giá công bằng và chính xác hiệu năng VPS của InterData, bạn nên sử dụng các công cụ chuyên nghiệp như fio. Với cấu hình phần cứng Enterprise mạnh mẽ, InterData đảm bảo hệ thống luôn cung cấp IOPS cao và độ trễ thấp, giúp các ứng dụng nặng của bạn vận hành trơn tru, ổn định, điều mà các con số từ dd không thể hiện được.
