Website được thiết kế tối ưu cho thành viên chính thức. Hãy Đăng nhập hoặc Đăng ký để truy cập đầy đủ nội dung và chức năng. Nội dung bạn cần không thấy trên website, có thể do bạn chưa đăng nhập. Nếu là thành viên của website, bạn cũng có thể yêu cầu trong nhóm Zalo "HI.AI Members" các nội dung bạn quan tâm.

Bài 5. Hết RAM khi xử lý tài liệu lớn

1. Đặt vấn đề

RAM hệ thống rất quan trọng khi xử lý tài liệu lớn, xây dựng RAG, tạo chunk, embedding, FAISS index, đọc file PDF/Word, chạy batch hoặc xử lý nhiều file cùng lúc. Dù máy chủ có RAM lớn, nếu pipeline xử lý tài liệu không tối ưu, vẫn có thể hết RAM hoặc dùng swap nhiều, làm hệ thống chậm và mất ổn định.

Trong bệnh viện, kho tài liệu có thể rất lớn: quy trình, quy định, biểu mẫu, báo cáo, tài liệu đào tạo, văn bản pháp luật, PDF scan, file Word, bảng Excel. Vì vậy, lỗi hết RAM khi xử lý dữ liệu cần được dự phòng từ đầu.

2. Dấu hiệu nhận biết

  • Hệ thống chậm đột ngột.
  • htop báo RAM gần đầy.
  • free -h báo swap tăng.
  • Process Python bị kill.
  • FAISS build lỗi.
  • Embedding batch dừng.
  • API timeout khi xử lý file lớn.
  • SSH vẫn vào được nhưng máy phản hồi chậm.
  • Log có thông báo out of memory.

3. Kiểm tra RAM

Dùng:

 
free -h
 

Dùng:

 
htop
 

Xem log OOM:

 
dmesg | grep -i "out of memory"
 

hoặc:

 
journalctl -k | grep -i "killed process"
 

4. Nguyên nhân thường gặp

4.1. Xử lý quá nhiều file cùng lúc

Batch đọc hàng nghìn file vào RAM.

4.2. PDF quá lớn hoặc scan

Trích xuất text/OCR có thể rất nặng.

4.3. Chunk và embedding giữ toàn bộ trong RAM

Pipeline không streaming mà lưu tất cả vào list lớn.

4.4. FAISS index lớn

Index lớn cần nhiều RAM khi build.

4.5. Nhiều process chạy song song

Embedding, API, Ollama, database, backup cùng chạy.

4.6. Model chạy CPU/offload

Model lớn dùng RAM hệ thống nhiều.

5. Cách xử lý nhanh

  • Dừng batch đang chạy.
  • Kiểm tra process chiếm RAM trong htop.
  • Không kill database hoặc service quan trọng nếu chưa xác định.
  • Giảm số worker.
  • Chia nhỏ batch.
  • Tạm dừng embedding.
  • Kiểm tra swap.
  • Nếu hệ thống quá chậm, khởi động lại service liên quan sau khi ghi nhận log.

6. Thiết kế pipeline tiết kiệm RAM

Nên:

  • Xử lý từng file.
  • Ghi kết quả trung gian ra disk.
  • Không giữ toàn bộ tài liệu trong RAM.
  • Chia batch embedding nhỏ.
  • Commit metadata theo lô.
  • Build index theo phiên bản.
  • Dọn file tạm.
  • Giới hạn số worker.

Pipeline tốt phải chịu được kho tài liệu lớn.

7. Tách xử lý nền khỏi giờ cao điểm

Không nên chạy xử lý tài liệu lớn trong giờ nhiều người dùng chatbot. Nên lập lịch:

  • Ban đêm.
  • Cuối tuần.
  • Thời điểm ít request.
  • Khi GPU/CPU/RAM rảnh.

Nếu phải chạy ban ngày, cần giới hạn tài nguyên.

8. Xử lý file lớn

Với file rất lớn:

  • Tách chương/mục.
  • Chuyển sang text trước.
  • Kiểm tra lỗi định dạng.
  • Tránh OCR hàng loạt nếu không cần.
  • Loại file trùng.
  • Không đưa file scan không đọc được vào RAG nếu chưa xử lý.

9. Theo dõi và cảnh báo

Nên có cảnh báo:

  • RAM sử dụng trên 80%.
  • Swap bắt đầu tăng.
  • Process embedding chạy quá lâu.
  • OOM xuất hiện.
  • Batch lỗi.
  • File tạm tăng bất thường.

10. Phòng ngừa

Cần:

  • Thiết kế batch nhỏ.
  • Test trên tập nhỏ trước.
  • Ghi log file đang xử lý.
  • Có resume khi lỗi.
  • Không xử lý toàn bộ kho tài liệu một lần nếu chưa thử.
  • Đảm bảo backup dữ liệu trước rebuild lớn.
  • Tài liệu hóa cấu hình batch.

11. Kết luận

Hết RAM khi xử lý tài liệu lớn là lỗi thường gặp trong xây dựng RAG. Nguyên nhân thường do pipeline giữ quá nhiều dữ liệu trong bộ nhớ, xử lý file lớn hàng loạt, FAISS index lớn hoặc nhiều process chạy đồng thời. Giải pháp là xử lý theo lô, streaming dữ liệu, giới hạn worker, chạy ngoài giờ cao điểm và theo dõi RAM/swap. Với bệnh viện, pipeline dữ liệu ổn định quan trọng không kém model tốt.