Công cụ thống kê quy mô lớn

Bạn có thể sử dụng công cụ Megascale Stats để phân tích hiệu suất giao tiếp giữa các lát của những khối lượng công việc trải rộng trên nhiều lát TPU giao tiếp trên Mạng trung tâm dữ liệu (DCN).

Tất cả các chỉ số xuất hiện trong công cụ Megascale Stats đều được tạo trên cơ sở mỗi TPU.

Nền tảng được hỗ trợ

Công cụ Megascale Stats chỉ được hỗ trợ trên TPU.

Thuật ngữ liên quan đến Nhóm

Công cụ này hiển thị các chỉ số liên quan đến hoạt động giao tiếp giữa các phần TPU, bao gồm những thao tác sau:

• send: Ngắt máy chủ để bắt đầu Truy cập trực tiếp vào bộ nhớ (DMA) và cung cấp một vùng đệm đã điền cho máy chủ để bắt đầu chuyển dữ liệu.
• send-done: Báo hiệu cho máy chủ lưu trữ biết rằng quá trình chuyển dữ liệu đã hoàn tất.
• recv: Cung cấp một vùng đệm trống để máy chủ điền dữ liệu đã truyền.
• recv-done: Báo hiệu cho máy chủ lưu trữ rằng dữ liệu đã được nhận.

Một tập hợp được bắt đầu bằng một thao tác send và hoàn tất bằng thao tác recv-done tương ứng. Quá trình gửi dữ liệu thực tế diễn ra sau khi hoàn tất thao tác gửi. Thao tác send-done xảy ra sau khi dữ liệu đã được gửi. Tương tự, dữ liệu được nhận sau khi thao tác recv hoàn tất. Thao tác recv-done diễn ra sau khi dữ liệu được nhận.

Thành phần giao diện

Công cụ này hiển thị một bảng có các cột sau, với một hàng cho mỗi thao tác tập thể được lập hồ sơ:

• Tên chung của DCN: Do XLA chỉ định.
• Tên thao tác Recv: Tên thao tác recv-done của TPU. Điều này giúp bạn dễ dàng tìm kiếm các thao tác TPU tập thể tương ứng trong Trace Viewer.
• Tên thao tác gửi: Tên thao tác send của TPU.
• Thời gian dự phòng: Được xác định là thời gian độc lập với mạng mà tập thể phải truyền dữ liệu. Đây là chỉ số đo lường thời gian mà nhóm có thể gửi và nhận dữ liệu, không bao gồm các thao tác send, send-done, recv hoặc recv-done. Việc tăng thời gian dự phòng sẽ giảm khả năng làm chậm TPU cho một nhóm. Ví dụ: giả sử bạn có dòng thời gian sau:

Slack time is calculated in this example as:

Slack time = t<sub>1</sub> + t<sub>2</sub> + t<sub>3</sub>

• Thời lượng quan sát: Thời lượng quan sát được cho mỗi tập thể. Độ trễ này được tính là khoảng thời gian từ khi bắt đầu thao tác send đến khi kết thúc thao tác recv-done tương ứng, bao gồm cả thời gian gửi và nhận dữ liệu. Ví dụ: với dòng thời gian sau:

Observed duration is calculated as:

Observed duration = t<sub>send</sub> + t<sub>1</sub> + t<sub>send-done</sub> + t<sub>2</sub> + t<sub>recv</sub> + t<sub>3</sub> + t<sub>recv-done</sub>

• Thời lượng tạm dừng: Khoảng thời gian mà TPU tạm dừng tập thể. Đây là tổng thời gian mà tập hợp dành cho các thao tác send, send-done, recv và recv-done, không bao gồm thời gian truyền dữ liệu. Ví dụ: với dòng thời gian sau:

Stall duration is calculated in this example as:

Stall duration = t<sub>send</sub> + t<sub>send-done</sub> + t<sub>recv</sub> + t<sub>recv-done</sub>

• Số lần diễn ra: Tổng số lần một nhóm được bắt đầu và hoàn thành trong thời gian hoạt động của một hồ sơ. Thao tác send và thao tác recv-done tương ứng phải diễn ra trong thời lượng hồ sơ để được đưa vào chỉ số này.
• Tổng thời gian chờ tổng hợp: Tổng thời gian mà một nhóm chờ một TPU trong thời gian lập hồ sơ. Tổng số lần tạm dừng tổng hợp được tính như sau:
  • Tổng thời gian chờ = thời gian chờ * số lần
• Kích thước dữ liệu được truyền: Lượng dữ liệu được truyền qua mạng cho tập hợp, được tính dựa trên hình dạng của thao tác XLA.
• Băng thông cần thiết: Băng thông cần thiết để truyền dữ liệu trong khoảng thời gian dự phòng đã cung cấp. Bạn có thể sử dụng chỉ số này để xem số lượng nhóm đang cạnh tranh băng thông mạng trong thời gian của hồ sơ. Băng thông bắt buộc được tính như sau:
  • Băng thông cần thiết = kích thước dữ liệu được truyền / thời gian dự phòng

Phân tích dữ liệu của công cụ Megascale Stats

Cách phân tích dữ liệu có trong công cụ này:

1. Sắp xếp bảng theo Aggregated Total Stall theo thứ tự giảm dần.
2. Xác định tên tập thể DCN có Aggregated Total Stall cao nhất. Giá trị cao hơn đáng kể so với các giá trị khác có thể cho thấy một điểm tắc nghẽn.
3. Nhân Required Bandwidth của nhóm DCN với số lượng lõi (ví dụ: 8 mỗi máy chủ TPU phiên bản 4). Nếu giá trị này lớn hơn băng thông mạng tối đa của TPU, thì có thể cho thấy tình trạng tắc nghẽn mạng. Hãy thử thay đổi cơ chế phân đoạn để giảm băng thông cần thiết.
4. Tạo một kết xuất HLO để kiểm tra các vấn đề về trình biên dịch. Việc mở rộng các thao tác send và recv-done có thể cho phép lập lịch nhiều thao tác HLO chồng chéo hơn và giảm thời gian tạm dừng TPU.
5. Kiểm tra thời lượng của các thao tác recv-done trong Trace Viewer cho tập hợp có tổng thời gian chờ tối đa. Thời gian truyền cao có thể cho thấy tình trạng tắc nghẽn băng thông vì các thao tác recv-done thường bị chặn trên mạng.
6. Nếu thời lượng của các thao tác recv-done không quá cao so với thời gian dự phòng, thì có thể đã xảy ra vấn đề về phần cứng.