JP2017515234A

JP2017515234A - トランザクションミドルウェアマシン環境において適応セルフチューニングロックメカニズムをサポートするためのシステムおよび方法

Info

Publication number: JP2017515234A
Application number: JP2016565190A
Authority: JP
Inventors: ジン，ヨンシュン; シェン，シュガン; ヂャン，チンシェン
Original assignee: オラクル・インターナショナル・コーポレイション
Priority date: 2014-04-30
Filing date: 2014-04-30
Publication date: 2017-06-08
Anticipated expiration: 2034-04-30
Also published as: JP6446475B2; CN106471486A; WO2015165073A1; US20150317191A1; KR102239280B1; US9846603B2; KR20160147984A; CN106471486B

Abstract

システムおよび方法は、トランザクションミドルウェアマシン環境において適応セルフチューニングロックメカニズムをサポートすることができる。当該システムは、複数のプロセスの各プロセスが、共有メモリ内のデータに対するロックを取得するために１つ以上のテスト・アンド・セット（ＴＡＳ）オペレーションを行なうことを可能にする。当該システムは次に、現在のチューニング期間のスピン失敗レートを取得することができ、許容される最大回数のＴＡＳオペレーションを行った後でプロセスがロックの取得に失敗した場合、スピン失敗が発生する。さらに、当該システムは、取得したスピン失敗レートに基づいて次のチューニング期間のスピンカウントを適応的に構成することができ、スピンカウントは、次のチューニング期間について許容されるＴＡＳオペレーションの最大回数を特定する。

Description

著作権表示
この特許文献の開示の一部は、著作権保護の対象となる題材を含んでいる。著作権の所有者は、特許商標庁の包袋または記録に掲載されるように特許文献または特許開示を誰でも複製できることに対して異議はないが、その他の点ではすべての如何なる著作権をも保有する。

関連出願との相互参照
本願は以下の特許出願に関連しており、以下の特許出願の各々はその全内容が参照により本明細書に援用される。

２０１２年３月７日に出願され、「トランザクショナルミドルウェアマシン環境においてセルフチューニングロックメカニズムをサポートするためのシステムおよび方法（SYSTEM AND METHOD FOR SUPPORTING A SELF-TUNING LOCKING MECHANISM IN A TRANSACTIONAL MIDDLEWARE MACHINE ENVIRONMENT）」と題された、出願番号第１３／４１４，５９３号である米国特許出願（代理人整理番号：ＯＲＡＣＬ−０５２５５ＵＳ１）。

発明の分野
本発明は、概して、コンピュータシステムおよびミドルウェアなどのソフトウェアに関し、特に、トランザクションミドルウェアマシン環境をサポートすることに関する。

背景
トランザクションミドルウェアシステムまたはトランザクション指向型ミドルウェアは、組織内のさまざまなトランザクションを処理することができるエンタープライズアプリケーションサーバを含む。高性能ネットワークおよびマルチプロセッサコンピュータなどの新技術の開発によって、トランザクションミドルウェアの性能をさらに改善する必要がある。これらは、発明の実施形態が対処しようとする一般的領域である。

概要
トランザクションミドルウェアマシン環境において適応セルフチューニングロックメカニズムをサポートすることができるシステムおよび方法が本明細書中に記載される。当該システムは、複数のプロセスの各プロセスが、共有メモリ内のデータに対するロックを取得するために１つ以上のテスト・アンド・セット（test-and-set：ＴＡＳ）オペレーションを行なうことを可能にする。当該システムは次に、現在のチューニング期間のスピン失敗レートを取得することができ、許容される最大回数のＴＡＳオペレーションを行った後でプロセスがロックの取得に失敗した場合、スピン失敗が発生する。さらに、当該システムは、取得したスピン失敗レートに基づいて次のチューニング期間のスピンカウントを適応的に構成することができ、スピンカウントは、次のチューニング期間について許容されるＴＡＳオペレーションの最大回数を特定する。

発明の一実施形態に従う、ロックメカニズムをサポートするトランザクションミドルウェアマシン環境の例を示す図である。発明の一実施形態に従う、トランザクションミドルウェアマシン環境において適応セルフチューニングロックメカニズムをサポートする例を示す図である。発明の一実施形態に従う、トランザクションミドルウェアマシン環境において適応セルフチューニングロックメカニズムをサポートするための例示的なフローチャートを示す図である。発明の一実施形態に従う、適応セルフチューニングロックメカニズムをサポートするトランザクションミドルウェアマシン環境においてスピンカウント値を動的に増加させる例を示す図である。発明の一実施形態に従う、適応セルフチューニングロックメカニズムをサポートするトランザクションミドルウェアマシン環境においてスピンカウント値を動的に減少させる例を示す図である。発明の一実施形態に従う、適応セルフチューニングロックメカニズムをサポートするトランザクションミドルウェアマシン環境においてスピンカウント値をそのまま維持する例を示す図である。発明の一実施形態に従う、適応セルフチューニングロックメカニズムをサポートするトランザクションミドルウェアマシン環境において負荷サージ保護を用いてスピンカウントを構成する例を示す図である。発明の一実施形態に従う、トランザクションミドルウェアマシン環境において負荷サージ保護を用いてスピンカウントを構成するための例示的なフローチャートを示す図である。

