(57)【特許請求の範囲】
【請求項１】
マルチスレッド処理システムにおいて、複数の作業スレッドを含むスレッドプールの動的サイズ変更をサポートするための方法であって、当該方法は、コンピュータシステムが、サイズ変更ジョブを実行するステップを含み、
前記サイズ変更ジョブを実行するステップは、
現在期間において前記スレッドプールの処理量（Ｔnow）を測定するステップと、
Ｔnowを前回期間に測定された前記スレッドプールの処理量（Ｔlast）と比較することによって、前記スレッドプールの処理量の変化（ΔＴ）を決定するステップと、
前記スレッドプールをシェークするタイミングではない場合に、ΔＴに基づいて、前記前回期間に比べて前記現在期間の処理量が所定量以上変化しているか否かを判断するステップと、
前回のサイズ変更動作が、前記スレッドプールに１つ以上の作業スレッドを追加する動作、前記スレッドプールから１つ以上の作業スレッドを削除する動作、および前記スレッドプールを変更しない動作のうちのいずれであるかを判断するステップと、
前記前回のサイズ変更動作が前記スレッドプールから１つ以上の作業スレッドを削除する動作であり、且つ前記前回期間に比べて前記現在期間の処理量が前記所定量以上増加している場合に、次回のサイズ変更ジョブまでの期間を短縮し、前記スレッドプールから１つ以上の作業スレッドを削除するステップと、
前記次回のサイズ変更ジョブまでの期間に従って、前記次回のサイズ変更ジョブをスケジュールするステップとを含む、方法。
【請求項２】
マルチスレッド処理システムにおいて、複数の作業スレッドを含むスレッドプールの動的サイズ変更をサポートするための方法であって、当該方法は、コンピュータシステムが、サイズ変更ジョブを実行するステップを含み、
前記サイズ変更ジョブを実行するステップは、
現在期間において前記スレッドプールの処理量（Ｔnow）を測定するステップと、
Ｔnowを前回期間に測定された前記スレッドプールの処理量（Ｔlast）と比較することによって、前記スレッドプールの処理量の変化（ΔＴ）を決定するステップと、
前記スレッドプールをシェークするタイミングではない場合に、ΔＴに基づいて、前記前回期間に比べて前記現在期間の処理量が所定量以上変化しているか否かを判断するステップと、
前回のサイズ変更動作が、前記スレッドプールに１つ以上の作業スレッドを追加する動作、前記スレッドプールから１つ以上の作業スレッドを削除する動作、および前記スレッドプールを変更しない動作のうちのいずれであるかを判断するステップと、
前記前回のサイズ変更動作が前記スレッドプールから１つ以上の作業スレッドを削除する動作であり、且つ前記前回期間に比べて前記現在期間の処理量が前記所定量以上低下している場合に、次回のサイズ変更ジョブまでの期間を増加し、前記スレッドプールに１つ以上の作業スレッドを追加するステップと、
前記次回のサイズ変更ジョブまでの期間に従って、前記次回のサイズ変更ジョブをスケジュールするステップとを含む、方法。
【請求項３】
前記サイズ変更ジョブを実行するステップは、
前記前回のサイズ変更動作が前記スレッドプールに１つ以上の作業スレッドを追加する動作であり、且つ前記前回期間に比べて前記現在期間の処理量が前記所定量以上増加している場合に、前記次回のサイズ変更ジョブまでの期間を短縮し、前記スレッドプールに１つ以上の作業スレッドを追加するステップをさらに含む、請求項１または２に記載の方法。
【請求項４】
前記サイズ変更ジョブを実行するステップは、
前記前回のサイズ変更動作が前記スレッドプールに１つ以上の作業スレッドを追加する動作であり、且つ前記前回期間に比べて前記現在期間の処理量が前記所定量以上低下している場合に、前記次回のサイズ変更ジョブまでの期間を増加し、前記スレッドプールから１つ以上の作業スレッドを削除するステップをさらに含む、請求項１〜３のいずれか１項に記載の方法。
【請求項５】
前記サイズ変更ジョブを実行するステップは、
前記前回のサイズ変更動作が前記スレッドプールを変更しない動作であり、前記スレッドプール内の複数の作業スレッドのうちのアクティブな作業スレッドの数が前記複数の作業スレッドの数の第１の割合を超えており、且つ前記前回期間に比べて前記現在期間の処理量が前記所定量以上増加している場合に、前記スレッドプールに１つ以上の作業スレッドを追加するステップをさらに含む、請求項１〜４のいずれか１項に記載の方法。
【請求項６】
前記サイズ変更ジョブを実行するステップは、
前記前回のサイズ変更動作が前記スレッドプールを変更しない動作であり、前記スレッドプール内の複数の作業スレッドのうちのアクティブな作業スレッドの数が前記複数の作業スレッドの数の第２の割合を下回っており、且つ前記前回期間に比べて前記現在期間の処理量が前記所定量以上低下している場合に、前記スレッドプールから１つ以上の作業スレッドを削除するステップをさらに含む、請求項１〜５のいずれか１項に記載の方法。
【請求項７】
前記サイズ変更ジョブを実行するステップは、
前記前回期間に比べて前記現在期間の処理量が前記所定量以上変化しておらず、且つ前記スレッドプール内の複数の作業スレッドのうちのアクティブな作業スレッドの数が前記複数の作業スレッドの数の第１の割合を超えている場合に、前記スレッドプールに１つ以上の作業スレッドを追加するステップをさらに含む、請求項１〜６のいずれか１項に記載の方法。
【請求項８】
前記サイズ変更ジョブを実行するステップは、
前記前回期間に比べて前記現在期間の処理量が前記所定量以上変化しておらず、且つ前記スレッドプール内の複数の作業スレッドのうちのアクティブな作業スレッドの数が前記複数の作業スレッドの数の第２の割合を下回っている場合に、前記スレッドプールから１つ以上の作業スレッドを削除するステップをさらに含む、請求項１〜７のいずれか１項に記載の方法。
【請求項９】
前記サイズ変更ジョブを実行するステップは、
前記スレッドプールをシェークするタイミングである場合に、前記スレッドプールにランダム数の作業スレッドを追加する動作、または、前記スレッドプールからランダム数の作業スレッドを削除する動作を実行し、次回のサイズ変更ジョブまでの期間に従って、前記次回のサイズ変更ジョブをスケジュールするステップをさらに含む、請求項１〜８のいずれか１項に記載の方法。
【請求項１０】
一連のサイズ変更ジョブが実行され、
各サイズ変更ジョブは、対応する期間に実行される、請求項１〜９のいずれか１項に記載の方法。
【請求項１１】
スレッドプールの動的サイズ変更をサポートするためのシステムであって、
メモリとプロセッサとを有するコンピュータシステムを備え、前記プロセッサは、複数のコアを有し、マルチスレッド動作可能であり、
前記コンピュータシステム上で動作するスレッドプールを備え、前記スレッドプールは、複数の作業スレッドを含み、
前記複数の作業スレッドのうち、１つの作業スレッドは、サイズ変更ジョブを実行するように構成され、当該サイズ変更ジョブは、
現在期間において前記スレッドプールの処理量（Ｔnow）を測定することと、
Ｔnowを前回期間に測定された前記スレッドプールの処理量（Ｔlast）と比較することによって、前記スレッドプールの処理量の変化（ΔＴ）を決定することと、
前記スレッドプールをシェークするタイミングではない場合に、ΔＴに基づいて、前記前回期間に比べて前記現在期間の処理量が所定量以上変化しているか否かを判断することと、
前回のサイズ変更動作が、前記スレッドプールに１つ以上の作業スレッドを追加する動作、前記スレッドプールから１つ以上の作業スレッドを削除する動作、および前記スレッドプールを変更しない動作のうちのいずれであるかを判断することと、
前記前回のサイズ変更動作が前記スレッドプールから１つ以上の作業スレッドを削除する動作であり、且つ前記前回期間に比べて前記現在期間の処理量が前記所定量以上増加している場合に、次回のサイズ変更ジョブまでの期間を短縮し、前記スレッドプールから１つ以上の作業スレッドを削除することと、
前記次回のサイズ変更ジョブまでの期間に従って、前記次回のサイズ変更ジョブをスケジュールすることとを含む、システム。
【請求項１２】
スレッドプールの動的サイズ変更をサポートするためのシステムであって、
メモリとプロセッサとを有するコンピュータシステムを備え、前記プロセッサは、複数のコアを有し、マルチスレッド動作可能であり、
前記コンピュータシステム上で動作するスレッドプールを備え、前記スレッドプールは、複数の作業スレッドを含み、
前記複数の作業スレッドのうち、１つの作業スレッドは、サイズ変更ジョブを実行するように構成され、当該サイズ変更ジョブは、
現在期間において前記スレッドプールの処理量（Ｔnow）を測定することと、
Ｔnowを前回期間に測定された前記スレッドプールの処理量（Ｔlast）と比較することによって、前記スレッドプールの処理量の変化（ΔＴ）を決定することと、
前記スレッドプールをシェークするタイミングではない場合に、ΔＴに基づいて、前記前回期間に比べて前記現在期間の処理量が所定量以上変化しているか否かを判断することと、
前回のサイズ変更動作が、前記スレッドプールに１つ以上の作業スレッドを追加する動作、前記スレッドプールから１つ以上の作業スレッドを削除する動作、および前記スレッドプールを変更しない動作のうちのいずれであるかを判断することと、
前記前回のサイズ変更動作が前記スレッドプールから１つ以上の作業スレッドを削除する動作であり、且つ前記前回期間に比べて前記現在期間の処理量が前記所定量以上低下している場合に、次回のサイズ変更ジョブまでの期間を増加し、前記スレッドプールに１つ以上の作業スレッドを追加することと、
記次回のサイズ変更ジョブまでの期間に従って、前記次回のサイズ変更ジョブをスケジュールすることとを含む、システム。
【請求項１３】
前記サイズ変更ジョブは、
前記スレッドプールをシェークするタイミングである場合に、前記スレッドプールにランダム数の作業スレッドを追加する動作、または、前記スレッドプールからランダム数の作業スレッドを削除する動作を実行し、次回のサイズ変更ジョブまでの期間に従って、前記次回のサイズ変更ジョブをスケジュールすることをさらに含む、請求項１１または１２に記載のシステム。
【請求項１４】
命令を含むコンピュータプログラムであって、
前記命令は、コンピュータシステムによって実行されると、前記コンピュータシステムに、請求項１〜１０のいずれか１項に記載の方法を実行させる、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
著作権の表示
この特許文書の開示の一部には、著作権保護の対象となるものが含まれている。著作権者は、特許商標庁の特許ファイルまたは記録に掲載された特許文書または特許開示の複製に対しては異議を唱えないが、その他の場合、すべての著作権を留保する。
【０００２】
発明の分野
本発明は、一般にコンピュータシステムに関し、特に分散データグリッドに関する。
【発明の概要】
【課題を解決するための手段】
【０００３】
概要
本開示は、分散データグリッド内でスレッドプールのサイズ変更および再変更をサポートすることができるシステムおよび方法を記載する。以下の分散データグリッドに関する説明に記載のように、分散データグリッドのノードによって提供されるサービスは、通常、１つのサービススレッドを使用して、サービスの特定の機能を提供する。一部のサービスは、必要に応じて、サービススレッドに追加の処理リソースを提供するように構成することができる作業スレッドのスレッドプールをサポートする。本開示は、サービススレッドに追加の処理リソースを提供するように構成することができる作業スレッドの拡張可能なスレッドプール、並びに、拡張可能なスレッドプールの動的サイズ変更を行うためのシステムおよび方法を記載する。本開示に記載されたスレッドプールのサイズを動的に変更および再変更するシステムおよび方法は、多種多様な他のマルチスレッド処理環境に適用することもできる。
【０００４】
実施形態において、本開示は、分散データグリッドなどのようなマルチスレッド処理環境に適切に使用されるスレッドプールの動的サイズ変更をサポートするシステムおよび方法を記載する。スレッドプールの動的サイズ変更は、例えば、分散データグリッド内のサービススレッドに関連付けられた拡張可能なスレッドプールにおいて実行することができる。スレッドプールの動的サイズ変更は、スレッドプール処理量および作業スレッド使用率の測定値および前回のスレッドプールサイズ変更動作の効果分析を併用して、現在のサイズ変更動作においてスレッドプールに作業スレッドを追加するかまたはスレッドプールから作業スレッドを削除するかを決定する。さらに、スレッドプールの動的サイズ変更システムおよび方法は、システムの需要に応じて、サイズ変更の反復分析および作業スレッドの追加および削除速度を加速または減速することができる。最適化を組み込むことによって、最大処理量の局部低下を回避する。これによって、スレッドプールの動的サイズ変更／再変更システムおよび方法は、作業量および利用可能なプロセッサの変化に応答して、スレッドプールのサイズを迅速に調整する。
【０００５】
実施形態において、本開示は、分散データグリッドにおいて、スレッドプールの動的サイズ変更をサポートすることができるシステムおよび方法を記載する。システムは、一定期間に対応するスレッドプールの処理量を測定することができる。次に、システムは、前回期間からスレッドプールの処理量の変化を決定し、１つ以上の基準が満たされる場合に、ランダム量でスレッドプールのサイズを変更することができる。さらに、システムは、前回期間においてスレッドプールのサイズ変更の効率に基づいて、次回期間の長さを決定することができる。
【０００６】
特定の実施形態において、本開示は、マルチスレッド処理システムにおいて、複数の作業スレッドを含むスレッドプールの動的サイズ変更をサポートするための方法、システム、または非一時的媒体を記載する。方法、システムおよび非一時的媒体は各々、サイズ変更ジョブを実行することによって、スレッドプールの動的サイズ変更をサポートする。サイズ変更ジョブは、現在期間において前記スレッドプールの処理量（Ｔnow）を測定することと、Ｔnowを前回期間に測定されたスレッドプールの処理量（Ｔlast）と比較することによって、スレッドプールの処理量の変化（ΔＴ）を決定することと、スレッドプールに１つ以上の作業スレッドを追加する動作、スレッドプールから１つ以上の作業スレッドを削除する動作、およびスレッドプールを変更しない動作のうちの１つを含むサイズ変更動作を実行することと、前回期間の後に実行され、ΔＴによって示された前回のサイズ変更動作の効果に基づいて、次回期間の持続時間を計算することと、次回期間が切れる後に実行される次回のサイズ変更ジョブをスケジュールすることとを含む。
【０００７】
本発明のこれらのおよび他の目的および利点は、当業者なら、添付図面を参照して、さまざまな実施形態の以下の説明から分かるであろう。
【図面の簡単な説明】
【０００８】
【図１】本発明の一実施形態に従った分散データグリッドを示す図である。
【図２】本発明の一実施形態に従った拡張可能なスレッドプールシステムを示す図である。
【図３Ａ】本発明の一実施形態に従った拡張可能なスレッドプールシステムおよび方法を示す図である。
【図３Ｂ】本発明の一実施形態に従った拡張可能なスレッドプールシステムおよび方法を示す図である。
【図４Ａ】本発明の一実施形態に従って、図２、図３Ａ、および図３Ｂの拡張可能なスレッドプールシステムに作業スレッドを追加する方法を示す図である。
【図４Ｂ】本発明の一実施形態に従って、図２、図３Ａ、および図３Ｂの拡張可能なスレッドプールシステムから作業スレッドを削除する方法を示す図である。
【図５】本発明の一実施形態に従って、拡張可能なスレッドプールの動的サイズ変更を行うための方法を示す図である。
【図６】本発明の一実施形態に従って、拡張可能なスレッドプールの動的サイズ変更を行うための方法を示す図である。
【図７】本発明の一実施形態に従って、拡張可能なスレッドプールおよび分散データグリッド内で拡張可能なスレッドプールの動的サイズ変更を行うためのシステムの実装を示す図である。
【発明を実施するための形態】
【０００９】
詳細な説明
本開示は、分散データグリッド内のスレッドプールのサイズ変更およびサイズ再変更をサポートすることができるシステムおよび方法を記載する。以下の分散データグリッドに関する説明に記載のように、分散データグリッドのノードによって提供されるサービスは、通常、１つのサービススレッドを使用して、サービスの特定の機能を提供する。一部のサービスは、必要に応じて、サービススレッドに追加の処理リソースを提供するように構成することができる作業スレッドのスレッドプールをサポートする。本開示は、サービススレッドに追加の処理リソースを提供するように構成することができる作業スレッドの拡張可能なスレッドプール、並びに、拡張可能なスレッドプールの動的サイズ変更を行うためのシステムおよび方法を記載する。本開示に記載されたスレッドプールの動的サイズ変更を行うためのシステムおよび方法は、図１を参照して以下に説明する分散データグリッド、および図２、図３Ａ、図３Ｂ、図４Ａおよび図４Ｂを参照して以下に説明する拡張可能なスレッドプールにおいて、特に有用である。本開示に記載されたスレッドプールの動的サイズ変更／再変更は、多種多様な代替的スレッドプールシステム並びに他のマルチスレッド処理環境およびアプリケーションに適用することもできる。
【００１０】
以下の説明において、本発明は、限定ではなく例示として、添付の図面に示される。本開示において、さまざまな実施形態の言及は、必ずしも同一の実施形態に限定されず、少なくとも１つの実施形態を意味する。特定の実装形態を説明する場合、これらの特定の実装形態は、例示のみの目的で提供されていることを理解すべきである。当業者なら、本発明の範囲および精神から逸脱することなく、他の要素および構成を使用できることを理解するであろう。
【００１１】
場合によって、本発明の完全な説明を提供するように、多数の具体的な詳細を記載する。しかしながら、これらの具体的な詳細がなくても、本発明を実施できることは、当業者にとって明らかであろう。また、場合によって、本発明を不明瞭にしないように、周知の特徴は、詳細に記載されない。
【００１２】
本発明は、特定の機能の実行およびそれらの関係を示す機能性構成ブロックを用いて説明される。これらの機能性構成ブロックの境界は、通常、説明の便宜上、本開示に任意に定義される。したがって、同様の要素によって実行されるように示された機能は、代替的な実施形態において、異なる要素によって実行されてもよい。代替的には、別々の要素によって実行されるように示された機能は、１つの要素によって実行されてもよい。特定の機能およびそれらの関係が適切に実行される限り、代替的な境界を定義してもよい。したがって、これらの代替的な境界のいずれも、本発明の範囲および精神内に含まれる。
【００１３】
共通の参照番号を使用して、図面および詳細な説明における同様の要素を示す。したがって、他の箇所で図示された要素を説明する場合、図面に使用されている参照番号は、必ずしもこの図面に対応する詳細な説明に記載する必要がない。３桁の参照番号のうち、最初の数字は、要素が最初に現れる図面の順番を示す。
【００１４】
分散データグリッド
分散データグリッドとは、分散型環境またはクラスタ化環境において情報および関連動作、例えば演算を管理するために、複数のコンピュータサーバが１つ以上のクラスタに協働して動作するシステムを指す。分散データグリッドを使用して、サーバ間に共有されているアプリケーションオブジェクトおよびデータを管理することができる。分散データグリッドは、短い応答時間、高い処理量、予測可能な拡張性、継続的な可用性、情報の信頼性を提供する。その結果、分散データグリッドは、計算集約型ステートフル中間層アプリケーションの使用に適している。特定の例において、分散データグリッド、例えばOracle（登録商標）Coherenceデータグリッドは、高性能を達成するように情報をインメモリに格納し、その情報のコピーを複数のサーバ間に同期するように冗長性を採用しているため、サーバの故障時に、システムの復元性およびデータの継続的な可用性を確保する。
【００１５】
以下の記載において、分割キャッシュを有するOracle（登録商標）Coherenceデータグリッドを説明する。しかしながら、当業者であれば、本発明の範囲から逸脱することなく、例えば上記の概要に記載された発明を当該技術分野に知られている任意の分散データグリッドに適用することができることを理解するであろう。さらに、本発明の完全な説明を提供するために、Oracle（登録商標）Coherence分散データグリッドの多くの具体的な詳細を記載するが、本発明は、これらの特定の詳細がなくても、分散データグリッドに実施することができる。したがって、いくつかの実施形態において、本発明を具体化する分散データグリッドの特定の実装は、本発明の範囲から逸脱することなく、以下に説明する分散データグリッドの特定の特徴を含まなくてもよく、および／または以下に説明する分散データグリッドの特定の特徴と異なる特徴またはその変更特徴を含んでもよい。
【００１６】
図１は、データを格納し、クライアント１５０にデータの利用を提供する分散データグリッド１００の例を示している。「データグリッドクラスタ」または「分散データグリッド」は、分散型環境またはクラスタ化環境において情報および関連動作、例えば計算を格納および管理するために、１つ以上のクラスタ（例えば、１００ａ、１００ｂ、１００ｃ）に協働して動作する複数のコンピュータサーバ（例えば、１２０ａ、１２０ｂ、１２０ｃおよび１２０ｄ）を含むシステムを指す。分散データグリッド１００は、例として、クラスタ１００ａ内に５つのデータノード１３０ａ、１３０ｂ、１３０ｃ、１３０ｄおよび１３０ｅを有する４つのサーバ１２０ａ、１２０ｂ、１２０ｃおよび１２０ｄを含むものとして図示されているが、任意数のクラスタを含むことができ、各クラスタ内に任意数のサーバおよび／または任意数のノードを含むことができる。分散データグリッドは、高性能を達成するように情報をインメモリに格納し、その情報のコピーを複数のサーバ間に同期するように冗長性を採用しているため、サーバの故障時に、システムの復元性およびデータの継続的な可用性を確保することができる。一実施形態において、分散データグリッド１００は、例えば、上記の概要および以下の詳細な説明に記載される本発明を実現する。
【００１７】
図１に示すように、分散データグリッドは、協働して動作する多数のサーバ（例えば、１２０ａ、１２０ｂ、１２０ｃおよび１２０ｄ）の間にデータを分散することによって、データの記憶および管理機能を提供する。データグリッドクラスタの各サーバは、例えば、１〜２個のプロセッサソケットを備え、各プロセッサソケットに２〜４個のＣＰＵコアを配置した「汎用ｘ８６」サーバハードウェアプラットフォームなどの従来のコンピュータシステムであってもよい。各サーバ（例えば、１２０ａ、１２０ｂ、１２０ｃおよび１２０ｄ）は、例えば、１つ以上のＣＰＵ、ネットワークインターフェイスカード（ＮＩＣ）、および最低４ＧＢ最大６４ＧＢまたはそれ以上のＲＡＭを含むメモリを備えるように構成される。図示されたサーバ１２０ａは、ＣＰＵ１２２ａ、メモリ１２４ａおよびＮＩＣ１２６ａ（これらの要素は、他のサーバ１２０ｂ、１２０ｃ、１２０ｄにも存在するが、図示されていない）を備える。必要に応じて、各サーバは、溢流記憶容量を提供するために、フラッシュメモリ（例えば、ＳＳＤ１２８ａ）を備えてもよい。ＳＳＤを備える場合、その容量は、好ましくはＲＡＭの容量の１０倍である。データグリッドクラスタ１００ａ内のサーバ（例えば、１２０ａ、１２０ｂ、１２０ｃおよび１２０ｄ）は、高帯域幅のＮＩＣ（例えば、ＰＣＩ−ＸまたはＰＣＩｅ）を介して、高性能（例えば、ギガビットイーサネット（登録商標）またはそれ以上）ネットワークスイッチ１２０に接続される。
【００１８】
故障時にデータを損失する可能性を回避するために、クラスタ１００ａは、好ましくは最低４つの物理サーバを含むが、典型的な実装として、より多くのサーバを含んでもよい。各クラスタに存在するサーバが多くなればなるほど、フェイルオーバー（failover）およびフェイルバック（failback）がより効率的になり、サーバの故障によってクラスタに与える影響が軽減される。サーバ間の通信時間を最短にするために、各データグリッドクラスタは、理想的には、サーバ間にシングルホップ通信を提供する単一のスイッチ１０２に接続される。したがって、クラスタは、スイッチ１０２上のポート数によって制限される。よって、典型的なクラスタは、４〜９６個の物理サーバを含む。
【００１９】
分散データグリッド１００の殆どの広域ネットワーク（ＷＡＮ）構成において、ＷＡＮ内の各データセンタは、相互独立しているが、相互接続されたデータグリッドクラスタ（例えば、１００ａ、１００ｂおよび１００ｃ）を備える。ＷＡＮは、例えば図１に示されたクラスタよりも多くのクラスタを含んでもよい。さらに、相互接続されているが相互独立しているクラスタ（例えば、１００ａ、１００ｂ、１００ｃ）を使用することによって、および／または相互接続されているが相互独立しているクラスタを相互遠隔であるデータセンタに配置することによって、分配型データグリッドは、自然災害、火災、洪水、長期間の電力損失などによって、１つのクラスタ内のすべてのサーバが同時に喪失しないように、安全性のあるデータおよびサービスをクライアント１５０に提供することができる。企業および地区の全体に亘って維持されているクラスタは、企業データの自動バックアップ記憶および高可用性サービスを構成する。
【００２０】
１つ以上のノード（例えば、１３０ａ、１３０ｂ、１３０ｃ、１３０ｄおよび１３０ｅ）は、クラスタ１００ａの各サーバ（例えば、１２０ａ、１２０ｂ、１２０ｃおよび１２０ｄ）上で動作する。分散データグリッドにおいて、ノードは、例えばソフトウェアアプリケーション、仮想マシンなどであってもよく、サーバは、ノードが動作するオペレーティングシステム、ハイパーバイザ（図示せず）などを含んでもよい。Oracle（登録商標）Coherenceデータグリッドにおいて、各ノードは、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）である。サーバのＣＰＵ処理能力および利用可能なメモリに応じて、各サーバは、複数のＪＶＭ／ノードを備えてもよい。分散データグリッドの需要に応じて、ＪＶＭ／ノードを起動、停止、追加および削除することができる。Oracle（登録商標）Coherenceを実行するＪＶＭは、起動時に自動的に結合し、クラスタ化する。クラスタに加入したＪＶＭ／ノードは、クラスタメンバまたはクラスタノードと呼ばれる。
【００２１】
Oracle（登録商標）Coherenceデータグリッドにおいて、クラスタメンバは、ＴＣＭＰ（Tangosol Cluster Management Protocol）を使用して通信する。ＴＣＭＰは、クラスタメンバの検出、クラスタの管理、サービスの提供、およびクラスタメンバ間でデータの送信に使用されているＩＰベースプロトコルである。ＴＣＭＰプロトコルは、完全な信頼性で順序通りに、すべてのメッセージを配信する。基礎のＵＤＰ／ＩＰプロトコルが信頼性のある配信または順序通りの配信を提供しないため、ＴＣＭＰは、行列化された完全非同期ＡＣＫおよびＮＡＣＫに基づくメカニズムを使用することによって、信頼性のあるメッセージ配信を行うと共に、一体化された特定のＩＤを使用することによって、サーバ上で動作するＪＶＭに関連して行列化されたメッセージの順序を保証する。ＴＣＭＰプロトコルは、クラスタサイズに関係なく、ＪＶＭ／ノード毎に３つのＵＤＰ／ＩＰソケット（１つのマルチキャスト、２つのユニキャスト）および６つのスレッドしか必要としない。
【００２２】
データグリッドクラスタの機能は、クラスタノードによって提供されたサービスに依存する。クラスタノードによって提供された各サービスは、特定の機能を有する。各クラスタノードは、クラスタサービスの提供およびクラスタサービスの使用の両方の観点から、多くのクラスタサービスに加入することができる（メンバになることができる）。一部のクラスタサービスは、クラスタ内のすべてのノードによって提供されるが、他のサービスは、クラスタ内の１つのノードのみまたは一部のノードのみによって提供される。各サービスは、データグリッドクラスタ内のサービスを一意に識別するサービス名と、行えるサービスを規定するサービス種類とを有する。（ルートクラスタサービスを除き）データグリッドクラスタのノードによって提供された各サービス種類には、複数の名前付きインスタンスが存在することがある。すべてのサービスは、好ましくは、データ損失なしに、フェイルオーバーおよびフェイルバックを提供する。
【００２３】
クラスタノードによって提供された各サービスインスタンスは、通常、１つのサービススレッドを使用して、サービスの特定の機能を提供する。例えば、あるノードによって提供された分散キャッシュサービスは、そのノードの単一サービススレッドによって提供される。ＪＶＭ／ノードで分散キャッシュのスキーマ定義を解析する場合、サービススレッドは、スキーマに指定された名前でインスタンス化される。このサービススレッドは、スキーマ定義を使用して作成されたキャッシュ内にデータを管理する。一部のサービスは、必要に応じて、サービススレッドに追加の処理リソースを提供するように構成することができる作業スレッドのスレッドプールをサポートする。このサービススレッドは、スレッドプール内の作業スレッドと連携して、特定のサービス機能を提供する。
【００２４】
Oracle（登録商標）Coherenceデータグリッドにおいて、クラスタサービス（例えば、１３６ａ、１３６ｂ、１３６ｃ、１３６ｄ、１３６ｅ）は、クラスタ内のメンバシップおよびサービスを追跡する。各クラスタノードは、常に１つのみのこの種のサービスを実行している。クラスタサービスは、自動的に起動して、クラスタノードをクラスタに加入することができる。クラスタサービスは、他のクラスタノードの検出、クラスタノードの故障（停止）の検出、およびクラスタに利用可能な他のサービスの登録を行う。プロキシサービス（例えば、１３８ｃ）によって、クラスタ外部のクライアントは、（例えば、ＴＣＰを使用して）クラスタに接続することができる。呼び出しサービス（例えば、１３４ｄ）によって、アプリケーションコードは、エージェントを呼び出して、クラスタ内の任意のノードまたは任意のノードグループまたはクラスタ全体に亘って、動作を実行することができる。呼び出しサービスおよびプロキシサービスは、図示では各々が１つのみのノードに設けられていると示されているが、分散データグリッド内の任意数のノード上に、最大すべてのノード上に設けられることができる。
【００２５】
Oracle（登録商標）Coherenceデータグリッドにおいて、分散キャッシュサービス（例えば、１３２ａ、１３２ｂ、１３２ｃ、１３２ｄ、１３２ｅ）は、分散データグリッドにデータ記憶を提供し、クラスタ内のノードが記憶不能に設定されても、クラスタ内のすべてのノード上でキャッシュデータの読み取り／書き込み／記憶を行うことができる。分散キャッシュサービスによって、クラスタノードは、クラスタ１００ａの全体にデータを分散（分配）することができる。これによって、キャッシュ内の各データ断片は、主に１つのみのクラスタノードによって管理（保持）される。分散キャッシュサービスは、putおよびgetなどの記憶操作要求を処理する。分散キャッシュサービスは、分散スキーマ定義に定義され、クラスタのノード間に分配された分散キャッシュ（例えば、１４０ａ、１４０ｂ、１４０ｃ、１４０ｄ、１４０ｅ）を管理する。
【００２６】
パーティションは、分散データグリッドに管理されたデータの基本単位であり、分散キャッシュ（例えば、１４０ａ、１４０ｂ、１４０ｃ、１４０ｄおよび１４０ｅ）に格納される。論理的に、データは、基本パーティション（例えば、１４２ａ、１４２ｂ、１４２ｃ、１４２ｄおよび１４２ｅ）に分配される。これらの基本パーティションは、複数のクラスタノードに分散され、クラスタ内の１つのみのノードがキャッシュ内の各データ断片を格納する。各キャッシュ（例えば、１４０ａ、１４０ｂ、１４０ｃ、１４０ｄおよび１４０ｅ）は、複数のパーティションを保持することができる。各パーティション（例えば、１４２ａ、１４２ｂ、１４２ｃ、１４２ｄ、１４２ｅ）は、１つのデータム（datum）を保持することができ、多くのデータムを保持することもできる。パーティションは、必要または要望に応じて、１つのノードのキャッシュから、別のノードのキャッシュに移行することができる。例えば、クラスタにノードを追加する場合、新しく追加されたノードを含む使用可能なノード間にパーティションを分散するように、これらのパーティションを移行する。非複製型の分散データグリッドには、各パーティション（基本パーティション）は、１つのアクティブコピーしか有しない。しかしながら、通常、各パーティションは、１つ以上のレプリカ／バックアップコピーを有する。これらのレプリカ／バックアップコピーは、別のサーバに格納され、フェイルオーバーに使用される。クラスタのサーバ間に分散されたパーティションにデータを分配するため、データを管理する負荷およびデータを利用する負荷は、クラスタの全体に自動的に分散される。
【００２７】
分散キャッシュサービスは、各データ断片が１つ以上の他のクラスタノードによってバックアップされ、データ損失なしにフェイルオーバーをサポートするように構成することができる。例えば、図１に示すように、各パーティションは、基本パーティション（例えば、濃い色の四角形１４２ａ、１４２ｂ、１４２ｃ、１４２ｄおよび１４２ｅ）および同期されたパーティションの１つ以上のバックアップコピー（例えば、薄い色の四角形１４４ａ、１４４ｂ、１４４ｃ、１４４ｄおよび１４４ｅ）に格納される。各パーティションのバックアップコピーは、同期の元である基本パーティションと異なるサーバ／ノードに格納される。ノード上の分散キャッシュサービスのフェイルオーバーは、パーティションのバックアップコピーを基本パーティションに昇格する必要がある。特定のサーバ／ノードが故障した場合、残りのすべてのクラスタノードは、故障したノードの基本パーティションに対応して保持されたバックアップパーティションを決定する。次に、クラスタノードは、任意のクラスタノード上に保持されているバックアップパーティションを基本パーティションに昇格する（その後、新規バックアップパーティションを作成する）。
【００２８】
分散キャッシュは、データオブジェクトの集合である。各データオブジェクト／データムは、例えば、データベーステーブルの一行に等価することができる。各データムは、データムを識別する特定のキーに関連付けられる。各パーティション（例えば、１４２ａ、１４２ｂ、１４２ｃ、１４２ｄ、１４２ｅ）は、１つのデータムを保持することができ、多くのデータムを保持することもできる。これらのパーティションは、クラスタ内のすべてのノード間に分散される。Oracle（登録商標）Coherenceのデータグリッドにおいて、各キーおよび各データムは、ＰＯＦ（Portable Object Format）と呼ばれる効率的な非圧縮バイナリエンコーディングによってシリアル化されたデータオブジェクトとして、格納される。
【００２９】
特定のデータムを探し出すために、各ノードは、キーをパーティションにマッピングするマップ、例えばハッシュマップを有する。このマップは、クラスタ内のすべてのノードに認識され、クラスタのすべてのノード間に同期され、更新される。各パーティションは、パーティションに関連付けられた各キーをそのパーティションに格納された対応のデータムにマッピングするバッキングマップを有する。分散データグリッド内の任意のノードは、クライアントから、特定のキー／データムに関連付けられた操作を受信することができる。ノードが操作を受信すると、キーが受信ノード上の基本パーティションに関連付けられている場合、ノードは、そのキーに関連付けられた値／オブジェクトを直接に利用することができる。キーが受信ノード上の基本パーティションに関連付けられていない場合、ノードは、操作をそのキーに関連付けられた基本パーティションを保持するノードに直接に（シングルホップで）導くことができる。したがって、各ノードは、ハッシュマップおよびパーティションマップを使用することによって、分散キャッシュにおいて、各キーに対応する各データムを直接利用するまたはシングルホップを介して利用することができる。
【００３０】
いくつかのアプリケーションにおいて、分散キャッシュ内のデータは、最初に、データ１１２を含むデータベース１１０から取り込まれる。データベース１１０内のデータ１１２は、シリアル化され、分散データグリッドのノード間に分配され、分散される。分散データグリッド１００は、データベース１１０のデータ１１２から作成されたデータオブジェクトをサーバ１１０ａ、１２０ｂ、１２０ｃ、１２０ｄのメモリ内のパーティションに格納する。これによって、クライアント１５０および／またはデータグリッド１００内のアプリケーションは、メモリからこれらのデータオブジェクトを直接利用することができる。したがって、分散データグリッド１００からデータオブジェクトの読み出しおよび分散データグリッド１００にデータオブジェクトの書き込みは、遥かに高速になり、データベース１１０を直接使用することよりも、多くの同時接続を達成できる。データのインメモリ複製および保証されたデータ一貫性によって、分散データグリッドは、保管および報告のためにトランザクションをデータベース１１０などの外部データソースに長期保存されるまで、メモリ内でトランザクションを管理することができる。メモリ内のデータオブジェクトに変更があった場合、その変更は、基本パーティションとバックアップパーティションとの間に同期された後、非同期書き込み（ライトバック）を用いてデータベース１１０に書き込まれ、ボトルネックを回避する。
【００３１】
データがクラスタノード間に分散されていることにも関わらず、クライアント１５０は、任意のクラスタノードに接続して、任意のデータを取り出すことができる。このことは、位置透明性（location transparency）と呼ばれ、開発者がキャッシュのトポロジーに基づいてコードを作成する必要がない。いくつかの実施形態において、クライアントは、特定のサービス、例えば特定のノード上のプロキシサービスに接続することができる。他の実施形態において、接続プールまたはロードバランサを使用して、クライアントを特定のノードに導くことができ、クライアントの接続を一部またはすべてのデータノード間に確実に分散することができる。どのように接続されても、分散データグリッド内の受信ノードは、クライアント１５０からタスクを受信することができる。各タスクは、特定のデータムに関連付けられているため、特定のノードによって処理されなければならない。ノードは、特定のデータムに対応するタスク（例えば、キャッシュサービスに対するコール）を受信すると、そのデータムを格納するパーティション、およびそのパーティションに対応するノードを特定する。その後、受信ノードは、例えばリモートキャッシュを呼び出すことによって、タスクを要求されたパーティションを保持するノードに導く。各データムが１つのみのクラスタノードにより管理されているため、ネットワークを経由したアクセスは、「シングルホップ」操作である。この種のアクセスは、ポイントツーポイント（point-to-point）通信を使用するので、インフィニバンド（InfiniBand）などのスイッチドファブリックネットワークを最大限に活用することができるため、拡張性が非常に高い。
【００３２】
同様に、キャッシュ更新動作は、同様のシングルホップポイントツーポイント方法を使用して、基本パーティションを備えるノードおよびパーティションのバックアップコピーを備えるノードの両方にデータを送信する。キャッシュに対する変更は、すべてのバックアップから承認応答を受け取るまで完了していないと見なされる。これによって、データの一貫性が維持され、書き込み操作中にクラスタノードが予期せず故障した場合に、データが損失しないことが保証される。また、分散キャッシュサービスは、一部のクラスタノードを、データを格納するように構成することができ、他のクラスタノードを、データを格納しないように構成することができる。
【００３３】
いくつかの実施形態において、必要に応じて、分散データグリッドは、固体装置（例えば、ＳＳＤ１２８ａ）、最も典型的にはフラッシュドライブを利用して、キャッシュに溢流容量を提供する弾性データ機構を有するように構成される。弾性データ機構を使用する場合、キャッシュは、ＲＡＭまたはＤＩＳＫジャーナルに基づくバッキングマップを使用するように指定される。ジャーナルは、オブジェクトの状態変化を格納するメカニズムを提供する。各データム／値は、特定のキーに関連して記録され、インメモリツリーを使用して、データムへのポインタを格納する（小さなデータム／値は、ツリーに直接格納されてもよい）。これにより、一部の値（データ）を固体装置（例えば、ＳＳＤ１２８ａ）に格納すると共に、インデックス／メモリツリーをメモリ（例えば、ＲＡＭ１２４ａ）に格納することができる。弾性データ機構によって、分散データグリッドは、完全にＲＡＭに基づく解決策に比べて、性能を殆ど損なうことなく、各ノードにより多くのデータをサポートすることができる。
【００３４】
上述したOracle（登録商標）Coherenceデータグリッドのような分散データグリッドは、データ操作の遅延問題を解決し、リアルタイムでデータをキャッシュおよび処理することによって、システムの性能を改善することができる。アプリケーションは、データをデータグリッドにキャッシュすることによって、高価なバックエンドデータソースを要求することを回避する。共有データキャッシュは、キャッシュされたデータの一貫性のある単一鏡像を提供する。キャッシュからの読み取りは、バックエンドデータソースのクエリよりも高速であり、アプリケーション層の規模に従って変化する。インメモリ実行は、ボトルネックを軽減し、データの競合を減少し、アプリケーションの応答性を改善する。並列のクエリおよび演算をサポートすることによって、データに基づく計算の性能を改善する。分散データグリッドは、故障許容性を有するため、データの信頼性、正確性、整合性、高可用性および災害復旧性を実現する。分散データグリッドによって、予測可能なコストで、リソース使用率を改善するように、アプリケーションを線形的に且つ動的に拡張することができる。分散データグリッドは、多くのアプリケーションに、データソースを共有する貴重な解決策を提供する。
【００３５】
実施形態において、分散データグリッド１００は、例えば、以下に記載され、図２、３Ａ、３Ｂ、４Ａおよび４Ｂに示された１つ以上の拡張可能なスレッドプールシステムおよび方法を実装する。本発明の実施形態において、分散データグリッド１００は、以下に記載され、図５および６に示された拡張可能なスレッドプールの動的サイズ変更を行うための１つ以上のシステムおよび方法を実装する。特定の実施形態において、拡張可能なスレッドプールシステム、拡張可能なスレッドプールの動的サイズ変更を行うためのシステムおよび方法は、例えば、分散データグリッド１００のノード上で動作し、キャッシュサービススレッドおよびプロキシサービススレッドを含む１つ以上のサービススレッドに対して実装されてもよい。
【００３６】
スレッドプール
本開示は、分散データグリッドにおいて、スレッドプールの動的サイズ変更をサポートすることができるシステムおよび方法を記載する。上述した分散データグリッドの説明に記載したように、分散データグリッドのノードによって提供されたサービスは、通常、１つのサービススレッドを使用して、サービスの特定の機能を提供する。サービススレッドに追加の処理リソースを提供するように構成することができる作業スレッドのスレッドプールをサポートする。本開示は、サービススレッドに追加の処理リソースを提供するように構成することができる作業スレッドの拡張可能なスレッドプール、並びに、拡張可能なスレッドプールの動的サイズ変更／再変更を行うためのシステムおよび方法を記載する。
【００３７】
上述のように、分散データグリッドは、クライアントから受信した非常に多くの短いタスクを処理するように構成される。例えば、分散キャッシュサービスのサービススレッドは、アプリケーションまたはネットワークの他のノードから受信したputおよびgetなどの非常に多くの記憶操作要求を処理するように構成される。各記憶操作の処理時間が短いが、記憶操作の数が非常に多い。非常に大量の短期操作を効率的に処理するために、サービススレッド、例えばキャッシュサービスを行うためのサービススレッドは、作業スレッドのスレッドプールを利用することができる。
【００３８】
例えば、分散データグリッド内にタスクの数が非常に多い場合、各タスクに対応してスレッドを作成することは、実用的ではない。さらに、タスクのサイズが小さい場合、スレッドの作成および破棄に関連するオーバーヘッドは、行われる実際の作業よりも重要である。スレッドプールにおいて、作業スレッドは、タスクを受信する時にオンデマンドで作成されではなく、再利用される。スレッドプールによって、スレッドが複数の操作に再利用され、スレッドの作成および削除に関するオーバーヘッドを複数の操作に分散することができるため、各タスクに新規作業スレッドを作成することに比べて、作業スレッドのスレッドプールを使用することは、有利である。スレッドの作成および破棄に関するオーバーヘッドの削減は、より良い性能およびより良いシステム安定性をもたらすことができる。追加の利点として、タスクを処理するために新規スレッドを作成することによって、このタスクの処理を遅らせることがない。通常、タスクの数は、スレッドの数よりも多い。スレッドは、すべてのタスクが処理完了するまでに、１つのタスクを完了すると、すぐにキューから次のタスクを要求する。スレッドは、新規タスクが与えられない場合、終了してもよく、スリープしてもよい。
【００３９】
一般に、スレッドプールの最適サイズは、プロセスに利用可能なプロセッサコアの数、作業の性質および量に依存する。スレッドおよび関連するリソースの作成および破棄は、時間の観点から高価なプロセスである。しかしながら、過剰のスレッドの維持は、メモリを浪費し、実行可能なスレッド間の環境切換も性能を損なう。スレッドプール内のスレッドが多すぎる場合、多くのスレッドは、アイドル状態になるため、システムのリソースを浪費する。スレッドプール内のスレッドが少なすぎる場合、タスクは、スレッドが使用可能になるまで、待機する必要があるため、遅延を引き起こす。アイドル状態のスレッドが存在することによるリソースの浪費およびスレッドが少なすぎることによる遅延を最小限に抑えるように、スレッドプールのサイズを選択することは好ましい。したがって、スレッドプールの最適サイズの選択は、システムの性能および作業量に依存する。よって、スレッドプールに使用されるスレッドの数は、最高の性能を提供するように調整できるパラメータである。
【００４０】
作業量に基づいて、スレッドプール内のスレッドの数を動的に変更することができる。スレッドを作成または破棄する時間を決定する方法は、全体の性能に影響する。必要以上のスレッドを作成した場合、リソースが浪費され、使用されないスレッドの作成に時間も浪費される。必要以上のスレッドを破壊した場合、必要に応じて新規スレッドを作成するのに、時間／リソースが浪費される。スレッドの作成が遅い場合、待ち時間が長くなる。アイドル状態のスレッドの破棄が遅い場合、他のプロセスに利用可能なリソースが不足になる。したがって、スレッドプール内のスレッド数と、スレッドプールにスレッドを追加する時間および速度を決定するためのメカニズムとは、スレッドプール、スレッドプールを使用するサービススレッド、およびコンピュータシステムのリソースを共有する他のスレッドの性能に著しい影響を与える。
【００４１】
分散データグリッドにおいて、作業量は、サービススレッド間に大幅に変化する可能性があり、各サービススレッドに対応する時間に伴って大幅に変化する可能性がある。さらに複雑なことは、分散データグリッドにおいて、異なる名前のキャッシュに対応する多数のキャッシュサービスが同一のノード内に同時に動作する可能性があるということである。さらに、複数の異なるサービススレッドを有する複数のノードは、同一のサーバ上で動作するため、プロセッサリソースを共有する可能性がある。これらのさまざまなサービススレッドの利用率は、時間と共に変化する可能性がある。したがって、分散データグリッドにおいて、スレッドプールの最適サイズは、スレッドプールに関連付けられたサービススレッドに与えられた作業だけではなく、同時に同一のサーバ上の他のサービススレッドに与えられた作業に依存して、大幅に変化する可能性がある。
【００４２】
スレッドプールを実装するときに、スレッドの安全性を考慮しなければならない。同一のリソースに関連するタスクは、順番に実行しなければならない。複数のスレッドが同一のリソースに関連するタスクを取得できるとしても、一度に進行できるのは、これらのスレッドのうち１つのみである。このことは、複数のスレッドの用途、すなわち、複数のスレッドを並行して動作させないため、不利である。したがって、タスクの先入先出（FIFO：first-in-first-out）順序を保証し、スレッドのブロッキング／シリアライゼーションを防止するための技術が必要とされる。１つのよく使用されている解決策として、単一生産者−複数消費者キュー（single producer-multiple consumer queue）である。しかしながら、そのようなキューを使用すると、以下に説明する競合が生じてしまう。従来のデータキュー構造の場合、複数の消費者としての作業スレッドは、キューにアクセスするために、互いに競合する。一度にキューから読み取ることができる作業スレッドが１つのみである。作業スレッドの数を増やすと、キューの競合が増加する。したがって、単一生産者−複数消費者キューは、多数の作業スレッドに従って容易に拡張することができない。よって、単純なキューを使用してサービススレッドと通信するスレッドプールは、拡張できない。したがって、スレッドの安全性を維持しながらスレッドプールの拡張を可能にし、競合を低減および／または排除するように、作業を作業スレッドに提供するためのデータ構造を提供することが望ましい。
【００４３】
従来のスレッドプールおよびスレッドプールサイズ変更方法の問題点に鑑みて、本開示は、サービススレッドに追加の処理リソースを提供するように構成することができる作業スレッドの拡張可能なスレッドプール、並びに、拡張可能なスレッドプールの動的サイズ変更を行うためのシステムおよび方法を記載する。特に、本開示は、マルチコアシステム上で高性能を示し、必要に応じて、分散データグリッドのサービススレッドに追加の作業スレッドを提供することによって分散データグリッドの性能を改善する単一生産者−複数消費者且つ動的拡張可能なスレッドプールを記載する。また、本開示は、スレッドプールの拡張を可能にしながら、競合を低減および／または排除するように、作業スレッドに作業を提供するためのデータ構造を記載する。さらに、本開示は、スレッドプールのスレッド数を変更し、スレッドプールサイズを動的に選択することによって、スレッドプールの性能を最適化し、処理量の変更に応じてスレッドプールサイズを迅速に変更することを可能にするメカニズムを記載する。
【００４４】
拡張可能なスレッドプールシステム
図２は、分散データグリッドに適切に使用される拡張可能なスレッドプールシステムを示す概要図である。図２に示すように、分散データグリッド２００内のサービススレッド２０１は、１つ以上のメッセージ、例えばメッセージ２１１〜２１３を受信することができる。サービススレッド２０１は、メッセージ２１１〜２１３を処理することができ、またはメッセージ２１１〜２１３を拡張可能なスレッドプール２０２に提供することができる。拡張可能なスレッドプール２０２は、１つ以上の作業スレッド２２１〜２２３を含む。システムは、関連パイル２１０を使用して、１つ以上の要素（例えば、メッセージ２１１〜２１３）を保持することができる。また、システムは、複数のスレッド（例えば、作業スレッド２２１〜２２３）が関連パイル２１０から要素を並列にポーリングすることを可能にする。さらに、システムは、関連パイル２１０に保持され、過去にポーリングされた要素と関連性を有する要素が、過去にポーリングされた関連要素がリリースされるまでポーリングされることを防ぐことができる。
【００４５】
関連パイル、例えば関連パイル２１０は、キューのような規定を用いて、要素を緩い順序に保持するデータ構造である。関連パイルは、一部の要素が関連付けキーを介して互いに関連付けられるという可能性を重視する。同一のキーに関連付けられた要素は、先入先出（FIFO）順序を維持する必要があるが、異なるキーに関連付けられた要素の場合、順序を変えることができる。キーは、例えば、上述した分散データグリッドにデータムを識別する特定のキーであってもよい。特定のデータムに対して一度に１つのスレッドしか動作できず、特定のデータムに対して実行される操作は、データムの受信順序に従って実行しなければならない。したがって、関連パイルは、例えば、同一の特定キーに関連付けられた同一のデータムに対して実行される操作を先入先出（FIFO）順序に維持することができる。
【００４６】
要素を関連パイルに追加することができ、関連パイルから削除することもできる。要素は、呼び出しスレッドによって、関連パイルに追加される。要素は、作業スレッドによって、関連パイルから削除される。要素の削除は、２つのステップで実行される。まず、関連パイルを「ポーリング」する作業スレッドによって、使用可能な要素を削除する。次に、作業スレッドは、要素と共に使い果たすと、関連パイルから「リリース」される。関連パイルは、ポーリングされたがまだリリースされていない要素が複数のスレッド上で並列に処理されると仮定するため、同一のキーに関連付けられた要素がポーリングされたがまだリリースされていない要素としてポーリングされることを防ぐ。
【００４７】
図３Ａおよび３Ｂは、拡張可能なスレッドプールの例を示す。図３Ａおよび３Ｂに示すように、サービススレッド３００は、拡張可能なスレッドプール３００に関連付けられる。スレッドプール３００は、固定数（ＣＰＵ数）の作業スロット３１０を有する。図示には、４つの作業スロット３１０ａ、３１０ｂ、３１０ｃおよび３１０ｄが示される。各作業スロットは、開閉可能なスレッドゲートを有する。スレッドゲートが開放している場合、スレッドは、ゲートに進入または退出することができる。スレッドがゲートに進入した場合、ゲートを閉じることができない。スレッドゲートが閉じている場合、スレッドは、ゲートに進入することができない。
【００４８】
サービススレッドによって作業をスレッドプールに追加すると、追加された作業は、作業スロットの間に分散される。サービススレッドは、一定のランダム性をもって、最小のバックログを有するスロット３１０ａ、３１０ｂ、３１０ｃまたは３１０ｄ（すなわち、最小の関連パイルを有するスロット）に作業を追加する。しかしながら、関連する作業の順序を維持するために、同一のキーに関連付けられたすべての作業は、同一のスロットに追加される。スレッドプールの作業スロットに作業を追加すると、以下に説明するように、呼び出しスレッドは、作業スロットのスレッドゲートに進入し、作業を関連パイルに追加する。
【００４９】
スレッドプールの固定数（ＣＰＵ数）の作業スロットは、１つ以上の関連パイルを介して、１つ以上の作業スレッドにリンクされる。このスレッドプールは、動的数の関連パイル３２０を有する。各作業スロットは、１つのみの関連パイルに関連付けられる。しかしながら、複数の作業スロットは、同一の関連パイルを共有することもできる。スレッドプールの作業スロットに作業を追加すると、呼び出しスレッドは、作業スロットのスレッドゲートに進入し、作業を１つの関連パイルに追加する。特定の作業スロットを介して追加されたすべての作業は、その特定の作業スロットに関連付けられた特定の関連パイルに送られる。特定のキーに関連するすべての作業は、同一の作業スロットを介して追加されるため、同一の関連パイルに送られる。
【００５０】
スレッドプールは、動的数の作業スレッド３３０を有する。各作業スレッドは、１つのみの関連パイルに関連付けられる。作業スレッドは、関連パイルから作業をポーリングする。しかしながら、各作業スレッドは、作業スレッドに関連付けられた１つの関連パイルから、作業をポーリングする。複数の作業スレッドは、同一の関連パイルに関連付けられ、同一の関連パイルから作業をポーリングする。図３Ａおよび３Ｂに示すように、作業スレッドの数および拡張可能なスレッドプール内の関連パイルの数は、図４Ａ、４Ｂ、５および６を参照して説明される方法に従って作業スレッドを追加または削除することによって、時間と共に変化することができる。
【００５１】
図３Ａは、作業スレッド３３０の数が作業スロット３１２の数よりも多い構成を示す。作業スレッドが作業スロットよりも多い場合、関連パイルの数は、作業スロットの数に等しい。図３Ａの構成において、７つのアクティブ作業スレッド３３０ａ、３３０ｂ、３３０ｃ、３３０ｄ、３３０ｅ、３３０ｆおよび３３０ｇが存在する。したがって、図３Ａに示すように、４つの作業スロット３１０ａ、３１０ｂ、３１０ｃおよび３１０ｄが存在するため、４つの関連パイル３２０ａ、３２０ｂ、３２０ｃおよび３２０ｄも存在する。図３Ａに示すように、各作業スロットは、専用の関連パイルを有する。呼び出しスレッドは、スロットに進入し、作業を関連パイルに追加する。特定のキーに関連するすべての作業は、同一の作業スロットを介して追加されるため、同一の専用の関連パイルに供給される。作業スレッドがパイルよりも多いため、作業スレッド３３０ａ、３３０ｂ、３３０ｃ、３３０ｄ、３３０ｅ、３３０ｆおよび３３０ｇのうち、少なくとも一部の作業スレッドは、一部の関連パイルを共有する必要がある。換言すれば、２つ以上の作業スレッドは、１つの関連パイルから作業をポーリングする。例えば、作業スレッド３３０ａおよび３３０ｂの両方は、関連パイル３２０ａから作業をポーリングする。
【００５２】
図３Ｂは、作業スレッド３３０の数が作業スロット３１２の数より少ない構成を示す。作業スレッドが作業スロットよりも少ない場合、関連パイルの数は作業スレッドの数に等しい。したがって、図３Ｂは、３つの作業スレッド３３０ａ、３３０ｂおよび３３０ｃと、３つの関連パイル３２０ａ、３２０ｂおよび３２０ｃとを示している。作業スロット３１０が関連パイル３２０よりも多いため、一部の作業スロットは、パイルを共有しなければならない。例えば、作業スロット３１０ｃおよび３１０ｄに進入した呼び出しスレッドの両方は、関連パイル３２０ｃに作業を置くことができる。しかしながら、特定のキーに関連するすべての作業は、同一の作業スロットを介して追加されたため、同一（共有）の関連パイルに送られる。しかしながら、図３Ｂに示すように、各作業スレッドは、作業を受け取る専用の関連パイルを有する。しかしながら、作業スレッドは、作業をもっていない場合、スリープ状態に入る前に、別のスレッドのパイルから作業を取ろうとする。
【００５３】
スレッドの追加および削除
図３Ａおよび３Ｂの拡張可能なスレッドプールに作業スレッドを追加するときおよび／または作業スレッドを削除するときに、作業スレッド、関連パイルおよび作業スレッドの間の関係が考慮される。作業スレッド、スロット、関連パイルの間のバランスを維持することが重要である。また、作業スレッドが作業スロットより多い場合、関連パイルの数が作業スロットの数に等しく、作業スロットよりも作業スレッドが少ない場合、関連パイルの数が作業スレッドの数に等しくなるように、スレッドプールの特性を維持する必要がある。さらに、作業スレッド数および／または関連パイル数を変更する間に、スレッドの安全性および同一のキーに関連された要素のＦＩＦＯ順序を保持する必要がある。図４Ａおよび４Ｂは、これらの目的に従って、図３Ａおよび３Ｂの拡張可能なスレッドプールに作業スレッドを追加および削除する方法を示す図である。
【００５４】
図４Ａは、図３Ａおよび３Ｂの拡張可能なスレッドプールに作業スレッドを追加する方法を示す図である。ステップ４００において、拡張可能なスレッドプールに作業スレッドを追加するプロセスを開始する。ステップ４０２において、現在のスレッド数を作業スロット数と比較する。例えば図３Ａに示すように、ステップ４０４で作業スレッド数≧作業スロット数と判定された場合、プロセスは、ステップ４０６に進む。作業スレッド数≧作業スロット数の場合、１つ以上の関連パイルを２つ以上の作業スレッドに関連付ける必要がある。ステップ４０６において、最小数の作業スレッドに共有されている関連パイルを決定し、このパイル（例えば、図３Ａの関連パイル３２０ｄ）を選択する。ステップ４０８において、ステップ４０６で選択された関連パイルに新規作業スレッドを関連付ける。その後、プロセスは、ステップ４３０に進み、作業スレッドを追加するプロセスを終了する。このプロセスによって、作業スレッドは、最小数の作業スレッドを有する関連パイルに追加される。
【００５５】
例えば図３Ｂに示すように、ステップ４１４で作業スレッド数＜作業スロット数と判定された場合、プロセスは、ステップ４１６に進む。図３Ｂに示すように、作業スレッド数＜作業スロット数の場合、少なくとも２つの作業スロットは、同一の関連パイルを共有している。これらのスロットのうち１つ（例えば、作業スロット３１０ｃまたは作業スロット３１０ｄ）を新規関連パイルに関連付けると共に、新規関連パイルに新規作業スレッドを作成する必要がある。一方、作業スロット３１０ｃおよび３１０ｄの両方からのすべてのタスクを受け取る古い関連パイル３２０ｃは、依然として作業スレッド３３０ｃによって処理される。作業スロット３１０ｄに新規関連パイルを作成する場合、タスクのFIFO順序を維持するために、作業スロット３１０ｄに関連付けられた新規関連パイルを起動する前に、作業スロット３１０ｄによって共有されている関連パイル３２０ｃに入れられたタスクがすべて終了したことを確認する必要がある。
【００５６】
再び図４Ｂを参照して、ステップ４１６において、関連パイルを共有しているスロット（例えば、図３Ｂの作業スロット３１０ｄ）が選択される。ステップ４１８において、新規関連パイルが作成され、ステップ４１６で選択された作業スロットに関連付けられる。しかしながら、対応するデーモン（daemon）は、直ちに起動されない。その代わりに、ステップ４２０において、古い共有関連パイル（例えば、図３Ｂの関連パイル３２０ｃ）に総合StartWorkerジョブを追加する。StartWorkerジョブが古い共有関連パイルで処理されたときに、先入先出順序によって、作業スロット３１０ｄに関連付けられた古い共有関連パイル内に以前にポストされたすべてのジョブは、既に処理されたことが保証される。したがって、ステップ４２２において、総合StartWorkerジョブが処理されたときに、新規作業スレッドを起動し、ステップ４１６で選択された作業スロットに関連付けられた新規関連パイルに関連付ける。その後、プロセスは、ステップ４３０に進み、作業スレッドを追加するプロセスを終了する。
【００５７】
図４Ｂは、図３Ａおよび３Ｂの拡張可能なスレッドプールから作業スレッドを削除する方法を示す図である。ステップ４５０において、拡張可能なスレッドプールから作業スレッドを削除するプロセスを開始する。ステップ４５２において、現在のスレッド数を作業スロット数と比較する。例えば図３Ａに示すように、ステップ４５４で作業スレッド数＞作業スロット数と判定された場合、プロセスは、ステップ４５６に進む。ステップ４５６において、最大数の作業スレッドを有する作業スロットのうつ、１つの作業スロットを選択する（例えば、図３Ａの作業スロット３１０ａ、３１０ｂまたは３１０ｃのうち、１つを選択する）。ステップ４５８において、ステップ４５６で選択された作業スロットを介して、総合StopWorkerジョブをスレッドプールに追加する。次いで、プロセスは、ステップ４８０に進み、作業スレッドを削除するプロセスを終了する。StopWorkerジョブがポーリングされると、StopWorkerジョブを処理するスレッドが停止される。したがって、そのスロットに対応する作業スレッドの数を減らすことができる。例えば、作業スロット３１０ａに位置するStopWorkerジョブは、関連パイル３２０ａに送られ、作業スレッド３３０ａおよび３３０ｂのうち１つによってポーリングされることによって、関連パイル３２０ａからこのStopWorkerジョブをポーリングする作業スレッドを停止する。
【００５８】
しかしながら、例えば図３Ｂに示すように、ステップ４６４で作業スレッド数≦作業スロット数と判定された場合、プロセスは、ステップ４６６に進む。作業スレッド数≦作業スロット数の場合、各パイルは、１つのみの作業スレッドにより処理される。したがって、作業スレッドを停止する場合、関連パイルを削除し、削除された関連パイルに関連付けられたスロットをリダイレクトする必要がある。ステップ４６６において、最小数の作業スロットによって共有される関連パイル（Ｐ１）（例えば、図３Ｂの関連パイル３２０ａ）を選択する。ステップ４６８において、ステップ４６６で選択された関連パイル（Ｐ１）にStopWorkerジョブを追加する。ステップ４７０において、StopWorkerジョブが実行されると、プロセスは、Ｐ１に対応するすべての作業スロット（例えば図３Ｂの作業スロット３１０ａ）を停止する。ステップ４７２において、次の最小数のスロットによって共有されるパイル（Ｐ２）（例えば、図３Ｂの関連パイル３２０ｂ）を探し出し、ステップ４７４において、Ｐ１（例えば、図３Ｂの関連パイル３２０ａ）の内容をＰ２（例えば、図３Ｂの関連パイル３２０ｂ）に合併し、Ｐ１（例えば、図３Ｂの関連パイル３２０ａ）を破棄して、すべての閉合スロット（例えば、図３Ｂの作業スロット３２０ａ）をＰ２（例えば、図３Ｂの関連パイル３２０ｂ）にリダイレクトし、閉合スロットを再び開放する。その後、プロセスは、ステップ４８０に進み、作業スレッドを削除するプロセスを終了する。
【００５９】
スレッドプールの動的サイズ変更
実施形態において、本開示は、分散データグリッドなどのようなマルチスレッド処理環境に適切に使用されるスレッドプールの動的サイズ変更をサポートするシステムおよび方法を記載する。スレッドプールの動的サイズ変更は、例えば、分散データグリッド内のサービススレッドに関連付けられた拡張可能なスレッドプールに実行することができる。スレッドプールの動的サイズ変更は、スレッドプール処理量および作業スレッド使用率の測定値および前回のスレッドプールサイズ変更動作の効果分析を併用して、現在のサイズ変更動作においてスレッドプールに作業スレッドの追加またはスレッドプールから作業スレッドの削除を決定する。さらに、スレッドプールの動的サイズ変更システムおよび方法は、システムの需要に応じて、サイズ変更の反復分析および作業スレッドの追加および削除速度を加速または減速することができる。最適化を組み込むことによって、最大処理量の局部低下を回避する。これによって、スレッドプールの動的サイズ変更／再変更システムおよび方法は、作業量および利用可能なプロセッサの変化に応答して、スレッドプールのサイズを迅速に調整する。
【００６０】
本発明の一実施形態によれば、分散データグリッドは、拡張可能なスレッドプールを動的にサイズ変更／再変更することによって、スレッドプールの処理量を最大化し、システムリソースの利用率を最小限にすることができる。スレッドプールのサイズ変更は、以下に説明するサイズ変更分析の反復実施によって実現される。上記の説明は、図３Ａおよび３Ｂの拡張可能なスレッドプールにスレッドを追加する方法およびスレッドプールからスレッドを削除する方法を提供する。以下の説明は、作業量および利用可能なプロセッサの変化に応じて、拡張可能なスレッドプールにスレッドを追加および削除するタイミングを決定する方法を提供する。以下で説明するサイズ変更および再変更メカニズムは、上述の拡張可能なスレッドプールに適用することができ、他の可変サイズおよび／または拡張可能なスレッドプールに適用することもできる。
【００６１】
上述した分散データグリッドにおいて、作業量は、サービススレッド間に大幅に変化する可能性があり、各サービススレッドに関する時間に伴って大幅に変化する可能性がある。さらに複雑なことは、分散データグリッドにおいて、異なる名前のキャッシュに対応する多数のキャッシュサービスが同一のノード内に同時に動作する可能性があるということである。さらに、複数の異なるサービススレッドを有する複数のノードは、同一のサーバ上で動作するため、プロセッサリソースを共有する可能性がある。これらのさまざまなサービススレッドの利用率は、時間と共に変化する可能性がある。したがって、分散データグリッドにおいて、スレッドプールの最適サイズは、スレッドプールに関連付けられたサービススレッドに与えられた作業だけではなく、同一のサーバ上の他のサービススレッドに同時に与えられた作業に従って、大幅に変化する可能性がある。したがって、望ましくは、スレッドプールの動的サイズ変更メカニズムは、作業量の変動に迅速に応答し、少ない反復回数で特定の作業量および作業環境に対して最適なスレッドプールサイズを決定するように、サイズ変更を実行する。
【００６２】
図５は、本発明の一実施形態に従った、分散データグリッドにおいてスレッドプールの動的サイズ変更をサポートするためのシステムおよび方法を示す図である。図５に示すように、拡張可能なスレッドプール、例えばスレッドプール５００は、そのスレッド数を動的に調整することができる。ステップ５０１において、システムは、スレッドプール５００の一定期間の処理量を測定することができる。次に、ステップ５０２において、システムは、前回期間からスレッドプール５００の処理量の変化を決定し、１つ以上の基準が満たされた場合、ランダム量でスレッドプールのサイズを変更することができる。さらに、ステップ５０３において、システムは、前回期間においてスレッドプール５００のサイズ変更効率に基づいて、次回期間の長さを決定することができる。
【００６３】
このスレッドプールの動的サイズ変更方法は、図３Ａおよび３Ｂの拡張可能なスレッドプールと合わせて使用され、スレッド数を動的に調整することによって、拡張可能なスレッドプールの処理量を増加し、および／またはリソース使用率を最小限に抑える。動的サイズ変更は、周期的な総合ResizePoolジョブを上記の拡張可能なスレッドプールに挿入することによって行われる。一般的に、総合ResizePoolジョブは、スレッドの追加または削除に応じて性能応答を分析し、分析結果を使用してスレッドを追加または削除するか否かを判断し且つ性能を再解析するまでの待機時間を決定するサイズ変更方法を使用する。一旦潜在的な最大処理量を達成すると、最大処理量の局部低下を回避するために、スレッドプール内のスレッド数をランダムに増加または減少する。
【００６４】
周期的な総合ResizePoolジョブのスケジュールは、サイズ変更ジョブ間の可変期間に依存する。１つのResizePoolジョブを挿入する時間と次のResizePoolジョブを挿入する時間との間隔は、前回のサイズ変更による効果によって変化する。ResizePoolジョブの実行によって処理量が変化する場合、そのResizePoolジョブを挿入する時間と次のResizePoolジョブを挿入する時間との間隔が短くなる。ResizePoolジョブの実行によって処理量が大幅に変化しない場合、ResizePoolジョブを挿入する時間と次のResizePoolジョブを挿入する時間との間隔が長くなる。この方法は、本質的に反復性能分析実験であり、処理量およびスレッド使用率の測定値に基づいて、作業量、処理量および利用可能なプロセッサの変化を考慮して、スレッドプールのサイズを動的に調整できる。
【００６５】
図６は、総合ResizePoolジョブに実行されるステップを示す図である。総合ResizePoolジョブは、計算期間が切れた時に、実行のためにジョブを上述した拡張可能なスレッドプールに挿入することによって、ステップ６００で開始される。次に、ジョブは、作業スレッドによって関連パイルからポーリングされ、図示のように処理される。ステップ６０２において、ジョブは、まず、スレッドプールの処理量（Ｔnow）を測定し、前回の実行から処理量（Ｔlast）の変化（ΔＴ）を計算する。ΔＴは、ＴnowとＴlastとの差として計算することができる。Ｔnowは、メモリに保存され、次のジョブを実行する時にＴlastとして使用される。ステップ６０４において、ジョブは、プールを「シェークする」タイミングであるか否かを判断する。この判断は、反復カウンタ、またはタイマ、または等価物を使用して行うことができる。プールを「シェークする」タイミングである場合、ジョブは、ステップ６０６に進み、ランダム量でプールのサイズを変更する。その後、ジョブは、ステップ６２２に進み、再スケジュールする。ランダム量は、特定範囲内のスレッド数のランダム百分率または予め設定された数のスレッドのランダム百分率として計算されてもよい。ResizePoolジョブは、計算期間が切れた時に、実行のためにジョブを上述した拡張可能なスレッドプールに挿入することによって、ステップ６００で再び開始される。別の実施形態において、ResizePoolジョブは、専用のスレッドおよび／またはスレッドプールに含まれていないスレッドによって実行される。
【００６６】
再び図６を参照して、ステップ６０４でプールを「シェークする」タイミングではない場合、ジョブは、ステップ６０８に進む。ステップ６０８において、ジョブは、「顕著な」処理量変化（Ｔjitter）をＴlastの単純な関数（例えば１０％または５％）として計算する。次に、ジョブは、ＴjitterをΔＴと比較することによって、処理量に大幅な変化が発生したか否かを判断する。別の方法として、ステップ６０８において、ジョブは、前回にジョブを実行したときの処理量と現在の処理量との差が、前回の処理量に比べて処理量の顕著な変化を表すか否かを判定する（代替的に、処理量の変化の顕著性は、前回の処理量の代わりに現在の処理量と比較することによって行うことができる）。
【００６７】
ステップ６０８でΔＴをＴjitterと比較することによって決定されたように、前回にジョブを実行してから処理量に顕著な変化がなかった場合、ジョブは、ステップ６１０に移行する。ステップ６１０において、スレッドプールが過度に使用されている場合、ジョブは、スレッドプールにスレッドを追加し、スレッドプールが十分に活用されていない場合、ジョブは、スレッドプールから１つ以上のスレッドを削除する。スレッドプールが過度に使用されておらずまたは十分に活用されていない場合、ジョブは、スレッドプールに変更を加えない。ResizePoolジョブを実行しているときに、アクティブな作業スレッドの数がすべての作業スレッド数に対して一定の割合（例えば、６６％または８０％）を超える場合、スレッドプールは、過度に使用されていると見なされる。アクティブな作業スレッドの数がすべての作業スレッド数に対して一定の割合（例えば、３３％または２０％）を下回る場合、スレッドプールは、十分に活用されていないと見なされる。スレッドプールが「最大限」に達したとしても、すなわちスレッドプールが追加の作業を実行できない場合でも、一部の作業スレッドが常に「ジョブの間」にあるため、スレッドの表示使用率は、１００％未満である。スレッドを追加した後、スレッドを削除した後、またはスレッドの数を変更しない場合、ジョブは、ステップ６２０に進む。
【００６８】
ステップ６０８において、前回にジョブを実行してから処理量に顕著な変化があった場合、ジョブによる次の動作は、前回にジョブを実行したときに取った動作（前回のサイズ変更動作）に依存する。したがって、ステップ６１２において、前回のサイズ変更動作（すなわち、スレッドの追加、スレッドの削除または動作無し）を判断する。前回のサイズ変更動作は、通常、Ｔnow／Ｔlastおよび現在期間の間隔などの他の値と共に、ResizePoolジョブに関連付けられた状態で記録される。これらの値は、例えばメモリに格納され、ResizePoolジョブを実行するたびに、これらの値を利用することができる。
【００６９】
前回の動作でスレッドを追加した場合、ジョブは、ステップ６１４に進む。ステップ６１４において、ΔＴが処理量の増加を示した場合、ジョブは、１つ以上の追加スレッドをスレッドプールに追加し、次回の分析までの間隔を短縮する。ステップ６１４において、ΔＴが処理量の低下を示した場合、ジョブは、スレッドプールから１つ以上のスレッドを削除し、次回の解析までの間隔を増加する。スレッドの追加によって処理量が低下することは、例えば、作業量の増加に応じて多過ぎるスレッドを追加したこと、すなわち、最適なスレッド数を「オーバーシュート」したことを示すことができる。したがって、１つ以上のスレッドを削除し、解析を減らすことによって変動を減少する。スレッドを追加した後またはスレッドを削除した後、ジョブは、ステップ６２０に進む。
【００７０】
前回の動作でスレッドを削除した場合、ジョブは、ステップ６１６に進む。ステップ６１６において、ΔＴが処理量の増加を示した場合、ジョブは、スレッドプールから１つ以上のスレッドをさらに削除し、次回の分析までの間隔を短縮する。ステップ６１６において、ΔＴが処理量の低下を示した場合、ジョブは、スレッドプールに１つ以上のスレッドを追加し、次回の解析までの間隔を増加する。スレッドの削除によって処理量が低下することは、例えば、作業量の減少に応じて多過ぎるスレッドを削除したこと、すなわち、最適なスレッド数を「アンダーシュート」したことを示すことができる。したがって、１つ以上のスレッドを追加し、解析を減らすことによって変動を減少する。スレッドを追加した後またはスレッドを削除した後、ジョブは、ステップ６２０に進む。
【００７１】
ResizePoolジョブは、拡張可能なスレッドプールから作業スレッドを追加または削除するようにサイズ変更動作を実行する必要があると判断した場合、図４Ａおよび４Ｂに関連して上述したように、１つ以上のStartWorkerジョブまたはStopWorkerジョブをスレッドに挿入することによって、作業スレッドの追加または削除を行う。上記のステップに追加または削除したスレッドの数（結果的に、スレッドプールに挿入すべきStartWorkerジョブまたはStopWorkerジョブの数）は、ジョブが実行されているスレッドプールにとって効果があるように選択する必要がある。したがって、より多いスレッドを有するスレッドプールの場合、各操作に、より多くのスレッドを追加または削除することができる。より小さいスレッドを有するスレッドプールの場合、各操作に、より少ないスレッドを追加または削除することができる。一実施形態において、１つのステップに追加または削除するスレッドの数は、現在のスレッド数に従って、例えば現在のスレッド数の５％、１０％または２０％に基づいて決定することができる。上述したオーバーシュートおよびアンダーシュートの例において、オーバーシュートを修正するために、より少ない数のスレッド、例えば前回の操作に追加または削除したスレッドの半数を追加または削除することができる。代替的には、スレッドに追加または削除するスレッドの数を固定することもできる（例えば、一回に１つのスレッド）。
【００７２】
なお、スレッドプールにスレッドの追加速度またはスレッドプールからスレッドの削除速度は、ResizePoolジョブの各反復に追加または削除するスレッドの数およびResizePoolジョブを実行する頻度に依存する。したがって、期間を短縮すると、ResizePoolジョブの頻度が増加し、単位時間に実行できる反復が多くなる。したがって、より多くの作業スレッドを追加または削除することもできる。これにより、動的サイズ変更システムおよび方法は、処理量、作業量および利用可能なプロセッサなどの他の要因の変化に迅速に反応することができる。
【００７３】
前回の動作でスレッド数の変更を行わなかった場合、ジョブは、ステップ６１８に進む。ステップ６１８において、ΔＴが処理量の増加を示し、スレッドプールが過度に使用されている場合、ジョブは、１つ以上のスレッドをスレッドプールに追加する。ステップ６１８において、ΔＴが処理量の低下を示し、スレッドプールが十分に活用されていない場合、ジョブは、スレッドプールから１つ以上のスレッドを削除する。上記のいずれもではない場合、ジョブは、スレッドプールを変更しない。スレッドを追加した後、スレッドを削除した後、またはスレッドの数を変更しない場合、ジョブは、ステップ６２０に進む。
【００７４】
ステップ６２０において、前のステップのいずれかでスレッドを追加または削除する決定がなされた場合、総合ResizePoolジョブは、システムが定着した後、新しい処理量統計値を収集するために、新しい期間の半分で再び実行するように自己スケジュールする。新しい処理量統計値を収集した後（またはスレッドの数を変更しなかった場合には、直ぐに）、総合ResizePoolジョブは、新規期間に再び実行するように自己スケジュールする。すなわち、期間の終了後に、ステップ６００でジョブを再開する。さらに、ResizePoolジョブが次回の反復で実行された前回のサイズ変更動作を示す情報を利用できるように、実行されたサイズ変更動作は、メモリに格納される。ResizePoolジョブは、数回反復的に実行され、処理量およびスレッド使用率の測定値に応じて、スレッドプール内の作業スレッドの数を調整し、上述した前回のサイズ変更動作の効果に応じて、次回のジョブまでの待機時間を増減することによって、分析回数を増加または減少する。
【００７５】
本発明の実施形態において、分散データグリッド１００は、以下に記載され、図２、３Ａ、３Ｂ、４Ａおよび４Ｂに示された１つ以上の拡張可能なスレッドプールシステムおよび方法を実装する。本発明の実施形態において、分散データグリッド１００は、以下に記載され、図５および６に示された拡張可能なスレッドプールの動的サイズ変更を行うための１つ以上のシステムおよび方法を実装する。特定の実施形態において、拡張可能なスレッドプールシステム、拡張可能なスレッドプールの動的サイズ変更を行うためのシステムおよび方法は、例えば、分散データグリッド１００のノード上で動作し、キャッシュサービススレッドおよびプロキシサービススレッドを含む１つ以上のサービススレッドに対して実装されてもよい。
【００７６】
図７は、本発明の一実施形態に従って、拡張可能なスレッドプールおよび分散データグリッド内で拡張可能なスレッドプールの動的サイズ変更を行うためのシステムの実装を示す図である。例えば、図７に示すように、分散データグリッド１００において、ノード１３０ａによって提供されたサービスは、サービススレッド７１０によって提供することができる。サービスは、例えば、キャッシュサービス１３２ａであってもよい。余分な処理リソースを提供するために、サービススレッド７１０は、可変数の作業スレッド（図示では３つ）７０２ａ、７０２ｂ、７０２ｃを含む拡張可能なスレッドプール７００と協働して、作業を実行することができる。一実施形態において、拡張可能なスレッドプール７００は、上記に記載され、図２、３Ａ、３Ｂ、４Ａおよび４Ｂに示された拡張可能なスレッドプールシステムおよび方法を実装する。拡張可能なスレッドプールは、処理量およびスレッド利用率に基づいて、拡張可能なスレッドプール７００内のスレッドの数を調整するためのサイズ変更システム７２０を含む。一実施形態において、サイズ変更システム７２０は、上記に記載され、図５および６に示された拡張可能なスレッドプールの動的サイズ変更を行うためのシステムおよび方法を実装する。キャッシュサービス１３２ａのサービススレッド７１０が例示の目的で示されているが、拡張可能なスレッドプール７００およびサイズ変更システム７２０は、スレッドが作業スレッドのスレッドプールと協働して動作する分散データグリッド１００内の多くの他のスレッドに関して実施することもできる。
【００７７】
本開示は、拡張可能なスレッドプール並びにスレッド利用率および処理量に応じて拡張可能なスレッドプールを動的にサイズ変更するためのシステムおよび方法を提供することによって、分散データグリッドにおいて拡張可能なスレッドプールを利用してサービススレッドに追加のリソースを提供するサービススレッドなどのスレッドの動作を高め、需要の変化に応じて分散データグリッドの性能および分散データグリッドの能力を向上させる。分散データグリッドに関して説明したが、上述した拡張可能なスレッドプールおよび動的サイズ変更システムおよび方法は、スレッドがスレッドプールを使用して追加のリソースを提供し、変化する需要に対処するために拡張する必要がある多種多様な状況にも適用可能である。例えば、上述した拡張可能なスレッドプールおよび動的サイズ変更システムおよび方法は、多種多様なマルチスレッド処理環境および応用に適用可能である。動的サイズ変更システムおよび方法は、図２、３Ａ、３Ｂ、４Ａおよび４Ｂに示すものと異なる構成を有する可変サイズ／拡張可能なスレッドプールにも適用可能である。
【００７８】
分散データグリッドなどのようなマルチスレッド処理環境において拡張可能なスレッドプールをサポートするためのシステムおよび方法。作業分配システムは、関連パイルの集合を利用して、サービススレッドと複数の作業スレッドとの間に要素を通信可能に保持する。関連パイルに関連付けられた作業スレッドは、並行で要素をポーリングする。ポーリングされた要素は、作業スレッドから返されるまでリリースされない。動作の先入先出順序は、関連要素が確実に同一の関連パイルに保持され、以前にポーリングされた関連要素がリリースされるまで関連要素のポーリングを防止することによって、関連要素に対して維持される。関連要素に対して動作の適切な順序を保証しながら、要素を複数の関連パイルに分割することによって、拡張可能なスレッドプールは、従来の単一生産者−複数消費者キューに比べて、競合を減らし、大きなスレッドプールの使用を可能にする。
【００７９】
一実施形態の方法は、マルチスレッド処理環境内の呼び出しスレッドから受信した複数の順序付きタスクを実行するための拡張可能なスレッドプールを提供する。この方法は、タスクを保持するように構成された１つ以上の結合パイルを提供するステップと、２つ以上の作業スロットを提供するステップとを含み、各作業スロットは、１つのみの関連パイルに向けられ、その結果、呼び出しスレッドによって作業スロットに提供された複数の順序付きタスクの各タスクは、呼び出しスレッドによって、作業スロットを介して作業スロットが向けられた１つのみの関連パイルに提供される。この方法は、１つ以上の関連パイルの各々に関連付けられた１つ以上の作業スレッドを提供するステップを含み、各作業スレッドは、関連付けられた関連プールからタスクをポーリングし、タスクを実行し、完了したときにタスクをリリースするように構成される。この方法は、作業スレッドによって関連パイルからポーリングされた保留タスクが完了時に作業スレッドによってリリースされるまでその関連パイルに保持されるように、各関連パイルを構成するステップと、保留タスクおよび保留タスクに関連するすべてのタスクのポーリングを防止することによって、各関連パイルが関連タスクの先入先出順序を維持するように、各関連パイルを構成するステップとを含む。
【００８０】
一実施形態の方法において、作業スレッドの数は、作業スロットの数よりも多く、タスクを保持するように構成された１つ以上の関連パイルの提供は、複数の作業スロットの各々に１つのみの専用の関連パイルを提供することを含む。
【００８１】
一実施形態の方法において、作業スロットの数は、作業スレッドの数よりも多く、タスクを保持するように構成された１つ以上の関連パイルの提供は、複数の作業スレッドの各々に１つのみの関連パイルを提供することを含む。
【００８２】
一実施形態の方法において、呼び出しスレッドは、すべての関連タスクが２つ以上の作業スロットのうち、同一の作業スロットを介して提供されるように構成される。
【００８３】
一実施形態の方法において、複数の順序付きタスクの各タスクは、１つのキーに関連付けられ、保留タスクおよび保留タスクに関連するすべてのタスクのポーリングを防止することによって、各関連パイルが関連タスクの先入先出順序を維持するように、各関連パイルを構成するステップは、保留タスクおよび保留タスクと同一のキーを有するすべてのタスクのポーリングを防止することによって、各関連パイルが同一のキーに関連付けられたタスクの先入先出順序を維持するように、各関連パイルを構成することを含む。
【００８４】
一実施形態の方法において、同一のキーを有するすべてのタスクが２つ以上の作業スロットのうち、同一の作業スロットを介して提供されるように、呼び出しスレッドを構成する。
【００８５】
一実施形態の方法において、作業スレッドの数は、作業スロットの数よりも多く、最小数の作業スレッドに関連付けられた関連パイルのいずれかにStartWorkerジョブを配置することによって、作業スレッドを追加するステップをさらに含む。これによって、StartWorkerジョブを実行するときに、新規作業スレッドが、関連パイルに関連して作成される。
【００８６】
一実施形態の方法において、作業スレッドの数は、作業スロットの数よりも多く、最小数の作業スレッドに関連付けられた関連パイルのいずれかにStartWorkerジョブを配置することによって、作業スレッドを削除するステップをさらに含む。これによって、StartWorkerジョブを実行するときに、関連パイルに関連付けられた作業スレッドが停止される。
【００８７】
一実施形態の方法において、作業スロットの数は、作業スレッドの数よりも多く、最大数の作業スレッドに関連付けられた関連パイルのいずれかにStartWorkerジョブを配置することによって、作業スレッドを追加するステップをさらに含む。これによって、StartWorkerジョブを実行するときに、新規関連パイルが、作業スロットに関連して作成され、新規作業スレッドが、関連パイルに関連して作成される。
【００８８】
一実施形態の方法において、作業スロットの数は、作業スレッドの数よりも多く、最小数の作業スレッドに関連付けられた関連パイルのいずれかにStopWorkerジョブを配置することによって、作業スレッドを削除するステップをさらに含む。これによって、StopWorkerジョブを実行するときに、関連パイルに関連付けられた作業スレッドが停止され、当該関連パイルが別の関連パイルに合併される。
【００８９】
一実施形態のシステムは、マルチスレッド処理環境内の呼び出しスレッドから受信した複数の順序付きタスクを実行する拡張可能なスレッドプールを提供する。このシステムは、メモリとプロセッサとを有するコンピュータシステムを含み、プロセッサは、複数のコアを有し、マルチスレッド動作可能であり、タスクを保持するように構成された１つ以上の関連パイルと、２つ以上の作業スロットとを含み、各作業スロットは、各作業スロットは、１つのみの関連パイルに向けられ、その結果、呼び出しスレッドによって作業スロットに提供された複数の順序付きタスクの各タスクは、呼び出しスレッドによって、作業スロットを介して作業スロットが向けられた１つのみの関連パイルに提供され、１つ以上の関連パイルの各々に関連付けられた１つ以上の作業スレッドを含み、各作業スレッドは、関連付けられた関連プールからタスクをポーリングし、タスクを実行し、完了したときにタスクをリリースするように構成され、各関連パイルは、作業スレッドによって関連パイルからポーリングされた保留タスクが完了時に作業スレッドによってリリースされるまでその関連パイルに保持されるように構成され、各関連パイルは、保留タスクおよび保留タスクに関連するすべてのタスクのポーリングを防止することによって、各関連パイルが関連タスクの先入先出順序を維持するように構成される。
【００９０】
１つの実施形態のシステムにおいて、作業スレッドの数は、作業スロットの数よりも多く、システムは、複数の作業スロットの各々に提供された１つのみの専用の関連パイルを含む。
【００９１】
一実施形態のシステムにおいて、作業スロットの数は、作業スレッドの数よりも多く、システムは、複数の作業スレッドの各々に提供された１つのみの関連パイルを含む。
【００９２】
一実施形態のシステムにおいて、呼び出しスレッドは、すべての関連タスクが２つ以上の作業スロットのうち、同一の作業スロットを介して提供されるように構成される。
【００９３】
一実施形態のシステムにおいて、複数の順序付きタスクの各タスクは、１つのキーに関連付けられ、各関連パイルは、保留タスクおよび保留タスクと同一のキーを有するすべてのタスクのポーリングを防止することによって、各関連パイルが同一のキーに関連付けられたタスクの先入先出順序を維持するように構成される。
【００９４】
一実施形態のシステムにおいて、作業スレッドの数は、作業スロットの数よりも多く、システムは、最小数の作業スレッドに関連付けられた関連パイルのいずれかにStartWorkerジョブを配置することによって、作業スレッドを追加するように構成される。これによって、StartWorkerジョブを実行するときに、新規作業スレッドが、関連パイルに関連して作成される。
【００９５】
一実施形態のシステムにおいて、作業スレッドの数は、作業スロットの数よりも多く、システムは、最小数の作業スレッドに関連付けられた関連パイルのいずれかにStartWorkerジョブを配置することによって、作業スレッドを削除するように構成される。これによって、StartWorkerジョブを実行するときに、関連パイルに関連付けられた作業スレッドが停止される。
【００９６】
一実施形態において、作業スロットの数は、作業スレッドの数よりも多く、システムは、最大数の作業スレッドに関連付けられた関連パイルのいずれかにStartWorkerジョブを配置することによって、作業スレッドを追加するように構成さる。これによって、StartWorkerジョブを実行するときに、新規関連パイルが、作業スロットに関連して作成され、新規作業スレッドが、関連パイルに関連して作成される。
【００９７】
一実施形態の方法において、作業スロットの数は、作業スレッドの数よりも多く、システムは、最小数の作業スレッドに関連付けられた関連パイルのいずれかにStopWorkerジョブを配置することによって、作業スレッドを削除するように構成される。これによって、StopWorkerジョブを実行するときに、関連パイルに関連付けられた作業スレッドが停止され、当該関連パイルが別の関連パイルに合併される。
【００９８】
実施形態は、マルチスレッド処理環境内の呼び出しスレッドから受信した複数の順序付きタスクを実行する拡張可能なスレッドプールを提供するための命令を格納する非一時的なコンピュータ可読媒体を提供する。これらの命令は、実行されると、コンピュータシステムに、以下のステップを実行される。当該ステップは、タスクを保持するように構成された１つ以上の結合パイルを提供するステップと、２つ以上の作業スロットを提供するステップとを含み、各作業スロットは、１つのみの関連パイルに向けられ、その結果、呼び出しスレッドによって作業スロットに提供された複数の順序付きタスクの各タスクは、呼び出しスレッドによって、作業スロットを介して作業スロットが向けられた１つのみの関連パイルに提供される。当該ステップは、１つ以上の関連パイルの各々に関連付けられた１つ以上の作業スレッドを提供するステップを含み、各作業スレッドは、関連付けられた関連プールからタスクをポーリングし、タスクを実行し、完了したときにタスクをリリースするように構成される。当該ステップは、作業スレッドによって関連パイルからポーリングされた保留タスクが完了時に作業スレッドによってリリースされるまでその関連パイルに保持されるように、各関連パイルを構成するステップと、保留タスクおよび保留タスクに関連するすべてのタスクのポーリングを防止することによって、各関連パイルが関連タスクの先入先出順序を維持するように、各関連パイルを構成するステップとを含む。
【００９９】
上記で本発明のさまざまな実施形態を説明したが、これらの実施形態は、限定ではなく例示として提示されることを理解すべきである。本発明の精神および範囲から逸脱することなく、形態および詳細のさまざまな変更を行うことができることは、当業者にとって明らかであろう。
【０１００】
本発明の多くの特徴は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせに実行する、またはそれらを使用して実行する、またはそれらの援助で実行することができる。本発明は、本開示の教示に従ってプログラムされた１つ以上のプロセッサ、メモリおよび／またはコンピュータ可読記憶媒体を含む１つ以上の従来の汎用または専用デジタルコンピュータ、コンピューティング装置、機械、またはマイクロプロセッサを使用して都合よく実施することができる。本発明の特徴は、例えば、特定用途向け集積回路（ＡＳＩＣ）およびプログラマブル論理装置などのハードウェア要素を使用して、ハードウェアで実施することもできる。本開示に記載の機能を実行するために、ハードウェア状態機械を実装することは、当業者には明らかであろう。
【０１０１】
本発明の特徴は、処理システムのハードウェアを制御し、本発明の結果を利用して処理システムと他の機構との相互作用を可能にするソフトウェアおよび／またはファームウェアに組み込むことができる。そのようなソフトウェアまたはファームウェアは、アプリケーションコード、装置ドライバ、オペレーティングシステムおよび実行環境／コンテナを含むことができるがこれらに限定されない。ソフトウェア分野の当業者には明らかであるように、熟練したプログラマは、本開示の教示に基づいて、適切なソフトウェアのコーディングを容易に準備することができる。
【０１０２】
いくつかの実施形態において、本発明は、本発明のプロセスのうちいずれかを実行するようにコンピュータをプログラムするために使用できる命令を格納する非一時的な記録媒体またはコンピュータ読取可能な媒体であるコンピュータプログラム製品を含む。この記録媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む、任意の種類のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム（分子メモリＩＣを含む）、または、命令および／もしくはデータを格納するのに適した任意の種類の媒体もしくは装置を含むことができるが、これらに限定されない。
【０１０３】
本発明の上記記載は、例示および説明を目的として提供される。本発明を網羅的なものまたは開示された形態そのものに限定することを意図していない。当業者には数多くの変更および変形が明らかであろう。修正例および変形例は、開示された特徴の任意可能な組み合わせを含む。実施形態は、本発明の原理およびその実際の応用を最も良く説明することによって、他の当業者がさまざまな実施形態および考えられる特定の用途に適したさまざまな変形に応じて本発明を理解できるように、選択され説明される。本発明の範囲は、添付の特許請求の範囲およびそれらの同等物によって規定されると意図する。
【図１】
0006613305.tif 000002
【図２】
0006613305.tif 000003
【図３Ａ】
0006613305.tif 000004
【図３Ｂ】
0006613305.tif 000005
【図４Ａ】
0006613305.tif 000006
【図４Ｂ】
0006613305.tif 000007
【図５】
0006613305.tif 000008
【図６】
0006613305.tif 000009
【図７】
0006613305.tif 000010