Đối với điểm chuẩn này, chúng tôi đã sử dụng kết quả của cấu hình lớn (hai máy chủ PowerEdge R750 được kết nối với bốn mảng ME4084) với mô-đun HDMD tùy chọn (hai máy chủ PowerEdge R750) sử dụng một mảng ME4024 duy nhất từ ​​bản phát hành vào tháng 11 năm 2021. Kể từ đó, tùy chọn Mô-đun HDMD (một cặp máy chủ PowerEdge R750 có một hoặc nhiều mảng ME4024) đã được thay thế bằng các cặp máy chủ NVMe xử lý siêu dữ liệu. Phần này cung cấp thông tin điểm chuẩn ME4024 làm tài liệu tham khảo, nhưng có phần hiệu suất mới cho HDMD NVMe. Bảng 2  và  Bảng 3  lần lượt liệt kê các phiên bản phần mềm được sử dụng trên máy chủ và máy khách.

Hiệu suất IOzone tuần tự N máy khách đến N tệp

Hiệu suất của N máy khách liên tiếp đến N tệp được đo bằng IOzone phiên bản 3.492. Các bài kiểm tra mà chúng tôi đã chạy đa dạng từ một luồng đơn lẻ cho đến 1024 luồng.

Chúng tôi đã sử dụng các tệp đủ lớn để giảm thiểu tác động của bộ nhớ đệm, với tổng kích thước dữ liệu là 8 TiB, nhiều hơn gấp đôi tổng kích thước bộ nhớ của máy chủ và máy khách. Lưu ý rằng GPFS đặt nhóm trang có thể điều chỉnh thành dung lượng bộ nhớ tối đa được sử dụng để lưu vào bộ đệm ẩn dữ liệu, bất kể dung lượng RAM được cài đặt và dung lượng trống (được đặt thành 32 GiB trên máy khách và 96 GiB trên máy chủ để cho phép tối ưu hóa I/O). Trong khi các giải pháp HPC khác của Dell sử dụng kích thước khối cho các lần truyền tuần tự lớn là 1 MiB, thì GPFS được định dạng với kích thước khối là 8 MiB; do đó, hãy sử dụng giá trị đó hoặc bội số của nó trên điểm chuẩn để có hiệu suất tối ưu. Kích thước khối 8 MiB có vẻ quá lớn và lãng phí quá nhiều dung lượng khi sử dụng các tệp nhỏ, nhưng GPFS sử dụng phân bổ khối con để ngăn tình trạng này. Trong cấu hình hiện tại, mỗi khối được chia thành 512 khối con, mỗi khối 16 KiB. 

Các lệnh sau được sử dụng để chạy điểm chuẩn cho các thao tác ghi và đọc, trong đó  Chủ đề  là biến có số lượng luồng được sử dụng (1 đến 512 tăng dần theo lũy thừa của 2) và  danh sách luồng  là tệp phân bổ từng luồng trên một nút khác , sử dụng phương pháp vòng tròn để trải chúng đồng nhất trên 16 nút điện toán. Biến  FileSize  có kết quả là 8192 (GiB)/Chủ đề để chia đều tổng kích thước dữ liệu cho tất cả các luồng được sử dụng. Kích thước truyền 16 MiB đã được sử dụng cho đặc tính hiệu suất này.

./iozone -i0 -c -e -w -r 16M -s ${FileSize}G -t $Threads -+n -+m ./threadlist

./iozone -i1 -c -e -w -r 16M -s ${FileSize}G -t $Threads -+n -+m ./threadlist

Hình 17.     Hiệu suất tuần tự từ N đến N

Từ kết quả, chúng tôi thấy rằng hiệu suất đọc cao hơn so với bản phát hành trước với số lượng luồng thấp (>10%) đạt mức cao nhất ở bốn luồng, cao hơn gần 18% so với pixstor 5. Sau đó, nó chỉ cao hơn một chút so với những gì quan sát được với pixstor 5, với hiệu suất giảm nhẹ ở 1024 luồng. Hiệu suất ghi gần như giống nhau đối với một và hai luồng. Ở bốn luồng, nó cao hơn 24% so với pixstor 5. Đã đạt đến mức ổn định và duy trì cao hơn khoảng 20% ​​so với pixstor 5 cho đến khi đạt đến số lượng luồng tối đa mà IOzone cho phép và hiệu suất giảm nhẹ ở 1024 luồng (vì chỉ có 640 luồng lõi trong các nút, kết quả này có thể là do chi phí đăng ký quá mức). Lưu ý rằng hiệu suất đọc cao nhất là 23 GB/giây ở 32 luồng và hiệu suất ghi cao nhất là 20,5 đạt được ở 64 luồng. Sự cải thiện đáng kể về hiệu suất ghi (so với pixstor 5) là một kết quả ngoài mong đợi nhưng tốt. Kết quả này có thể là do các cải tiến Block IO trong Red Hat Enterprise Linux 8.x hoặc các cải tiến về phần cứng và trình điều khiển cho HBA335e mới (bộ điều hợp PCIe 4). Do tổng kích thước dữ liệu là 8 TiB, không thể do bất kỳ hiệu ứng bộ đệm nào từ máy chủ, máy khách hoặc sự kết hợp của cả hai.