詳細な説明
トランザクションミドルウェアマシン環境において適応セルフチューニングロックメカニズムをサポートするためのシステムおよび方法が本明細書中に記載される。

発明の一実施形態に従うと、当該システムは、高性能ハードウェア、たとえば６４ビットプロセッサ技術、高性能な大容量メモリ、ならびに冗長なインフィニバンドおよびイーサネット（登録商標）ネットワーキングと、ＷｅｂＬｏｇｉｃＳｕｉｔｅのようなアプリケーションサーバまたはミドルウェア環境との組合せを含み、これにより、迅速に備えられ得るとともにオンデマンドでスケール変更可能な大規模並列インメモリグリッドを含む完全なＪａｖａ（登録商標）ＥＥアプリケーションサーバコンプレックスを提供する。一実施形態に従うと、当該システムは、アプリケーションサーバグリッド、ストレージエリアネットワーク、およびインフィニバンド（ＩＢ）ネットワークを提供するフルラック、ハーフラック、もしくはクォーターラック、または他の構成としてデプロイされ得る。ミドルウェアマシンソフトウェアは、たとえばＷｅｂＬｏｇｉｃＳｅｒｖｅｒ、ＪＲｏｃｋｉｔまたはＨｏｔｓｐｏｔＪＶＭ、ＯｒａｃｌｅＬｉｎｕｘ（登録商標）またはＳｏｌａｒｉｓ、およびＯｒａｃｌｅＶＭといった、アプリケーションサーバと、ミドルウェアと、他の機能性とを提供し得る。一実施形態に従うと、当該システムは、ＩＢネットワークによって互いに通信する複数のコンピュートノードと、ＩＢスイッチゲートウェイと、ストレージノードまたはユニットとを含み得る。ラック構成として実装される場合、当該ラックの未使用部分は、空のままとされるか、またはフィラー（ｆｉｌｌｅｒ）によって占有され得る。

本明細書において「ＳｕｎＯｒａｃｌｅＥｘａｌｏｇｉｃ」または「Ｅｘａｌｏｇｉｃ」と称される発明の一実施形態に従うと、当該システムは、ＯｒａｃｌｅＭｉｄｄｌｅｗａｒｅＳＷｓｕｉｔｅまたはＷｅｂｌｏｇｉｃといったミドルウェアまたはアプリケーションサーバソフトウェアをホスティングするための、デプロイが容易なソリューションである。本明細書に記載されるように、一実施形態に従うと、当該システムは、１つ以上のサーバと、ストレージユニットと、ストレージネットワーキングのためのＩＢファブリックと、ミドルウェアアプリケーションをホストするために要求されるすべての他のコンポーネントとを含む「グリッド・イン・ア・ボックス（grid in a box）」である。たとえばＲｅａｌＡｐｐｌｉｃａｔｉｏｎＣｌｕｓｔｅｒｓおよびＥｘａｌｏｇｉｃＯｐｅｎｓｔｏｒａｇｅを用いて大規模並列グリッドアーキテクチャを活用することにより、すべてのタイプのミドルウェアアプリケーションのために有意な性能が与えられ得る。このシステムは、線形のＩ／Ｏスケーラビリティとともに向上した性能を与え、使用および管理が簡易であり、ミッションクリティカルな可用性および信頼性を与える。

発明の一実施形態に従うと、Ｔｕｘｅｄｏ（登録商標）は、高性能の分散ビジネスアプリケーションの構築、実行および管理を可能にし、多くの多階層アプリケーション開発ツールによってトランザクションミドルウェアとして使用されてきた一組のソフトウェアモジュールである。Ｔｕｘｅｄｏは、分散コンピューティング環境において分散トランザクション処理を管理するために使用することができるミドルウェアプラットフォームである。無限のスケーラビリティおよび規格に基づいたインターオペラビリティを提供しつつ、企業レガシーアプリケーションをアンロックし、それらをサービス指向のアーキテクチャに拡張するための検証済みのプラットフォームである。

発明の一実施形態に従うと、Ｔｕｘｅｄｏシステムのようなトランザクションミドルウェアシステムは、Ｅｘａｌｏｇｉｃミドルウェアマシンのような複数のプロセッサを有する高速マシン、およびインフィニバンド（ＩＢ）ネットワークのような高性能ネットワーク接続を利用することができる。

ロックメカニズム
図１は、発明の一実施形態に従う、ロックメカニズムをサポートするトランザクションミドルウェアマシン環境の例を示す。図１に示されるように、トランザクションミドルウェア環境１００は、同時トランザクションが（すなわちプロセス１１１〜１１５について）ある場合、Ｔｕｘｅｄｏ環境においてたとえば掲示板（bulletin board：ＢＢ）などの共有メモリ１０１内のさまざまなトランザクションデータ１０２を保護するためのロックメカニズム１０３を採用することができる。

