(5/8)

3.3.運用形態の変更と新たな課題

　2000年4月からの新年度運用に合わせて、それまでの運用を見直して、運用形態の大幅な変更を行った。具体的には、つぎのものである。

1. jobexecコマンドによる会話型並列サービス
2. NQSの許可量の見直し
3. SHAREモードでの運用

3.3.1. 会話型並列実行のサービス

　これまで並列ジョブは、NQS経由でないと認めていなかった、しかし、Try　＆　Errorでの並列プログラムの開発作業は、会話型のほうが効率よい。したがって、jobexecコマンドに対する１）システム内での同時実行コマンド数制限、２）利用者当たりの同時実行コマンド数制限、３）jobexecコマンドの経過時間打ち切り機能などを要望していたが、これらの機能が3月末に提供されたので、4月からjobexecコマンドによる会話型並列サービスを開始した。
　本センターでのjobexecコマンドの許可量および制限は、つぎのように設定している。

1. jobexecコマンドの許可量
   
   • 最大CPU時間30分、最大PE数　４、経過時間　1時間
     
2. 制限値
   
   • システム内多重度　４
     
   • 利用者当たりの実行コマンド数　1
     

3.3.2.NQSの許可量の見直しと運用形態の変更

　4月からのNQSの許可量を表２に示す。

表２：キュー名と許可量（2000年4月〜）

　基本的な変更点は、メモリサイズを標準3GB、最大7GBとし、また、CPUを最大20時間まで緩和したことである。
　メモリサイズの3GBは、それまでのアカウントデータを分析して、8割以上のジョブが3GB以下で実行されている事実からこの値を採用した。これらの標準値、最大値の管理は、NQS-JMの資源割り当て管理機能を用いている。
　また、それまでの運用では、最大値だけで管理しており、利用者に対してジョブ投入時に必要なジョブ資源を明示することを要求してこなかったが、メモリ量、CPU時間、およびPE数をqsubコマンドで指定するように指導するようにした。

3.3.3.SHAREモードでの運用とジョブスケジューリング

　4月からの運用では、NQSキューの許可量を見直すとともに並列、非並列ともにキューの定義をSHAREモードに変更してサービスを開始した。なお。並列ジョブのバリアモードは、高速バリアモード（バリアモード０）である。
　基本的なジョブスケジューリング戦略は、つぎのようなものである。

1. ジョブクラスリスト
   
   • 非並列キューは、基本的にP-PEを除く7台のIO-PEにだけに割付ける。
     
   • 並列キューは、基本的に55台のS-PEに割り付ける。
     
2. NQS-JSの設定
   
   • max non-parallel=2を指定し非並列ジョブが最大２ジョブ同時に実行されるようにし、また、空きPEがある場合にはジョブが重ならないようにpack=noを指定した。
   • また、CPU時間、メモリ量、PE数のファクタで要求資源の少ないジョブが優先的に実行され、かつ、実行待ち時間により多くの資源を必要とするジョブが不当に永く待ちになることを防いでいる。
3. Run_Lｉｍｉｔによるスケジューリング
   • 40PEを使うキューｈのジョブは、他の並列ジョブ（キューf,g）が複数ある限り、必要なPE台数を確保できないので、実行待ち時間を調べRun_Limitを調整することで長時間待ちを回避している。

3.3.4. SHAREモードの問題と対策

　ジョブが混み始めた5月中旬、利用者から同じジョブでCPUが非常にばらつくという申告を受けた。
　調査すると二つの並列ジョブの割り付けPEが部分的に重なった場合の問題であることが判明したので、並列ジョブキューの実行モードをSIMPLEXに変更して追試を行った。
　追試の結果、本センターのようにジョブ課金を行っている場合、バリア同期の方法をCPU_LOOPからSYS_POLLにしないとSHAREモードでの運用は困難であることが明らかとなり、SYS_POLLに切り替える場合の問題点について検討した。明らかとなった問題点は、つぎのようなものである。

1. CPU_LOOPとSYS_POLLの切り替えは、プログラム実行時の環境変数での指定であり、センターとして一括して変更できるような枠組みがいる。
2. バリア同期の方法が環境変数で指定可能になった時期がFortran/VPP,HPF、メッセージパッシングライブラリ（MPI、PVM）で異なる。
3. SYS_POLLに切り替えた場合、システムコールのオーバヘッドにより性能劣化が起こるので、ベンチマーク的なジョブにはまずい。
4. PA(Performance Analyzer)でデータ転送に関するデータを測定する場合、SIMPLEXモードの実行が必須。

　また、これらの問題に対する対処は、つぎのようなものである。
　１）の問題に関しては、環境設定ファイルにFLIB_SYSPOLL（Fortran/VPP,HPF）およびVPP_POLL（MPI,PVM）を指定し、並列ジョブのバリア同期の方法をデフォルトでSYS_POLLに切り替える。２）の問題については、センターで導入したアプリケーションパッケージに関する調査では問題がなかったが、センター外で作成されたモジュールを利用者が実行する場合、注意が必要である。また、３）、４）の問題に関しては、本来、ジョブの投入時にqsubコマンドのオペランドで実行モードが選択できればよいが、NQSではこのような機能はない。したがって、メモリサイズで７GBを指定して貰いPEを占有して実行させるとともに利用者が環境変数でバリア同期の方法をCPU_LOOPに切り替えて実行するようなアナウンスが必要である。
　SHAREモードでの運用は、キューhのような高並列ジョブのスループットの改善には必須であると考えている。ここで上げた問題点および対処方法を整理して、利用者に対するアナウンスの後、適当な時期からSHAREモードでの運用に戻すことを考えている。