NFS over RDMA : NFS(tcp)やLustreとの性能比較

RHEL7.4が8月にリリースされ、それまで長らくTech Preview扱いだったNFS over RDMAが正式サポートされることになりました。ということで今回、NFS(tcp)とNFS over RDMAとの性能比較をしてみました。また、NFSではないですが同じくRDMAを使っている共有ファイルシステムということでLustreについて比較したデータも紹介したいと思います。

RDMA (Remote Direct Memory Access)
言葉の通り、ネットワーク越しの別のマシンのメモリに直接アクセスできるというもので、この場合の直接というのは、CPUを介すること無くという意味です。主にInfiniBandで使われることが多く、複数ノードでMPI並列のジョブを実行するの性能に効果を発揮するものです。
参考URL : https://community.mellanox.com/docs/DOC-1963

性能比較(IOR) : NFS(tcp) vs NFS(rdma)

テスト環境

  • NFS領域: 20本のHDD(7.2Krpm)でHardware RAID6(18+2)
  • NFS領域のFilesystem: XFS
  • NFS Client: 1台
  • Network: QDR InfiniBand
  • 測定ツール: IOR-3.0.1(openmpi-3.0.0)

結果

下記のグラフの通りRead/WriteともにNFS(tcp)に比べてNFS(rdma)の方が性能が出ていることがわかります。特にReadに関しては50%ほどの性能差が出ています。

性能比較(dd) : NFS(tcp) vs NFS(rdma)

Read性能に差がかなりの差が出ているので念の為ddでも測定してみました。Writeは差がでないものの、Readは2倍の差が出ました。

  • Write性能 :
$ time dd if=/dev/zero of=25G bs=1M count=25000
NFS(tcp) : 27.977s(937MB/s)
NFS(RDMA) : 27.421s(956MB/s)
  • Read性能 :
$ time cat 25G > /dev/null
NFS(tcp) : 19.998s(1250MB/s)
NFS(RDMA) : 9.792s(2553 MB/s)

性能比較(IOR) : NFS(tcp) vs Lustre

続いてNFS(tcp)とLustre(rdma)の性能比較です。上記とは異なる環境で実施しています。
テスト環境は下記の通りで、実際に1台のサーバーでMDS/OSSを兼ねてLustreを構築することは実運用上はほとんどないかと思いますが、
あくまでテスト用の環境です。

テスト環境

  • NFS領域: 20本のHDD(7.2Krpm)でHardware RAID6(18+2)
  • NFS領域のFilesystem: ZFS
  • LustreのBackend Filesystem: ZFS
  • NFS/Lustre Client: 4台
  • Network: QDR InfiniBand
  • 測定ツール: IOR-3.0.1(openmpi-3.0.0)
  • Lustre version: 2.9.59_32

結果

4台のNFS/Lustre ClientからIORを実行した結果は以下の通りです。
NFS(rdma)との比較同様、同じHardware構成であってもSingle構成のLustreはNFS(tcp)に対してRead/Writeともの大きな性能差を発揮しています。