発明の一実施形態に従うと、トランザクションミドルウェア環境１００は、有効なロックメカニズムを実装するためのアトミックＴＡＳ（テスト・アンド・セット）１０４アセンブリコンポーネントを用いることによってマルチプロセッサマシンを利用することができる。その上、トランザクションアプリケーションにおけるプロセスは、必要に応じて、オペレーティングシステム（ＯＳ）によって提供されるセマフォメカニズム１０７を用いてデータ１０２に対するロックを取得することができる。

たとえば、プロセス１１１がデータ１０２に対するロックの取得を望む場合、プロセス１１１はＴＡＳオペレーションを多数回行なうことができる。システムは、許容されるＴＡＳオペレーションの最大回数であるスピンカウント（spin count）１０５を特定することができる。

図１に示されるように、スピンカウント１０５に到達する前にロック１０３が利用可能になった場合、プロセス１１１は、ＯＳによって提供されるセマフォ１０７メカニズムよりもはるかに低いコストでロック１０３を取得することができる。

そうでなく、許容される最大回数のＴＡＳオペレーションをプロセス１１１が行なうまではロック１０３が利用可能にならない場合、プロセス１１１はセマフォ１０７上でブロックし、ロック所有者がロック１０３を解除するまで待機することができる。たとえば、セマフォ１０７上でブロックしているロック要求を、たとえばセマフォ待機キュー１０６などのキューに入れることができる。

その上、セマフォ１０７上でブロックしているロック要求は、ＴＡＳアセンブリコンポーネント１０４に基づくロック要求よりも高い優先順位を有することができる。したがって、セマフォ待機キュー１０６が空でない限り、ロック保持者はまずロック１０３をセマフォ待機キュー１０６内のプロセスに対して解除する。

適応セルフチューニングロックメカニズム
図２は、発明の一実施形態に従う、トランザクションミドルウェアマシン環境において適応セルフチューニングロックメカニズムをサポートする例を示す。図２に示されるように、トランザクションミドルウェア環境２００は、同時トランザクションが（すなわちプロセス２１１〜２１５について）ある場合、共有メモリ２０１内のさまざまなトランザクションデータ２０２を保護するためのロックメカニズム２０３を採用することができる。

たとえば、プロセス２１１〜２１５がデータ２０２に対するロック２０３の取得を望む場合、プロセス２１１〜２１５の各々はＴＡＳ２０４オペレーションを多数回行なうことができる。システムは、許容されるＴＡＳオペレーションの最大回数であるスピンカウント２０５を特定することができる。発明の一実施形態に従うと、Ｔｕｘｅｄｏ構成ファイルにおけるSPINCOUNTパラメータなどのメタデータを用いて、スピンカウント２０５のデフォルト値および／または初期値を特定することができる。

図２に示されるように、スピンカウント２０５に到達する前にロック２０３が利用可能になった場合、プロセス（たとえばプロセス２１１〜２１２および２１４〜２１５の１つ）は、ＯＳによって提供されるセマフォメカニズムよりもはるかに低いコストでロック２０３を取得することができる。

そうでなく、スピンカウント２０５に到達するまではロック２０３が利用可能にならない（すなわちスピン失敗が起こる）場合は、セマフォ上でブロックし、ロック所有者がロック２０３を解除して覚醒させるまで待機するようにプロセス（たとえばプロセス２１３）を構成することができる。

さらに、スピンカウント値２０５を共有メモリ２０１に記憶させることができる。Ｔｕｘｅｄｏデーモンプロセスのような特殊なプロセスは、先のチューニング期間中に収集された動作情報に従ってスピンカウント値２０５を周期的に調整（または変更）することができる。たとえば、Ｔｕｘｅｄｏデーモンは、デフォルトで目標スピンカウント値を５秒につき一度更新することができる。

一実施形態に従うと、異なるアルゴリズムを用いてスピンカウント２０５の値を算出および構成することができる。たとえば、現在のチューニング期間のＣＰＵアイドル率が十分である場合、スピン失敗レート２０８が目標よりも高い（すなわち、現在のチューニング期間中にあまりに多くのＴＡＳ２０４オペレーションがロック２０３の取得に失敗し、セマフォに切換わった）ときに、単純アルゴリズム２０６がスピンカウント２０５の値を増加させることができる。さらに、この単純アルゴリズムは、ＣＰＵアイドル率が高過ぎる場合、スピンカウント２０５の値を減少させることができる。

