【課題】時系列データがほぼ一定となる期間を判定し、その期間内の時系列データを抽出して平均値を計算する作業の自動化を実現する。
【解決手段】クライアント装置１００においては、パラメータ入力部１５１が記憶部１０１から読み出した許容幅及び最短期間を入力し、判断部１５３が、この許容幅及び最短期間に基づいて、処理量の時系列データが許容幅内に収まった期間で最短期間以上の期間を一定期間として判断し、集計部１５５が、判断された一定期間毎の、処理量の時系列データの平均値及び前記ＣＰＵ利用率の時系列データの平均値を算出し、結果出力部１５６が、算出された各平均値に基づいて、処理量とＣＰＵ利用率とを関連付けたグラフの表示処理を実行する。 （もっと読む）

【課題】監視対象装置の過去と現在の稼働情報に基づき異常検出を行うシステムにおいて、モデルデータが適切でない場合があり、再現率や適合率などの異常検出精度が低下してしまう。また、誤判定の際は管理者判断に時間がかかる。
【解決手段】稼働情報分析部２２０やプロセス状態分析部２３０が、曜日、時間帯、プロセス状態で分類した稼働情報から、モデルデータを作成し、異常判定部２５０で異常検出を行うことで、適切なモデルデータによる判定を行う。また、どの様なグラフを想定して、現在のグラフがどの程度乖離しているから異常と判定しているのか、想定している状態と現在の状態は似ているのか、などをディスプレイ１２５上に可視化することで判定の詳細を管理者に示す。 （もっと読む）

インターネット要求のロギング方法には、関心のある複数のフィールドタイプを定義し、１つ以上のフィールドを含む要求をインターネットから受信することが含まれる。この方法には、１つ以上のフィールドの第１のフィールドの第１フィールドタイプが、関心のある複数のフィールドタイプの１つと一致するかどうかを判断し、第１のフィールドの少なくとも一部をキャッシュに格納することも含まれる。この方法には、１つ以上のフィールドの第２のフィールドの第２のフィールドタイプが、関心のある複数のフィールドタイプの１つに一致するかどうかを判断し、第２のフィールドの少なくとも一部をキャッシュに格納することも含まれる。さらに、この方法には、このキャッシュをサーバーに転送し、フィールド値の出現回数を判断し、このフィールド値の出現回数を含むレポートを提供することも含まれる。
（もっと読む）

【課題】物理マシンへの仮想マシン集約台数の最大化とリソース利用率の最適化をともに実現する。
【解決手段】物理マシン４に対する最大仮想マシン台数を暫定的に予測し、この台数での想定負荷量の性能測定を行なう。この際、得られた性能情報が要求性能やリソースといった条件を満たす場合には仮想マシン４３の台数の追加もしくは仮想メモリの縮小を試み、条件を満たさない場合には仮想マシンの台数の減少もしくは仮想メモリの拡大を行なった上で性能測定を再度行なう。過去の性能測定で条件を満たさなかった場合で後の性能測定で条件を満たした時点、もしくは過去の性能測定で条件を満たした場合で後の性能測定で条件を満たさなかった時点で、最適な仮想マシンシステム構成や集約可能な仮想マシン台数が確定する。 （もっと読む）

【課題】相関分析に基づきメモリ消費監視を実行する。
【解決手段】メモリガーベージコレクションイベント及びノードコンテンツサービスリクエストの発生を監視し、ノードコンテンツサービスリクエストとメモリガーベージコレクションイベントとの間の相関を決定し、かつ、ノードコンテンツサービスリクエストのうちの疑わしいリクエストと関連した情報を報告するように動作する、装置、システム、及び、方法が開示されている。疑わしいリクエストは、相関と関連した予め選択された基準を満足するリクエストとして識別してもよい。追加的な装置、システム、及び、方法が開示されている。 （もっと読む）

【課題】複数台の実行制御サーバを並列に実行したとしてもシステム全体でリクエストを監視することができ、サービスコンポーネントへのリクエスト処理量を向上することができる。
【解決手段】トラフィック情報管理サーバ１４は、実行制御サーバ１，２，３から収集したトラフィック情報を集計するトラフィック集計機能部１６と、集計したトラフィック情報に基づいて閉塞状態にするサービスコンポーネントを抽出するサービスコンポーネント監視機能部１７と、集計したトラフィック情報に基づいて特定のサービスコンポーネントに対して一時利用不可能にするユーザを抽出するユーザ監視機能部１８と、閉塞状態にするサービスコンポーネント又は一時利用不可能にするユーザをプロファイルサーバ２１に通知するリアクション機能部１９と、を備える。 （もっと読む）