まとめ

  • IORでは、NFS(rdma0はNFS(tcp)に比べてWriteで10-20%、Readで40-50%程度高い性能をIO性能が得られる
  • 同じくRDMAで通信を行うLustreで測定した場合でも同様にNFS(tcp)に対して高い性能が得られる
  • 基本的にはNFSv3,v4どちらでも使えるが、NFS ServerのNFS領域がZFSで構成されている場合は、IORがエラーとなって実行できず(v3なら問題なし)
    • Server側
      kernel: svcrdma: send: invalid request error (9/0x8a)
    • Client側
      kernel: RPC: rpcrdma_recvcq_process_wc: rep ffff88203bd60540: local length error
      kernel: rpcrdma: connection to 192.168.255.1:20049 on mlx4_0, memreg ‘frwr’, 128 credits, 16 responders

実アプリケーションでの評価も行う必要がありますが、NFS over RDMAをお使いのTakeruで使いたいという場合には担当の営業かエンジニアまで
ご連絡いただければと思います。

Galaxy Reporting機能紹介

概要

Galaxyにはより詳細な情報を得られるレポート機能があります。標準では動作していませんが、本稿ではこのレポート機能について紹介します。

レポート機能について

本機能では、Galaxyの運用上で有用な様々な情報を得ることができます。
Jobs, Histories, Tools, Workflows, Users, Systemといったメニューがあり、Galaxy上のユーザーやジョブ、データ領域などについての情報を得られます。
管理者はこれらのデータをもとにユーザーやディスク容量の管理、ツールやワークフローの改善の計画などを行うことができます。

レポート機能へのアクセス

標準ではポート9001で動作します。
正しく設定し、起動できていると、
http://[IPアドレス]:9001
でアクセスできます。

jobsメニュー

Jobsでは、今現在動作しているジョブの情報、1ヶ月毎に実行されていたジョブ数の確認、エラーや完了できなかったジョブの情報、ユーザーあたり実行していたジョブの数、ツールあたり実行されていたジョブの数、などが確認できます。

[例:実行されていたジョブの月次報告]

[例:各ユーザーのジョブ実行状況確認]

Historiesメニュー

Historiesでは、各ユーザーの持っているHistoryやデータ量の情報が得られます。例えば管理者として、エラー状態のデータを多く持っているユーザーの把握が可能になりますので、積極的に利用者の支援を行うことも可能です。

[例:各ユーザーのHistory数やデータ数確認]

[例:History毎の状況確認]

Toolsメニューについて

Toolsではツールごとにエラーの多いものや利用状況などの情報を得られます。また、実行時間についても平均値や最大値などの情報が得られます。

[例:StateがOKであるツールの上位一覧]

[例:ツール毎の平均実行時間等の情報]

Workflowsメニューについて

Workflowsではworkflowの実行状況についての情報が得られます。

[例:ワークフロー毎の実行回数一覧]

Usersメニューについて

Usersでは、ユーザーがいつ登録されたか、最後にログインしたのはいつなのか、といった情報を得られます。また、ユーザーの持つHistoryの数や、ディスク容量の使用状況も得られます。

[例:ユーザー毎のディスク使用状況一覧]

[例:月次別ユーザー作成状況一覧]

Systemメニューについて

Systemでは、ディスクの使用状況について情報が得られます。
例えば4GB以上のデータを一覧し、データの所有者やどのHistoryで使われているかなどの情報も得られます。

[例:ディスクの使用状況および、サイズの大きいデータ一覧]

まとめ

Galaxyには標準では動作していないものも多いのですが様々な機能があります。
単にGalaxyのユーザーといっても、ダウンロードして試しに動作させている方から、本家Galaxyなどのように複数のセンターを拠点とした巨大なものまであるためのようです。

今回はレポート機能を紹介いたしました。
Galaxyを運用していると出てくる、ディスク容量の把握や予測、効率良く実行できているかの確認、ユーザーの管理などに有用な情報が得られるようになります。

ユーザーや利用状況の情報が多く得られるものですので、実装の際はセキュリティに配慮する必要があります。
本機能に興味がございましたら担当営業やエンジニアに直接お問い合わせください。

Univa Grid Engine : DockerをUGEで管理する

概要

Univa Grid Engine(以下UGE)の8.4.0以降のバージョンではUGEはDockerに対応しています。
とは言っても、正直言ってこれが意味するところはすぐにはピンと来ないかもしれません。
それは、対応するしないにかかわらず、
$ qsub -b y -N DOCK -cwd docker run -it --rm .....
というように、dockerのジョブであることを意識せずに非dockerのジョブと同じようにqsubすれば
ハードウェアリソースの状況を見てジョブをスケジューリングするということが可能である、
ということが一因としてあるのではないかと思います。

今回は、UGEがDockerに対応していることのメリットについて少し挙げてみたいと思います。


UGEがDockerに対応していることのメリット

a) ホスト毎のdockerの有無をリソースとして管理している

計算ノード内でdockerのdaemonが動いているノードと動いていないノードがあった場合、
dockerが動いているノードを実行対象としてくれます。
” # qstat -F docker “と実行してhl:docker=1となっていればそのホストではdockerのジョブの実行が可能です。
hl:docker=0の場合はdockerのジョブは投入されません。

