GIÁM SÁT HIỆU NĂNG VÀ GỠ LỖI (MONITORING & DEBUGGING) CHO CỤM DGX SPARK

Tác giả dangkhoa 06/04/2026 10 phút đọc

GIÁM SÁT HIỆU NĂNG VÀ GỠ LỖI (MONITORING & DEBUGGING) CHO CỤM DGX SPARK

Trong môi trường tính toán hiệu năng cao (HPC), một lỗi cấu hình nhỏ có thể khiến GPU rơi vào trạng thái "Idle" (nghỉ ngơi), lãng phí hàng nghìn USD mỗi giờ. Giám sát hệ thống NVIDIA DGX Spark không chỉ là xem biểu đồ CPU/RAM thông thường, mà là phân tích sâu vào sự phối hợp giữa nhân CUDA, băng thông NVLink và các Executor của Spark. Bài viết này sẽ hướng dẫn bạn cách xây dựng một hệ thống giám sát toàn diện và các kỹ thuật gỡ lỗi chuyên sâu.

1. Hệ sinh thái Giám sát "Ba lớp" trên DGX

Để quản lý hiệu quả, chúng ta cần chia việc giám sát thành ba tầng dữ liệu tách biệt nhưng liên kết chặt chẽ:

1.1. Tầng Phần cứng: NVIDIA DCGM (Data Center GPU Manager)

DCGM là trái tim của việc giám sát GPU. Nó cung cấp các thông số mà các trình giám sát thông thường không thấy được:

  • GPU Utilization: Tỷ lệ phần trăm nhân CUDA đang tính toán.

  • Memory Copy Utilization: Tốc độ dữ liệu di chuyển vào/ra VRAM.

  • NVLink Throughput: Băng thông trao đổi dữ liệu giữa các GPU.

  • XID Errors: Các lỗi phần cứng hoặc driver nghiêm trọng cần can thiệp ngay.

1.2. Tầng Điều phối: Prometheus & Grafana

Dữ liệu từ DCGM và Spark Metrics được đẩy về Prometheus để lưu trữ và hiển thị trên Grafana.

  • Dashboard: Tạo các biểu đồ trực quan để theo dõi sức khỏe của 8 GPU cùng lúc trên một màn hình duy nhất.

1.3. Tầng Ứng dụng: Spark UI & RAPIDS Dashboard

Spark UI cung cấp cái nhìn về các Stage và Task, trong khi RAPIDS Dashboard (mở rộng của Spark UI) cho biết chính xác phần nào của câu lệnh SQL đang được GPU xử lý và phần nào đang bị đẩy về CPU.


2. Các chỉ số "Sinh tử" cần theo dõi

Để biết hệ thống DGX Spark có đang tối ưu hay không, bạn phải chú ý 3 chỉ số sau:

2.1. GPU Sm Active (Streaming Multiprocessor)

Nếu chỉ số này thấp (< 50%) trong khi Job Spark đang chạy, nghĩa là mã nguồn của bạn chưa đủ độ song song hoặc dữ liệu nạp vào quá chậm (nghẽn I/O).

2.2. GPU Memory Max Used

GPU H100 có 80GB VRAM. Nếu Job Spark thường xuyên chạm ngưỡng 75-78GB, rủi ro lỗi Out of Memory (OOM) là rất cao. Bạn cần điều chỉnh kích thước Batch hoặc phân vùng lại dữ liệu.

2.3. PCIe/NVLink Traffic

Nếu bạn thấy lưu lượng trên PCIe rất cao nhưng NVLink lại thấp, có nghĩa là dữ liệu đang bị luân chuyển giữa CPU và GPU quá nhiều (hiện tượng Fallback). Đây là dấu hiệu cần phải tối ưu lại Code (xem lại Bài 16).


3. Kỹ thuật Gỡ lỗi (Debugging) chuyên sâu trên DGX

Khi Job Spark bị lỗi hoặc chạy chậm bất thường, hãy thực hiện quy trình gỡ lỗi sau:

3.1. Phân tích Stack Trace từ CUDA

Khác với lỗi Python thông thường, lỗi GPU thường xuất hiện dưới dạng