【課題】プログラム実行の際、プログラムの各関数の呼び出しに関する情報を取得することを課題とする。
【解決手段】複数の関数を含むプログラムを実行するプログラム処理装置であって、前記複数の関数と関数毎に異なる所定の値とを対応付けるテーブルを格納する記憶部と、前記プログラム実行中に使用される積算値を格納し、前記プログラム実行中に一の関数が他の関数を呼び出したとき、当該他の関数に対応付けられた所定の値を前記記憶部に格納される前記テーブルから読み出し、当該読み出した値を前記積算値に加算する管理部と、を備えるプログラム処理装置とした。 （もっと読む）

【課題】サーバ内で動作するプロセス間通信において、運用中のシステムのネットワーク性能に応じたサーバ上のプロセスが最速な通信路を選択可能とする。
【解決手段】ＯＳからメモリ領域の割り当てを受けて処理を実行する複数のプロセスと、前記各プロセッサ間通信で送信パケットの最大パケット長と測定分割数を定義する環境ファイルと、前記環境ファイル内容を読み込み、動的に測定パケット長条件を変化させながら複数のプロトコルスタックごとのプロセス間通信処理性能を周期的に測定する動的通信性能測定部と、前記動的通信性能測定部の測定結果に基づき、パケットごとに最適なプロトコルスタックを選択し分配するプロトコル分配部とを備える。 （もっと読む）

【課題】 本発明の課題は、マルチタスクＯＳ上で動作するタスク毎のタスク状態の時間や割合をオペレータの手間をかけずに測定し、その結果を統計的かつグラフィカルに表示することを目的とする。
【解決手段】 上記課題は、リアル・タイム・オペレーティング・システムに、プロセッサが実行するタスクを切替えるディスパッチを実現する機構であり、該ディスパッチの際に該タスクの状態変化を検出するディスパッチャを備え、前記ディスパッチャは、前記タスクの状態変化を検出すると、複数のタスク各々のタスク状態を所定記憶領域で管理するサブルーチンを呼び出して、該タスクの状態を変化後の状態に変更させることにより達成される。 （もっと読む）

プロセス及びオペレーションの電力コストに基づきそれらプロセス及びオペレーションを監視し制御するよう動作する電子装置が提供される。この電子装置は、電力を要求するプロセス又はネットワーク装置を識別し、それらプロセス又はネットワーク装置に対して要求される予想電力量を決定し、そして電力要求のコストを計算する。例えば、電子装置は、電力供給者が消費電力のコストを計算する仕方を定義するデータ又はアルゴリズムを受け取り、特定電力要求の予想コストを推定する。プロセス又は装置の重要性、及び予想電力コストに基づき、電子装置は、プロセスを遂行するか、又はネットワーク装置に電力を供給するか、或いはプロセスを遅延又はキャンセルして、装置の電力コストがそのプリセット境界内に留まるよう保証することができる（例えば、装置又はそのホームネットワークの電力コストが最大上限を越えない）。 （もっと読む）

【課題】ＯＳ環境下で実行中のプログラムに対して、プログラムの修正や実行停止することなく、特定のプログラムの挙動に関する情報を取得すること。
【解決手段】性能プロファイリング取得ツール１２０では、プロセッサ１００のイベントコンテキストレジスタ１０２に測定対象となるプロセスのプロセスＩＤを登録する。そして、ＯＳ１１０の環境下で測定対象プログラム１１１が実行されると、実行中の測定対象プログラム１１１のプロセスＩＤが実行情報としてプロセッサ１００のコンテキストレジスタ１０３に記録される。コンテキストレジスタ１０３に記録されたプロセスＩＤは、比較器１０４によって、イベントコンテキストレジスタ１０２に登録されている測定対象となるプロセスＩＤと比較される。比較器１０４では、比較されたプロセスＩＤ同士が一致した場合にのみ、イベントカウンタ１０５にカウント指示を出力する。 （もっと読む）

【課題】アプリケーションにおいて発生するタイミング依存の不具合の再現率が高いスレッドのスケジュール方法を見出すことを可能とする。
【解決手段】調査プログラム１１は、複数のスレッドのスケジュール方法を表すスレッド制御ポリシーを設定する。スレッド制御用スレッド１４１は、設定されたスレッド制御ポリシーによって表されるスケジュール方法で複数のスレッドが実行されるための制御を行う。調査プログラム１１は、不具合発生プログラム１２に不具合が発生したことが検出された場合に、不具合が発生したこと及び複数のスレッドが実行されてから不具合が発生するまでの時間を統計情報として実行結果統計情報記録ＤＢ１３に記録する。調査プログラム１１は、実行結果統計情報記録ＤＢ１３に記録された統計情報に基づいて、不具合発生プログラム１２に発生した不具合の発生頻度が高いスレッド制御ポリシーを特定する。 （もっと読む）