単純アルゴリズム２０６は容易に実行できるが、単純アルゴリズム２０６は、たとえばＯｒａｃｌｅｄａｔａｂａｓｅなどの実際のリソースマネージャ（ＲＭ）上で実行されると異なる問題に直面し得る。たとえば、スピン失敗率が標準以下である限り単純アルゴリズム２０６はスピンカウント値２０５を増加させることになるため、単純アルゴリズム２０６は極めて大きいスピンカウント値２０５を生成し得る。また、スピンカウント値２０５を増加させるために単純アルゴリズム２０６が取るステップは大きくなり過ぎる傾向があり、スピンカウント値２０５は数回のチューニングで上限に到達し得るため、単純アルゴリズム２０６はスピンカウント値２０５を微調整できない場合がある。その上、単純アルゴリズム２０６は大きいスピンカウント値２０５を生成し得、これは実のところ、実際のＲＭ上で実行された場合にシステムにおけるスループットの悪化の原因となる。さらに、単純アルゴリズム２０６は、アイドルＣＰＵ率が十分高い場合、スピンカウント値２０５を減少させない場合がある。さらに、単純アルゴリズム２０６が実際のＲＭ環境に従ってデフォルトの元のスピンカウント値２０５およびスピン失敗レート２０８のデフォルト目標を構成することは困難であり得る。

代替的に、システムは適応アルゴリズム２０７を採用して、リアルタイムでスピンカウント２０５の値を動的に算出することができる。適応アルゴリズム２０７は、単純アルゴリズム２０６を用いて、システムがたとえばＯｒａｃｌｅｄａｔａｂａｓｅなどの実際のリソースマネージャ（ＲＭ）上で実行されると起こり得るさまざまな問題を回避することができる。

発明の一実施形態に従うと、適応アルゴリズム２０７は良好なチューニングを維持することによって不良のチューニングを防止することができる。たとえば、適応アルゴリズム２０７は、最後の良好なチューニング期間からのスピンカウント値２０５およびスピン失敗レート２０８を記憶することができる。

チューニング期間２１０毎に、システムは、現在のスピン失敗レート２０８が、記憶された最後の良好なスピン失敗率よりも良好であるか否かを確認することができる。現在のスピン失敗レート２０８が最後の良好なスピン失敗率よりも良好である場合、システムは現在のチューニング期間２１０を良好なチューニングと見なすことができる。そして、システムは、現在のスピンカウント値２０５および現在のスピン失敗レート２０８をキャッシュすることができる。一方、現在のスピン失敗レートがチューニング後に増加した（すなわち悪化した）場合、システムは、記憶された最後の良好なスピンカウント値２０５を次のチューニング期間２１０に用いることができる。

したがって、トランザクションミドルウェア環境２００は、大規模な同時トランザクションシナリオをサポートし、高スループットを達成することができる。

図３は、発明の一実施形態に従う、トランザクションミドルウェアマシン環境において適応セルフチューニングロックメカニズムをサポートするための例示的なフローチャートを示す。図３に示されるように、ステップ３０１において、各プロセスは、共有メモリ内のデータに対するロックを取得するために１つ以上のテスト・アンド・セット（ＴＡＳ）オペレーションを行なうことができる。その上、ステップ３０２において、システムは現在のチューニング期間のスピン失敗レートを取得することができ、許容される最大回数のＴＡＳオペレーションを行った後でプロセスがロックの取得に失敗した場合、スピン失敗が発生する。さらに、ステップ３０３において、システムは、取得したスピン失敗レートに基づいて次のチューニング期間のスピンカウント値を適応的に構成することができ、スピンカウントは、次のチューニング期間について許容されるＴＡＳオペレーションの最大回数を特定する。

目標スピンカウント値を動的に算出するための適応アルゴリズム
発明の一実施形態に従うと、システムは適応アルゴリズムを用いて、リアルタイムで目標スピンカウント値を動的に求めることができる。また、システムは、ハードウェア構成およびアプリケーションシナリオのコンテキストにおいて目標スピンカウント値を算出することができる。

たとえば、Ｔｕｘｅｄｏ環境において、システムは以下に示されるようなファンクションを呼出すことによってスピンカウント値を算出することができる。

static int _calc_spintuning(_TCADEF)

Ｔｕｘｅｄｏにおいて、アプリケーションは、たとえば各走査ユニット（ＲＥＳＯＵＲＣＥセクションにおけるパラメータＳＣＡＮＵＮＩＴを用いて構成され得る）において、各チューニング期間中に上記のファンクションを呼出すことができる。

その上、以下に示されるように、システムは、ＣＰＵ率の取出しを担う別のファンクションを呼出すことができる。

static int getCPUrate(int type, float* rate, int size)

上記のファンクションについての実装はプラットフォームに依存し得る。たとえば、上記のファンクションは、ＥｘａｌｏｇｉｃＥｌａｓｔｉｃＣｌｏｕｄ（Ｌｉｎｕｘ６４ｂｉｔ）プラットフォームにおけるｆｉｌｅ／ｐｒｏｃ／ｓｔａｔツールのようなシステムツールを介してＣＰＵ率を取得することができる。代替的に、上記のファンクションは、ＳＰＡＲＣＳｕｐｅｒＣｌｕｓｔｅｒ（Ｓｐａｒｃ６４ｂｉｔ）プラットフォームにおけるｋｓｔａｔライブラリのようなシステムライブラリを介してＣＰＵ率を取得することができる。