Hãy nhớ rằng đối với GPFS, phương thức hoạt động ưa thích bị phân tán và giải pháp được định dạng để sử dụng nó. Trong chế độ này, các khối được phân bổ ngay sau khi tạo hệ thống tệp theo kiểu giả ngẫu nhiên, trải rộng dữ liệu trên toàn bộ bề mặt của mỗi ổ cứng. Mặc dù nhược điểm rõ ràng là hiệu suất tối đa ban đầu thấp hơn, nhưng hiệu suất vẫn không đổi bất kể bao nhiêu dung lượng được sử dụng trên hệ thống tệp. Kết quả này trái ngược với các hệ thống tệp song song khác ban đầu sử dụng các rãnh bên ngoài có thể chứa nhiều dữ liệu hơn (các cung) trên mỗi vòng quay của đĩa. Do đó, các hệ thống tệp này có hiệu suất cao nhất có thể mà ổ cứng có thể cung cấp, nhưng khi hệ thống sử dụng nhiều dung lượng hơn, các rãnh bên trong có ít dữ liệu hơn trên mỗi vòng quay của ổ cứng sẽ được sử dụng, dẫn đến giảm hiệu suất.

Hiệu suất IOR tuần tự N máy khách thành 1 tệp

Hiệu suất của N máy khách tuần tự cho một tệp được chia sẻ duy nhất được đo bằng IOR phiên bản 3.3.0, với  OpenMPI  v4.1.2A1 để chạy điểm chuẩn trên 16 nút điện toán. Các thử nghiệm mà chúng tôi đã chạy đa dạng từ một luồng đơn lên đến 512 luồng vì không có đủ lõi cho 1024 luồng (16 máy khách có tổng cộng 16 x2 x 20 = 640 lõi). Ngoài ra, chi phí đăng ký quá mức dường như ảnh hưởng đến kết quả IOzone ở 1024 luồng.

Hiệu ứng bộ nhớ đệm được giảm thiểu bằng cách đặt giá trị có thể điều chỉnh nhóm trang GPFS thành 32 GiB trên máy khách và 96 GiB trên máy chủ, đồng thời sử dụng tổng kích thước dữ liệu là 8 TiB, nhiều hơn gấp đôi kích thước RAM từ máy chủ và máy khách cộng lại. Kích thước truyền 16 MiB đã được sử dụng cho đặc tính hiệu suất này. Để có giải thích đầy đủ, hãy xem  Hiệu suất IOzone tuần tự N máy khách đến N tệp . 

Các lệnh sau được sử dụng để chạy điểm chuẩn, trong đó  Chủ đề  là số lượng luồng được sử dụng (1 đến 512 tăng dần theo lũy thừa của 2) và  my_hosts.$Threads  là tệp tương ứng phân bổ mỗi luồng trên một nút khác nhau, sử dụng vòng -robin để phân tán chúng một cách đồng nhất trên 16 nút điện toán. Biến  FileSize  có kết quả là 8192 (GiB)/Chủ đề để chia đều tổng kích thước dữ liệu cho tất cả các luồng được sử dụng. 

mpirun –allow-run-as-root -np $Threads –hostfile my_hosts.$Threads –mca btl_openib_allow_ib 1 –mca pml ^ucx –oversubscribe –prefix /usr/mpi/gcc/openmpi-4.1.2a1 /usr/local/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/ior/tst.file -w -s 1 -t 16m -b ${FileSize}G 

mpirun –allow-run-as-root -np $Threads –hostfile my_hosts.$Threads –mca btl_openib_allow_ib 1 –mca pml ^ucx –oversubscribe –prefix /usr/mpi/gcc/openmpi-4.1.2a1 /usr/local/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/ior/tst.file -r -s 1 -t 16m -b ${FileSize}G

Hình 18.     Hiệu suất tuần tự từ N đến 1

Từ kết quả, chúng tôi thấy rằng pixstor 6 có hiệu suất đọc tương tự và hiệu suất ghi tốt hơn so với kết quả thấy trong pixstor 5. Tuy nhiên, trong trường hợp này, hiệu suất tăng nhanh đối với các thao tác đọc với số lượng máy khách được sử dụng. Sau đó, nó đạt đến trạng thái ổn định có thể bán ổn định đối với các thao tác đọc và ổn định đối với các thao tác ghi cho đến số lượng luồng tối đa được sử dụng trong bài kiểm tra này. Do đó, hiệu suất tuần tự tệp lớn, chia sẻ đơn ổn định ngay cả đối với 512 luồng đồng thời. Lưu ý rằng hiệu suất đọc tối đa là 23,8 GB/giây ở 16 luồng. Hơn nữa, hiệu suất đọc giảm từ giá trị đó cho đến khi đạt mức ổn định ở khoảng 21 GB/giây, với mức giảm tạm thời dưới 21 GB/giây ở 64 và 128 luồng. Tương tự, lưu ý rằng hiệu suất ghi tối đa là 20.