Compiler: gcc 4.8.5
Benchmark: himenoBMTxp
Size: L

[TABLE=22]

Haswell Refreshアーキテクチャー・プロセッサーCPU「Core i3-4170 」のベンチマーク記録を追加しました。コンパイラーは、gcc 4.8.5を利用しました。

2015年5月に弊社でも販売を開始しましたIntel Xeon D搭載システムを姫野ベンチマークにて評価しました。

【環境】

①シングルスレッド評価

姫野ベンチ（himenoBMTxp_l）を各コンパイラにてコンパイルし測定しました。

以前測定したIntel Xeon E5-2687W(3.1GHz)のスコア3525 MFLOPSと比較しても非常に高いスコアといえます。姫野ベンチはメモリに依存しているベンチマークですので、メモリがDDR3からDDR4になったことでスコアが大きく延びていると考えられます。また、インテルコンパイラではgccの約1.8倍のスコアとなりましたのでインテルコンパイラの使用が非常に有効といえます。

②マルチスレッド評価

コンパイラとMPIライブラリを組み合わせて姫野ベンチ並列バージョン（cc_himenobmt_mpi）をコンパイルし測定しました。

両組み合わせにおいてシングルスレッドでは前項目のシングルスレッド評価と同等の信頼できるスコアが確認できます。8スレッドでは12600～12900 MFLOPS程度、「HyperThreading on」の16スレッドでも11300～12300 MFLOPS程度と12000 MFLOPS付近にてスコアが収束しているように見えます。

確認の為、「icc + Intel MPI Library」にて2~4スレッドの測定も行いました。

2スレッドではリニアに数値が倍増しているといえますが、3スレッドで既に収束範囲に到達しています。これも、姫野ベンチがメモリに依存しているベンチマークであるため、3スレッド以降ではメモリ帯域を使い切ってしまい収束範囲に達してからはスコアが伸びなくなったと考えられます。

【総評】

Supermicro X10SDV-TLN4Fに搭載のIntel Xeon D-1540は組込CPUに分類されますが、シングルスレッドのスコアでは、2世代前のワークステーション用CPUに迫るスコアを記録しました。マルチコア（8コア）CPUですので、メモリ帯域を多く使用しないプログラムであればマルチスレッドで性能が発揮されると期待できます。

SSD 8台でRAID0のシステムの評価中、ベンチマークしていますがこれは相当速いです。

・ハードウェア
RAIDカード：ARC-1883x　外部12G/s　2ポート
SSD：Samsung　MZ-7KE512B x8台
SAS JBOD (12G/sケーブルで接続)

・ベンチマーク環境
CrystalDiskMark 3.0.3 x64で4000MBを5回
Windows Server 2008 R2 SP1

———————————————————————–
RAID0 StripeSize 64KB

Sequential Read : 3107.352 MB/s
Sequential Write : 3748.819 MB/s
Random Read 512KB : 1610.638 MB/s
Random Write 512KB : 3402.341 MB/s
Random Read 4KB (QD=1) : 36.670 MB/s [ 8952.5 IOPS]
Random Write 4KB (QD=1) : 171.722 MB/s [ 41924.4 IOPS]
Random Read 4KB (QD=32) : 292.501 MB/s [ 71411.4 IOPS]
Random Write 4KB (QD=32) : 258.604 MB/s [ 63135.8 IOPS]
———————————————————————–

NFS/RDMAは、Infinibandの高速ネットワーク上で、NFSサーバ－NFSクライアント間において、メモリデータの遠隔転送(RDMA = Remote Direct Memory Access)を行う技術です。

InfiniBandアダプタ/スイッチを利用すると、高速ネットワークを構築することが出来ます。
さらに、RDMA (Remote Direct Memory Access) も利用することで、高速ネットワーク上のコンピュータ間でデータのメモリー間転送を行うことが出来ます。RDMAではCPU の介入がほとんどなく、コンピュータ間でメモリデータの遠隔転送が出来るそうです。これらをNFSで利用すると、データ転送速度アップを期待出来ます。

