Cấu hình và Chạy Benchmark hiệu năng Vector
Bước đầu tiên là xác lập đường cơ sở (baseline) về thông lượng (throughput) và độ trễ (latency) của hệ thống Vector Database sau khi đã thực hiện các tinh chỉnh Kernel ở các phần trước.
Sử dụng sysbench để đo lường hiệu năng I/O của đĩa, yếu tố then chốt ảnh hưởng đến tốc độ truy vấn Vector.
sudo apt update && sudo apt install -y sysbench
Kết quả mong đợi: sysbench được cài đặt thành công, không báo lỗi thiếu gói.
Thực hiện benchmark đọc/ghi ngẫu nhiên (random read/write) với kích thước block 4KB (tương thích với vector index nhỏ) và 64KB (tương thích với vector embedding lớn).
sysbench fileio --file-test-mode=rndrw --num-threads=8 --file-total-size=10G --file-block-size=64K --file-num=16 --max-time=60 run
Kết quả mong đợi: Xuất hiện dòng "operations performed: [số lượng] in [thời gian] sec" và "trans/sec: [số lượng giao dịch/giây].
Sử dụng công cụ vector-benchmark (hoặc script Python tùy chỉnh sử dụng thư viện `pymilvus` hoặc `weaviate-client`) để đo độ trễ truy vấn thực tế trên cơ sở dữ liệu.
Tạo file script benchmark Python tại `/usr/local/bin/vector_benchmark.py` với nội dung hoàn chỉnh:
#!/usr/bin/env python3
import time, random, numpy as np
from pymilvus import connections, CollectionSchema, FieldSchema, Collection, utility
# Cấu hình kết nối
connections.connect("default", host="localhost", port=19530)
# Tạo collection nếu chưa tồn tại
dim = 1536
schema = CollectionSchema([
FieldSchema(name="id", dtype=INT64, is_primary_key=True),
FieldSchema(name="vector", dtype=FLOAT_VECTOR, dim=dim)
], "Vector Benchmark Collection")
if not utility.has_collection("benchmark_vec"):
collection = Collection("benchmark_vec", schema)
index_params = {
"index_type": "HNSW",
"metric_type": "L2",
"params": {"M": 16, "efConstruction": 200}
}
collection.create_index(field_name="vector", index_params=index_params)
print("Collection created and indexed.")
else:
collection = Collection("benchmark_vec")
print("Collection already exists.")
# Chạy benchmark Top-K Search
num_queries = 1000
vectors = np.random.random((num_queries, dim)).astype("float32")
start_time = time.time()
for _ in range(num_queries):
collection.search(vectors, "vector", {"metric_type": "L2", "params": {"ef": 64}}, limit=10)
end_time = time.time()
latency_ms = (end_time - start_time) / num_queries * 1000
print(f"Total queries: {num_queries}")
print(f"Average Latency: {latency_ms:.2f} ms")
print(f"QPS: {num_queries / (end_time - start_time):.2f}")
Kết quả mong đợi: Script chạy xong và in ra "Average Latency" dưới 10ms (đối với máy cấu hình tốt đã tối ưu) và "QPS" cao.
Chạy script benchmark:
sudo chmod +x /usr/local/bin/vector_benchmark.py && python3 /usr/local/bin/vector_benchmark.py
Kết quả mong đợi: Không báo lỗi PermissionDenied hoặc ConnectionRefused. Các chỉ số QPS và Latency được in ra màn hình.
Giám sát Hiệu năng Thực tế với Prometheus và Grafana
Cài đặt Node Exporter và Prometheus
Để giám sát sâu các chỉ số Kernel và Database, ta cần triển khai Prometheus để thu thập metrics từ Node Exporter.
Cài đặt Node Exporter để thu thập thông số CPU, RAM, Disk I/O, Network.
sudo apt install -y prometheus-node-exporter
Kết quả mong đợi: Service `prometheus-node-exporter` tự động chạy và listen port 9100.
Cấu hình file `/etc/prometheus/prometheus.yml` để thu thập metrics từ Node Exporter và Vector Database (giả định Milvus/Weaviate có endpoint metrics).
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']
- job_name: 'vector-db'
static_configs:
- targets: ['localhost:9091'] # Milvus metrics port
# - targets: ['localhost:8080'] # Weaviate metrics port
Kết quả mong đợi: File cấu hình hợp lệ, không lỗi syntax.
Khởi động lại Prometheus để áp dụng cấu hình mới.
sudo systemctl restart prometheus && sudo systemctl status prometheus
Kết quả mong đợi: Prometheus đang chạy (active (running)) và không có lỗi trong log.
Giám sát với Grafana
Cài đặt Grafana để trực quan hóa dữ liệu từ Prometheus.
sudo apt install -y grafana && sudo systemctl enable --now grafana-server
Kết quả mong đợi: Grafana đang chạy, truy cập được tại `http://localhost:3000`.
Thêm Data Source Prometheus trong Grafana: Vào Configuration -> Data Sources -> Add -> Prometheus -> URL: `http://localhost:9090` -> Save & Test.
Tải template dashboard cho Vector Database (Dashboard ID 10268 cho Milvus, hoặc custom dashboard cho Weaviate) và nhập ID vào Grafana.
Verify kết quả: Mở dashboard và thấy các biểu đồ CPU usage, Memory usage, Query Latency, và Disk I/O đang cập nhật theo thời gian thực.
Giám sát và Phân tích với eBPF (bpftrace)
Giám sát System Call và Disk I/O
Sử dụng bpftrace để giám sát các hệ thống call (syscall) cấp thấp, giúp phát hiện các điểm nghẽn mà các công cụ thông thường bỏ qua.
Cài đặt bpftrace.
sudo apt install -y bpftrace
Kết quả mong đợi: Package bpftrace được cài đặt thành công.
Chạy script bpftrace để theo dõi độ trễ của các syscall đọc/ghi file (`read`, `write`) của tiến trình Vector Database (giả sử PID là 1234).
bpftrace -e 'tracepoint:syscalls:sys_enter_read { printf("PID: %d, Duration: %d us\n", pid, nsecs); }'
Kết quả mong đợi: Dòng output hiện ra liên tục khi có hoạt động I/O, hiển thị PID và thời gian thực thi tính bằng microsecond.
Để theo dõi cụ thể tiến trình Vector DB (ví dụ `milvus`), sử dụng filter theo tên tiến trình.
bpftrace -e 'tracepoint:syscalls:sys_enter_read { @[pid] = count(); } / comm == "milvus" /'
Kết quả mong đợi: Chỉ đếm các syscall `read` của tiến trình milvus, giúp xác định xem DB có đang thực hiện quá nhiều đọc đĩa không.
Giám sát độ trễ I/O của đĩa (Block I/O) để phát hiện disk bottleneck.
bpftrace -e 'tracepoint:block:block_rq_issue { @[dev] = hist(duration); }'
Kết quả mong đợi: Histogram hiển thị phân bố thời gian của các request đĩa, nếu thấy nhiều giá trị ở bin cao (>10ms) thì disk đang bị quá tải.
Phân tích Log lỗi và Xử lý OOM Killer
Xác định nguyên nhân OOM (Out of Memory)
Khi hệ thống bị thiếu RAM, Linux Kernel sẽ kích hoạt OOM Killer để giết tiến trình. Việc đầu tiên là kiểm tra log hệ thống.
Xuất log của OOM Killer từ journal.
journalctl -k | grep -i "killed process"
Kết quả mong đợi: Các dòng log hiển thị thông tin về tiến trình bị giết, ví dụ: "Out of memory: Kill process 1234 (milvus) score 900...".
Kiểm tra file log kernel trực tiếp.
grep -i "oom" /var/log/kern.log
Kết quả mong đợi: Nội dung log tương tự như journalctl, xác nhận thời điểm và tiến trình bị OOM.
Cấu hình OOM Score để bảo vệ Vector DB
Để ngăn OOM Killer giết Vector Database, ta cần giảm điểm ưu tiên (score) của nó xuống thấp nhất có thể (-1000), trừ khi hệ thống hoàn toàn cạn kiệt RAM.
Thiết lập `oom_score_adj` cho tiến trình Vector DB (ví dụ PID 1234).
echo -1000 > /proc/1234/oom_score_adj
Kết quả mong đợi: Không có lỗi, lệnh thực thi thành công.
Để cấu hình này tồn tại sau khi restart, tạo file systemd drop-in cho service Vector DB.
Tạo file `/etc/systemd/system/milvus.service.d/oom.conf` (hoặc `weaviate.service.d/oom.conf` tùy service name) với nội dung:
[Service]
OOMScoreAdjust=-1000
Kết quả mong đợi: File được tạo, chứa cấu hình OOMScoreAdjust.
Reload systemd và restart service để áp dụng.
sudo systemctl daemon-reload && sudo systemctl restart milvus
Kết quả mong đợi: Service restart thành công, kiểm tra lại bằng `cat /proc/[pid]/oom_score_adj` thấy giá trị là -1000.
Phân tích log lỗi Vector Database
Kiểm tra log của Vector Database để tìm lỗi cấu hình hoặc lỗi runtime.
sudo journalctl -u milvus -n 100 --no-pager
Kết quả mong đợi: Xem được 100 dòng log gần nhất. Tìm các từ khóa "ERROR", "PANIC", "segment fault".
Nếu gặp lỗi "Connection refused" hoặc "Timeout", kiểm tra cấu hình network và firewall.
sudo ufw status
Kết quả mong đợi: Đảm bảo port 19530 (Milvus) hoặc 8080 (Weaviate) đang được allow.
Tips Tối ưu cuối cùng để đạt độ trễ thấp nhất
Tinh chỉnh Scheduler và CPU Affinity
Đảm bảo tiến trình Vector DB luôn chạy trên các lõi CPU hiệu năng cao nhất (Performance Cores) và tránh bị di chuyển giữa các core (migration).
Sử dụng `taskset` để pin tiến trình vào các CPU core cụ thể (ví dụ core 0-3).
sudo taskset -p 0-3
Kết quả mong đợi: Tiến trình bị gắn (pinned) vào các core đã chỉ định, giảm thiểu cache miss do migration.
Đặt chính sách scheduler thành `SCHED_FIFO` hoặc `SCHED_RR` cho tiến trình quan trọng (cần root và cẩn thận).
sudo chrt -f 99
Kết quả mong đợi: Tiến trình chạy với độ ưu tiên realtime, giảm độ trễ khi CPU tải cao.
Tối ưu Cache và Filesystem
Giảm thiểu hoạt động flush buffer từ RAM xuống Disk để tăng throughput, chấp nhận rủi ro mất dữ liệu nhỏ khi mất điện (trade-off).
Giảm tần suất commit metadata của filesystem (ví dụ ext4/xfs).
sudo mount -o remount,data=writeback /dev/sda1 /mnt/data
Kết quả mong đợi: Filesystem được mount lại với option `data=writeback`, tăng tốc độ ghi nhưng giảm tính nhất quán (chỉ dùng cho môi trường test hoặc có UPS).
Giảm `vm.vfs_cache_pressure` để hệ thống giữ lại cache filesystem lâu hơn.
echo 100 > /proc/sys/vm/vfs_cache_pressure
Kết quả mong đợi: Giá trị được thay đổi, giúp giảm số lần đọc lại metadata từ đĩa.
Verify kết quả tối ưu cuối cùng
Chạy lại script benchmark ở phần đầu tiên để so sánh kết quả trước và sau khi áp dụng các tips.
python3 /usr/local/bin/vector_benchmark.py
Kết quả mong đợi: Chỉ số "Average Latency" giảm đáng kể (ví dụ từ 15ms xuống dưới 5ms) và "QPS" tăng lên so với baseline ban đầu.
Kiểm tra lại dashboard Grafana để đảm bảo CPU usage không bị spike cao bất thường và Disk I/O ổn định.
Điều hướng series:
Mục lục: Series: Tối ưu hóa Database Vector trên Ubuntu 24.04 với Linux Kernel Tuning
« Phần 5: Tối ưu hóa lưu trữ: Filesystem, Disk Cache và Write-back