図４は、発明の一実施形態に従う、適応セルフチューニングロックメカニズムをサポートするトランザクションミドルウェアマシン環境においてスピンカウント値を動的に増加させる例を示す。図４に示されるように、適応アルゴリズムは、適切な場合、スピンカウントを動的に増加させることができる。

ステップ４０１において、システムは、現在のアイドルＣＰＵが十分であるか否か、すなわち、現在のチューニング期間のアイドルＣＰＵレートがユーザが構成した最小アイドルＣＰＵレートよりも大きいか否かを確認することができる。また、ステップ４０２において、システムは、現在のスピン失敗率がユーザが構成した目標未満であるか否かを確認することができる。

次に、適応アルゴリズムは、現在のアイドルＣＰＵが不十分である場合、または現在のチューニング期間の現在のスピン失敗率がユーザが構成した目標を既に達成している場合、スピンカウントを増加させないと決定し得る。

そうでなければ、ステップ４０３において、適応アルゴリズムは、現在のスピン失敗率が、記憶されている最後の良好なスピン失敗率よりも良好であるか否かを確認することができる。また、ステップ４０４において、適応アルゴリズムは、現在のスピン失敗率がチューニングしなくては悪化するか否かを確認することができる。

結果として、ステップ４０５において、現在のチューニング期間のスピン失敗率が最後の良好なスピン失敗率未満である場合、または現在のチューニング期間のスピン失敗率がチューニングしなくては悪化する場合、システムはスピンカウントを増加させることができる。

最後に、ステップ４０６において、システムは次のチューニング期間に進むことができ、これによってプロセスは、次のチューニング期間について上記のステップ４０１〜４０５を再び繰返すことができる。

Ｔｕｘｅｄｏにおいて、システムは以下のアルゴリズムを用いてスピンカウントの増加を求める（すなわち次のチューニング期間のtuned SPINCOUNTを算出する）ことができる。

Tuned SPINCOUNT +=
(SPINCOUNT * base_factor) * min(max_times,(idle CPU ratio/ user CPU ratio))

上記のアルゴリズムは、２つのファクターを用いて、現在のSPINCOUNT値およびidle CPU ratio/user CPU ratioの値に依存するSPINCOUNTの増加を微調整する。現在のSPINCOUNTの貢献を減少させるために用いられ得る第１のファクターであるbase_{_}factorは１よりも小さい。第２のファクターであるmax_{_}timesは、idle CPU ratio/user CPU ratioの上限として用いられ得る。

その上、可能性のあるSPINCOUNT値の範囲はいくつかの間隔に分割され得る。以下の表１は、いくつかの間隔の例示的な分割を示す。

上記の表１に示されるように、異なる間隔は異なるbase_{_}factorおよびmax_{_}timesの値で構成され得る。SPINCOUNTが徐々に目標値に到達可能であることを確実にするために、base_{_}factorおよびmax_{_}timesの値は、SPINCOUNTが大きくなるにつれて小さくなるように設定され得る。

図５は、発明の一実施形態に従う、適応セルフチューニングロックメカニズムをサポートするトランザクションミドルウェアマシン環境においてスピンカウント値を動的に減少させる例を示す。図５に示されるように、適応アルゴリズムは、適切な場合、スピンカウントを動的に減少させることができる。

ステップ５０１において、適応アルゴリズムは、アプリケーションがアイドル状態であるか否かを確認することができる。また、ステップ５０２において、適応アルゴリズムは、現在のアイドルＣＰＵ率が限界よりも大きいか否か、およびユーザＣＰＵ率が十分であるか否かを確認することができ、ステップ５０３において、適応アルゴリズムは、現在のスピンカウントが十分長い期間にわたってそのまま（または安定して）保たれているか否かを確認することができる。

次に、ステップ５０４において、アプリケーションがアイドル状態である場合、アルゴリズムはスピンカウントを減少させることができる。たとえば、Ｔｕｘｅｄｏは以下の数式を用いてSPINCOUNT値を減少させることができる。

Tuned SPINCOUNT -= Tuned SPINCOUNT>>3

上記のアルゴリズムを用いて、Ｔｕｘｅｄｏは、アプリケーションがアイドル状態である場合、高いSPINCOUNT値を自動的に元のSPINCOUNT値に戻すことができる。

また、ステップ５０４において、現在のアイドルＣＰＵ率が（ユーザによって構成されるような）限界よりも大きく、ユーザＣＰＵ率が十分である場合、アルゴリズムはスピンカウントを減少させることができる。たとえば、Ｔｕｘｅｄｏは以下の数式を用いてSPINCOUNT値を減少させることができる。

Tuned SPINCOUNT = Tuned SPINCOUNT>>2

