(57)【要約】【課題】キューぺアの数及びキューペアの深さを調節する入出力キューペアを管理する方法及びシステムを提供する。【解決手段】本発明による入出力キューペアを管理する方法は、システム利用率を計算するステップと、第１長閾値を超える時間周期中、前記システム利用率が第１利用閾値を超え、新たなキューペアの追加がシステムの性能を向上させることが期待されることを判断する（ｄｅｔｅｒｍｉｎｅ）ステップと、前記新たなキューペアを追加するステップと、を有し、前記システム利用率は、入出力リクエストの到着レートに対するサービスレートの割合である。【選択図】  図１
2020201957.tif 000002
【特許請求の範囲】
【請求項１】
入出力キューペアを管理する方法であって、
システム利用率を計算するステップと、
第１長閾値を超える時間周期中、前記システム利用率が第１利用閾値を超え、新たなキューペアの追加がシステムの性能を向上させることが期待されることを判断する（ｄｅｔｅｒｍｉｎｅ）ステップと、
前記新たなキューペアを追加するステップと、を有し、
前記システム利用率は、入出力リクエストの到着レートに対するサービスレートの割合であることを特徴とする入出力キューペアを管理する方法。
【請求項２】
前記第１長閾値を超える時間周期中、前記システム利用率が前記第１利用閾値よりも低い第２利用閾値未満に保たれ、キューペアの削除がシステムの性能を向上させることが期待されることを判断するステップと、
前記キューペアを削除するステップと、をさらに有することを特徴とする請求項１に記載の入出力キューペアを管理する方法。
【請求項３】
前記システム利用率が、前記第１利用閾値未満であり、前記第１利用閾値と前記第２利用閾値との間の第３利用閾値よりも高いことを判断するステップと、
下限キューの高さ閾値をサービスレートの関数と等しくなるように調整するステップと、をさらに有することを特徴とする請求項２に記載の入出力キューペアを管理する方法。
【請求項４】
前記入出力キューペアの第１キューペアの送信（ｓｕｂｍｉｓｓｉｏｎ）キューのロックが解除され、集中化（ｃｅｎｔｒａｌｉｚｅｄ）されたキューが入出力リクエストを保存し、前記送信キューの高さが上限キューの高さ閾値よりも低いことを判断するステップと、
前記入出力リクエストを前記第１キューペアにエンキュー（ｅｎｑｕｅｕｅ）するステップと、をさらに有することを特徴とする請求項３に記載の入出力キューペアを管理する方法。
【請求項５】
前記送信キューの現在高さが、前記上限キューの高さ閾値と同じであることを判断することステップと、
前記送信キューをロックするステップと、をさらに有することを特徴とする請求項４に記載の入出力キューペアを管理する方法。
【請求項６】
前記送信キューの現在高さが、前記下限キューの高さ閾値を超えないことを判断するステップと、
前記送信キューのロックを解除するステップと、をさらに有することを特徴とする請求項５に記載の入出力キューペアを管理する方法。
【請求項７】
前記関数は、入出力リクエストあたりの平均処理遅延のモデルの最小値の数値として求められることを特徴とする請求項３に記載の入出力キューペアを管理する方法。
【請求項８】
前記モデルは、前記サービスレートと前記下限キューの高さ閾値の関数としての入出力リクエストあたりの過去の平均処理遅延の多項式適合（ｐｏｌｙｎｏｍｉａｌ  ｆｉｔ）であることを特徴とする請求項７に記載の入出力キューペアを管理する方法。
【請求項９】
キューペアの数を決定及び設定するために、数値最小化の直近の使用後に、第２長閾値を超える長さを有する時間間隔が経過したことを判断するステップと、
動作中に使用するキューペアの数を計算するために、キューペアの数の関数としての入出力リクエストあたりの平均処理遅延のモデルの数値最小化を行うステップと、
キューペアの数が動作中に使用するキューペアの計算された数と同一になるように、０個以上の新たなキューペアを追加するか、又は、０個以上のキューペアの数を削除するステップと、をさらに有することを特徴とする請求項２に記載の入出力キューペアを管理する方法。
【請求項１０】
処理回路と、
１以上の永久保存装置と、を有し、
前記処理回路は、前記１以上の永久保存装置に送信される入出力リクエストと、前記１以上の永久保存装置から受信したコマンド完了を保存するための１以上の入出力キューペアとをインスタンス化（ｉｎｓｔａｎｔｉａｔｅ）し、
システム利用率を計算し、
第１長閾値を超える時間周期中、前記システム利用率が第１利用閾値を超え、新たなキューペアの追加がシステムの性能を向上させることが期待されることを判断し、
前記新たなキューペアを追加するように構成され、
前記システム利用率は、入出力リクエストの到着レートに対するサービスレートの割合であることを特徴とするシステム。
【請求項１１】
前記処理回路は、前記第１長閾値を超える時間周期中、前記システム利用率が前記第１利用閾値よりも低い第２利用閾値未満に保たれ、キューペアの削除がシステムの性能を向上させることが期待されることを判断し、
前記キューペアを削除するようにさらに構成されることを特徴とする請求項１０に記載のシステム。
【請求項１２】
前記処理回路は、前記システム利用率が、前記第１利用閾値未満であり、前記第１利用閾値と前記第２利用閾値との間の第３利用閾値よりも高いことを判断し、
下限キューの高さ閾値をサービスレートの関数と等しくなるように調整するようにさらに構成されることを特徴とする請求項１１に記載のシステム。
【請求項１３】
前記処理回路は、前記入出力キューペアの第１キューペアの送信キューのロックが解除され、集中化されたキューが入出力リクエストを保存し、前記送信キューの高さが上限キューの高さ閾値よりも低いことを判断し、
前記入出力リクエストを前記第１キューペアにエンキューするようにさらに構成されることを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記処理回路は、前記送信キューの現在高さが、前記上限キューの高さ閾値と同じであることを判断し、
前記送信キューをロックするようにさらに構成されることを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記処理回路は、前記送信キューの現在高さが、前記下限キューの高さ閾値を超えないことを判断し、
前記送信キューのロックを解除するようにさらに構成されることを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記関数は、入出力リクエストあたりの平均処理遅延のモデルの最小値の数値として求められることを特徴とする請求項１２に記載のシステム。
【請求項１７】
前記モデルは、前記サービスレートと前記下限キューの高さ閾値の関数としての入出力リクエストあたりの過去の平均処理遅延の多項式適合であることを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記処理回路は、キューペアの数を決定及び設定するために、数値最小化の直近の使用後に、第２長閾値を超える長さを有する時間間隔が経過したことを判断し、
動作中に使用するキューペアの数を計算するために、キューペアの数の関数としての入出力リクエストあたりの平均処理遅延のモデルの数値最小化を行い、
キューペアの数が動作中に使用するキューペアの計算された数と同一になるように、０個以上の新たなキューペアを追加するか、又は、０個以上のキューペアの数を削除するようにさらに構成されることを特徴とする請求項１１に記載のシステム。
【請求項１９】
処理手段と、
１以上の永久保存装置と、を有し、
前記処理手段は、前記１以上の永久保存装置に送信される入出力リクエストと、前記１以上の永久保存装置から受信したコマンド完了を保存するための１以上の入出力キューペアとをインスタンス化し、
システム利用率を計算し、
第１長閾値を超える時間周期中、前記システム利用率が第１利用閾値を超え、新たなキューペアの追加がシステムの性能を向上させることが期待されることを判断し、
前記新たなキューペアを追加するように構成され、
前記システム利用率は、入出力リクエストの到着レートに対するサービスレートの割合であることを特徴とするシステム。
【請求項２０】
前記処理手段は、前記第１長閾値を超える時間周期中、前記システム利用率が、前記第１利用閾値未満に保たれ、キューペアの削除がシステムの性能を向上させることが期待されることを判断し、
前記キューペアを削除するようにさらに構成されることを特徴とする請求項１９に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＮＶＭｅｏＦ（Ｎｏｎ−Ｖｏｌａｔｉｌｅ  Ｍｅｍｏｒｙ  ｅｘｐｒｅｓｓ  ｏｖｅｒ  Ｆａｂｒｉｃｓ）を使用するデータ保存システムに関し、特に、このようなデータ保存システムの性能を向上させるための入出力キューペアを管理する方法及びシステムに関する。
【背景技術】
【０００２】
従来のＮＶＭｅｏＦシステムは、一部の状況において、低下した性能を示す。
これは、次の問題の内の一つ又は両方により引き起こされる。
第一に、一部のＮＶＭｅｏＦの具現は、
（ｉ）余分のアイドリングキューペア（ｉｄｌｅｄ  ｑｕｅｕｅ  ｐａｉｒ）を保つか、
（ｉｉ）十分なキューペアを保つことがなく、システムを過少利用（ｕｎｄｅｒｕｔｉｌｉｚｉｎｇ）することによりシステムリソースを浪費する。
第二に、一部のＮＶＭｅｏＦの具現には、高いＩ／Ｏ圧力（例えば、キューペアにある多くのキューイングＩ／Ｏ作業）のために、キューペアサービスレート（ｓｅｒｖｉｃｅ  ｒａｔｅ）の遅延を防止するための適切なフロー制御体系がない。
【０００３】
従って、ＮＶＭｅｏＦのデータ保存システムの性能を向上させるためのシステム及び方法の開発が課題となっている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１８−１８５１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、上記従来のＮＶＭｅｏＦシステムにおける課題に鑑みてなされたものであって、本発明の目的は、キューぺアの数及びキューペアの深さを調節する入出力キューペアを管理する方法及びシステムを提供することにある。
【課題を解決するための手段】
【０００６】
上記目的を達成するためになされた本発明による入出力キューペアを管理する方法は、システム利用率を計算するステップと、第１長閾値を超える時間周期中、前記システム利用率が第１利用閾値を超え、新たなキューペアの追加がシステムの性能を向上させることが期待されることを判断する（ｄｅｔｅｒｍｉｎｅ）ステップと、前記新たなキューペアを追加するステップと、を有し、前記システム利用率は、入出力リクエストの到着レートに対するサービスレートの割合であることを特徴とする。
【０００７】
前記第１長閾値を超える時間周期中、前記システム利用率が前記第１利用閾値よりも低い第２利用閾値未満に保たれ、キューペアの削除がシステムの性能を向上させることが期待されることを判断するステップと、前記キューペアを削除するステップと、をさらに有することが好ましい。
前記システム利用率が、前記第１利用閾値未満であり、前記第１利用閾値と前記第２利用閾値との間の第３利用閾値よりも高いことを判断するステップと、下限キューの高さ閾値をサービスレートの関数と等しくなるように調整するステップと、をさらに有することが好ましい。
前記入出力キューペアの第１キューペアの送信（ｓｕｂｍｉｓｓｉｏｎ）キューのロックが解除され、集中化化されたキューが入出力リクエストを保存し、前記送信キューの高さが上限キューの高さ閾値よりも低いことを判断するステップと、前記入出力リクエストを前記第１キューペアにエンキュー（ｅｎｑｕｅｕｅ）するステップと、をさらに有することが好ましい。
前記送信キューの現在高さが、前記上限キューの高さ閾値と同じであることを判断することステップと、前記送信キューをロックするステップと、をさらに有することが好ましい。
前記送信キューの現在高さが、前記下限キューの高さ閾値を超えないことを判断するステップと、前記送信キューのロックを解除するステップと、をさらに有することが好ましい。
前記関数は、入出力リクエストあたりの平均処理遅延のモデルの最小値の数値として求められることが好ましい。
前記モデルは、前記サービスレートと前記下限キューの高さ閾値の関数としての入出力リクエストあたりの過去の平均処理遅延の多項式適合（ｐｏｌｙｎｏｍｉａｌ  ｆｉｔ）であることが好ましい。
キューペアの数を決定及び設定するために、数値最小化の直近の使用後に、第２長閾値を超える長さを有する時間間隔が経過したことを判断するステップと、動作中に使用するキューペアの数を計算するために、キューペアの数の関数としての入出力リクエストあたりの平均処理遅延のモデルの数値最小化を行うステップと、キューペアの数が動作中に使用するキューペアの計算された数と同一になるように、０個以上の新たなキューペアを追加するか、又は、０個以上のキューペアの数を削除するステップと、をさらに有することが好ましい。
【０００８】
上記目的を達成するためになされた本発明によるシステムは、処理回路と、１以上の永久保存装置と、を有し、前記処理回路は、前記１以上の永久保存装置に送信される入出力リクエストと、前記１以上の永久保存装置から受信したコマンド完了を保存するための１以上の入出力キューペアとをインスタンス化（ｉｎｓｔａｎｔｉａｔｅ）し、
システム利用率を計算し、第１長閾値を超える時間周期中、前記システム利用率が第１利用閾値を超え、新たなキューペアの追加がシステムの性能を向上させることが期待されることを判断し、前記新たなキューペアを追加するように構成され、前記システム利用率は、入出力リクエストの到着レートに対するサービスレートの割合であることを特徴とする。
【０００９】
前記処理回路は、前記第１長閾値を超える時間周期中、前記システム利用率が前記第１利用閾値よりも低い第２利用閾値未満に保たれ、キューペアの削除がシステムの性能を向上させることが期待されることを判断し、前記キューペアを削除するようにさらに構成されることが好ましい。
前記処理回路は、前記システム利用率が、前記第１利用閾値未満であり、前記第１利用閾値と前記第２利用閾値との間の第３利用閾値よりも高いことを判断し、下限キューの高さ閾値をサービスレートの関数と等しくなるように調整するようにさらに構成されることが好ましい。
前記処理回路は、前記入出力キューペアの第１キューペアの送信キューのロックが解除され、集中化化されたキューが入出力リクエストを保存し、前記送信キューの高さが上限キューの高さ閾値よりも低いことを判断し、前記入出力リクエストを前記第１キューペアにエンキューするようにさらに構成されることが好ましい。
前記処理回路は、前記送信キューの現在高さが、前記上限キューの高さ閾値と同じであることを判断し、前記送信キューをロックするようにさらに構成されることが好ましい。
前記処理回路は、前記送信キューの現在高さが、前記下限キューの高さ閾値を超えないことを判断し、前記送信キューのロックを解除するようにさらに構成されることが好ましい。
前記関数は、入出力リクエストあたりの平均処理遅延のモデルの最小値の数値として求められることが好ましい。
前記モデルは、前記サービスレートと前記下限キューの高さ閾値の関数としての入出力リクエストあたりの過去の平均処理遅延の多項式適合であることが好ましい。
前記処理回路は、キューペアの数を決定及び設定するために、数値最小化の直近の使用後に、第２長閾値を超える長さを有する時間間隔が経過したことを判断し、動作中に使用するキューペアの数を計算するために、キューペアの数の関数としての入出力リクエストあたりの平均処理遅延のモデルの数値最小化を行い、キューペアの数が動作中に使用するキューペアの計算された数と同一になるように、０個以上の新たなキューペアを追加するか、又は、０個以上のキューペアの数を削除するようにさらに構成されることが好ましい。
【００１０】
また、上記目的を達成するためになされた本発明によるシステムは、処理手段と、１以上の永久保存装置と、を有し、前記処理手段は、前記１以上の永久保存装置に送信される入出力リクエストと、前記１以上の永久保存装置から受信したコマンド完了を保存するための１以上の入出力キューペアとをインスタンス化し、システム利用率を計算し、第１長閾値を超える時間周期中、前記システム利用率が第１利用閾値を超え、新たなキューペアの追加がシステムの性能を向上させることが期待されることを判断し、前記新たなキューペアを追加するように構成され、前記システム利用率は、入出力リクエストの到着レートに対するサービスレートの割合であることを特徴とする。
【００１１】
前記処理手段は、前記第１長閾値を超える時間周期中、前記システム利用率が、前記第１利用閾値未満に保たれ、キューペアの削除がシステムの性能を向上させることが期待されることを判断し、前記キューペアを削除するようにさらに構成されることが好ましい。
【発明の効果】
【００１２】
本発明に係る入出力キューペアを管理する方法及びシステムによれば、キューペアの数及びキューペアの深さを調節して、Ｉ／Ｏリクエストの遅延時間を最適化するという効果がある。
【図面の簡単な説明】
【００１３】
【図１】本発明の一実施形態によるＮＵＭＡ（Ｎｏｎ−Ｕｎｉｆｏｒｍ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）を適用したシステムベースのＮＶＭｅｏＦシステムのための性能オプティマイザのコンポーネントアーキテクチャを説明するための図である。
【図２Ａ】本発明の実施形態で使用する用語を要約したものを示す表である。
【図２Ｂ】本発明の一実施形態によるＮＶＭｅｏＦプロトコルのアーキテクチャを説明するための図である。
【図２Ｃ】本発明の一実施形態によるＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）ポートにおけるキューペアのキューイングモデル（ｑｕｅｕｅｉｎｇ  ｍｏｄｅｌ）を説明するための図である。
【図２Ｄ】本発明の実施形態によるボトルネックベースのサービスレート分析及びモデリングに使用される記号及び説明を要約したものを示す表である。
【図２Ｅ】本発明の一実施形態によるウォーターマーク変数及び多数のキューペア変数の関数としてのサービスレートの最大値を見つけるのに使用される例示的な３Ｄ表面を示すグラフである。
【図３Ａ】本発明の一実施形態によるクライアントスタック及びターゲットスタックのキューペアのモデルを説明するための図である。
【図３Ｂ】本発明の一実施形態によるキューペアの数及びキューペアの深さを調整するための２つの方法（第１方法及び第２方法）の比較を示す表である。
【図３Ｃ】本発明の一実施形態による第１方法でキューペアの数を調整するための２つのアプローチ（第１アプローチ及び第２アプローチ）の比較を示す表である。
【図３Ｄ】本発明の一実施形態による異なるシステム利用率のケースに基づいた切り替え最適化のアプローチに関する動作態様を説明するための例示的な図である。
【図３Ｅ】本発明の一実施形態によるキューペアの数及びキューペアの深さを調整するのに使用される閾値及びターゲット利用率、並びにシステム利用率の計算を示す表である。
【図３Ｆ】本発明の一実施形態によるキューペアの数及びキューペアの深さを調整するのに使用されるケース及び対応する動作を示す表である。
【図３Ｇ】本発明の一実施形態によるキューペアの数を調整するのに使用される２つのコンポーネントのワークフロー図である。
【図３Ｈ】本発明の一実施形態によるキューペアの数を調整するのに使用される第１コンポーネントのサブコンポーネント及び機能を示す表である。
【図３Ｉ】本発明の一実施形態によるキューペアの数を調整するのに使用される第１コンポーネントのサブコンポーネント間の関係を示す図である。
【図３Ｊ】本発明の一実施形態による回帰ベース（ｒｅｇｒｅｓｓｉｏｎ−ｂａｓｅｄ）の攻撃的アプローチに使用された例示的な目的関数（ｏｂｊｅｃｔｉｖｅ  ｆｕｎｃｔｉｏｎ）を示すグラフである。
【図４Ａ】本発明の一実施形態によるキューペアの深さを調整するのに使用されるキューイングモデルを説明するための例示図である。
【図４Ｂ】本発明の一実施形態によるキューペアの深さの調整と関連する用語及び対応する説明を示す表である。
【図４Ｃ】本発明の一実施形態によるキューペアの深さを調整するコンテクスト（ｃｏｎｔｅｘｔ）で使用されるキューイングした入力／出力（Ｉ／Ｏ）の高さとサービスレートとの関係における例示を示す図である。
【図４Ｄ】本発明の一実施形態によるキューペアの深さを調整するコンテクストで使用されるキューイングした入力／出力（Ｉ／Ｏ）の高さとサービスレートとの関係におけるさらなる例示を説明するための図である。
【図４Ｅ】本発明の一実施形態によるキューペアの深さを調整するためのウォーターマークベースの最適化における条件及び対応する動作を説明するための図である。
【図４Ｆ】本発明の一実施形態によるキューペアの深さを調整するためのウォーターマークベースの最適化に関する一部の例示的な手順を示す図である。
【図４Ｇ】本発明の一実施形態によるキューペアの深さを調整するためのウォーターマークベースの最適化に関する例示的なワークフローを示すフローチャートである。
【図４Ｈ】本発明の一実施形態によるキューペアの深さ調整に関する用語及び対応する説明を示す表である。
【図４Ｉ】本発明の一実施形態によるキューペアの深さ調整に関する異なる時間周期の間の例示的な平均のキューイングＩ／Ｏリクエストの高さを説明するための図である。
【図４Ｊ】本発明の一実施形態による低ウォーターマークを選択するために本発明のシステムにより使用される３次元グラフの例示図である。
【発明を実施するための形態】
【００１４】
次に、本発明に係る入出力キューペアを管理する方法及びシステムを実施するための形態の具体例を図面を参照しながら説明する。
【００１５】
本発明は、ＮＶＭｅｏＦのデータ保存システムの性能を向上させるためのシステム及び方法の例示的な実施形態の説明として意図しており、本発明が構成されるか又は利用される唯一の形態を表すことを意図したものではない。
本説明は、示している実施形態に関して本発明の特徴を説明する。
しかし、同一又は均等の機能及び構造は、本発明の範囲内に含むことを意図する異なる実施形態により達成されることを理解すべきである。
本発明の他の部分に示すように、同様の構成要素の番号は、同様の構成要素又は特徴を示すことを意図している。
【００１６】
＜＜１．導入＞＞
本発明は、一般に、キューペアの数を適応的に調整することなく、Ｉ／Ｏフローを制御しない従来のシステムに対して、サービスレートの側面で向上した性能を得るようにキューペアの数を適応的に調整し、Ｉ／Ｏフローを制御することにより、キューペアベースのＮＶＭｅｏＦイニシエータターゲットシステムのＩ／Ｏ送信性能を向上させるための、「ＮＶＭｅＱＰＯ（ＮＶＭｅキューペア性能オプティマイザ（ＮＶＭｅ  Ｑｕｅｕｅ  Ｐａｉｒ  Ｐｅｒｆｏｒｍａｎｃｅ  Ｏｐｔｉｍｉｚｅｒ））」と呼ばれる性能オプティマイザに関する。
【００１７】
一実施形態において、キューペアの数、及び（到着ワークロードの分配パターンにより反映される）各キューペアにおける平均のキューイングＩ／Ｏの高さによって決まるクライアントスタックのサービスレート全体のようなＮＶＭｅｏＦシステムのある特性によって動機が与えられる。
【００１８】
ＮＶＭｅｏＦは、計算及び保存の並列性と拡張性とを改善し、ストレージ（ｓｔｏｒａｇｅ）から計算を分離（デカップリング）させるために使用する。
一実施形態において、各ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃｏｎｔｒｏｌｌｅｒ）ポートの一部のキューペアのサービスレート全体及びターゲット側にある対応するキューペアは、ＮＩＣポートの集中化（ｃｅｎｔｒａｌｉｚｅｄ）されたキュー（ＮＩＣ＿ＣＱ）において、Ｉ／Ｏの到着と無関係である。
従って、システムにおいて、各Ｉ／Ｏリクエストの遅延を最小化することによって性能を向上させるために、本発明のシステムは、ランタイムの間に到着するＩ／Ｏのパラメータ及びキューペアの設定を動的に調整することにより、サービスレートを最大化する。
【００１９】
上述の通り、一部のＮＶＭｅｏＦシステムは、次の問題を有する。
（１）ワークロードパターン及びシステムの性能変更に基づいたＮＩＣのキューペア数に対する適応的な調整がない場合、一部のＮＶＭｅｏＦの具現によりシステムリソースが浪費される。
このような浪費は、
（ｉ）余分のアイドリングキューペアを保つか、
（ｉｉ）十分なキューペアを保つことがなく、システムを過少利用することにより発生する。
（２）一部のＮＶＭｅｏＦの具現には、高いＩ／Ｏ圧力の場合（即ち、キューペアにキューイングしたＩ／Ｏ作業が多い場合）、キューペアサービスレートの遅延を防止するためのフロー制御体系がない。
【００２０】
図１は、本発明の一実施形態によるＮＵＭＡ（Ｎｏｎ−Ｕｎｉｆｏｒｍ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）を適用したシステムベースのＮＶＭｅｏＦシステムのための性能オプティマイザのコンポーネントアーキテクチャを説明するための図である。
上述の問題点を解決するために、本発明の一実施形態は、図１に示すように、２つのコンポーネント「第１コンポーネント：キューペア数の管理者」及び「第２コンポーネント：キューペア深さベースのフローコントローラ」を有する。
本発明のシステムは、サービスレートを向上しようとキューペアの数を変更するために、第１コンポーネントを使用する。
また、本発明のシステムは、到着フローを制御し、到着Ｉ／Ｏリクエストストリームの分布を調整するために、２つのウォーターマークを使用する第２コンポーネントをさらに実装することができる。
さらに詳細な内容は、次のセクションで説明する。
【００２１】
＜＜２．ＮＶＭｅＱＰＯのシステムの概要＞＞
このセクションでは、一部のＮＶＭｅｏＦの具現において、データ経路の背景技術と制限について紹介した後、問題の定式化（ｐｒｏｂｌｅｍ  ｆｏｒｍｕｌａｔｉｏｎ）及び関連するアルゴリズムを紹介する。
図２Ａは、このセクションで使用する用語を要約したものを示す表である。
【００２２】
＜２．１．ＮＶＭｅｏＦの背景技術＞
ＳＳＤは、アクセス速度が速く、遅延が小さいため、ＳＳＤの容量が増加し、ＳＳＤの価格が下がるにつれ、特定の市場（例えば、データセンター市場）で徐々に従来のＨＤＤを代替している。
従来、ＳＳＤは、ＡＨＣＩ（Ａｄｖａｎｃｅ  Ｈｏｓｔ  Ｃｏｎｔｒｏｌｌｅｒ  Ｉｎｔｅｒｆａｃｅ）メカニズムにより、ＳＡＴＡ（Ｓｅｒｉａｌ  Ａｄｖａｎｃｅｄ  Ｔｅｃｈｎｏｌｏｇｙ  Ａｔｔａｃｈｍｅｎｔ）又はＳＡＳ（Ｓｅｒｉａｌ  Ａｔｔａｃｈｅｄ  Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ）のインターフェーススペックを介してサーバマザーボードに接続される。
しかし、上述の具現性能を制限する２つのボトルネック現像がある。
【００２３】
〈（１）第１ボトルネック：並列化の欠如〉
ＳＳＤの高いＩ／Ｏ速度は、ＳＡＴＡインターフェースによりボルトネック現像が発生する。
ＳＡＴＡは、元々従来のＨＤＤのために設計され、ＳＳＤの帯域幅よりも遥かに低い、最大６００ＭＢ／秒の帯域幅のみ提供する。
ＮＶＭｅ（Ｎｏｎ−Ｖｏｌａｔｉｌｅ  Ｍｅｍｏｒｙ  Ｅｘｐｒｅｓｓ）というインターフェーススペックは、ボルトネック現像を克服するための並列化及び直接アクセスを説明するものである。
【００２４】
ＮＶＭｅは、ＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  Ｅｘｐｒｅｓｓ）バスチャネルを使用し、６４ｋ個のコマンドキュー及びキューあたりの最大６４個のコマンドをサポートすることにより、ＳＳＤ帯域幅の使用増加を説明する。
これに比べて、ＳＡＴＡは、最大３２個のコマンドキュー及びキューあたりの１個のコマンドのみサポートする。
ＮＶＭｅは、マルチコアプロセッサリソースを使用するのに役立つＰＣＩｅバスチャネルにおいて、多数のＩ／Ｏ動作を並列に処理することにより、コンピューティング全体の性能を向上させる。
また、ＳＡＴＡ及びＳＡＳと異なり、ＮＶＭｅ装置は、比較的高速のＰＣＩｅ接続を直接使用してシステムＣＰＵと通信するため、中間のスタック階層を迂回し、Ｉ／Ｏの遅延時間を減らす。
【００２５】
〈（２）第２ボルトネック：比較的厳しい計算−ストレージカップリングによる拡張性の問題〉
１つのＳＳＤ配置方法は、クライアントインスタンス（ｃｌｉｅｎｔ  ｉｎｓｔａｎｃｅｓ）（例えば、仮想マシン、ドッカーコンテナ（ｄｏｃｋｅｒ  ｃｏｎｔａｉｎｅｒ）又はその他のアプリケーション）が同一のサーバで実行され、関連するＳＳＤリソースを使用するサーバにＳＳＤを配置することを含む。
しかし、ストレージと計算リソースとがカップリングするため、このようなアーキテクチャは拡張しない。
例えば、サーバのディスクスロット数によりストレージが制限され、計算及びストレージが過度利用又は過少利用される。
このような過度利用又は過少利用は、低い性能効率性（例えば、不充分なリソース管理）及び低い財務効率性（例えば、高い総所有コスト）につながる。
【００２６】
この制限を克服するために、ＮＶＭｅｏＦは、ＮＶＭｅＳＳＤ（一部の専用ストレージ、専用ホスト／サーバに格納）を一般サーバに固定せず、クラスターに直結することにより、ストレージと計算とを分離（デカップリング）する。
このようなデカップリングは、他のサーバに計算タスクを残している間に、多くの（例えば、数千個以上）ＮＶＭｅＳＳＤのクラスターとの結合を容易にする。
その結果、様々な拡張性に関する特徴（例えば、データの複製及びマイグレーション（ｍｉｇｒａｔｉｏｎ））が達成される。
【００２７】
図２Ｂは、本発明の一実施形態によるＮＶＭｅｏＦプロトコルのアーキテクチャを説明するための図であり、ＮＶＭｅｏＦによりサポートされる異なるトランスポートモード等のＮＶＭｅｏＦシステムにおける異なる階層の例を示す。
ＮＶＭｅｏＦは、ＮＶＭｅ１．２プロトコルに基づき、ＮＶＭｅトランスポートの階層への変更を含む。
ＮＶＭｅｏＦは、３つの送信モード「メモリ」、「メッセージ」並びに「メモリ及びメッセージ」をサポートする。
（ＰＣＩｅを介する）ＮＶＭｅとＮＶＭｅｏＦとの差異点の１つは、ＮＶＭｅＰＣＩｅは共有メモリを使用するのに対し、ＮＶＭｅｏＦはメッセージベースのトランスポートであるファブリック（Ｆａｂｒｉｃｓ）で実行されるというものである。
【００２８】
図２Ｂに示すように、ＮＶＭｅｏＦも、（帯域幅の約４０Ｇｂｐｓを有する）ＩｎｆｉｎｉＢａｎｄ、ＲｏＣＥ（ＲＤＭＡ  ｏｖｅｒ  Ｃｏｎｖｅｒｇｅｄ  Ｅｔｈｅｒｎｅｔ）、及びｉＷＡＲＰ（Ｉｎｔｅｒｎｅｔ  Ｗｉｄｅ  Ａｒｅａ  ＲＤＭＡ  Ｐｒｏｔｏｃｏｌ）（ＲｏＣＥ及びｉＷＡＲＰは、帯域幅が約２５Ｇｂｐｓ又は１００Ｇｂｐｓであるイーサネットを介してなる）を含むＲＤＭＡ（Ｒｅｍｏｔｅ  Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）を使用し依存するというものである。
ｉＳＣＳＩ（Ｉｎｔｅｒｎｅｔ  Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅ）に比べて、ＮＶＭｅｏＦは、さらに低い遅延を有する。
これにより、トラフィックがネットワークを通るのに若干の遅延（例えば、数マイクロ秒）が追加される。
ＮＶＭｅｏＦは、ホストとストレージシステムとの間でのより早いアクセスを可能にする。
【００２９】
ＮＶＭｅ及びＮＶＭｅｏＦは、上述の制限を克服するのに使用するが、ＮＶＭｅｏＦに使用するサービスレートは、到着Ｉ／Ｏリクエストのストリーム及びクライアントスタックのキューペア数等の様々な要素に対して独立していない。
次のサブセクションにおいて、実装に関する詳細な内容を説明する。
【００３０】
＜２．２．問題の公式化＞
図２Ｃは、本発明の一実施形態によるＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）ポートにおけるキューペアのキューイングモデル（ｑｕｅｕｅｉｎｇ  ｍｏｄｅｌ）を説明するための図であり、例示的なＮＶＭｅｏＦの環境におけるＩ／Ｏ経路の例示を示す。
上述の通り、ＮＶＭｅｏＦは、計算とストレージとの分離に使用する。
従って、図２Ｃは、２つのスタックであるクライアントスタック（データ処理サーバ）とターゲットスタック（ストレージプール）とを示す。
【００３１】
Ｉ／Ｏリクエストは、クライアントスタックの「ユーザアプリケーション」（図２Ｃの左側）により生成される。
オペレーティングシステムのディスパッチャ（図２Ｃの右側に示すディスパッチャとは別にキューペアにＩ／Ｏを分配）は、ＮＵＭＡの優先ターゲットリストに基づいた各Ｉ／Ｏリクエストについて、ＮＵＭＡ（例えば、複数の内でＮＵＭＡを適用した処理回路）を選択する。
経路が選択されると（例えば、ＮＵＭＡ１のＮＩＣ３が第２ターゲットグループにある第１ターゲットと通信するために選択）、このようなＩ／Ｏリクエスト及び対応する計算タスクがこのＮＵＭＡに割り当てられる（例えば、ＣＰＵ及びメモリリソースが使用される）。
【００３２】
Ｉ／Ｏのアクセス作業は、ネットワークスイッチを介してターゲットスタックに伝達される。
また、各ＮＵＭＡ内部のメモリは、２つの部分「ユーザバッファ」及び「ＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）」に分かれる。
ユーザバッファは、ターゲットスタックから戻ってきたＩ／Ｏの結果を保存するメモリ領域である。
ＤＭＡは、ＮＶＭｅｏＦターゲットとＩ／Ｏ送信との送受信を専用にする。
関連するＲＤＭＡ送信プロトコルがＤＭＡを行うために連続物理メモリを得るために、メモリ領域の固定を要求することもあるため、このＤＭＡは部分的に使用される。
一部の実施形態において、クライアントスタックでパラメータを調節することにより、性能を向上させる。
【００３３】
また、Ｉ／Ｏ経路は、図２Ｃの右側に示すサーバキューのモデルにより説明される。
各ＮＩＣポートは、自身で集中化したキュー（即ち、ＮＩＣ＿ＣＱ）を有し、与えられたＮＩＣポートに割り当てられたＩ／Ｏは、まず（ＮＩＣ＿ＣＱ）にキューイングする。
その後、ディスパッチャは、キューイングしたＩ／Ｏを１つずつ対応するキューペア（ＮＩＣ＿ＱＰ）に分配する。
各キューペアは、ターゲットスタックの対応するキューペア（ＴＡＲ＿ＱＰ）に接続される。
ディスパッチャは、クライアントスタックにおけるキューペア間の負荷バランスを取る。
【００３４】
（ＮＩＣ＿ＱＰ）及び（ＴＡＲ＿ＱＰ）は、単一サーバ（例えば、ブラックボックス）としてモデリングされ、次のことが観察される。
（１）（ＮＩＣ＿ＱＰ）の数は、サービスレートに影響を与え、これらの関係は線形でなくてもよい。
（２）また、（ＮＩＣ＿ＱＰ）でキューイングしたＩ／Ｏリクエストの数は、サービスレートに影響を与え、これらの関係は線形でなくてもよい。
（３）システムは、（ＮＩＣ＿ＣＱ）でキューイングしたＩ／Ｏの数が有限であり、即ち、到着レートがサーバのサービスレート以下であることを保証する。
【００３５】
それぞれのＩ／Ｏリクエストの遅延を最小化するために、以下に示す数式２−１の最適化フレームワークが使用される。
【数２−１】
2020201957.tif 000003
【００３６】
数式２−１の目的関数は、Ｍ／Ｍ／１キューイングモデルによるＩ／Ｏリクエストの平均遅延を示し、これは、一般にキューの動作を説明するモデルを示す。
二番目の数式は、システムが安定的であることを保証する制約を示す。
三番目の数式は、サービスレートが２つの入力パラメータであるクライアントスタックにおけるキューペアの数及び平均のキューイングＩ／Ｏリクエストの高さの関数としての表現（又は「回帰」、即ち、回帰技術を使用してモデリング）を反映する。
数式２−１の最後の行は、本発明のシステムが平均のキューイングＩ／Ｏリクエストの高さを制御するために、（以下でより詳細に説明する）低ウォーターマークを使用することを示す。
【００３７】
キューペアの深さを調整する方法に関する詳細な内容及び証明は、セクション４．で説明する。
言い換えれば、本発明のシステムは、到着レートがサービスレート以下であることを保証するためのメカニズムを適用する。
λ≦μであれば、目標は、その後にサービスレートμを最大化する方法となる。
【００３８】
【数２−２】
2020201957.tif 000004
【００３９】
図２Ｄは、本発明の実施形態によるボトルネックベースのサービスレート分析及びモデリングに使用される記号及び説明を要約したものを示す表であり、
図２Ｅは、本発明の一実施形態によるウォーターマーク変数及び多数のキューペア変数の関数としてのサービスレートの最大値を見つけるのに使用される例示的な３Ｄ表面を示すグラフであり、このようなドメイン、即ち、低ウォーターマークＷＬ及びキューペアの数Ｎｑを調節することにより、μを最大化すること、を示している例示的な図を示す。
本発明のシステムは、平均のキューイングＩ／Ｏの高さ
2020201957.tif 000005
を直接制御しないが、低ウォーターマークＷＬを調節することにより、間接的に制御することになる。
以下のセクション４．は、これに関する詳細な内容を含む。
【００４０】
例えば、表面が凹型であるという厳格な保証がないため、ランタイムの間、図２Ｅに示す３Ｄ表面で最大ポイントを見付けることが計算上において集約的である。
また、キューペアの数を変更すること、及び低ウォーターマークを調整することに関する作業は、互いに異なる関連オーバーヘッドを有する。
一般に、キューペアは、ＣＰＵ及びメモリリソースを消費するスレッドを含むため、キューペアの数の調整は計算コストがさらにかかる。
従って、本発明のシステムは、一実施形態において、どの変数がサービスレートにさらに影響を与えるかに基づいた異なるシナリオのもと、一方の変数を固定させ、他方の変数を調整する。
言い換えれば、本発明のシステムは、２つの方法を適用する。
【００４１】
〈第１方法〉
もし、本発明のシステムがウォーターマークを固定させた場合、本発明のシステムは、サービスレートμを最適化（最大化）するために、Ｎｑを調節する。
【数２−３】
2020201957.tif 000006
【００４２】
〈第２方法〉
もし、本発明のシステムがキューペアを固定させた場合、本発明のシステムは、サービスレートμを最適化（最大化）するために、ＷＬを調節する。
【数２−４】
2020201957.tif 000007
【００４３】
第１方法は、第１コンポーネントにより行われ、第２方法は、第２コンポーネントにより行われる。
次のセクションでどのアプローチを使用するかについて説明する。
【００４４】
＜＜３．第１コンポーネント：キューペア数の管理者＞＞
このセクションでは、まず、クライアントスタックにおけるキューペア数の境界について説明する。
その後、互いに異なる関連シナリオによって、互いに異なる目的に基づいてキューペアの数を調整するための２つの異なるアプローチを説明する。
また、上述の通り、第１アプローチと第２アプローチとを切り替えるためのＮＶＭｅＱＰＯのソリューションを説明する。
【００４５】
＜３．１．キューペア数の境界に関する説明＞
図３Ａは、本発明の一実施形態によるクライアントスタック及びターゲットスタックのキューペアのモデルを説明するための図であり、集中化したキュー及び複数のキューペアの例示を示し、それぞれの全体部分はクロスハッチング（ｃｒｏｓｓ  ｈａｔｃｈｉｎｇ）で示す。
クライアントスタックとターゲットスタックいずれも多数のキューペアがある。
それぞれのスタックにおけるそれぞれのキューペアについて、本発明のシステムはそれぞれのキューペアに対して別のスレッドを生成し、各キューペアによって作動するソフトウェアＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ，Ｆｉｒｓｔ  Ｏｕｔ）キューを構成する。
【００４６】
ターゲットスタックの構成がホストシステムによって容易に調整されない可能性があるため、本発明の実施形態において、クライアントスタックにおけるキューペアの数を調整することを説明する。
クラウドコンピューティングのインフラ構造の様々な実装では、ターゲットスタックに関するさらなる細部情報が利用されない場合がある。
【００４７】
異なるキューペアの構成に関して、複数のポイントを考慮する必要がある。
（１）２つのスタックにおけるキューペアの数は、同一であっても異なってもよい。
（２）クライアントスタックにおける各キューペアは、ターゲットスタックにおける１つのキューペアと接続される。
（３）キューペアＱＰの個数が異なると、サービスレートμ全体が異なってもよく、これらの関係は線形でなくてもよい。
（４）ＮＶＭｅにあるターゲットは、接続されるキューペア数の最大値（ＮＴａｒｇｅｔ）を通知する。
（５）ＱＰ数に制限がある。また、本発明のシステムは、クライアントスタックにおけるキューペアの上限をターゲットスタックにおけるキューペアの数とマッチングさせる。
（６）ターゲットが書き込むための単一ＳＳＤを有し、且つキューペアあたりのキュー深さがターゲットによって通知される場合（Ｗｍａｘ）、単一キューペアは与えられた行レート（ｌｉｎｅ  ｒａｔｅ）を達成するのに十分である。
【００４８】
従って、以下に示す数式３−１が得られる。
【数３−１】
2020201957.tif 000008
【００４９】
〈なぜ、キューペア数の最大値を使用しないのか。〉
経験的に、本発明のシステムは、最大ワークロードを送信し、サービスレートを向上させるために使用されるキューペア数の最大値を決定する。
例えば、ホストシステムは、ターゲットベンダーによって通知されるターゲットスタックと同一のクライアントスタックにおけるキューペア数の最大値を使用するように構成される。
しかし、ターゲットによって通知されるキューペア数の最大値を使用することは最適ではない。
例えば、キューペアのさらなる数を維持することにより、クライアント側でオーバーヘッドとして用いられ、また、より小さなワークロードに多数のキューペアを使用することにより、性能に逆の影響を与える（例えば、アイドリングキューペアがリソースを浪費する）。
【００５０】
言い換えれば、クライアントスタックにより多くのキューペアを有することは、クライアント及びターゲットスタックにおいて、ネットワーク帯域幅及びＣＰＵリソースの使用の増加を可能にすることにより、性能を向上させる。
しかし、キューペアを有するにはコストがかかる。
コストが発生する理由は、キューペアを設定すると、（クライアントスタックにおける）ホストＮＵＭＡのＣＰＵ及びメモリリソースを消費するスレッドを生成するからである。
実際に、ＮＵＭＡのＣＰＵ及びメモリリソースは制限的であり、高コストであり、所定の閾値を超えて多数のアイドリングキューペアを有することは好ましくない。
【００５１】
本発明は、まず、システム利用に基づいて、キューペアの数を繰り返し（単位時間当たり１回）適応的に増加及び減少させる、「保守的アプローチ」をサブセクション３．２．で紹介する。
本発明は、ランタイムモニタリング及び回帰を使用してキューペアの数を所定の動作ポイントに直接変更することにより、周期的により正確な性能の最適化を行うための「攻撃的アプローチ」と呼ばれる第２アプローチをサブセクション３．３．で紹介する。
【００５２】
＜３．２．保守的アプローチ＞
システム利用率は、システムがどの程度「十分に」用いられるかを示すことにより、方法を切り替える時点を決定するのに使用される。
図３Ｂは、本発明の一実施形態によるキューペアの数及びキューペアの深さを調整するための２つの方法（第１方法及び第２方法）の比較を示す表であり、２つの方法の差異点を要約したものである。
また、図３Ｃは、本発明の一実施形態による第１方法でキューペアの数を調整するための２つのアプローチ（第１アプローチ及び第２アプローチ）の比較を示す表であり、第１方法のために開発した２つのアプローチを要約する。
本発明は、このサブセクションで「保守的アプローチ」を紹介し、サブセクション３．３．で「攻撃的アプローチ」を説明する。
【００５３】
第１方法は、サービスレートを即座に、且つ、著しく変更させるが、かなりのオーバーヘッドをトリガーするのに対し、第２方法は、低いオーバーヘッドでサービスレートの所定の動作ポイントにゆっくり集まる。
このように、本発明の実施形態において、システムは、例えば、システム利用率が過少利用閾値よりも低い場合、リソースを節約して残ったキューペアのサービスレートを向上させるために、キューペアを除去（非活性化）する。
【００５４】
同様に、システム利用率が過度利用閾値よりも高い場合、システムは、不安定なシステムの生成を避けるために、新たなキューペアを生成（活性化）する。
これらの２つの場合は、ウォーターマークを変更することにより、比較的短期間に改善する必要がない比較的極端な動作環境を示す。
一方、過少利用でない期間及び過度利用でない期間の範囲内において、本発明のシステムは、サービスレートを向上させるために、ウォーターマークを使用する。
【００５５】
図３Ｄは、本発明の一実施形態による異なるシステム利用率のケースに基づいた切り替え最適化のアプローチに関する動作態様を説明するための例示的な図であり、システム利用率に基づいたランタイムの間、２つのアプローチがどのように切り替わるか例示を示す。
また、図３Ｅは、本発明の一実施形態によるキューペアの数及びキューペアの深さを調整するのに使用される閾値及びターゲット利用率、並びにシステム利用率の計算を示す表であり、図３Ｄで使用する記号を説明している。
一部の例示において、計算コストがかかるため、キューペアの数を変更する頻度を制限するのが有利である。
このような制限を達成するために、本発明のシステムは２つの閾値に到着すると、キューペアの数を変更するか否かを決定するために２つの追加条件を導入する。
【００５６】
〈第１条件〉
過度利用又は過少利用の期間が既設定の閾値時間ウィンドウＴｕｔｌ（又は「第１長閾値」）と比較することにより、十分に長いか否かを判断する。
〈第２条件〉
キューペアの増加又は減少がサービスレートを向上させるか否かを判断する（サブセクション３．３．及び図３Ｈの表で説明）。
【００５７】
図３Ｆは、本発明の一実施形態によるキューペアの数及びキューペアの深さを調整するのに使用されるケース及び対応する動作を示す表である。
上述の条件に基づいて、図３Ｆの表に示すように、７つの異なるシナリオについて、次の動作が適用される。
【００５８】
具体的には、ケース１及びケース２は、システム利用率が「過度利用閾値」（又は「第１利用閾値」）よりも大きい状況に関し、本発明のシステムはサービスレートを即時向上させる。
ケース１は、２つの条件を完全に満たさない状況を表し、本発明のシステムは、これを一時的なバースト、又はＮｑの変更が役に立たない場合と見て、本発明のシステムは何もしない。
ケース２は、２つの条件を完全に満たす状況を表し、本発明のシステムは、その後のサービスレートを即時改善しようと第１アプローチを行うために第１コンポーネントをトリガーする。
【００５９】
システム利用率が「過少利用閾値」（又は「第２利用閾値」）よりも低いと、ケース３及びケース４に対して同様の設計が使用される。
システム利用率が過度利用及び過少利用でない場合（即ち、「安全区域」）、本発明のシステムは、ウォーターマークを調節することによりサービスレートを最大化させる（さらなる詳細な内容は、下記のセクション４．で説明する）。
【００６０】
本発明のシステムは、大きなウィンドウＴｒｅｇ（又は「第２長閾値」）を有する回帰ベースの最適化（例えば、数値最小化）（また、第１コンポーネントによって達成される）をさらに行って、全てのキューペアのデータポイントの数にわたって最上のサービスレートを見つけることで性能をさらに向上させる。
これを「攻撃的アプローチ」といい、図３Ｅの表にケース７を示しており、ここで本発明のシステムは、第１条件及び第２条件を考慮することなく、その値を１ずつゆっくり調整する代わりに、キューペアの数を所定の動作ポイントに直接調整する。
詳細な内容は、サブセクション３．３．に記述する。
このような数値最小化は、キューペアの数を決定して設定するための数値最小化を直近で使用した後、第２長閾値を超える長さを有する時間間隔が経過すると、行われる。
【００６１】
頻繁に変更する設定のオーバーヘッドをさらに減少させるために、本発明のシステムは、サービスレートを最大化する代わりに、ターゲットシステム利用率に集まるように構成される。
具体的には、本発明のシステムは、サービスレートμが増加するが、ターゲットρＴ（又は「第３利用閾値」）に到着すると（
2020201957.tif 000009
の定義により、サービスレートの増加は、同じ到着レートλ下でρを減少させることに気付く）、頻繁な調整は計算コストがかかるため、本発明のシステムは、最大サービスレートにさらに接近するために追加調整をする必要がない。
【００６２】
従って、本発明のシステムは、異なる扱いをする状況を区別するために、システム利用率を（図３Ｈに示す他の条件と共に）指標として構成し、性能を向上させるために、異なるアプローチ及び対応する動作を使用する。
このように、本発明の実施形態において、動作中の状況が変化に適応し、特定のパラメータ変更により発生するシステムのオーバーヘッドコストを考慮する。
【００６３】
具体的には、ケース５は、利用率がターゲットよりも高いが、利用率が過度利用閾値よりも低い状況を表す。
この領域において、システムは、第２コンポーネントを使用することによりターゲットに集まる。
ターゲットに到着して利用率が（ρＴ、ρＴ）の範囲にあると、本発明のシステムは、ケース６に示すように、第１コンポーネント及び第２コンポーネントを呼び出す必要がない。
さらに、図３Ｇは、本発明の一実施形態によるキューペアの数を調整するのに使用される２つのコンポーネントのワークフロー図であり、このようなアプローチ切り替え動作の主要手順を示す。
【００６４】
＜３．３．攻撃的アプローチ＞
キューペア数の保守的な調整は、比較的漸進的な方法で性能改善タスクを処理するが、本発明のシステムも、保守的アプローチが非常に遅い場合において、キュー計算の数を比較的計上算効率的な数に攻撃的に調整する。
【００６５】
図３Ｈは、本発明の一実施形態によるキューペアの数を調整するのに使用される第１コンポーネントのサブコンポーネント及び機能を示す表であり、図３Ｈの表は、（第２条件、即ち、１つのキューペアが増加／減少した後に推定された性能変化を確認するための）保守的アプローチ、及び（最大サービスレートに対する所定の動作ポイントを見付けるための）攻撃的アプローチで使用する第１コンポーネントに使用した３つのサブコンポーネントを示す。
【００６６】
このようなサブコンポーネントを使用する２つのアプローチ間の１つの差異点は、保守的アプローチは、第３サブコンポーネントの「第１モード：概略的な回帰」と通信する第２サブコンポーネントの「第１モード：概略的な予測」を呼び出すのに対し、攻撃的アプローチは、第３サブコンポーネントの「第２モード：正確な回帰」と通信する第２サブコンポーネントの「第２モード：正確な予測」を呼び出すことである。
従って、攻撃的アプローチは、保守的アプローチに比べて計算コストがかかり、このような理由により、本発明のシステムは、頻繁に呼び出さない（即ち、図３Ｅの表において、Ｔｒｅｇは比較的長時間の間隔であるべきである。例えば、１．０秒〜１００．０秒（例えば、１０秒））。
【００６７】
図３Ｉは、本発明の一実施形態によるキューペアの数を調整するのに使用される第１コンポーネントのサブコンポーネント間の関係を示す図であり、第１コンポーネントにあるサブコンポーネント間の関係を示す。
【００６８】
本発明のシステムが性能予測関数を有すると、本発明のシステムは以下に示す数式３−１の最適化フレームワークを行う。
2020201957.tif 000010
及びＷＬが固定されると、数式３−２に示すように、本発明のシステムはサービスレート
2020201957.tif 000011
を最大化することにより、Ｔｓｙｓを最小化するように試みる。
【数３−２】
2020201957.tif 000012
【００６９】
ここで、最初の数式は、フレームワークの目的が比較的低い遅延（例えば、遅延はＭ／Ｍ／１キューイング理論に基づいて計算される）を達成するキューペアの数を見つけることを示す。
二番目の数式は、ＷＬが与えられると、本発明のシステムがキューペアの数に対して繰り返すことを示す。
三番目の数式は、Ｎｑの境界である。
四番目の数式は、上限がターゲットスタックにおいて通知される最大キューペア数と一致しなければならないことを示す。
また、最後の数式は、システムが安定的であることを保証する。
【００７０】
本発明のシステムは、その後の図３Ｊにおいて、陰影を付けた曲面の上方境界を形成する線において、最小のＴｓｙｓポイントを探索する。
図３Ｊは、本発明の一実施形態による回帰ベース（ｒｅｇｒｅｓｓｉｏｎ−ｂａｓｅｄ）の攻撃的アプローチに使用された例示的な目的関数（ｏｂｊｅｃｔｉｖｅ  ｆｕｎｃｔｉｏｎ）を示すグラフである。
関数μの曲線及びキューペアの数は線形曲線ではなく、即ち、１つの所定の動作ポイントを有する。
本発明のシステムは、所定の動作ポイントを見つけるために、周期的に曲線をモニタリング及び回帰し、アルゴリズム（例えば、グリーディ（ｇｒｅｅｄｙ）アルゴリズム、勾配降下法、Ａ＊探索アルゴリズム及び／又は他の機械学習方法等）を使用する。
【００７１】
＜＜４．第２コンポーネント：キューペア深さベースのフローコントローラ＞＞
キューペア数の他に、キューペアの深さもシステムの性能に影響を与える。
言い換えれば、サービスレートは、クライアントスタックのキューペアにおいて、平均のキューイングＩ／Ｏリクエストの高さ（即ち、キュー深さ）に応じて異なる。
キューの深さは、Ｉ／Ｏリクエスト間のＩ／Ｏフロー及び遅延（又はギャップ）を制御し、適切な遅延（又はギャップ）を有することにより、ターゲットスタックリソースが並列に行われるバックグラウンドプロセスをよりスケジューリングする機会を有する。
しかし、キューの深さを直接制御することは計算上難しい。
その結果、ＮＶＭｅＱＰＯの第２コンポーネントは、キューの深さに関する２つのウォーターマークを調節することで（例えば、到着レートでなく到着パターンを制御することで）サービスレートを向上させる。
【００７２】
＜４．１．ワークロードによるサービスレートキューイングモデル＞
図４Ａは、本発明の一実施形態によるキューペアの深さを調整するのに使用されるキューイングモデルを説明するための例示図である。
図４Ａで示し、以下でさらに詳細に説明する通り、ストレージコントローラキューペアを説明するためにモデルが使用される。
図４Ｂは、本発明の一実施形態によるキューペアの深さの調整と関連する用語及び対応する説明を示す表であり、このセクションで使用する複数の用語を要約したものである。
【００７３】
ホストのイニシエータＨＢＡ（Ｈｏｓｔ  Ｂｕｓ  Ａｄａｐｔｅｒ）からストレージコントローラのターゲットアダプタへのＩ／Ｏリクエスト（ＳＣＳｉコマンド）は、まず、ＮＩＣポートの集中化したキュー（ＮＩＣ＿ＣＱ）にキューイングする。
Ｉ／Ｏリクエストは、秒あたりのＩ／Ｏ単位（ＩＯＰＳ）である到着レートλを有する。
その際、（ＮＩＣ＿ＣＱ）は、そのＩ／Ｏを、それと関連するＮｑキューペア（ＮＩＣ＿ＱＰ）に均等に配ることを目指すディスパッチャに送信する（Ｎｑは、ＮＩＣにあるキューペアの数である）。
同一の（ＮＩＣ＿ＣＱ）と関連するこのようなキューペアは、同一の構成を有する。
【００７４】
また、比較的長時間間隔にわたって、キューペアはλ／Ｎｑ到着レートを得、キューペアはＩＯＰＳ単位であるμサービスレートを有する。
ＮＩＣ＿ＱＰは、無限キューではなく、１つのＣＱと関連する（ＮＩＣ＿ＱＰ）は同一であり、固定の最大深さＱｍａｘ（Ｃｌｉｅｎｔ）を有し、これはそのＱＰのターゲットによりキューイング及び処理されるＩ／Ｏ数の最大値である。
【００７５】
本発明の実施形態において、サービスレートは固定されず、キューイングしたＩ／Ｏの数と関連する。
（ＮＩＣ＿ＱＰ）が満杯になると、この（ＮＩＣ＿ＱＰ）に割り当てられた任意の新たなＩ／Ｏ（即ち、まだ処理されていないＩ／Ｏがポート限度に到着する）は、ストレージポートから送信された「ＱＦＵＬＬ」（即ち、キューが満杯になる）エラーメッセージにより拒否される。
ＱＦＵＬＬメッセージがイニシエータへ送信されると、ＨＢＡが暫くした後にＩ／Ｏを一時中止した後、ゆっくりとストレージポートの実行を再度試みる。
満杯になったＱＰへＩ／Ｏを送信することは、「ＱＦＵＬＬ」エラーをトリガーし、性能を低下させる。
【００７６】
ＱＦＵＬＬエラーの他に、サービスレートは、キューイングしたＩ／Ｏの高さと関連する。
図４Ｄは、本発明の一実施形態によるキューペアの深さを調整するコンテクストで使用されるキューイングした入力／出力（Ｉ／Ｏ）の高さとサービスレートとの関係におけるさらなる例示を説明するための図である。
図４Ｃに示すように、「プッシュなし」と「プッシュ」がある場合、３つの軽いクロスハッチングされたＩ／Ｏリクエストに対するサービスレートは異なり、低い高さは大きなサービスレートを有する。
後者は、クライアントスタックとターゲットスタックのキューペアから「ＱＦＵＬＬ」エラーが発生する可能性が高いため、「ＱＦＵＬＬ」エラー及び対応する再試行によってサービスレートがかなり遅くなる。
【００７７】
しかし、キューイングした高さとサービスレートとの間は、線形関係、即ち、「高さが低いほどサービスレートがさらに良い」のではない。
例えば、（ＮＩＣ＿ＱＰ）のキューイングした高さが非常に低い場合、（ＴＡＲ＿ＱＰ）リソースが完全に活用されず、よって、サービスレートが最大化しない。
従って、「キューペア超過利用：過度に多いＱＦＵＬＬ」又は「キューペア過少利用：少ないＱＦＵＬＬであるがアイドリングリソース」の間にトレードオフがある。
平均のキューイングＩ／Ｏリクエストの所定の動作ポイント（即ち、本発明のシステムが最上のサービスレートを達成する適切な圧力値）がある。
これに対する例示は、図４Ｄに示しており、ここでｈ＝５は、最上のサービスレート１０を有する。
【００７８】
このような所定の動作ポイントは、次の２つ理由のために存在する。
（１）所定の動作ポイントは、
（ｉ）「ＱＦＵＬＬ」を減少させるために高さを低くし、
（ｉｉ）過度に低いキュー高さを有さないことによりリソースを完全に利用することを目指すことで、上述のトレードオフのバランスを取る。
（２）所定の動作ポイントは、また、ターゲットスタックが並列に行われるバックグラウンド動作（例えば、「メモリコピー」のようなシステム割り込み）をスケジューリングすることを保証し、Ｉ／Ｏスタックのハートビート（ｈｅａｒｔｂｅａｔ）に合わせて同期化するように若干のアイドリング時間を許容する。
従って、本発明のシステムは、最上のサービスレートを得るために、所定の動作ポイントに平均キュー高さを合わせるようにする。
【００７９】
＜４．２．２つのウォーターマークによるサービスレートの制御＞
本発明のシステムは、性能を向上させるために平均キュー高さを直接制御することはないが、本発明のシステムは、２つのウォーターマーク、即ち、高ウォーターマークＷＨ（又は「上限キューの高さ閾値」）及び低ウォーターマークＷＬ（又は「下限キューの高さ閾値」）を使用することにより間接的に制御する。
具体的に、ＷＨはＱＦＵＬＬを防止するために上限をマッチングするのに使用され、ＷＬは高さを制御し、最上のサービスレートを見つけるのに使用される。
【００８０】
図４Ｅは、本発明の一実施形態によるキューペアの深さを調整するためのウォーターマークベースの最適化における条件及び対応する動作を説明するための図であり、各キューペアに対するウォーターマークベースの最適化の条件と対応する動作を要約したものである。
図４Ｆは、本発明の一実施形態によるキューペアの深さを調整するためのウォーターマークベースの最適化に関する一部の例示的な手順を示す図であり、図４Ｇは本発明の一実施形態によるキューペアの深さを調整するためのウォーターマークベースの最適化に関する例示的なワークフローを示すフローチャートであり、図４Ｈは、本発明の一実施形態によるキューペアの深さ調整に関する用語及び対応する説明を示す表である。
図４Ｆ及び図４Ｇは、ウォーターマークベースの最適化の基本体系をさらに示す。
本発明の実施形態において、ＮＶＭｅＱＰＯは、負荷バランス又はディスパッチャよりはＩ／Ｏフロー制御方法の方を使用する。
実際に、ある負荷バランスアルゴリズム、さらに非常に単純なラウンドロビンアルゴリズムもまた実装される。
【００８１】
具体的には、それぞれのキューペアについて、図４Ｆの第１行に示すように、「ロック」と呼ばれるロックフラグがある。
このフラグは、ディスパッチャが１つの単一（ＮＩＣ＿ＱＰ）に新たなＩ／Ｏを割り当てることを許容するか否かを示す。
Ｉ／Ｏは、各（ＮＩＣ＿ＱＰ）に１つずつ順に割り当てられ、本発明のシステムは、可能な全てのシナリオを次の４つの場合に分類する。
【００８２】
ケース１：（ＮＩＣ＿ＱＰ）は、ロックが解除され満杯でない場合（「ｆｕｌｌ」はＷＨに到着したことを意味）、本発明のシステムは、（ＮＩＣ＿ＱＰ）にＩ／Ｏをエンキューする。
（ＮＩＣ＿ＱＰ）の「ｅｎｑｕｅｕｅ（）」の手続きは、図４Ｅ（１）及び図４Ｆの第１１行〜第１８行に示すように、この（ＮＩＣ＿ＱＰ）に新たなＩ／Ｏをエンキューするために呼び出される。
【００８３】
ケース２：新たなＩ／Ｏがこの（ＮＩＣ＿ＱＰ）にキューイングし続ける間、ＮＶＭｅＱＰＯは、（ＮＩＣ＿ＱＰ）が満杯か否かも確認する。
図４Ｅ（２）及び図４Ｆの第１７行に示すように、満杯になると、この（ＮＩＣ＿ＱＰ）がロックされ、この（ＮＩＣ＿ＱＰ）において、これ以上新たなＩ／Ｏリクエストがキューイングすることを許容しない（即ち、「ｗａｉｔ（）」の手続きが呼び出される）。
このＮＩＣ＿ＱＰは、（ＷＨ−ＷＬ）個のキューイングしたＩ／Ｏが完了するまで待機する。
【００８４】
ケース３：（ＮＩＣ＿ＱＰ）がロックされたが、（ＮＩＣ＿ＱＰ）が（ＷＨ−ＷＬ）個のキューイングしたＩ／Ｏを完了した場合（即ち、「ＷＬＴｒｉｇｇｅｒｅｄ」フラグが真である場合）、（ＮＩＣ＿ＱＰ）はロックが解除され（図４Ｆの第８行）、新たなＩ／Ｏがエンキューされることを許容し（図４Ｆの第９行）、これもまた図４Ｅの（３）に示している。
【００８５】
ケース４：ケース２と同様に、（ＮＩＣ＿ＱＰ）はロックが解除されたが、満杯になった場合、ＮＶＭｅＱＰＯはロックし、「ｗａｉｔ（）」の関数が呼び出される。
この（ＮＩＣ＿ＱＰ）は、（ＷＨ−ＷＬ）個のキューイングしたＩ／Ｏが完了するまで待機する。
【００８６】
要約すると、ＮＶＭｅＱＰのウォーターマークベースのフロー制御は、（ＮＩＣ＿ＱＰ）が満杯になるまで（即ち、ＷＨに到着するまで）、ホストにＩ／Ｏを追加することを許容する。
満杯になると、（ＷＨ−ＷＬ）個のＩ／Ｏが完了するまでロックする。
これを通じて、ＮＶＭｅＱＰは「ＱＦＵＬＬ」エラー数を間接的に減らし、圧力（即ち、長時間間隔にわたる、平均のキューイングＩ／Ｏリクエストの高さ）を制御する。
【００８７】
次のサブセクションでは、この２つのウォーターマークの値を調整する方法と、高いサービスレートを得るためにＩ／Ｏフロー（到着パターン）を制御するようＷＬを動的に調節する方法を提示する。
【００８８】
＜４．２．１．高ウォーターマーク：ターゲットスタックキューペアの最大深さの上限マッチング＞
本発明の実施形態において、クライアントスタックにおけるキューペアのキュー深さは、ターゲットスタックにおけるキューペアのキュー深さと同一の値を有するように構成される。
その理由は、クライアントとターゲットスタックのキューが同じでない場合、ターゲットスタックにおいて多くの「ＱＦＵＬＬ」拒否をトリガーする可能性が高く、性能が大きく低下する可能性があるためである。
例えば、Ｑｍａｘ（Ｃｌｉｅｎｔ）がＱｍａｘ（Ｔａｒｇｅｔ）よりも大きいと仮定することとする。
その後、長時間にわたって、ターゲットコントローラの最大キュー深さに到着すると、ターゲットストレージコントローラは、高価な「ＱＦＵＬＬ」応答をクライアントスタックに返すことで、より多くの受信コマンドを拒否しなければならない。
このような「ＱＦＵＬＬ」拒否は、システムの性能を大きく低下させ、一部のシステムにおいてエラーを引き起こす。
【００８９】
結果、クライアントスタックにおける各ＱＰのサービスレートは、ディスパッチャの観点から減少する。
このような「ＱＦＵＬＬ」拒否を避けるために、本発明のシステムは、制御可能な上限ＷＨをターゲットスタックにおけるＱＰとマッチングするように調整する。
このような「マッチング」のプロセスは、簡単な構成により処理されるが、
（ｉ）クライアントスタックＱｍａｘ（Ｃｌｉｅｎｔ）（クライアントスタックには既設定の制限も存在する）と、
（ｉｉ）ターゲットスタックＱｍａｘ（Ｔａｒｇｅｔ）とにおけるキューペアの最大値が接続の設定（即ち、クライアントスタックにおける各ＱＰがターゲットスタックの対応するＱＰと接続される）の間、通知されるためである。
【００９０】
従って、
【数４−１】
2020201957.tif 000013
最初の数式の例示は、図４Ａに示し、ここでＷＨはＱｍａｘ（Ｃｌｉｅｎｔ）とＱｍａｘ（Ｔａｒｇｅｔ）の内のより小さな値である８に制限された。
【００９１】
＜４．２．２．低ウォーターマーク：キュー高さの制御及び最上のサービスレートを見付ける＞
上述の通り、（ＮＩＣ＿ＱＰ）における平均のキューイングＩ／Ｏリクエストの高さを直接制御するのは難しいため、本発明のシステムは、（ＮＩＣ＿ＱＰ）における平均のキューイングＩ／Ｏリクエストの高さのこの制御を間接的に達成するために、低ウォーターマークを使用する。
【００９２】
このサブセクションでは、まず、実行の可能性を説明し、最上のサービスレートを見つけるのに役立つ最適化フレームワークを紹介する。
2020201957.tif 000014
とＷＬとの正の相関関係を説明する。
本発明の実施形態において、本発明のシステムは、単調増加関数
2020201957.tif 000015
、又は直接
2020201957.tif 000016
としての関数を回帰する。
【００９３】
＜４．２．２．１．正の相関関係に基づいた間接制御＞
固定のＮｑ及びＷＨが与えられると、
2020201957.tif 000017
関数は固定され、本発明のシステムは、以下のようにＷＬ関数としての平均高さを推定する。
特定のＱＰにおける平均のキューイングＩ／Ｏの高さは、キューイングしたＩ／Ｏの数が減少している状況で、ＷＨからＷＬまで１ずつ増加して計算される。
【００９４】
直観的に、以下に示す数式４−２のように、これは各高さの時間長さの加重値と各高さの和をＷＨからＷＬまでの総時間で割った値である。
【数４−２】
2020201957.tif 000018
数式４−２に基づいて、２つの異なる入力値ＷＬ１及びＷＬ２（ＷＬ１≦ＷＬ２）と平均高さの関係は、同一のＮｑとＷＨが与えられると計算される。
【００９５】
ＷＬ２のケースのためのプロセスは、２つの部分に分離する。
第１部分はＷＨからＷＬ１までであり、第２部分はＷＬ１からＷＬ２までである。
従って、以下に示す数式４−２のように定義される。
【数４−３】
2020201957.tif 000019
【００９６】
従って、
【数４−４】
2020201957.tif 000020
図４Ｉは、本発明の一実施形態によるキューペアの深さ調整に関する異なる時間周期の間の例示的な平均のキューイングＩ／Ｏリクエストの高さを説明するための図である。
図４Ｉに示すように、
【数４−５】
2020201957.tif 000021
従って、
【数４−６】
2020201957.tif 000022
数式４−２及び数式４−６に基づく。
【００９７】
【数４−７】
2020201957.tif 000023
従って、ＷＬ１＞ＷＬ２である限り、
2020201957.tif 000024
が保たれる。
それは、
2020201957.tif 000025
がＷＬと正の相関関係である。
即ち、
2020201957.tif 000026
である。
【００９８】
ＮＶＭｅＱＰＯは、ＷＬを使用して平均高さを制御する方法をガイドするために、ランタイムの間、
2020201957.tif 000027
としての単調増加関数を回帰する。
【００９９】
＜４．２．２．２．最適化フレームワーク＞
本発明のシステムは、Ｔｓｙｓを最適化（最小化）する。
即ち、最適化の目標は、システムにおけるＩ／Ｏに対する平均遅延を最小化することである（即ち、（ＮＩＣ＿ＣＱ）及び（ＮＩＣ＿ＱＰ））。
【数４−８】
2020201957.tif 000028
【０１００】
図４Ｊは、本発明の一実施形態による低ウォーターマークを選択するために本発明のシステムにより使用される３次元グラフの例示図であり、目的関数の例示に関する図である。
双曲面
2020201957.tif 000029
とサービスレートに対するウォーターマークＷＬの関数μ＝ｆ（ｇ（ＷＬ））の交差は、図４Ｊの曲線面に陰影を付けた上方境界を形成する曲線に示すように関連性がある。安定的なシステムを保証するために、はよりも大きくする必要があるので、の双曲線を使用する。
【０１０１】
関数μ＝ｆ（ｇ（ＷＬ））は、凹型であるので、図４Ｊに示す曲線例示も凹型である。
実際に、一実施形態において、１つの単一曲線形状に焦点を合わせず、曲線の最小値を見つけることを目指すため、曲線を示す方法を制限する必要はない。
サブセクション３．３．と同様に、本発明のシステムは、所定の動作ポイントを見つけるために、周期的に曲線をモニタリング及び回帰し、グリーディアルゴリズム、勾配降下法、Ａ＊探索アルゴリズム又は他の機械学習方法を使用する。
例えば、本発明のシステムは、サービスレート及び下限キューの高さ閾値の関数としての入出力リクエストあたりの過去の平均処理遅延の多項式適合モデルを使用する。
本発明のシステムは、この作業を処理するための技術の使用を制限しない。
【０１０２】
一実施形態において、クライアントは、本明細書で説明している方法の一部又は全部を行うように構成された処理回路を含む。
「処理回路」という用語は、データ又はデジタル信号を処理するために適用されるハードウェア、ファームウェア及びソフトウェアの任意の組み合わせの意味として本明細書で使用する。
処理回路のハードウェアは、例えば、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）、ＣＰＵ、ＤＳＰ、ＧＰＵ、及びＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）のようなプログラミング可能な論理装置を含む。
本明細書では、処理回路の各機能は、機能を行うために構成されるハードウェア（即ち、ハードウェアに内蔵）、又は非一時的保存媒体に保存されるコマンドを実行するように構成されたＣＰＵのような、より一般的な用途のハードウェアによって行われる。
処理回路は、単一ＰＣＢ（Ｐｒｉｎｔｅｄ  Ｃｉｒｃｕｉｔ  Ｂｏａｒｄ）上で作製されるか、又は複数の相互接続されたＰＣＢに分配される。
処理回路は、他の処理回路を含み、例えば、処理回路はＰＣＢ上に相互接続された２つの処理回路、ＦＰＧＡ及びＣＰＵを含む。
【０１０３】
「第１」、「第２」、「第３」等の用語は、様々な構成要素、コンポーネント、領域、階層、及び／又はセクションを説明するために本明細書で使用するが、これらの構成要素、コンポーネント、領域、階層、及び／又はセクションはこれらの用語によって制限されない。
これらの用語は、１つの構成要素、コンポーネント、領域、階層、又はセクションを他の構成要素、コンポーネント、領域、階層、又はセクションと区別するために使用する。従って、本明細書で説明した第１の構成要素、コンポーネント、領域、階層、又はセクションは、本発明の思想及び範囲を逸脱することなく、第２の構成要素、コンポーネント、領域、階層、又はセクションと称される。
【０１０４】
本明細書で使用する用語は、単に特定の実施形態を説明するためのものであり、本発明を限定しようと意図するものではない。
本明細書で使用するように、「実質的に」、「約」という用語及び同様の用語は、程度の用語ではなく、近似値の用語として使用し、当該技術分野の通常の技術者によって認識される測定された、又は計算された値の固有の偏差を説明するためのものである。
【０１０５】
日本語で単数形式で示されるものは、コンテクスト上明らかに異なるように示さない限り、複数形式を含むものとして意図する。
本明細書の「含む」及び／又は「含んでいる」という用語は、言及した特徴、整数、ステップ、動作、構成要素、及び／又はコンポーネントの存在を具体化するが、１つ以上の他の特徴、整数、段階、動作、構成要素、コンポーネント、及び／又はそのグループの追加又は存在を排除しない。
本明細書で使用する「及び／又は」という用語は、１つ以上の関連して挙げられた物の任意且つ全ての組み合わせを含む。
構成要素のリストに先行する「少なくとも１つ」のような表現は、構成要素のリスト全体を変更し、リストの個々の構成要素は変更しない。
なお、本発明の実施形態を説明する際の「できる」の使用は、「本発明の１つ以上の実施形態」を示す。
なお、「例示的な」という用語は、例示又は図示を示すことを意図している。本明細書の「使用」、「使用する」、及び「使用される」という用語は、それぞれ「利用」、「利用する」、及び「利用される」という用語の同意語と見なす。
【０１０６】
構成要素又は階層が、他の構成要素又は階層「（上）に」、「接続される」、「結合される」又は「隣接する」と言及する場合、それは直接的に、他の構成要素又は階層（上）に接続されるか、結合されるか、隣接するか、又は、１つ以上の中間構成要素又は階層が存在する。
一方、構成要素又は階層が、他の構成要素又は階層に「直接」、「直接接続される」、「直接結合される」、又は「隣接する」と言及する場合、中間構成要素又は階層は存在しない。本明細書で使用するように、単語「又は」は包括的であり、例えば「Ａ又はＢ」は、（ｉ）Ａ、（ｉｉ）Ｂ、並びに（ｉｉｉ）Ａ及びＢの内の何れか１つを意味する。
【０１０７】
本明細書で引用する任意の数値範囲は、引用された範囲内に含まれる同一の数値精度の全てのサブ範囲を含むことを意図している。例えば、「１．０から１０．０まで」又は「１．０と１０．０との間」の範囲は、引用された最小値１．０と引用された最大値１０．０との間の（及び含む）全てのサブ範囲を含むことを意図している。
即ち、例えば、２．４から７．６までのように、１．０以上の最小値及び１０．０以下の最大値を有する。
本明細書で引用する任意の最大数値の制限は、その中に含まれる全てのサブ数値の制限を含むことを意図しており、本明細書で引用する任意の最小数値の制限は、その中に含まれる全てのより高い数値の制限を含むことを意図している。
【０１０８】
ＮＶＭｅｏＦシステムの性能を向上させるための方法及びシステムの例示的な実施形態を本明細書で具体的に説明及び示した。
尚、本発明は、上述の実施形態に限られるものではない。本発明の技術的範囲から逸脱しない範囲内で多様に変更実施することが可能である。
【図１】
2020201957.tif 000030
【図２Ａ】
2020201957.tif 000031
【図２Ｂ】
2020201957.tif 000032
【図２Ｃ】
2020201957.tif 000033
【図２Ｄ】
2020201957.tif 000034
【図２Ｅ】
2020201957.tif 000035
【図３Ａ】
2020201957.tif 000036
【図３Ｂ】
2020201957.tif 000037
【図３Ｃ】
2020201957.tif 000038
【図３Ｄ】
2020201957.tif 000039
【図３Ｅ】
2020201957.tif 000040
【図３Ｆ】
2020201957.tif 000041
【図３Ｇ】
2020201957.tif 000042
【図３Ｈ】
2020201957.tif 000043
【図３Ｉ】
2020201957.tif 000044
【図３Ｊ】
2020201957.tif 000045
【図４Ａ】
2020201957.tif 000046
【図４Ｂ】
2020201957.tif 000047
【図４Ｃ】
2020201957.tif 000048
【図４Ｄ】
2020201957.tif 000049
【図４Ｅ】
2020201957.tif 000050
【図４Ｆ】
2020201957.tif 000051
【図４Ｇ】
2020201957.tif 000052
【図４Ｈ】
2020201957.tif 000053
【図４Ｉ】
2020201957.tif 000054
【図４Ｊ】
2020201957.tif 000055