MCP kết nối database: vì sao ổ NVMe rút ngắn thời gian phản hồi

Trả lời nhanh: Một lượt gọi MCP tới database gồm bốn khâu: nhận yêu cầu, chạy truy vấn, đọc dữ liệu từ bộ nhớ đệm hoặc ổ đĩa, trả kết quả. Khâu tốn thời gian nhất gần như luôn là đọc dữ liệu khi nó không nằm sẵn trong bộ nhớ đệm. Khi đó tốc độ ổ quyết định trực tiếp. Hai cách rút ngắn theo thứ tự hiệu quả: đánh chỉ mục đúng để giảm lượng dữ liệu phải đọc, và dùng ổ NVMe để mỗi lần đọc nhanh hơn.

Agent hỏi dữ liệu, chờ hai giây mới có câu trả lời. Hai giây đó không nằm ở mô hình mà nằm ở chỗ database phải lục tìm trên ổ đĩa.

Đường đi của một lượt gọi

Bốn khâu, và thời gian phân bổ rất lệch:

1. Nhận yêu cầu: gần như tức thì nếu MCP server nằm cùng máy.
2. Phân tích và lập kế hoạch truy vấn: vài mili giây.
3. Đọc dữ liệu: từ vài mili giây nếu có trong bộ nhớ đệm, tới hàng trăm mili giây nếu phải quét ổ.
4. Trả kết quả: nhanh, trừ khi trả về quá nhiều dòng.

Khâu ba chiếm phần lớn. Và nó phụ thuộc hai thứ: lượng dữ liệu phải đọc, và tốc độ đọc mỗi đơn vị.

Giảm lượng dữ liệu phải đọc

Đây là việc phải làm trước và không tốn đồng nào. Chạy kiểm tra kế hoạch truy vấn:

EXPLAIN ANALYZE SELECT ... ;

Thấy quét toàn bảng nghĩa là database đang đọc cả triệu dòng để lấy vài dòng. Thêm chỉ mục cho cột dùng trong điều kiện lọc thường rút thời gian từ vài trăm mili giây xuống vài mili giây.

Ngoài ra hãy để MCP server chỉ lấy cột thật sự cần thay vì lấy tất cả, và luôn đặt giới hạn số dòng trả về. Agent không cần mười nghìn dòng, nó cần vài chục dòng đúng.

Tăng tốc mỗi lần đọc

Sau khi đã tối ưu truy vấn, phần còn lại là tốc độ ổ. Database đọc kiểu ngẫu nhiên: nhảy tới nhiều vị trí khác nhau, mỗi lần lấy một khối nhỏ. Đây đúng là chỗ ổ NVMe cho IOPS gấp nhiều lần ổ SATA.

Đặc thù của agent làm khác biệt này lớn hơn bình thường: nó không gọi một lần mà gọi liên tiếp hàng chục lần trong một tác vụ. Tiết kiệm năm mươi mili giây mỗi lượt, nhân hai mươi lượt, là một giây cho mỗi vòng lặp. Nhân với vài chục vòng thì thành khác biệt rất dễ cảm nhận.

Đường đi của một lượt gọi, và chặng nào tốn nhất

Giảm lượng dữ liệu phải đọc, việc hiệu quả nhất

# Xem truy van nao dang cham va chay bao nhieu lan
psql -c "SELECT calls, round(mean_exec_time::numeric,1) AS tb_ms, left(query,70)
         FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;"

# Ty le doc trung bo nho dem, duoi 95% la dang xuong o dia nhieu
psql -c "SELECT round(100.0*sum(blks_hit)/nullif(sum(blks_hit)+sum(blks_read),0),2) AS ty_le_trung
         FROM pg_stat_database;"

# Chi muc nao khong ai dung, chi ton dung luong va lam cham lenh ghi
psql -c "SELECT relname, indexrelname, idx_scan FROM pg_stat_user_indexes
         WHERE idx_scan = 0 ORDER BY relname;"

Cách đọc: tỷ lệ đọc trúng bộ nhớ đệm dưới 95% nghĩa là cơ sở dữ liệu thường xuyên phải xuống ổ đĩa, và đây chính là lúc tốc độ ổ tạo khác biệt lớn. Trên 99% thì ổ đĩa gần như không ảnh hưởng, và đổi ổ nhanh hơn cũng không thay đổi gì.

Thứ tự tối ưu đúng

1. Chỉ trả về cột và số dòng thật sự cần. Rẻ nhất và tác dụng lớn nhất.
2. Thêm chỉ mục cho các truy vấn hay chạy, và xóa chỉ mục không ai dùng.
3. Tăng bộ nhớ để dữ liệu nóng nằm sẵn trong bộ nhớ đệm.
4. Đổi sang ổ NVMe khi phần dữ liệu vẫn phải đọc từ ổ còn lớn.
5. Đặt máy chủ gần người dùng, nếu độ trễ mạng đang chiếm phần lớn.

Làm ngược thứ tự này, ví dụ nâng cấu hình máy trước khi sửa truy vấn, là cách tốn tiền mà cải thiện ít.

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

Vì sao MCP gọi database chậm?

Thường vì truy vấn thiếu chỉ mục nên phải quét nhiều dữ liệu, hoặc vì dữ liệu không nằm trong bộ nhớ đệm nên phải đọc từ ổ đĩa.

Nên tối ưu chỉ mục hay nâng ổ trước?

Chỉ mục trước vì miễn phí và thường hiệu quả hơn. Sau khi truy vấn đã gọn mà vẫn chậm thì tốc độ ổ mới là yếu tố quyết định.

Bộ nhớ đệm database nên đặt bao nhiêu?

Với máy chuyên chạy database, khoảng 60 tới 70 phần trăm RAM. Dữ liệu nóng nằm trong RAM thì gần như không phải chạm ổ khi đọc.

Có nên giới hạn số dòng MCP trả về không?

Nên. Agent chỉ cần vài chục dòng đúng chứ không cần hàng nghìn dòng, và trả ít dòng cũng giảm thời gian truyền lẫn chi phí gọi mô hình.

Bài viết liên quan

• VPS ổ Enterprise U.2 NVMe RAID 10 tại TND
• VPS cho vibe coder
• Cloud VPS lưu trữ cụm Ceph