CUDA Error: out of memory hoặc Illegal memory access.

  • Kỹ thuật: Sử dụng biến môi trường

    CUDA_LAUNCH_BLOCKING=1 để bắt buộc GPU chạy tuần tự, giúp xác định chính xác dòng code nào gây ra lỗi.

3.2. Kiểm tra "GpuPlan" trong Spark SQL

Mở Spark UI, vào tab SQL và kiểm tra sơ đồ thực thi (Execution Plan).

  • Dấu hiệu đỏ: Nếu thấy các nút "RowToColumnar" và "ColumnarToRow" xuất hiện liên tục xen kẽ, đó là bằng chứng của việc dữ liệu bị "nhảy" qua lại giữa RAM và VRAM, gây lãng phí thời gian khủng khiếp.

3.3. Sử dụng NVIDIA Nsight Systems

Đây là công cụ "X-quang" cho hệ thống DGX. Nsight Systems cho phép bạn xem dòng thời gian (Timeline) cực kỳ chi tiết: khi nào GPU tính toán, khi nào nó đợi dữ liệu từ ổ cứng, và khi nào nó đợi đồng bộ hóa qua mạng.


4. Xử lý các lỗi phổ biến (Troubleshooting)

4.1. Lỗi "GPU Out of Memory"

  • Nguyên nhân: Kích thước phân vùng (Partition size) quá lớn hoặc dùng quá nhiều Broadcast Join.

  • Khắc phục: Giảm

    spark.sql.files.maxPartitionBytes và kiểm soát chặt chẽ spark.rapids.memory.gpu.allocFraction.

4.2. Job Spark chạy chậm hơn CPU

  • Nguyên nhân: Dữ liệu quá nhỏ (Small files) khiến chi phí khởi tạo GPU (Overhead) lớn hơn thời gian tính toán.

  • Khắc phục: Gom các file nhỏ thành file lớn (Coalesce) trước khi xử lý trên GPU.


5. Tự động hóa cảnh báo (Alerting)

Đừng đợi đến khi hệ thống treo mới kiểm tra. Hãy thiết lập cảnh báo tự động:

  • Nhiệt độ GPU: Cảnh báo nếu vượt quá 85°C (Dấu hiệu hệ thống làm mát có vấn đề).

  • GPU Throttle: Cảnh báo nếu GPU tự giảm xung nhịp do quá nhiệt hoặc quá công suất.

  • XID Error: Gửi tin nhắn Telegram/Slack ngay lập tức cho đội ngũ IT nếu có lỗi phần cứng.


6. Bảng kiểm soát hiệu năng (Performance Checklist)

Thành phầnTrạng thái TốtTrạng thái TệHành động
GPU Utilization> 70%< 20%Tăng số lượng Partition
VRAM Usage60% - 85%< 10% hoặc > 95%Điều chỉnh Batch Size
SQL PlanToàn bộ là GpuOperatorNhiều bước RowToColumnarTối ưu hóa Code PySpark
NVLink TrafficCao (GB/s)Thấp hoặc bằng 0Kiểm tra cấu hình NCCL

7. Kết luận

Giám sát và gỡ lỗi trên NVIDIA DGX Spark là một nghệ thuật cân bằng. Một hệ thống được giám sát tốt không chỉ giúp bạn tránh được các sự cố bất ngờ mà còn cung cấp dữ liệu quý giá để tối ưu hóa chi phí đầu tư. Hãy nhớ: "Bạn không thể tối ưu hóa những gì bạn không thể đo lường."

Tác giả dangkhoa Admin
Bài viết trước NLP VÀ CHUẨN BỊ DỮ LIỆU CHO LLM TRÊN HỆ THỐNG DGX SPARK

NLP VÀ CHUẨN BỊ DỮ LIỆU CHO LLM TRÊN HỆ THỐNG DGX SPARK

Bài viết tiếp theo

XÂY DỰNG ĐỘI NGŨ VÀ VĂN HÓA KỸ THUẬT DỮ LIỆU GPU TRONG DOANH NGHIỆP

XÂY DỰNG ĐỘI NGŨ VÀ VĂN HÓA KỸ THUẬT DỮ LIỆU GPU TRONG DOANH NGHIỆP
Viết bình luận
Thêm bình luận

Bài viết liên quan

Thông báo

0917111899