説明

Fターム[5B042HH20]の内容

デバッグ、監視 (27,428) | プログラムデバッグ、プログラムテスト (3,778) | プロファイル、パフォーマンスアナライズ (329)

Fターム[5B042HH20]に分類される特許

141 - 160 / 329


【課題】本発明は、障害の予兆を検出し、発生場所の特定が可能な運用管理装置を提供する。
【解決手段】運用管理装置は、性能種目又は被管理装置を要素とし、少なくとも第1の要素に関する性能情報の時系列変化を示す第1の性能系列情報と、第2の要素に関する性能情報の時系列変化を示す第2の性能系列情報との相関関数を導出し、この相関関数に基づいて相関モデルを生成しこの相関モデルを各要素間の組み合わせについて求める相関モデル生成部123と、被管理装置から新たに検出し取得される性能情報に基づいて、相関モデルの変化を分析する相関変化分析部124を含む。 (もっと読む)


【課題】各処理のアクセス量とともにアクセス時間の情報を取得することにより、メモリアクセスが集中しても性能劣化を回避する対策立案を可能とするメモリアクセス量測定装置、メモリアクセス量測定装置、メモリアクセス量測定方法を提供する。
【解決手段】複数の処理装置がメモリを共有するメモリ共有データ処理システムであって、処理装置は、タイマから通知される時刻を用いて処理装置で実行される処理ごとの開始時刻と終了時刻を測定する時間測定部と、処理の開始から終了までの間、処理のメモリへのアクセス量を測定するアクセス測定部と、を具備するメモリ共有データ処理システムである。 (もっと読む)


【課題】レコードサイズが不定の場合であっても、正確の処理性能を予測する自動チューニングシステム、自動チューニング装置、自動チューニング方法を提供する。
【解決手段】データウェアハウスに対する処理要求の実行計画を取得し、予測されるハードウェアに対する負荷を算出し、算出されたハードウェアに対する負荷と、既存ハードウェアリソースとを統合的に分析し、予測レスポンス時間を算出し、予測レスポンス時間と、要求されるレスポンス時間とを比較し、その差を計算し、予測レスポンス時間と、要求レスポンス時間との差が閾値を超える場合に、要求レスポンス時間を満たすようハードウェアリソースを追加する。 (もっと読む)


【課題】所望の機能を有する関数を効率的に検索する。
【解決手段】関数の検索を支援するシステムであって、複数の関数のそれぞれに対応付けて、当該関数から出力された少なくとも1つの出力パラメータの履歴を記憶している第1記憶装置と、検索するべき関数から出力されることが期待される出力パラメータの入力を受け付けるパラメータ入力部と、入力した前記出力パラメータと前記第1記憶装置に記憶されているそれぞれの前記出力パラメータとの間の値の近さを示す第1指標値を、前記第1記憶装置に記憶されているそれぞれの前記出力パラメータについて算出すると共に、算出した前記第1指標値を関数ごとに合計する算出部と、合計した前記第1指標値が予め定められた基準値よりも大きい関数を前記複数の関数の中から選択して出力する出力部とを備えるシステムを提供する。 (もっと読む)


【課題】1つの処理単位の処理に同一の複数のアプリケーションソフトウェアを用意せずに、複数の処理単位の処理を順次経るワークフローを定められた時間内で達成できる可能性を高めたワークフロー監視制御システム、方法およびプログラムを得ること。
【解決手段】ワークフロー監視制御システム205は、予測部229が合成されたワークフローについて制御履歴格納DB234に格納された制御履歴を用いて業務の監視から完了までの時間を予測して、これが合意サービス水準リポジトリ212に格納された基準時間以内とならないときには、制御条件調整部231で複数の処理を兼用する業務アプリケーションシステムにおけるワークフロー間の待ち時間を調整する。これにより、時間が足りないワークフローは時間が余ったワークフローから待ち時間を融通して貰う管理が可能になる。 (もっと読む)