NFS/RDMAを利用する場合/利用しない場合で、どの程度違いがあるのか検証を行いました。

NFS/RDMA動作には、カーネルモジュールが必要で、モジュールsvcrdmaとxprtrdmaは、Kernel 2.6.25以降から共にマージされています。Infinibandドライバをインストールして、必要な設定を行えば、NFS/RDMAを利用できます。今回、OFEDのホットスタック(バージョン3.12-1)を使用しました。

検証環境

• HCA：Mellanox MHQ19B-XTR (QDR)
• CPU：Xeon E5-2630V2 1つ搭載
• マザーボード：Supermicro X9DRi-F
• OS：CentOS6.4 x86_64
• Infinibandドライバ：
  OFED-3.12-1
• NFSサーバのシステムメモリ：64GB(64GBメモリ内1GBをシステムで利用し、残りはtmpfsで使用。tmpfsを/nfsへマウント。)
• NFSクライアントのシステムメモリ：1GB
• HCAポートにIPアドレスを設定
  NFSサーバIPアドレス 192.168.1.1
  NFSクライアン IPアドレス 192.168.1.2
• NFSサーバ－NFSクライアント間は一対一で接続しました。

設定

1. OFEDをNFSサーバとNFSクライアントへインストール
2. NFSサーバの設定

# mount -t tmpfs -o size=63g tmpfs /nfs # vi /etc/fstab ～ /nfs 192.168.1.0/24(rw,sync,no_root_squash,fsid=0,insecure) ～

3. NFSサーバ側RDMAモジュールの動作開始

# modprobe svcrdma # service nfs start # echo rdma 20049 > /proc/fs/nfsd/portlist

4. NFSクライアント側RDMAモジュールの動作開始とマウント

# modprobe xportrdma # mount -o rdma,port=20049 192.168.1.1:/nfs /mnt

テスト方法

• iozoneを利用し、2GBファイル(システムメモリの2倍サイズファイル)の書き出し/読み出し速度を計測。

# iozone -Ac -s 2g -f /mnt/file

なお、NFSサーバで、/nfsへマウントしたtmpfsに対して、iozoneにより同じファイルサイズで速度を計測するとWrite 3GB/sec程度、Read 6GB/sec程度でした。

結果

レコードサイズ4k〜16MBまでの結果の平均値をグラフ化しました。(標準偏差はNFS/RDMA使用時、未使用時ともにWriteで90くらい、Readで25くらい。)

Writeにはあまり違いがありませんが、Readでは倍以上の差を得られました。
Writeでも、差がもっと出て欲しいのですが、NFS設定ファイルは初期設定のままでしたので、チューニングすることにより、結果が変わるかもしれません。

当社のサーバ/ワークステーション製品の多くで、IPMI2.0準拠のマネージメントコントローラを利用出来ます。

マネージメントコントローラはOSとは独立に動作し、CPU温度、ファン回転数の監視したり、リモートでサーバの電源制御などができ、専用LANポート（もしくは、共用LANポート）を介して利用します。

専用LANポートには、サーバ背面のI/Oシールドに”監視”と表記されたシールが貼っています。(ただし、シールを貼ることが出来ない製品には貼っておりません。)

マネージメントコントローラを利用するには、動的もしくは静的にIPアドレスを割り当てて利用します。また、各種IPMIソフトウェアに対応していますので、ソフトウェア(※1)をインストールすれば、ターミナルからも利用出来ます。

◎ ターミナルで状態を確認

◎ イベントをsyslogへ出力

ipmievdを用いるとipmiのイベント出力をsyslogにも出力することが出来ます。

テストイベントを発生させ、syslogへの出力を確認します。

※1 CentOS6.5でのツールのインストールを例として紹介します。

A OpenIPMIとOpenIPMI-toolsをインストールします。

B ipmiを起動させます。

C ipmiの起動を確認します。

D ipmievdを起動させます。

E ipmievdの動作を確認します。

F ipmiとipmievdをOS起動時に開始するように設定します。