その上、ステップ５０４において、現在のSPINCOUNTが十分長い期間にわたって安定して保たれている場合、アルゴリズムはスピンカウントを減少させることができる。たとえば、Ｔｕｘｅｄｏは以下の数式を用いてSPINCOUNT値を減少させることができる。

Tuned SPINCOUNT -= Tuned SPINCOUNT>>3

上記のアルゴリズムを用いて、Ｔｕｘｅｄｏは、長い安定期間の後にSPINCOUNT値を減少させることができる。したがって、Ｔｕｘｅｄｏは、負荷が軽くなると、高いSPINCOUNTを自動的に適切な値に戻すことができる。

最後に、ステップ５０５において、システムは次のチューニング期間に進むことができ、これによってプロセスは、次のチューニング期間について上記のステップ５０１〜５０４を再び繰返すことができる。

図６は、発明の一実施形態に従う、適応セルフチューニングロックメカニズムをサポートするトランザクションミドルウェアマシン環境においてスピンカウント値をそのまま維持する例を示す。図６に示されるように、適応アルゴリズムは、異なるシナリオにおいてスピンカウントをそのまま維持することができる。

ステップ６０１において、適応アルゴリズムは、現在のスピン失敗率が要件を満たしているか否かを確認することができる。また、ステップ６０２において、適応アルゴリズムは、現在のスピンカウントがチューニング時に上限または下限に到達するか否かを確認することができ、ステップ６０３において、適応アルゴリズムは、現在のスピン失敗率が安定して保たれているか否かを確認することができる。

次に、ステップ６０４において、現在のスピン失敗率が要件を満たしている場合、または現在のSPINCOUNTがチューニング時に上限もしくは下限に到達する場合、または現在のスピン失敗率が安定して保たれている場合、アルゴリズムはスピンカウントをそのまま保つことができる。

負荷サージ保護を用いたスピンカウントの構成
図７は、発明の一実施形態に従う、適応セルフチューニングロックメカニズムをサポートするトランザクションミドルウェアマシン環境において負荷サージ保護を用いてスピンカウントを構成する例を示す。図７に示されるように、トランザクションミドルウェア環境７００は、同時トランザクションが（すなわちプロセス７１１〜７１５ついて）ある場合、共有メモリ７０１内のさまざまなトランザクションデータ７０２を保護するためのロック７０３を採用することができる。

さらに、トランザクションミドルウェア環境７００は、アトミックＴＡＳ（テスト・アンド・セット）７０４アセンブリコンポーネントを用いて有効なロックメカニズムを実装することができる。その上、システムは、スピン失敗が発生すると、プロセス（たとえばプロセス７１１〜７１３）をセマフォ待機キュー７０６に入れることができる。

図７に示されるように、セマフォ待機キュー７０６内で待機するプロセス７１１〜７１３によるロック要求は、ＴＡＳアセンブリコンポーネント７０４に基づくプロセス７１４〜７１５によるロック要求よりも高い優先順位を有することができる。

したがって、セマフォ待機キュー７０６が空でない限り、ロック保持者はまずロック７０３をセマフォ待機キュー７０６内のプロセス７１１〜７１３に対して解除し、プロセス７１４〜７１５はロック７０３へのアクセスを有し得ない。

発明の一実施形態に従うと、セマフォ待機キュー７０６の長さは時々異なり得るため、システムはリアルタイムでスピンカウント値を動的に求めることができる。

図７に示されるように、システムは、ＴＡＳアセンブリコンポーネント７０４を用いるプロセス７１４〜７１５に追加のスピンを加えることができる。たとえば、Ｔｕｘｅｄｏにおいて、システムは以下のアルゴリズムを用いて、実際に使用されるスピンカウント（すなわちused SPINCOUNT）をリアルタイムで求めることができる。

Used SPINCOUNT = tuned SPINCOUNT+ extraspin * depth of the semaphore waiting queue

上記に示されるように、使用されるSPINCOUNTを算出する際、Ｔｕｘｅｄｏはセマフォ待機キューの現在の深さを考慮に入れることができる。セマフォ待機キューが深いほど、used SPINCOUNTは大きく設定され得る。

発明の一実施形態に従うと、トランザクションミドルウェアマシン環境７００において負荷サージが起こると、ＴＡＳアセンブリコンポーネント７０４においてスピン失敗が急激に増加し得、これによって、セマフォ待機キュー７０６内でロック７０３を待機するプロセスが増加し得る。

ＴＡＳアセンブリコンポーネント７０４を用いるプロセス７１４〜７１５に追加のスピンを加えることによって、システムは、セマフォキューが深い場合にスピン失敗率を減少させることができる。さらに、システム内の負荷が最終的に軽くなると、セマフォ待機キュー７０６の長さは短くなる。したがって、実際に使用されるスピンカウントをチューニング期間内にリアルタイムで減少させることができる。