1つ以上のプロセッサコア(15)を有するプロセッサ(12)は、1つ以上のプロセス(P1,P2)を含む命令を実行する実行ロジックを有する。各プロセスは1つ以上の実行スレッド(T1,T2)を含んでもよい。また、前記プロセッサは、モニタロジック(18)とモニタプロセス(モニタコード)とを有するプロファイリングメカニズムを有する。前記モニタロジックは、前記1つ以上のプロセスをモニタし、モニタされている前記1つ以上のプロセスの制御のフローに割り込むことなく、前記1つ以上のプロセスに関連するパフォーマンスデータへのアクセスを提供する。前記モニタプロセスは、前記パフォーマンスデータを収集しうる。また、前記モニタプロセスは、ユーザモードで動作中に、前記1つ以上のプロセッサコアによって実行可能なプログラム命令を含んでもよい。
(もっと読む)


【課題】構成変更に起因する性能問題を確実に検出するためには詳細な性能情報が必要であるが、詳細な性能情報を保持及び分析するコストが問題になる。
【解決手段】ホスト計算機及びストレージシステムを備える計算機システムを管理する管理計算機であって、前記管理計算機は、前記ホスト計算機が前記ストレージシステムの物理記憶装置に書き込むデータが経由する経路に属するリソースの識別情報を保持し、前記経路への前記リソースの追加又は削除が検出されてから所定の時間が経過する前に前記経路に属する前記リソースから取得された第1時間間隔ごとの性能情報を保持し、前記経路への前記リソースの追加又は削除が検出されてから所定の時間が経過した後に前記経路に属する前記リソースから取得された前記第1時間間隔ごとの性能情報を保持せずに、前記経路に属する前記リソースから取得された前記第1時間間隔より長い第2時間間隔ごとの性能情報を保持する。 (もっと読む)


【課題】追加アプリの動作検証を比較的短時間で行うことが可能なCPU資源管理装置とその方法を実現すること。
【解決手段】優先度の高い既存アプリを動作させながら優先度の低い追加アプリの動作を検証するのにあたり、既存アプリの各動作周期について実際のCPU使用時間に基づき所定の最大CPU使用時間に満たない時間だけCPUに負荷を発生させるCPU負荷発生部を設け、前記既存アプリの各動作周期について既存アプリの最大CPU使用時間を確保することを特徴とするもの。 (もっと読む)


【課題】性能メトリクスの測定をより容易にする改善されたプロファイリング技術を提供する。
【解決手段】複数のシーケンシャル実行フレームにおけるコンピュータプログラムの1つ以上のコンポーネントを実行するように動作可能な実行環境を生成するように構成されている実行環境生成手段を含むシステムであって、実行環境はさらに、i)異なる実行フレームにおけるある前記コンポーネントと別の前記コンポーネントとの間の通信を可能にし、かつ、ii)前記同一実行フレームにおけるある前記コンポーネントと別の前記コンポーネントとの間の通信を妨げるように動作可能であり、前記実行環境生成手段は、実行されているプログラムコンポーネント(単数又は複数)の性能に関する性能メトリクスを得るようになっている。 (もっと読む)


【課題】対象装置の性能モデルのパラメータ同定のための集計区間データの精度を一定に保ちながら、一定時間内で多くの集計区間データを生成する。
【解決手段】集計区間計算部5は、集計区間iの開始時刻を設定し、計測データ中から当該開始時刻から一定時間内のリソース利用率情報を取得する。処理時間計算部4は、リソース利用率情報と無負荷時処理時間とを利用してリソース利処理時間情報を推定する。集計区間計算部5は、処理時間情報Rと許容誤差率とを利用し、集計区間iの時間を計算し、集計区間iの終了時刻を計算する。集計区間計算部5は、をデータ生成部6に送信する。データ生成部6は、集計区間iの開始時刻、終了時刻およびその間の計測データをもとに、集計区間iの開始時刻と終了時刻の間のリソース利用時間および処理の種類毎の発生量を集計することで集計区間データを生成する。 (もっと読む)