$  qstat -F docker
queuename                      qtype resv/used/tot. np_load  arch          states
---------------------------------------------------------------------------------
all.q@n000                      BIP   0/0/24         0.00     lx-amd64      
              hl:docker=1

b) ホスト毎に保持しているコンテナイメージのリストも管理している

ジョブの中で指定されたコンテナイメージを持っているホストにジョブが投入されるので
pullする時間を待つ必要が無く、効率的にジョブが実行される
(上記はデフォルトの動作で、”-soft” オプションを付けるとイメージを保持しているホストが無かったり、リソースが埋まっていて
すぐにジョブが投入されないような場合には、イメージを持っていないホストにジョブが投入され、docker pullも行われるようになります)

“# qstat -F docker_images”と実行すると各ホストで持っているイメージのリストがカンマ区切りで表示されます。

$  qstat -F docker
queuename                      qtype resv/used/tot. np_load  arch          states
---------------------------------------------------------------------------------
all.q@n000                      BIP   0/0/24         0.00     lx-amd64      
             hl:docker_images=docker.io/bgruening/galaxy-stable:latest,docker.io/nvidia/cuda:latest,docker.io/centos:latest

c) ジョブが完了したらコンテナを削除してくれる

若干地味なメリットかもしれませんし、--rmを付けるのを忘れなければいいという話でもあるかもしれませんが。
ジョブが完了した時だけでなく、何らかの原因でUGEの実行デーモンが落ちてしまったようなケースでも、
sge_container_shepherdというプロセスが残っており、次回デーモン起動時にフォローして削除してくれます。


ジョブの例

例1) centos:latestのコンテナを使って日時とホスト名を返すだけのジョブ

  • ジョブスクリプト
#!/bin/bash

#$ -N DOCKER_DEMO
#$ -l docker
#$ -l docker_images="*centos:latest*"

echo  =="DATE"
date
echo
echo  =="HOSTNAME"
hostname
  • UGEの結果ファイル
==DATE
Mon Oct  9 13:33:04 UTC 2017

==HOSTNAME
2240452d3be2

例2) UGEの-xdオプションを使ってdockerのオプションをUGEに渡すジョブ

  • ジョブスクリプト
#!/bin/bash

#$ -N DOCKER_DEMO
#$ -l docker
#$ -l docker_images="*centos:latest*"
#$ -xd "-v /home:/home" 
#$ -cwd

echo  =="DATE"
date
echo
echo  =="HOSTNAME"
hostname
echo
echo =="HOME"
ls -l /home
  • UGEの結果ファイル : “-v /home:/home”が正しく渡されてホスト機側でls -l /home/と実行したのと同じ出力が得られています。
==DATE
Mon Oct  9 13:49:58 UTC 2017

==HOSTNAME
a2db6ea920ac

==HOME
total 0
drwx------ 4 1000 1000 153 Oct  9 13:47 beowulf
drwx------ 2 1001 1001  62 Oct  9 13:46 takeru
drwx------ 2 1002 1002  62 Oct  9 13:46 voyager

例3) 保持していないコンテナイメージを使って実行するジョブ

  • ジョブスクリプト (ubuntu:latestはどのホストにも無い状態です)
$ qsub -cwd -l docker,docker_images="*ubuntu:latest*" -soft demo.sh

あるいは

$ qsub -b y -cwd -l docker,docker_images="*ubuntu:latest*" -soft cat /etc/os-release

本来なら上記は全てスクリプトに書いた上で $ qsub [スクリプト] としたいところなのですが、
そのように実行すると -softオプションが正しく伝わらずにpullを試みてくれませんので
上記のように実行する必要があります。(調査中)


注意点

dockerのバージョン依存