図８は、発明の一実施形態に従う、トランザクションミドルウェアマシン環境において負荷サージ保護を用いてスピンカウントを構成するための例示的なフローチャートを示す。図８に示されるように、ステップ８０１において、スピン失敗を有するプロセスが、セマフォ待機キュー内で、共有メモリ内のデータに対するロックの解除を待機することができる。次に、ステップ８０２において、ロック所有者が共有メモリ内のデータに対するロックを解除すると、プロセスは当該データにアクセスすることができる。さらに、ステップ８０３において、セマフォ待機キューが空でない場合、システムはＴＡＳオペレーションを行なう各プロセスに追加のスピンカウントを加えることができる。

本発明は、本開示の教示に従ってプログラムされる１つ以上のプロセッサ、メモリおよび／またはコンピュータ読取可能記憶媒体を含む、１つ以上の従来の汎用もしくは専用デジタルコンピュータ、コンピューティングデバイス、マシン、またはマイクロプロセッサを用いて便利に実装され得る。ソフトウェア技術の当業者にとっては明確であるように、適切なソフトウェアコーディングは、本開示の教示に基づいて熟練プログラマによって容易に準備され得る。

いくつかの実施形態において、本発明は、本発明の処理のいずれかを実行するようコンピュータをプログラムするのに用いられ得る命令を格納した記憶媒体またはコンピュータ可読媒体であるコンピュータプログラムプロダクトを含む。当該記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む任意のタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ素子、磁気もしくは光学カード、ナノシステム（分子メモリＩＣを含む）、または命令および／もしくはデータを格納するのに好適な任意のタイプの媒体もしくは装置を含み得るが、これらに限定されない。

本発明の上記の記載は、例示および説明目的で与えられている。網羅的であることまたは開示されたそのものの形態に本発明を限定することを意図したものではない。当業者にとっては、多くの修正および変形が明確であろう。これらの修正および変形は、開示された特徴の関連するあらゆる組合せを含む。上記の実施形態は、本発明の原理およびその実際的な適用をもっともよく説明するために選択および記載されたものであり、これにより他の当業者が、特定の使用に好適なさまざまな修正例を考慮して、さまざまな実施形態について本発明を理解するのが可能になる。本発明の範囲は、添付の特許請求の範囲およびそれらの均等物によって定義されることが意図される。

Claims