【課題】 関連のネットワーク・トポロジを有する指定のトランザクション・サーバの動作をモニターするための方法および装置を提供する。
【解決手段】 一実施形態は、ネットワーク・トポロジ内の複数のゾーンを定義するステップと、そのゾーンのそれぞれに1つまたは複数のモニター・エージェントを割り当てるステップであって、それぞれのエージェントが指定のサーバによって合成トランザクションを選択的に実行するように適合されるステップとを含む。この方法は、連続トランザクションに関連する任意のエラーを検出するために、エージェントによって実行される連続合成トランザクションの結果をモニターするステップをさらに含む。エージェントのうちの特定の1つによって実行された特定の合成トランザクションに関連するパフォーマンス問題または可用性問題を選択的に検出したことに応答して、1つまたは複数のエージェントは合成トランザクションを実行するように動的にスケジュールされ、スケジュールされた各トランザクションはその特定のトランザクションと指定の関係がある。 (もっと読む)


【課題】シナリオを用いてコンテキストアウェアサーバの拡張性、処理速度、安定性などの性能を総合的に評価できるシステムおよび方法を提供する。
【解決手段】コンテキストアウェアサーバ200の性能評価システム100は、複数の評価モジュール100−1〜nを含み、各評価モジュール100−1〜nは、ユーザの行為およびコンテキストの変化を含むシナリオを格納するシナリオ生成部110と、シナリオ生成部110に格納されたシナリオの進行に応じてイベントを出力するイベント生成部120と、イベント生成部120からイベントの入力を受けてコンテキストアウェアサーバに伝達するサービス管理部130と、サービス管理部130からの指令に応じて仮想的にサービスを行い、その結果をシナリオ生成部に通知する仮想サービスエージェント140とを含む。 (もっと読む)


【課題】本発明は、各アクティビティ毎の所要時間等の確率情報に基づき、プロセス実行時のプロセス全体の所要時間等の予測統計情報を、シミュレーションによって取得することを目的とするものである。
【解決手段】プロセス定義の各アクティビティ毎に記憶された所要時間や遷移先アクティビティ等の確率分布情報と、乱数とによって、所要時間・遷移先アクティビティ等を決定し、決定した所要時間・遷移先アクティビティ等を記録し、決定した遷移先アクティビティを新たな処理対象アクティビティとする処理を、プロセスの最初のアクティビティから始めて、プロセスが終了するまで繰り返し実行するシミュレーションを、多数回実行することにより、所要時間等の予測統計情報を取得する。 (もっと読む)


【課題】仮想化環境におけるI/Oエミュレーションに必要なCPU負荷をディスク負荷及び/又はネットワーク負荷から換算し、CPU負荷の見積もりの精度を向上させることを目的とする。
【解決手段】サーバ10〜12を仮想サーバとして動作させるサーバXのCPU負荷を見積もる場合、CPU性能換算部223はサーバ10〜12のCPU負荷の測定値を得る。負荷変換部220はサーバ10〜12のディスク負荷及び/又はネットワーク負荷から、ディスク及び/又はネットワークのI/Oに起因するサーバXのCPU負荷の見積値を得る。CPUオーバヘッド算出部224は仮想化に起因するCPUオーバヘッドを示す係数を得る。負荷見積部225は上記測定値と上記見積値と上記係数を用いてサーバXのCPU負荷を見積もる。 (もっと読む)


システムは、1つまたは複数の無線ハンドヘルドデバイスと、前記1つまたは複数の無線ハンドヘルドデバイスと通信する1つまたは複数のエンタープライズサーバと、前記1つまたは複数のエンタープライズサーバと通信するエンタープライズサーバモニターと、を具備し、前記エンタープライズサーバモニターは、選択されたユーザグループに使用されている前記1つまたは複数の無線ハンドヘルドデバイスと通信する前記1つまたは複数のエンタープライズサーバから通信パフォーマンスデータを収集し、前記収集された通信パフォーマンスデータが1つまたは複数の警告条件と一致する場合には、1つまたは複数の警告を生成する。前記1つまたは複数の警告条件は、潜在的通信失敗の1つまたは複数のレベルを示している。
(もっと読む)