CentOSでdockerを使う場合、現在は主に3つの選択肢があります。(docker-eeは省略)
– docker-ce(docker-ce.repo) : 10/9現在最新 v17.09
– docker-latest(centos repo) : 10/9現愛最新 1.13.1-23.git28ae36d.el7.centos.x86_64
– docker(centos repo) : 10/9現愛最新 1.12.6-55.gitc4618fb.el7.centos.x86_64
docker-latestとdockerの違いについてはこちらを >> http://rhelblog.redhat.com/2016/10/31/understanding-docker-latest-package/

ただ、docker-ceだとdockerのサービスが動作してる状態でも、hl:docker=1にならず動作しません。
パッケージ名がdocker-engineだった頃からマイナーバージョンの違いによってhl:dockerが0になったり1になったりするので
実際には使用するバージョンで試してみるしかないというところですが、少なくともdocker-ceは動かないと考えていいと思います。

centosのrepositoryから取得するdocker, docker-latestについてはいずれもhl:docker=1になって動作することを確認しています。


まとめ

上記のメリットのところでも挙げた通り、dockerの有無、dockerコンテナイメージの有無をUGE側で管理してくれるため
ユーザーがあまり意識をしなくても適切なノードにジョブを割り振ってくれるということが大きいのではないかと思います。
全ての計算ノードが同じハードウェア/ソフトウェア仕様で、保持しているコンテナも同じというような環境であれば
ジョブスケジューラー側での対応ということに特別な価値は無いのかもしれませんが、
ハードウェア構成の異なる機器でクラスタが構成されていたり、保持しているコンテナイメージもホスト毎に異なっている
といったケースでは、ジョブスケジューラーがDockerに対応しているということのメリットが享受できるはずです。

Skylake XeonのTurbo性能について

先月の話になりますが、IntelのXeonのE5-2600v4の後継の新しいXeonのCPUが発表されました。
今回からネーミングルールがIntel Xeon Scalable Processor Familyのもと
下記のような名称に変更となりました。(Skylakeはコード名で正式名称ではありません)

  • Platinum 81xx
  • Gold 61xx/51xx
  • Silver 41xx
  • Bronze 31xx

具体的にどういった点が変わったかについてはニュース記事などを参照して頂くとして
今回はタイトルの通り、Turbo性能に絞って書いてみたいと思います。

まず、CPUの製品一覧ページの表記が前世代も含めて変更になっていることに注目したいと思います。
これまでは、一覧ページにはベースクロックだけが表示されていたように思いますが
今回の変更からは、Turbo Boost時のMaxクロック周波数が先に表示されるようになっています。
(ブラウザの表示幅によって表示される項目数が変わるようです)

Turbo Boostというのは、熱的に余裕がある場合にCPUのクロック周波数を上げて性能を向上させる機能のことで
BIOSとOSの設定でONにしておけばあとはユーザーは気にせずとも勝手に上げ下げをしてくれます。

上記のURLには定格のクロック周波数とMaxのクロック周波数しか記載がありませんが、
Maxのクロック周波数というのは概ね1コア,2コア程度のみ使用している場合の動作周波数のことで、
Activeなコア数が増えるに従って、徐々に低下していきます。
ただ、全コアがActiveな場合でもクロック周波数は定格周波数まで落ちるということはなく、
定格に比べれば高い周波数で全コアが動作します。
先日確認した限りでは温度エラーのアラートが出るThresholdの温度に至るまではBoostされた周波数で動作していましたので
よほど温度環境が厳しい場合を除けば、基本的にはBoostされた周波数で動作するはずです。

そうなると気になってくるのは、何コアを使用した時にどんな周波数で動作するのかということですが、
Intelの公開されている資料に記載されていて、これについても仕様で決まっています。

E5-2600v4世代との比較のため下記の通りグラフにしてみました。
X軸がCPUの型番、Y軸がクロック周波数(GHz)となっていて、
青い点が各型番のベース周波数、赤い帯がターボ時の周波数の範囲を示しています。
(赤い帯の上端は1core,2coreのみActiveなときのActiveなコアのクロック周波数、
赤い帯の下端は全コア使用した際のクロック周波数です)