トランザクションミドルウェアマシン環境において適応ロックメカニズムをサポートするための方法であって、
複数のプロセスの各プロセスによって、共有メモリ内のデータに対するロックを取得するために１つ以上のテスト・アンド・セット（ＴＡＳ）オペレーションを行なうことと、
現在のチューニング期間のスピン失敗レートを取得することとを備え、許容される最大回数のＴＡＳオペレーションを行った後でプロセスが前記ロックの取得に失敗した場合、スピン失敗が発生し、前記方法はさらに、
取得した前記スピン失敗レートに基づいて次のチューニング期間のスピンカウントを適応的に構成することを備え、前記スピンカウントは、前記次のチューニング期間について許容されるＴＡＳオペレーションの最大回数を特定する、方法。
アセンブリコンポーネントを用いて前記１つ以上のＴＡＳオペレーションを行なうことをさらに備える、請求項１に記載の方法。
メタデータを用いて前記スピンカウントを予め構成することをさらに備える、請求項１に記載の方法。
前記現在のチューニング期間のアイドルＣＰＵレートがユーザが構成した最小アイドルＣＰＵレートよりも大きいか否か、および前記現在のチューニング期間のスピン失敗率がユーザが構成した目標を達成しているか否かを判断することをさらに備える、請求項１に記載の方法。
前記現在のチューニング期間のアイドルＣＰＵレートがユーザが構成した最小アイドルＣＰＵレートよりも大きく、前記現在のチューニング期間のスピン失敗率がユーザが構成した目標を達成していない場合、
前記現在のチューニング期間の前記スピン失敗率が最後の良好なスピン失敗率よりも良好であるときに、または
前記現在のチューニング期間の前記スピン失敗率がチューニングしなくては悪化するときに、
前記スピンカウントを増加させることをさらに備える、請求項４に記載の方法。
可能性のあるスピンカウント値の範囲をいくつかの間隔に分割することと、
異なる数式を用いて、異なる間隔の各々におけるチューニングされたスピンカウント値を算出することとをさらに備える、請求項５に記載の方法。
アプリケーションがアイドル状態である、
前記アイドルＣＰＵ率がユーザが構成した最小アイドルＣＰＵレートよりも大きく、前記ユーザＣＰＵ率が十分である、および
前記スピンカウントがある期間にわたって安定して保たれている、
の少なくとも１つである場合、前記スピンカウントを減少させることをさらに備える、請求項１に記載の方法。
前記現在のチューニング期間の前記スピン失敗率が要件を満たしている、
前記現在のチューニング期間の前記スピンカウントが上限または下限に到達している、および
前記現在のチューニング期間の前記スピン失敗率が安定して保たれている、
の少なくとも１つである場合、前記スピンカウントを維持することをさらに備える、請求項１に記載の方法。
スピン失敗を有するプロセスによって、前記共有メモリ内の前記データに対するロックの解除をセマフォ待機キュー内で待機することと、
ロック所有者が前記共有メモリ内の前記データに対する前記ロックを解除すると、前記データにアクセスすることとをさらに備える、請求項１に記載の方法。
前記セマフォ待機キューが空でない場合、前記ＴＡＳオペレーションを行なう各プロセスに追加のスピンカウントを加えることをさらに備える、請求項９に記載の方法。
トランザクションミドルウェアマシン環境において適応ロックメカニズムを提供するためのシステムであって、
１つ以上のプロセッサと、
複数のプロセスとを備え、前記複数のプロセスの各プロセスは、共有メモリ内のデータに対するロックを取得するために１つ以上のテスト・アンド・セット（ＴＡＳ）オペレーションを行なうように動作し、前記システムはさらに、
前記１つ以上のプロセッサ上で実行されるトランザクションサーバを備え、前記トランザクションサーバは、
現在のチューニング期間のスピン失敗レートを取得するように動作し、許容される最大回数のＴＡＳオペレーションを行った後でプロセスが前記ロックの取得に失敗した場合、スピン失敗が発生し、前記トランザクションサーバはさらに、
取得した前記スピン失敗レートに基づいて次のチューニング期間のスピンカウントを適応的に構成するように動作し、前記スピンカウントは、前記次のチューニング期間について許容されるＴＡＳオペレーションの最大回数を特定する、システム。
アセンブリコンポーネントを用いて前記１つ以上のＴＡＳオペレーションを行なう、請求項１１に記載のシステム。
前記スピンカウントはメタデータを用いて予め構成される、請求項１１に記載のシステム。
管理コンポーネントは、前記現在のチューニング期間のアイドルＣＰＵレートがユーザが構成した最小アイドルＣＰＵレートよりも大きいか否か、および前記現在のチューニング期間のスピン失敗率がユーザが構成した目標を達成しているか否かを判断するように動作する、請求項１１に記載のシステム。
前記現在のチューニング期間のアイドルＣＰＵレートがユーザが構成した最小アイドルＣＰＵレートよりも大きく、前記現在のチューニング期間のスピン失敗率がユーザが構成した目標を達成していない場合、前記管理コンポーネントは、
前記現在のチューニング期間の前記スピン失敗率が最後の良好なスピン失敗率よりも良好であるときに、または
前記現在のチューニング期間の前記スピン失敗率がチューニングしなくては悪化するときに、
前記スピンカウントを増加させるように動作する、請求項１４に記載のシステム。
可能性のあるスピンカウント値の範囲がいくつかの間隔に分割され、前記管理コンポーネントは、異なる数式を用いて、異なる間隔の各々におけるチューニングされたスピンカウント値を算出するように動作する、請求項１５に記載のシステム。
管理コンポーネントは、
アプリケーションがアイドル状態である、
前記アイドルＣＰＵ率がユーザが構成した最小アイドルＣＰＵレートよりも大きく、前記ユーザＣＰＵ率が十分である、および
前記スピンカウントがある期間にわたって安定して保たれている、
の少なくとも１つである場合、前記スピンカウントを減少させるように動作する、請求項１１に記載のシステム。
管理コンポーネントは、
前記現在のチューニング期間の前記スピン失敗率が要件を満たしている、
前記現在のチューニング期間の前記スピンカウントが上限または下限に到達している、および
前記現在のチューニング期間の前記スピン失敗率が安定して保たれている、
の少なくとも１つである場合、前記スピンカウントを維持するように動作する、請求項１１に記載のシステム。
管理コンポーネントは、
スピン失敗を有するプロセスを、前記共有メモリ内の前記データに対するロックの解除を待機するようにセマフォ待機キューに入れ、
ロック所有者が前記共有メモリ内の前記データに対する前記ロックを解除すると、前記データにアクセスし、
前記セマフォ待機キューが空でない場合、前記ＴＡＳオペレーションを行なう前記プロセスに追加のスピンカウントを加える
ように動作する、請求項１１に記載のシステム。
命令を格納している非一時的な機械読取可能記憶媒体であって、前記命令は、実行されると、システムに、
複数のプロセスの各プロセスによって、共有メモリ内のデータに対するロックを取得するために１つ以上のテスト・アンド・セット（ＴＡＳ）オペレーションを行なうことと、
現在のチューニング期間のスピン失敗レートを取得することとを備えるステップを実行させ、許容される最大回数のＴＡＳオペレーションを行った後でプロセスが前記ロックの取得に失敗した場合、スピン失敗が発生し、前記ステップはさらに、
取得した前記スピン失敗レートに基づいて次のチューニング期間のスピンカウントを適応的に構成することを備え、前記スピンカウントは、前記次のチューニング期間について許容されるＴＡＳオペレーションの最大回数を特定する、機械読取可能記憶媒体。