【課題】機器の故障において原因となる故障部品が特定されない場合であっても、そのようなケースを含む交換作業の情報に基づいて、故障確率算出に用いられる生存曲線を生成する。
【解決手段】交換記録テーブルＥをメンテナンスログＬから生成する第１の生成部２と、複数の部品のそれぞれについて部品故障テーブルＴを生成する第２の生成部３と、複数の部品のそれぞれについて生存曲線およびハザード関数を生成する第３の生成部４と、ハザード関数を用いてハザード値を計算し、各部品のハザード値を用いて正規化を行うことにより第２の重みを計算し、第１の重みと第２の重みとを比較して収束判定を行う判定部５と、収束判定により生存曲線を出力して処理を終了するか、新たな生存曲線およびハザード関数を第３の生成部４から生成したのち、判定部５により収束判定が繰り返し行われるように制御を行う制御部１と、を具備する。 （もっと読む）

【課題】分散コンピューティング環境下において指定イベントの証跡ログを効率的に取得するとともに、処理手順再現に係る汎用性を向上させることを課題とする。
【解決手段】サーバ装置が内在するサービス処理部では、ＳＯＡ環境下で全サービス共通のキー番号及び１以上の配列要素で表現される一連番号を含む共通ヘッダをサービス間で受け渡し、サービスが同期連動または派生連動時であるかによってインクリメントする要素を変えて一連番号を更新する。 （もっと読む）

【課題】ターゲットプログラムの実際の動作時のキャッシュミスのプロファイル情報を、関数毎に得ることができるプロセッサ及びマルチプロセッサを提供する。
【解決手段】プロセッサ１１は、ローカルメモリ２３と、クロック信号に基づいてクロック信号をカウントするクロックカウンタと、関数の呼び出しを検出すると、クロックカウンタのカウンタ値と、プログラムカウンタ値と、飛び先あるいは戻り先のアドレスの情報を、ローカルメモリ２３に出力する関数コール制御部４１と、キャッシュミスを検出すると、クロックカウンタのカウンタ値と、プログラムカウンタ値と、アクセスアドレスの情報を、ローカルメモリ２３に出力するキャッシュミス制御部４２とを有する。 （もっと読む）

【課題】 アプリケーションによる実装を行わなくてもデータ流量の目安を取得できるようにすること。
【解決手段】 デバイス（４０）とユーザプロセスとの間でメッセージを通信するためのデータ経路を有するコンピュータシステムのSTREAMS機構にて、メッセージの統計情報を採取するためのメッセージ統計情報採取モジュール（１０）は、統計情報管理領域（２０）を割り当てるためのオープンルーチン（１１）と、統計情報管理領域（２０）に統計情報を記録するためのputプロシジャ（１２）と、統計情報管理領域（２０）を解放するためのクローズルーチン（１３）と、を有する。 （もっと読む）

【課題】ファイルのデータを処理するトランザクション処理の性能低下を最小限に抑えつつ、滞留データの測定が可能な滞留データ測定システムを提供する。
【解決手段】読み込み情報ファイル格納手段２０は、トランザクションのコミットに成功すると、データファイル１５から読み込んだデータの管理情報を集計し、読み込み情報ファイル１３に加算する。また、書き込み情報ファイル格納手段２１は、データファイル１６に含まれるデータの管理情報を、送信先トランザクションごとに集計し、書き込み情報ファイル１４に加算する。滞留データを測定する際には、書き込み情報ファイル１４を検索して、測定対象のトランザクションに送信されたデータの管理情報を集計し、これと、測定対象のトランザクションの読み込み情報ファイル１３とを比較する。 （もっと読む）

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

【課題】 クライアントがサーバの処理の終了を必要以上に待つ時間を短縮しつつ、サーバの負荷が高いときには、サーバへのリクエスト送信の待機時間を大きくしてリクエスト回数を減らすことでサーバの負荷を軽減すること。また、サーバの負荷が低いときには、サーバへのリクエスト送信の待機時間を小さくしてリクエスト回数を増やすことでサーバ資源を有効に使用し、予想外な処理の早期終了に対応すること。
【解決手段】 サーバが、処理進捗度取得手段によって取得されるクライアントから要求された処理の進捗度および負荷取得手段によって取得されるサーバの負荷に基づいて、待機時間を算出する待機時間算出手段を持つ。 （もっと読む）

【課題】 アプリケーションが使用するリソースに関する情報を取得する。
【解決手段】 アプリケーションを実行させるためのリソースを備えた装置において、前記アプリケーションの実行中に、当該アプリケーションのメモリ使用量に関するメモリリソース情報を取得し、当該メモリリソース情報を前記アプリケーションのＩＤとともに記憶手段に格納する取得手段を有する。 （もっと読む）