３．現システムの問題点と我々のアプローチ

　前節までに、現システムのスケジューリングポリシを述べた。本節では、この問題点を挙げ、これを改善するためのスケジューリングポリシについて説明する。

３．１　現システムの問題点

　現システムでは、優先順位評価の対象となるものは、現在の資源で実行可能なものである。このことは、多くの資源を要するリクエスト R は、少ない資源で実行可能 なリクエストに追いこされやすいことを意味するばかりでなく、優先順位評価の対象にも成りにくい。さらに、評価のタイミングとして、バッチリクエスト受付時があるので、R より少ない資源で実行可能なリクエストが新たに受け付けられると、R は、再度追いこされる。

　このような問題を避けるために、現システムでは max wait time というパラメータを用意している。あるリクエストが、このパラメータで設定されている時間を過ぎると、優先順位に関係なく、このリクエストの順位が最高になる。よって、このパラメータにより新たな二つの問題が発生する。最初の問題は、max wait time は最悪の待ち時間であり、多くの資源を要するリクエストは、結局この時間まで待たされる可能性が非常に高い。また、もう一つの問題は効率が良くないということである。R₁ を、現在実行中のジョブとし、１６ＰＥのプロセッサとすべてのメモリを使用しているとする。このとき、R₂、R₃ のリクエストがキューにあるとする。R₂ は、３２ＰＥのプロセッサを使用し、max wait timeが超過しているとする。R₃ は１６ＰＥを使用し、実行時間は、R₁ の残りの実行時間より短かいとする。すると、R₃ が R₂ を追いこして実行するほうが効率がよいが、max wait time により、R₂ のほうが先に実行される。以上より max wait time を積極的に使うことは、効率の面から言えば避けるべきである。

　しかし、現システムのスケジューリングポリシでは、実行可能なものが優先順位の評価の対象となることから、現システムでは本質的な解決は不可能である。よって、ＮＱＳ−ＪＳを動的に制御する外部スケジューラを用い、優先順位の対象を広げるアプローチを提案する。

３．２ 我々のアプローチ

　ＮＱＳ−ＪＳに外付けするスケジューラを用い、優先順位の対象を広げることにする。このスケジューラのスケジューリングポリシは、

1. 評価の対象は、キュー内の全てのリクエスト
   
2. 後から受け付けられたリクエストに追いこされると、優先度を上げる
   
3. その他の優先順位評価方法はＮＱＳ−ＪＳと同じ
   

である。1.により、多くの資源を要するリクエストも優先順位評価の対象となり、2.により、このようなリクエストが長時間待たされることを避けるようにする。これら以外についての優先順位の決定はＮＱＳ−ＪＳと同じにする。これにより、既存のシステムを最大限に利用できる。
　以上から、外付けするスケジューラと現システムとの関係は 図２のようになる。

図２：　外付けスケジューラの位置付け

　外付けスケジューラは、ＮＱＳとＮＱＳ−ＪＳからスケジューリングに必要な情報を取得する。ＮＱＳからの取得は、qps から行ない、ＮＱＳ−ＪＳからの取得は、付属のＮＱＳ−ＪＳのサブコマンドから行う。外付けスケジューラの結果をＮＱＳ−ＪＳに渡す部分は、ＮＱＳ−ＪＳの重み付設定ファイルの書き換えによって行なう。
　これにより、ＮＱＳ−ＪＳのスケジューリングで考慮されなかった、現在資源を割り当てられているジョブに関する情報を参照し、より効率の良いスケジューリングを行うことができる。