【課題】アプリケーションプログラムのコンポーネントの生産性を損なうことなく当該コンポーネントの監視および監視結果にもとづいた処理を行なう。
【解決手段】コンポーネント実行管理部3は、入力装置8への入力操作によるリクエストに応じた監視情報を出力する旨の実行命令を監視情報出力部4に通知する。すると、監視情報出力部4は、記憶装置2の定義情報記憶部22に記憶されたコンポーネント実行管理定義情報の設定に従い、監視情報を出力する。監視情報処理部5は、監視情報出力部4からの監視情報の統計処理を行なう。そして、監視情報処理部5は、統計処理結果が記憶装置2の処理ルール記憶部23に記憶された監視情報統計値処理ルール上の監視条件を満たした場合には、当該監視情報統計値処理ルール上の振る舞いのルールで定められた処理を実行処理部7に指示する。 (もっと読む)


【課題】検査対象のプログラムに割り当てられた検査制限時間内に当該プログラムの検査が完了しないことを、検査制限時間が経過するより以前に検知し、検知した時点で検査を終了する。
【解決手段】プログラムの実行文を実行した回数を表す探索深度のうち、プログラムの初期状態からプログラムの検査仕様を満たす事を示す仕様充足状態へ状態を遷移するために要する最短探索深度を算出する最短探索深度算出部と、探索深度毎に仕様充足状態へ状態を遷移することが可能であるかの検査を実行し、探索深度の各々における検査に要した深度別検査時間を出力する到達可能性検査部と、到達可能性検査部が各探索深度について検査を完了する毎に、仕様到達予想時間を算出する予想検査時間算出部を備え、到達可能性検査部は、プログラムの検査に対する検査制限時間のうち残りの残検査制限時間を仕様到達予想時間が超過する場合には、検査を途中で終了する。 (もっと読む)


【課題】従来の仕様検証方式は機能仕様の検証のみを対象とし、処理時間・要求メモリ量等の性能仕様の検証に関しては考慮されておらず、上記機能検証の枠組みとは別に性能確認の為の性能測定用コードをソースコードに追加し、性能仕様の確認をおこなう等の対応が必要であった。このような方法では仕様検証の為の手法が、機能仕様の検証と性能仕様の検証とで異なってしまい、仕様検証作業を一元化できないことによる、信頼性低下・作業工数増大などの課題があった。
【解決手段】コンパイル手段等の実行コード生成装置に、性能仕様検証処理の記述を追加可能なアサーション機能を設けた。該アサーション機能はアサーションの有効・無効を指定可能とした。
更に、特定の性能検証処理のアサーション機能のみを有効・無効設定可能なアサーション指定情報に基づき、特定の性能検証処理のアサーション機能の有効・無効設定が可能とした。 (もっと読む)


【課題】
UPnP等の通信プロトコルを利用して相互連携するデバイス間において、
デバイスプログラム上のバグやパフォーマンス上の問題を抱えたデバイスが存在する場合でも、連携動作をおこなえるようにする。
【解決手段】
本発明のサービスを提供するネットワークデバイスのプログラム制御は、前記デバイスで動作するプログラムモジュールの機能を監視し、前記モジュールの機能に問題がある場合に、前記問題が改善されるまでの間、仮想デバイスプログラムにより前記デバイスの代理応答処理をおこなう。また、前記モジュールの機能に問題がある場合には、前記デバイスで動作するプログラムモジュールを最新のプログラムモジュールに更新して問題を改善し、前記仮想デバイスプログラムの動作を停止するようにする。 (もっと読む)


【課題】各装置間において時刻の同期がとれているかどうかに関わらず、所定の機能を実行したときのリソース使用量を計測する。
【解決手段】本発明は、自身のリソースを使用したときのリソース使用量を所定の時間間隔で計測可能な少なくとも一つのサーバを含むシステムに、通信手段を介して接続可能なリソース使用量取得装置であって、前記少なくとも一つのサーバに所定の機能を実行させる機能実行制御手段と、前記機能を実行させる前のタイミングと後のタイミングの少なくとも何れか一のタイミングで、当該機能が実行されたときのリソース使用量を特定するための目印となる負荷を前記サーバに生成させる目印負荷生成制御手段と、計測されたリソース使用量、及び各前記リソース使用量に対応付けられた時間情報を前記システムから取得するリソース使用量取得手段と、を備える。 (もっと読む)


141 - 160 / 329