型番が多く全ては載せられませんでしたが、Skylake世代のPlatinum/Goldシリーズに関しては、
E5-2600v4世代よりもクロック周波数が高めになっていて、スペック上のターボ性能が向上していることがわかります。
(ベースクロックとMin Turbo Frequencyの間がE5-2600v4世代よりも広い傾向)

特に6154,6134,6128,5122などは、1コアだけ使用している時も全コア使用している時も3.7GHzで動作する仕様になっていて
定格がこれでいいのでは?と思ってしまいます。

具体的なアプリケーションでの性能については別の機会に紹介したいと思いますが、Turboまわりのスペックを比較するだけでも
クロック周波数の性能向上が期待できますね。

Univa Grid Engine : GPGPUのリソース管理(RSMAP)

GPGPUのリソース管理について

CPUの場合、どのコアが使われるのかのスケジューリングはkernelによって行われるため
ジョブスケジューラーは使用コア数・空きコア数などの数を管理するだけでリソースが適切に配分されますが
GPGPUの場合は、ジョブやジョブスケジューラー側でその配分を行う必要があります。
そうしないと複数のジョブが重複して同じGPUで実行されてしまうケースを回避できません。

Univa Grid EngineのRSMAPというリソースタイプを使うと、各ホストのGPGPUの数(搭載GPU数と使用中のGPU数)の管理だけでなく、
各GPGPUに付けられたIDも含めた数の管理が可能となるため、各GPGPUに適切にジョブを振り分けることができます。

demo script

  • 1ジョブあたりGPUを1つ使用するジョブです。”-l gpu=1″
  • マシンには2枚のGPGPUが搭載されています。
  • IDは、SGE_HGR_[リソース名]の変数として出力されますので、アプリケーション側が要求するデバイス指定の書式に合わせる必要があります。
#!/bin/sh
#$ -N TEST_GPU
#$ -l gpu=1

if [ ${SGE_HGR_gpu} = "0" ]; then
GPU="--gpu 0"
fi

if [ ${SGE_HGR_gpu} = "1" ]; then
GPU="--gpu 1"
fi

time python chainer-2.0.2/examples/mnist/train_mnist.py ${GPU} -o out/out_`date +%y%m%d-%H%M%S-%N`

RSMAPが無い場合の挙動

  • ジョブ投入後の状態は下記のようになっています。
  • 下記例では、数の管理はできているため3つ目以降のジョブは待ち状態(qw)となっていますが
    nvidia-smiで確認するとジョブは2つともID:1のGPUに投入されてID:0のGPUが使われていない状態です。
$ qstat
job-ID prior name user state submit/start at queue jclass slots ja-task-ID
------------------------------------------------------------------------------------------------------------------------------------------------
5123 0.50617 TEST_GPU beowulf r 08/02/2017 22:37:06 node.q@demo01 1
5124 0.50617 TEST_GPU beowulf r 08/02/2017 22:37:07 node.q@demo01 1
5125 0.50617 TEST_GPU beowulf qw 08/02/2017 22:37:33 1
5126 0.50617 TEST_GPU beowulf qw 08/02/2017 22:37:34

$ qstat -j 5123 | grep resource
hard resource_list: gpu=1

$ nvidia-smi pmon -o T
#Time gpu pid type sm mem enc dec command
#HH:MM:SS Idx # C/G % % % % name
22:37:45 0 - - - - - - -
22:37:45 1 40725 C 14 4 0 0 python
22:37:45 1 40736 C 58 18 0 0 python
22:37:46 0 - - - - - - -
22:37:46 1 40725 C 36 11 0 0 python
22:37:46 1 40736 C 36 11 0 0 python

RSMAPを用いた場合の挙動

  • 投入スクリプトは上と同じものを使用
  • qstat -j の出力に上の例では無かった”resource_map”行が表示されています。
    ホスト名(demo01)の後ろの(0)と(1) がGrid Engine側で認識しているGPUリソースのIDです。
  • 5159のジョブでID:0のGPGPUが使用されているため、5160ではID:1が使用されて重複なく振り分けられていることがわかります。
  • nvidia-smiの出力を見てもそれぞれのGPUにジョブが振り分けられていることがわかります。
