−司会− 愛媛大学工学部　野田松太郎

【司会】

　ご質疑、ご討論をお願いします。

【志村】(科学技術振興事業団)

　今の京都大学さんのお話も、先程の宇宙研さんのお話もそうですが、NQSを越えた部分をご自分のところで作り込みされているわけですが、それはどの程度汎用的なのでしょうか。実は、うちでも今スケジューリングやシーケンシャル実行の保証等を考えて作り込みを検討しているのですが、同じようなものを作るのは馬鹿らしいので利用できないかと思いますが、仕組み的な面や制度的な面などから考えて、いかがでしょうか。

【浅岡】(発表者：京都大学大型計算機センター)

　現在は、センター固有のものとして作り込みをしようと考えておりますが、今後はまだ分かりません。

【志村】

　希望としては、ノウハウ等は出来る限り共有化していただくと有り難いと思っております。

【司会】

　先程の名古屋大学さんのお話に、sharedモードは、非常にやばいとありましたよね。CPU_LOOPというパラメタを使うとかなりずれますか。

【浅岡】

　はい。ジョブが投入された時に、PEにどのように割り付けられていたかどうか、2つのジョブの割り付けPEが全て重なった場合、一部重なった場合、全然重ならない場合で課金が違うのは非常にまずいということです。

【司会】

　先程のように、止まってしまうということはないのですね。

【浅岡】

　そういうバグもありました。（笑）

【福田】(航空宇宙技術研究所)

　Sharedモードで走らせるというのは、要するに一つのジョブだけで走っていたのでは、CPUに空きがでるので、それを他に回そうということですよね。空きがなぜできるのかは、いくつも状況があると思いますが、一つの並列ジョブから見ても、ロードバランスがとれていないから、空いているCPUはできるがそれを使おう、と言うのもあるだろうし、昔ですと一台の計算機しか無いので、I/Oで空いている時間をつぶしましょうというのが最初だったと思います。空いている時間がどれ程あるのか、その時間を塞ぐのに、CPUを食って、オーバーヘッドをかけてもまだ余るくらいCPUが空いている状況なのか、たいして空いていないので、システムオーバーヘッドに食われて、実質的に減るんだという状況なのか、もしI/Oのあたりで空き時間がある場合、ジョブの入れ替えるタイミングを、ジョブの100m secというスライスとか、同期のタイミングではなくI/Oを出したタイミングでジョブを入れ替えて、スワップする形を考えた方が良いのではないかと思います。そのあたりの検討状況はどうなっているのでしょうか。タイムスライス100m secで入れ替えるということになったのですか。

【長屋】(富士通(株)ソフトウェア事業本部第二ソフトウェア事業部第五開発部)

　Sharedモードで運用するのは、２つの目的があると思います。一つは先ほど福田先生がおっしゃられたように、I/Oを出している時間に、他のジョブを走らせて、ＰEの使用効率をあげるという点、もう一つは、一人が占有すると、ターンアラウンドが伸びてしまうので、公平にCPUをSHAREすることによって、実行時間は1.5〜2倍になるかもしれませんが、公平にCPUを割り当てることでジョブのスループットを全般的に短くしてあげるということだと思います。福田先生がおっしゃられたように、バリアの時、CPUを別なジョブに渡してどれだけ効果があるのか、I/Oの時だけジョブを切り替えればよいのではないかと、確かにそうかもしれません。ただ、現在はそうなっておらず、両方とも、SYSPOLL(システムコール)を出しています。次期のシステムではどう考えて良いのかということを、今まさに検討中です。

【浅岡】

　基本的にSharedモードにするというのは、高並列ジョブを効率よく実行させるというのが狙いです。高並列ジョブはPE確保が難しいため、多くの待ち時間が生じてしまうのですが、ある程度待たせてしまったら、Run Limitなどを調節し、強制的に実行させるようにしています。しかしこの高並列ジョブを実行させるためには多くのPEを確保しなければいけない、そうすると、PEが空いているのに、他の待ちジョブがそのPEを使って実行することができないという状態が発生します。「PEに空きがあるのになぜ僕のジョブは走らないのか」というような苦情がユーザより来まして、それで、Sharedモードにしないといけないと思いました。

【福田】

　うちの場合もそうなので分かります。うちのマシンはVPP500のプロットタイプみたいなものでSharedモードのような機能はないものですから、高並列ジョブは長い間待っていたら、何がなんでも走らせるんだとスケジューリングが動いて、空いているPEがあっても我慢するんだというのが、初期の運用方針だったということです。
　それから、もう一つ、富士通が回答した中で、Sharedの話で、3ケ所ともシステムの利用効率を上げたいとのことでしたが、それでしたら、個別のターンアラウンドを短くしたいというお話は発表の中にはなかったなあという気が少ししました。

