お問い合わせ | 導入事例 | システム構築 | HPC計算機 | マスターサーバ | オプション | OS/開発環境 | アプリケーション| 構成例 | サポート | FAQ | ベンチ | 技術情報 | 購入

基礎情報

計算機本体

ストレージ

ネットワーク

OS環境

開発環境

ジョブ管理

システム管理

設置環境


プロセッサ番号一覧へ

Linpack HPL定点観測テストへ

Quad-Core世代におけるLSFの有効性

多くのコアを持つ計算機の共同利用では、メモリ資源の取り合いが発生しやすい

Xeon 8CPUコアと32GBメモリを搭載した計算機が開発環境を含めて200万円以下で導入可能となっています。多くのコアが動作するマシンを共同利用する場合、適正にメモリ資源の管理を行っていないと、全体での利用メモリの合計が搭載メモリを越えてしまい、突然メモリスワップが発生してしまう危険性があります。

四角四面のメモリ資源管理では、折角の大容量メモリが活かせない

しかしメモリスワップを嫌うあまり、各CPUコアに均等にメモリを割り振るような四角張った管理にすると、こんどは折角搭載している大容量メモリを大きく使った大規模計算が行いにくくなります。

大規模計算を流すためには面倒な手続きが必要

大規模計算を行うためには、メモリが空いている必要があります。もし空きがなければ走っている計算が止まるのを待つか、あるいは計算を強制的に止めたうえで、目的の計算を流さなければなりません。さらに計算を投入した後は、計算が完了するまで他の計算を流さないように協力を依頼しなければなりません。もし誰かが大きな計算が流されているのを知らないで、空いているコアに計算を投入してしまうと、メモリスワップが起こる可能性が出てきます。

管理が煩雑になるのを避けようとすると、専用機としての運用に落ち着く

多くのコアが搭載されているメモリ共有マシンを、共同利用しようとすると、資源管理が急に難しくなります。そして結局は煩雑になる管理を避けるうち、いつのまにか大規模計算の専用機としての運用に落ち着いてしまいそうです。

以前のUNIX並列計算機はジョブ管理ソフトの搭載が当然だった

さて、過去の多くのCPUでメモリを共有する大型並列機ではLSFに代表されるジョブ管理ソフトの搭載が必須でした。メモリ資源をLSFなどで自動的に公平かつ効率良く分配しなければ、計算機の中は無法地帯と化してしまうからてす。

最近までのHPCクラスタは2CPUコア/ノード以下が主でCPU資源管理に軸足があった

最近までのHPCクラスタは、1CPUコア/ノード (シングルコアCPUによる1ソケット) をベースとしたクラスタが主でこの場合はメモリの奪い合いは起こりえませんでした。また、2CPUコア/ノード (シングルコアCPUによる2ソケット) の場合でも、ノードあたり2CPUコアと単純なため、メモリの奪い合い対策には重きがおかれていませんでした。このように以前のHPCクラスタでのLSF機能への期待は、CPUリソースの管理に重点が起これていました。

CPU資源とメモリ資源の効率的な自動運用でこそ本領発揮のLSF

LSFは、計算機資源の自動管理ソフトとして豊富な経験を蓄積しています。その蓄積が、HPCクラスタの64bit化や大容量メモリ化、8CPUコア化などが複合することによる高度化・複雑化により、大きく開花する局面に入っています。例えば、複数の8CPUコアのマシンで構成されたHPCクラスタで、システムに不慮の停止をさせることなく、快適な共同利用を実現するためには、キュー構成にも工夫が必要となります。8CPUコアを無駄なく利用することも大切ですし、搭載されているであろう大きなメモリをフルに活用した大規模計算にも自動対応させたいです。さらに、並列計算で計算速度も確保したいなど、要求は複雑化します。