$ qstat -j 5159 |grep resource
hard resource_list: gpu=1
resource map 1: gpu=demo01=(0)
$ qstat -j 5160 |grep resource
hard resource_list: gpu=1
resource map 1: gpu=demo01=(1)

$ nvidia-smi pmon -o T
#Time gpu pid type sm mem enc dec command
#HH:MM:SS Idx # C/G % % % % name
23:10:30 0 46000 C 58 20 0 0 python
23:10:30 1 46117 C 74 24 0 0 python
23:10:31 0 46000 C 77 28 0 0 python
23:10:31 1 46117 C 54 16 0 0 python
23:10:32 0 46000 C 55 19 0 0 python
23:10:32 1 46117 C 56 18 0 0 python

RSMAPその他の活用法

RSMAPはGPGPUやXeon Phiなどのコプロセッサ向けに開発されたものなのでそれらのデバイスを使う際には必要な機能となりますが、
RSMAP自体は、1台のホスト内に搭載されている複数のデバイスそれぞれにIDを付けてリソース管理が行えるというものなので
それ以外にも使いみちがありそうです。

例えば、Dual CPUのサーバーに2本のNVMe SSDが搭載されていて、それぞれがそれぞれのCPUのPCIeバス上にあるという構成の場合、
コアバインディングと組み合わせて近い方のBUSのNVMeをスクラッチ領域として使うことができ、アプリケーションによっては効果がありそうです。

tuned: tuning daemon

tuned について

tunedは、cpu,disk,kernelなどに関する複数のパラメーターを一括して一つのプロファイルとして保存し、
コマンド一発で設定・切り替えを行うことができるツールです。

CentOS7の場合は、tuned のパッケージにはあらかじめいくつかのプロファイルが用意されていて
その中で変更するだけでも性能の違いを実感できますし、その他にカスタムのプロファイルも作成することができます。

デフォルトで用意されているプロファイル

  • デフォルトで用意されているプロファイルには以下の9つがあります。
    また、tuned-profile-xxx といったパッケージ名で用意されたものをインストールすると
    RHELのAtomic Host、Laptop、Oracleといった環境向けの他、spindown-diskといったディスクの省電力向けの
    プロファイルも追加されます。
# tuned-adm list
Available profiles:
- balanced                    - General non-specialized tuned profile
- desktop                     - Optmize for the desktop use-case
- latency-performance         - Optimize for deterministic performance at the cost of increased power consumption
- network-latency             - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
- network-throughput          - Optimize for streaming network throughput.  Generally only necessary on older CPUs or 40G+ networks.
- powersave                   - Optimize for low power consumption
- throughput-performance      - Broadly applicable tuning that provides excellent performance across a variety of common server workloads.  This is the default profile for RHEL7.
- virtual-guest               - Optimize for running inside a virtual guest.
- virtual-host                - Optimize for running KVM guests

設定方法

manページを見ると、throughput-performanceがRHEL7のデフォルトである旨のことが書かれていますが
実際にはbalancedとなっているケースが多いです。

$ tuned-adm active :  現在有効となっているプロファイルが表示されます。

$ tuned-adm profile balanced : 左のケースでは"balanced"というプロファイルに設定されます。
このコマンドを実行するだけで、OSやサービスの再起動の必要なく、すぐに設定が適用されます。

実際に変更されているパラメーター

パッケージに含まれているプロファイルについては、/usr/lib/tuned/[プロファイル名]/tuned.conf に
実際に変更されているパラメーターとその設定値が記載されています。

下記はthroughput-performanceのtuned.confで
cpupower, x86_energy_perf_policyで設定されるようなCPUの電力管理系のプロファイル、
ディスクのread_ahead_kbのサイズ、kernelのパラメーターに関して記載されていることがわかります。

----
[main]
summary=Broadly applicable tuning that provides excellent performance across a variety of common server workloads.  This is the default profile for RHEL7.

[cpu]
governor=performance
energy_perf_bias=performance
min_perf_pct=100

[disk]
readahead=>4096