【姫野】(理化学研究所)

　それぞれのジョブクラスの、同時に実行されるPEの数が、私にとっては少し奇妙な数字に設定されているような気がしたんですが、どのような意図なのでしようか。

【浅岡】

　この表で、キューのf､g､hのPE数が、10､10､40と10の倍数に設定されているが、本来は、4、8、16といった2のべき乗ではないのかということですね。これはVPP500の時代に１PEジョブ、10PEジョブキューを定義し運用していまして、VPP800にリプレースした時に、運用形態の継承を最優先に考えてキューを設計したため、このような数になっています。

【姫野】

　10の実行可能なクラスで実行させるのに、8しか使わないということが起こってしまいますよね。

【浅岡】

　はい、あります。10のうち8しか使わないとなると、2つのPEがリザーブされたまま何も使われないという状態になります。昨年運用していた時にはそのようなことがたくさんありました。しかし、これではあまりにももったいないので、今年の4月、システムの運用率を上げるために、ジョブ投入時に必要となるPE数を指定してくださいと、センターのホームページ、広報、ニュース等でユーザにこまめに指導しました。

【司会】

　その場合、ジョブに8、残りの2はリザーブされていますよね。その点がものすごく気になっているのですが、今、京都大学さんのセンターの利用効率はどのくらいですか。

【浅岡】

　私の口からではなく、研究開発部長の金澤から説明します。（笑）

【金澤】(京都大学大型計算機センター)

　24時間運転をしていませんので、運転効率の統計を取ると悪くなります。例えば、一人で1PE使う20時間ジョブを入れて、午前0時を超えますと、ジョブの終わりまで実行を保証していますので、朝まで動いて連続運転になります。その時点では使用率は1/63です。したがって、統計上は非常に悪くなります。例えば、我々のところでは、4〜7月の4ヶ月間割引をしております。そうすると、最後の追い込みでキューができます。10PEのジョブが並んでいる時に、ちょうどタイミングよく8PE空いた、入れて20分くらいの8PEのジョブが追越した。これで良いのかなと思ったこともあります。なにぶん、箱詰め問題と同じですので、でたらめに詰めると、誰かの法則と同じで2/3にしかならない。一方、一つのメインのPEは、ずっと使っていても、残りのPEは、システムのループで待ちますとCPUカウントが低くなりますので、全部のPEを足すと、全部のPEが見かけ上動いていても、100％にならない。また減ってしまう。今までの3CPUや、4CPUのMシリーズの時代と同じような統計をとっていたら、低い使用率となります。

【司会】

　なぜこんなことをお聞きしたかといいますと、実は現在、地方大学、愛媛大学のリプレイスを考えているのですが、計算サーバの導入はやめようかと話し合っています。SINETがギガになりますので、そうなれば、京都大学さんや名古屋大学さんをどんどん使えば良いじゃないかと、あそこはガラガラだと言うのですが、どうもそうじゃないですね。（笑）これから益々、simplexにこだわらず、SHAREでもっとたくさんのプロセッサーを使って、ジョブを流していただきたい。そうすれば、日本の計算機機能がもっと上がるのでないか。我々も他のところに投資できるのではないかと思っております。
　どうもありがとうございました。（拍手）

Ｑ：理化学研究所　姫野龍太郎

　どうして Check Point Restart 機能は使わないのでしょうか。

Ａ：京都大学大型計算機センター　浅岡香枝

　ジョブ凍結機能は、戦略的なジョブスケジューリングでは、有効な機能ですが、運用について十分に検討できていません。今後の課題と考えています。

---

Ｑ：日本大学工学部情報工学科 　山本　登

　shareモードは、本来邪道ではないでしょうか。

Ａ：富士通(株)ソフトウェア事業本部第二ソフトウェア事業部第五開発部　長屋忠男

　業務ジョブ等を既定の時間内に完了するという目的に対しては、ご指摘の通り、shareモードの実行は推奨できません。
　しかし、計算機センタのような運用では、業務ジョブとデバッグジョブをshareモードで混在実行させることで、短時間のデバッグジョブのターンアラウンドを短縮してユーザの作業効率を向上できる等の効果も期待できるため、一つの選択枝としてOS機能としてshareモードを提供しています。