Ổ NVMe Cục Bộ Đấu Với AWS EBS gp3: Vì Sao Độ Trễ Mạng fsync Bóp Nghẹt SQLite
Hướng dẫn kiến trúc lưu trữ trên SQLiteEdge: lý giải vì sao độ trễ ổ mạng ở iodepth=1 làm nghẽn luồng ghi SQLite WAL và câu lệnh fio tự kiểm tra ổ NVMe.
- MỤC TIÊU THÔNG LƯỢNG MÔ HÌNH
- 15.2x Faster
- ĐẶC TÍNH ĐỌC / RPO
- 0.045ms vs 1.15ms
- PHÂN KHÚC MÁY CHỦ THAM CHIẾU
- Direct PCIe NVMe
Định kiến "SQLite không chịu nổi tải ghi" hầu hết bắt nguồn từ việc chạy thử nghiệm trên máy ảo AWS EC2 gắn ổ đĩa mạng EBS gp3. Do SQLite xử lý tuần tự từng luồng ghi qua 1 khóa duy nhất, thông lượng tối đa bị quyết định bởi công thức `1 / thời_gian_giữ_khóa`. Cộng thêm 1.15ms truyền mạng cho mỗi nhịp đồng bộ WAL lập tức kéo tụt trần ghi từ ~22.000 TPS xuống chỉ còn ~1.350 TPS.
Trong bản vẽ lưu trữ BP-07 trên SQLiteEdge, mọi tham số dưới đây bám sát tài liệu SQLite 3.46 và biểu phí nhà cung cấp đối chiếu ngày 2026-11-12.
Nguyên Tắc Thiết Kế SQLiteEdge Cho NVMe Cục Bộ vs Ổ Mạng EBS iodepth=1 Fsync
- Tuyệt đối không đặt tệp SQLite đang chạy thật lên ổ mạng NFS, AWS EFS, Ceph hay Block Volume qua mạng nếu ứng dụng có tải ghi thường xuyên.
- Luôn kiểm chứng độ trễ phần cứng thật trước khi lên sóng bằng lệnh `fio --rw=write --bs=4k --fdatasync=1 --iodepth=1` — chỉ số p99 lý tưởng phải dưới 120 micro-giây.
- Mount phân vùng Linux ext4 kèm cờ `noatime,nodiratime` để hàng vạn lệnh đọc SELECT mỗi giây không kích hoạt thao tác ghi cập nhật giờ truy cập tệp.
- Giữ nguyên cơ chế bảo vệ ghi (`barrier=1`) trên các ổ Enterprise NVMe có tụ chống mất điện (PLP) tại trung tâm dữ liệu để bảo toàn dữ liệu.
Mẫu Cấu Hình SQLiteEdge: Bài Đo Kiểm 60 Giây Độ Trễ fdatasync Đơn Luồng Chuẩn SQLite
# Đo chính xác độ trễ fdatasync 4K ở độ sâu hàng đợi = 1 (đặc tính SQLite WAL)
fio --name=sqlite_wal_probe \
--filename=/var/lib/sqlite/fio_probe.dat \
--size=256M \
--rw=write \
--bs=4k \
--ioengine=sync \
--fdatasync=1 \
--iodepth=1 \
--numjobs=1 \
--runtime=20 --time_based
# Kết quả đối chiếu thực tế:
# Vultr High Frequency Local NVMe : trung bình 45 us (0.045 ms) -> ~22.000+ WAL TPS
# Hostinger AMD EPYC Local NVMe : trung bình 110 us (0.11 ms) -> ~11.800+ WAL TPS
# AWS EC2 + Ổ mạng EBS gp3 : trung bình 1150 us (1.15 ms)-> ~1.350 WAL TPSBảng Mô Hình Thông Số & Chi Phí SQLiteEdge (BP-07)
Các mức giá tham khảo cập nhật ngày 2026-11-12 từ trang công khai của hãng (giá có thể thay đổi khi thanh toán); thông số thông lượng là ước tính mô hình lý thuyết, hãy tự xác thực bằng fio trên máy chủ của bạn.
| Hạ Tầng Ổ Cứng | Độ Trễ 4K fdatasync | Trần Ghi WAL Tối Đa | Chi Phí Tháng (8GB/16GB) |
|---|---|---|---|
| AWS EC2 m7i.large + EBS gp3 (3,000 IOPS) | 1.15 ms (1,150 µs) | 1,380 TPS | $108.00 / tháng |
| AWS EC2 + Ổ io2 Block Express cao cấp | 0.32 ms (320 µs) | 5,400 TPS | $390.00+ / tháng |
| Hostinger KVM 4 Ổ Gen4 NVMe Cục Bộ | 0.11 ms (110 µs) | 11,800 TPS | $10.49 / tháng |
| Vultr High Frequency 3.7GHz NVMe Cục Bộ | 0.045 ms (45 µs) | 22,400 TPS | $48.00 / tháng |
Cấu Hình Máy Chủ NVMe & Kho S3 Khớp Bản Vẽ BP-07 Trên SQLiteEdge
-
Vultr High Frequency 3.5GHz+ Ổ NVMe Cục Bộ (Độ Trễ fsync Cực Thấp)Xem Gói Vultr Cho BP-07 Trên SQLiteEdge →
Xung đơn nhân 3.7GHz+ & NVMe trực tiếp • fsync ~0.045ms đẩy kịch trần TPS ghi đơn luồng SQLite WAL (https://www.vultr.com/pricing/) -
InterServer Storage $6 Khóa Giá Trọn Đời (Đích Lưu Trữ S3 / MinIO Cho Litestream)Xem Kho S3 InterServer Cho BP-07 Trên SQLiteEdge →
Chỉ $6/tháng khóa giá trọn đời cho 1TB • $0 phí lệnh PUT S3 khi stream WAL mỗi giây bằng Litestream (https://www.interserver.net/vps/)
Câu Hỏi Kỹ Thuật SQLiteEdge Cho Bản Vẽ BP-07
-
Tại sao thông số iodepth=1 lại quan trọng hơn con số quảng cáo 100.000 IOPS của hãng Cloud?
Mức 100.000 IOPS chỉ đạt được khi đẩy song song 64–128 luồng hàng đợi ổ cứng. Luồng ghi của một tệp SQLite có độ sâu hàng đợi bằng đúng 1, nên độ trễ phản hồi đơn chiếc (micro-giây mỗi lần fsync) quyết định tất cả.
-
Hệ tệp ext4 hay XFS trên Linux chạy SQLite WAL nhanh hơn?
ext4 với tham số `noatime,data=ordered` thường nhỉnh hơn XFS khoảng 5–9% ở bài toán ghi tuần tự 1 tệp đơn lẻ nhờ nhật ký metadata gọn nhẹ hơn.