[sysctl]
kernel.sched_min_granularity_ns = 10000000
kernel.sched_wakeup_granularity_ns = 15000000
vm.dirty_ratio = 40
vm.dirty_background_ratio = 10
vm.swappiness=10
----

性能の比較

結論から言えば、”throughput-performance” がたいていのケースではおすすめです。

ネットワーク、ファイルコピーの速度比較

  • InfiniBand : QDR
  • OS : CentOS7.2
  • Mode : Connected Mode
balanced network-throughput throughput-performance
Netperfでの速度比較 21,656 Mbps 23,909 Mbps 25,528 Mbps
ddで作成した10GBのファイルのコピー時間(NFS越し) 0m12.873s 0m8.616s 0m8.624s

fioでのIOPS測定

  • Device /dev/md0(NVMe x4)
  • Filesystem:XFS
  • Queue Depth : 32
  • numjobs: 1
Random Read(4K) Random Write(4K)
balanced 200569 IOPS 227951 IOPS
latency-performance 268315 IOPS 289342 IOPS

bowtie2 の実行時間比較

  • bowtie2 : 2.3.1
  • index : hg19
  • fastq : SRR067579_1.fastq, SRR067579_2.fastq,
threads throughput-performance
(intel_pstate)
balanced
(intel_pstate)
throughput-performance
(acpi_cpufreq)
8 2479s 2477s 2507s
16 1276s 1290s 1279s
32 679s 690s 676s
56 545s 649s 616s

NAMDの性能比較

  • NAMD : Nightly Build(2017-06-30)
  • data : stmv.namd
  • OS : CentOS 7.3
threads throughput-performance(ns/day) balanced(ns/day)
4 0.0578 0.0555
8 0.1083 0.1077
16 0.2094 0.2086
32 0.4028 0.3931
上の例では、ベンチマークツールで1-4割、アプリケーションレベルで数%から2割程度の性能差が出ています。

もちろん、常時"throughput-performance"に設定しておいても良いのですが、
コマンド一発でプロファイルの切り替えができるという特性を考えると
ジョブ実行前に"throughput-performance"に切り替え、ジョブ完了後に省電力モードに戻す
といった使い方(ジョブスケジューラーへのジョブ投入スクリプト内に追記)はシンプルで
効果もあるかもしれません。(省電力の効果のほどはいずれ確認したいと思いますが)

また、仮にアプリケーションやデータの種類などそれぞれに最適のプロファイルを用意できたとすれば
ジョブスケジューラー側の機能を使ってジョブの名前やその他の値から自動的にプロファイルを選択、
設定して実行させるいった使い方もできるのではないかと思います。

Univa Grid Engineの紹介

TakeruではこれまでデフォルトのジョブスケジューラーとしてOpen SourceのOpen Grid Schedulerを使ってきましたが、昨年からは同じくGrid Engine系ではあるものの有償版のUniva Grid Engine(以下、UGE)をデフォルトのジョブスケジューラーとしています。

主な背景として以下の2つの理由があります。

  • UGEがGPGPUやDockerに対応している点
  • UGEがOpen Grid Schedulerと同じコマンド体系である点

Open Grid SchedulerでもGPGPUのジョブやDockerのジョブを投入・管理することは可能です。
ただ、Open Grid Scheduler自体は2012年から開発が止まっているため、これらのテクノロジーに適切に対応できておらず、余分に手間がかかったり、不十分なリソース配分をしてしまう可能性があります。

今後の投稿では、Univa Grid Engineの以下のような機能について紹介をしていきたいと思います。

  • GPGPU/Xeon Phiなどのコプロセッサー対応
  • Docker 対応
  • JSV(Job Submission Verifier)
  • Job Class
  • その他

Takeru Boostについて

Takeru Boostは、
Takeruをより”Boost”して活用して頂くための情報を中心としたNabe Internationalの技術情報ブログです。
OSやアプリケーションの設定や性能比較、新しいハードウェアの紹介などをしていきたいと思います。

(こちらのブログで紹介した内容は、あくまで特定の環境下での動作を確認したものです。
実際にお使いのTakeruへの適用をお考えの場合は別途ご連絡頂ければと思います。)