(57)【特許請求の範囲】
【請求項１】
データ収集方法であって、
ネットワーク管理デバイスはネットワーク要素デバイスが報告した処理待ちのデータファイルを収集することと、
前記処理待ちのデータファイルを複数のタスクに割り当てることと、
前記複数のタスクをタスクキューに加わり、前記タスクキューからタスクを1つずつ抽出して処理することとを含み、
前記処理待ちのデータファイルを複数のタスクに割り当てるステップは、
前記処理待ちのデータファイルの数量又は容量を評価することと、
ローカルの計算能力を評価することと、
ローカルの構成パラメータを取得することと、
前記処理待ちのデータファイルの数量又は容量、前記ローカルの計算能力及び前記構成パラメータに基づいて、タスク負荷を計算することと、
前記タスク負荷に基づいて、前記処理待ちのデータファイルを複数のタスクに割り当てることとを含むデータ収集方法。
【請求項２】
前記ローカルの計算能力はローカルCPU処理速度とメモリ容量とを含む請求項1に記載の方法。
【請求項３】
前記構成パラメータはスレッド数とスレッドの最大活動時間とを含む請求項1又は2に記載の方法。
【請求項４】
ネットワーク管理デバイスであって、
ネットワーク要素デバイスが報告した処理待ちのデータファイルを収集し、前記処理待ちのデータファイルを複数のタスクに割り当て、前記複数のタスクをタスクキューに加わり、前記タスクキューからタスクを1つずつ抽出して処理するように設置されるデータ収集装置を含み、
前記データ収集装置は、前記処理待ちのデータファイルの数量又は容量を評価し、ローカルの計算能力を評価し、ローカルの構成パラメータを取得し、前記処理待ちのデータファイルの数量又は容量、前記ローカルの計算能力及び前記構成パラメータに基づいてタスク負荷を計算し、前記タスク負荷に基づいて前記処理待ちのデータファイルを複数のタスクに割り当てる方式によって、前記処理待ちのデータファイルを複数のタスクに割り当てるように設置されるネットワーク管理デバイス。
【請求項５】
前記ローカルの計算能力はローカルCPU処理速度とメモリ容量とを含む請求項4に記載のネットワーク管理デバイス。
【請求項６】
前記構成パラメータはスレッド数とスレッドの最大活動時間とを含む請求項4又は5に記載のネットワーク管理デバイス。
【請求項７】
データ収集装置であって、
ネットワーク要素デバイスが報告した処理待ちのデータファイルを収集し、前記処理待ちのデータファイルを複数のタスクに割り当て、そして、前記複数のタスクをスレッドプールモジュールに送信するように設置されるタスクディスパッチングモジュールと、
受信された複数のタスクをタスクキューに追加し、前記タスクキューからタスクを1つずつ抽出して処理するように設置されるスレッドプールモジュールとを含み、
前記タスクディスパッチングモジュールは、
ネットワーク要素デバイスが報告した処理待ちのデータファイルを収集し、処理待ちのデータファイルの数量又は容量を評価し、評価された数量又は容量を計算ユニットに送信するように設置されるデータ評価ユニットと、
ローカルの計算能力を評価し、評価されたローカルの計算能力情報を計算ユニットに送信するように設置される計算能力評価ユニットと、
構成パラメータを取得し、取得された構成パラメータを計算ユニットに送信するように設置される構成パラメータユニットと、
受信された前記処理待ちのデータファイルの数量又は容量、前記ローカルの計算能力情報及び前記構成パラメータに基づいてタスク負荷を計算し、計算されたタスク負荷をタスク割り当てユニットに送信するように設置される計算ユニットと、
前記タスク負荷を受信した後、前記タスク負荷に基づいて前記処理待ちのデータファイルを複数のタスクに割り当て、前記複数のタスクをスレッドプールモジュールに送信するように設置されるタスク割り当てユニットとを含むデータ収集装置。
【請求項８】
前記ローカルの計算能力はローカルCPU処理速度とメモリ容量とを含む請求項7に記載のデータ収集装置。
【請求項９】
構成アイテムモジュールをさらに含み、前記構成アイテムモジュールは構成パラメータを定義するように設置され、前記構成パラメータがスレッド数とスレッドの最大活動時間とを含み、
前記構成パラメータユニットは前記構成アイテムモジュールから前記構成パラメータを取得するように設置される請求項7又は8に記載のデータ収集装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は配置可能、スケジューリング可能なデータ収集方法、データ収集装置及びネットワーク管理デバイスに関する。
【背景技術】
【０００２】
2種類の従来のデータ収集方法の構想及びその欠点は以下の通りである。
【０００３】
1、全てのデータファイルは被管理者により管理者が指定するあるディレクトリに送信し、データ収集は該ディレクトリでの全てのデータファイルを収集、解析する。
【０００４】
異なる製品の収集、解析過程が異なり、大体、
1)処理効率が低く、一旦スレッドが異常になった場合、全てのデータが処理されることを保証できないシングルスレッドの運行、
2)多数のスレッドが資源に競争するようになり、この競争の過程中に同期方法の費用を増加させ、効率を低下させるマルチスレッドの運行という2種類に分けられる。
【０００５】
2、異なる被管理者が生成したデータファイルを管理者における該被管理者の特定のディレクトリに送信し、データ収集は全てのディレクトリでのデータファイルを収集、解析する。
【０００６】
ディレクトリはマルチレベルに分けられることができ、各レベルのディレクトリに複数の並列のサブディレクトリが存在することができる。全てのデータはリーフサブディレクトリ(即ち、被管理者ディレクトリ)に保存され、各被管理者ディレクトリは一定の規則に応じて異なる上位のディレクトリに記憶され、これによって類推すれば、上位のディレクトリも一定の規則に応じてさらに上位のディレクトリに記憶される。
【０００７】
異なる製品の収集、解析過程が異なり、大体、
1)同様に処理効率が低く、且つシングルスレッドアクセスディレクトリの階層が深くなると、磁気ディスクIOの操作を実行することがスレッドの大量の処理時間及び資源を占用するシングルスレッドの運行、
2)それぞれのスレッドが1つの非リーフサブディレクトリでの処理を担当することは、各スレッドの作業負荷が不均一になることをもたらし、多数のスレッドが1つの非リーフサブディレクトリを担当することは、競争を形成する以外にも、あるデータがより少ないディレクトリでのスレッド資源の浪費をさらに引き起こすマルチスレッドの運行という2種類にも分けられる。
【０００８】
また、上記2種類の従来の構想は以下の欠点をさらに有する。
【０００９】
データを保存するディレクトリは処理スレッドの作成、起動及び停止の依拠になり、処理スレッドの作業負荷が不均一になり、統一監視できない問題を引き起こすことができる。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
本発明はデータ収集方法、データ収集装置及びネットワーク管理デバイスを提供し、コンピュータの構成及びパラメータ構成に基づいてタスクワークロードを自発的に調整し、異なる場合でデータ処理の最大効率に達することができる。
【課題を解決するための手段】
【００１１】
従来の技術問題を解決するために、本発明はデータ収集方法を提供し、
ネットワーク管理デバイスはネットワーク要素デバイスが報告した処理待ちのデータファイルを収集することと、
前記処理待ちのデータファイルを複数のタスクに割り当てることと、
前記複数のタスクをタスクキューに追加し、前記タスクキューからタスクを1つずつ抽出して処理することとを含む。
【００１２】
好ましくは、上記方法は、前記処理待ちのデータファイルを複数のタスクに割り当てるステップが、
前記処理待ちのデータファイルの数量又は容量を評価することと、
ローカルの計算能力を評価することと、
ローカルの構成パラメータを取得することと、
前記処理待ちのデータファイルの数量又は容量、前記ローカルの計算能力及び前記構成パラメータに基づいて、タスク負荷を計算することと、
前記タスク負荷に基づいて、前記処理待ちのデータファイルを複数のタスクに割り当てることとを含むという特徴を有する。
【００１３】
好ましくは、上記方法は、前記ローカルの計算能力はローカルのCPU処理速度とメモリ容量とを含むという特徴を有する。
【００１４】
好ましくは、上記方法は、前記構成パラメータがスレッド数とスレッドの最大活動時間とを含むという特徴を有する。
【００１５】
本発明はネットワーク管理デバイスをさらに提供し、
ネットワーク要素デバイスが報告した処理待ちのデータファイルを収集し、前記処理待ちのデータファイルを複数のタスクに割り当て、前記複数のタスクをタスクキューに追加し、前記タスクキューからタスクを1つずつ抽出して処理するように設置されるデータ収集装置を含む。
【００１６】
好ましくは、上記ネットワーク管理デバイスは、
前記データ収集装置が、前記処理待ちのデータファイルの数量又は容量を評価し、ローカルの計算能力を評価し、ローカルの構成パラメータを取得し、前記処理待ちのデータファイルの数量又は容量、前記ローカルの計算能力及び前記構成パラメータに基づいてタスク負荷を計算し、前記タスク負荷に基づいて前記処理待ちのデータファイルを複数のタスクに割り当てる方式によって、前記処理待ちのデータファイルを複数のタスクに割り当てるように設置されるという特徴を有する。
【００１７】
好ましくは、上記ネットワーク管理デバイスは、前記ローカルの計算能力がローカルCPU処理速度とメモリ容量とを含むという特徴を有する。
【００１８】
好ましくは、上記ネットワーク管理デバイスは、前記構成パラメータがスレッド数とスレッドの最大活動時間とを含むという特徴を有する。
【００１９】
本発明はデータ収集装置をさらに提供し、
ネットワーク要素デバイスが報告した処理待ちのデータファイルを収集し、前記処理待ちのデータファイルを複数のタスクに割り当て、そして、前記複数のタスクをスレッドプールモジュールに送信するように設置されるタスクディスパッチングモジュールと、
受信された前記複数のタスクをタスクキューに追加し、前記タスクキューからタスクを1つずつ抽出して処理するように設置されるスレッドプールモジュールとを含む。
【００２０】
好ましくは、上記データ収集装置は、前記タスクディスパッチングモジュールが、
ネットワーク要素デバイスが報告した処理待ちのデータファイルを収集し、処理待ちのデータファイルの数量又は容量を評価し、評価された数量又は容量を計算ユニットに送信するように設置されるデータ評価ユニットと、
ローカルの計算能力を評価し、評価されたローカルの計算能力情報を計算ユニットに送信するように設置される計算能力評価ユニットと、
構成パラメータを取得し、前記構成パラメータを計算ユニットに送信するように設置される構成パラメータユニットと、
受信された前記処理待ちのデータファイルの数量又は容量、前記ローカルの計算能力情報及び前記構成パラメータに基づいてタスク負荷を計算し、計算されたタスク負荷をタスク割り当てユニットに送信するように設置される計算ユニットと、
前記タスク負荷を受信した後、前記タスク負荷に基づいて前記処理待ちのデータファイルを複数のタスクに割り当て、前記複数のタスクをスレッドプールモジュールに送信する、ように設置されるタスク割り当てユニットとを含むという特徴を有する。
【００２１】
好ましくは、上記データ収集装置は、前記ローカルの計算能力がローカルCPU処理速度とメモリ容量とを含むという特徴を有する。
【００２２】
好ましくは、上記データ収集装置は構成アイテムモジュールをさらに含み、前記構成アイテムモジュールは構成パラメータを定義するように設置され、前記構成パラメータがスレッド数とスレッドの最大活動時間とを含み、前記構成パラメータユニットは前記構成アイテムモジュールから前記構成パラメータを取得するように設置されるものである。
【発明の効果】
【００２３】
本発明が提供するデータ収集方法、データ収集装置及びネットワーク管理デバイスは、以下の有益な効果を有する。
【００２４】
1、コンピュータの構成及びパラメータ構成に基づいてタスクワークロードを自発的に調整し、異なる場合でデータ処理の最大効率に達することができる。
【００２５】
2、タスクディスパッチングモジュールはタスク区分を行う時に、異なるタスクの作業範囲の重複を引き起こすことができなく、資源競争の可能性を除去し、タスクの処理効率を向上させる。
【００２６】
3、1つのタスクの内容は1層のディレクトリのアクセスのみに限られ、磁気ディスクのディレクトリに出入りするIO操作効率を向上させる。
【００２７】
4、構成ファイルはスレッドプールの規模を管理し、システム効率を損失しない前提でデータ収集機能の効率を向上させることができる。
【００２８】
5、 構成ファイルはスレッドの活動時間を管理し、スレッドが長時間に運行して異常が現れる可能性を低下させる。
【００２９】
6、タスクがディスパッチングされる時に、大量ファイルの操作によって一部の処理時間を損失するが、それがもたらされた損失は後続処理に節約する時間よりはるかに小さい。
【００３０】
7、タスクディスパッチングモジュールは、リアルタイムにコンピュータの構成に基づいてタスクを合理的に割り当てることができ、コンピュータの作業負荷が大きすぎる状況或いは完全に利用されていない状況を回避する。
【図面の簡単な説明】
【００３１】
【図１】本発明実施例のネットワーク管理デバイスの模式図
【図２】本発明実施例のデータ収集装置の模式図
【図３】本発明実施例のタスクディスパッチングモジュールの模式図
【図４】本発明実施例のデータ収集方法のフローチャート
【発明を実施するための形態】
【００３２】
以下、図面を結び付けて本発明実施例が提供する技術案をさらに説明する。ここで説明された好適な実施例は本発明を説明、解釈することのみに用いられ、本発明を限定するものではないことが理解されるべきである。
【００３３】
図1は本発明実施例のネットワーク管理デバイスの模式図であり、図1に示すように、本実施例のネットワーク管理デバイスはデータ収集装置を含み、以下の機能を有する。
【００３４】
ネットワーク要素デバイスが報告した処理待ちの(データファイルを解析することを意味してもよく、データファイルをネットワーク管理の上位層に転送することを意味してもよい)データファイルを収集し、処理待ちのデータファイルの数量及び/又は容量を評価し、且つローカルの計算能力及び構成パラメータに基づいて、タスク負荷を計算し、そして、タスク負荷に基づいて全ての処理待ちのデータファイルを複数のタスクに割り当てる。割り当てられた各タスクをタスクキューに追加し、そして、タスクキューヘッドから1つずつ取り出してタスクを実行し、取り出された各タスクの内容は一部の処理待ちのデータファイルである。
【００３５】
図2は本発明実施例のデータ収集装置の模式図であり、図2に示すように、本実施例のデータ収集装置は、トリガー、タスクディスパッチングモジュール、スレッドプールモジュール、後続処理モジュール及び構成アイテムモジュールを含み、各モジュールの主な機能は以下の通りである。
【００３６】
トリガーは主にタスクディスパッチングモジュールの作業の開始をトリガすることに用いられる。
【００３７】
タスクディスパッチングモジュールは、処理待ちのデータファイルを収集することに用いられ、例えば、非リーフサブディレクトリでの全ての、リーフサブディレクトリでの全ての処理待ちのデータファイルを収集し、データファイルの数量/容量、コンピュータの構成(例えば、ローカルの計算能力)、及び構成アイテムモジュールから抽出された構成アイテムパラメータに基づいて、各スレッドの作業負荷を動的に調整し、且つタスクの割り当てを行い、割り当てられたタスクをスレッドプールモジュールに送信する。
【００３８】
タスクディスパッチングモジュールはコンピュータの構成及びパラメータ構成に基づいてタスクワークロードを自発的に調整し、異なる場合でデータ処理の最大効率に達することができ、且つタスクディスパッチングモジュールはタスクの割り当てを行う時に、異なるタスクの作業範囲の重複を引き起こすことができなく、資源競争の可能性を除去し、さらにタスクの処理効率を向上させ、割り当てられたタスクは、1つのタスクの内容が1層のディレクトリ(即ち、リーフサブディレクトリであり、同一の階層、且つ同一の親ディレクトリに帰属する複数のディレクトリを意味する)のアクセスのみに限られるものであり、磁気ディスクのディレクトリに出入りするIO操作効率を向上させる。
【００３９】
スレッドプールモジュールは、タスクを処理する複数の活動スレッド及び1つのタスクキューからなり、スレッドプールモジュールは受信されたタスクをタスクキューに追加し、活動スレッドがタスクキューからタスクを取得した後に処理する。活動スレッドは、まずタスクキューヘッドから1つのタスクを取り出し、タスクに持たれる処理待ちのデータファイル情報を取得し、続いて、相応する情報に基づいてデータファイルを処理する。処理は、データファイルの解析、データファイルの転送を含むことができるが、この2種類の処理モードに限定されるべきではない。タスク実行中のデータファイルの処理結果は、データプロセスが完了したことではないこと或いはさらに加工する必要があることであれば、タスク実行の結果を後続処理モジュールに送信して、さらに処理を行う必要がある。
【００４０】
構成アイテムモジュールは、XML(Extensible Markup Language、拡張可能マークアップ言語)ファイルによって、或いはコードにおいてデータ収集機能の関連パラメータの定義を提供する。構成アイテムは、スレッドプールモジュールのスレッド数、スレッドの最大活動時間、ファイル数量/容量によってディスパッチングすること等を含む。
【００４１】
構成アイテムモジュールはスレッドプールの規模を管理し、システム効率を損失しない前提でデータ収集機能の効率を向上させることができ、構成アイテムによって「スレッド数」のパラメータを提供し、スレッドプールの初期化の過程中にこのパラメータに基づいて、いくつかの活動スレッドを生成し、即ち、スレッドプールの規模を選択する。
【００４２】
構成アイテムモジュールはスレッドの活動時間を管理し、スレッドが長時間運行して異常が現れる可能性を低下させる。具体的には構成アイテムによって「スレッドの活動時間」のパラメータを提供することができる。該パラメータはスレッドの運行の最長時間を決定する。例えば、該パラメータを1分間に設定すると、スレッドがタスクを実行する最大時間は1分間であり、1分間を超えるとスレッドがタスクの実行を自動的に停止させ、タスク内に、処理が完了していないデータファイルをタスクキューに追加する。スレッドが長時間の運行を持続して異常になる機会を増加することを回避するために、このパラメータを設置してスレッドが異常になる機会を低下させる。
【００４３】
後続処理モジュールは、後続処理の操作を提供する。例えば、データベースに書き込まれる操作、転送操作である。処理の容量に基づいて、同様にスレッドプールプラスデータキュー、即ち、1つのスレッドプール及び1つのデータキューの方式(ここでのスレッドプール及びデータキューは上述の内容におけるスレッドプール及びデータキューを意味することではなく、ユニバーサルの概念を意味することである)を採用する操作モードに設計することができ、しかし、処理容量がより小さいとシングルスレッドプラスデータキューに設計することができる。できる限りスレッドプールにおけるスレッドと同期方式に設計しないように注意する必要がある。後続処理の操作はデータをデータベースに書き込むこと或いはデータの転送操作を行うこと等を含む可能性があるが、この2種類に限られない。
【００４４】
本実施例のデータ収集装置におけるタスクディスパッチングモジュールの構造は、図3に示すように、データ評価ユニット、計算ユニット、計算能力評価ユニット、構成パラメータユニット及びタスク割り当てユニットを含む。
【００４５】
データ評価ユニットは、処理待ちのデータファイル、例えば、非リーフサブディレクトリでの全てのリーフサブディレクトリでのデータファイルを収集し、処理待ちのデータファイルを評価し、例えば、データファイルの数量及び/又は容量を評価することができ、評価された後のデータファイルの数量及び/又は容量を計算ユニットに送信するように設置される。
【００４６】
計算能力評価ユニットは、ローカルの計算能力、例えば、コンピュータのCPU処理速度、メモリ容量等の計算能力を評価し、評価されたローカルの計算能力を計算ユニットに送信するように設置される。
【００４７】
構成パラメータユニットは、構成アイテムモジュールから構成パラメータ、例えば、スレッド数及びスレッドの最大活動時間等を抽出し、構成パラメータ或いは運算された後の構成パラメータを計算ユニットに送信するように設置される。
【００４８】
計算ユニットは、データ評価ユニットが評価したデータファイルの数量及び/又は容量、計算能力評価ユニットが評価した計算能力及び構成パラメータユニットが提供した構成パラメータに基づいてタスク負荷を計算し、計算されたタスク負荷をタスク割り当てユニットに送信するように設置される。
【００４９】
タスク割り当てユニットは、全てのリーフサブディレクトリでの全ての処理待ちのデータファイルをタスク負荷に応じて複数のタスクに割り当て、そして、割り当てられたタスクをスレッドプールモジュールに送信するように設置される。各サブタスクは全ての収集されたリーフサブディレクトリの1つのサブセットの収集及び解析作業のみを担当する。
【００５０】
データの評価及びタスクの分解は数量或いは容量という2種類の次元に応じて行うことができる。
【００５１】
本発明実施例のネットワーク管理デバイス及びデータ収集装置に基づいて、非リーフサブディレクトリでの全てのリーフサブディレクトリでの処理待ちデータファイルを収集し、且つタスクの割り当てを行い、処理待ちのデータファイルの数量/容量、コンピュータの構成(即ち、ローカルの計算能力)及び構成アイテムパラメータに基づいて各タスクの作業負荷を動的に調整し、各スレッドの作業負荷が不均一である問題を解決するとともに、コンピュータの作業負荷が大きすぎる問題或いは完全に利用されていない問題を解決し、同一の非リーフサブディレクトリで多数のスレッドの作業範囲が 重複して競争を形成する問題をさらに解決し、且つ分解されたタスクはリーフサブディレクトリのみを操作し、ファイルのアクセスが多層のディレクトリに頻繁に出入ることを回避し、磁気ディスクIOの操作の効率が低い問題を解決した。データ処理が使用するモードはスレッドプールプラスタスクキューのモードであり、且つ構成アイテムによって管理される。
【００５２】
全ての処理スレッドを統一的に監視することができ、全ての処理スレッドを統一的に管理できない問題を解決し、且つ異なる場合に応じて解析スレッド数量及びその最大活動時間を調整することができ、スレッドが長時間運行して異常の出現を増大する可能性を低下させ、正確率を保証する前提で処理の最大効率に達する。
【００５３】
タスクがディスパッチングされる時に、大量ファイルの操作によって一部の処理時間を損失するが、それがもたらされた損失は後続処理において節約する時間よりはるかに小さい。
【００５４】
図4は本発明実施例のデータ収集方法のフローチャートであり、図4に示すように、本実施例のデータ収集方法は、以下のステップを含む。
【００５５】
S11、ネットワーク管理デバイスはネットワーク要素デバイスが報告した処理待ちのデータファイルを収集し、
トリガーがタスクディスパッチングモジュールの作業の開始をトリガーした後、タスクディスパッチングモジュールは各非リーフサブディレクトリで処理待ちのリーフサブディレクトリを収集し、これらのリーフサブディレクトリで各ネットワーク要素デバイスが報告した処理待ちのデータファイルが保存されている。
【００５６】
S12、処理待ちのデータファイルを評価し、
リーフサブディレクトリでのデータファイルを評価し、例えば、データファイルの数量及び/又は容量を評価することができる。
【００５７】
S13、ローカルの計算能力を評価し、
ローカルの計算能力は主にコンピュータCPU処理速度とメモリ容量等を含む。
【００５８】
S14、構成パラメータを取得し、
構成パラメータは主にスレッド数と最大活動時間等を含む。
【００５９】
ステップS12からステップS14までは順序の制限がない。
【００６０】
S15、タスク負荷を計算し、
ステップS12からステップS14まで取得されたパラメータに基づいて各スレッドのタスク負荷を計算し、タスク負荷の計算方式の例は以下の通りである。
【００６１】
1)データの総CPU処理時間を計算し、
データの総CPU処理時間は具体的に処理待ちのデータファイルの総数量又は総容量をCPU処理速度で割るものに等しい。
【００６２】
2)処理のバッチを計算し、
まずデータの総CPU処理時間をスレッド数と最大活動時間との積で割った商、データ総容量をメモリ容量で割った商を計算し、処理のバッチは2つの商の中の大きい方を取り、表現式は以下の通りである。
【００６３】
処理のバッチ=Max(データの総CPU処理時間/(スレッド数*最大活動時間)、データ総容量/メモリ容量) 、ただし、Maxは最大のものを取ることを示す。
【００６４】
3) タスク負荷を計算し、
各スレッドのタスク負荷はデータ総容量を処理のバッチで割ってさらにスレッド数で割ったものであり、表現式は以下の通りである。
【００６５】
各スレッドの負荷=データ総容量/処理のバッチ/スレッド数。
【００６６】
もちろん、上記の規則は必ずそれぞれの場合に適切しなく、他の計算法則にも同様に適用する。
【００６７】
S16、タスク負荷に基づいて処理待ちのデータファイルを複数のタスクに割り当て、且つ割り当てられた各タスクをタスクキューに追加する。
【００６８】
タスクの内容は該タスクがカバーするリーフサブディレクトリでのデータファイルへの解析のみである。
【００６９】
S17、タスクキューからタスクを1つずつ取り出して、且つ該タスクを処理する。
【００７０】
スレッドプールはアクティベーション通知を受信し、タスクキューからタスクを1つずつ取り出し、且つ該タスクを処理し、タスクの処理結果は後続処理モジュールに送信することができる。
【００７１】
タスクの処理過程中に、データファイルへの処理はデータファイルへの解析であってもよく、実行の結果はストレージ待ちのデータ或いは転送待ちのデータである。
【００７２】
S18、後続操作を行い、
後続処理モジュールのスレッドは絶えずにデータキューからデータを取り出し、且つ後続の操作を実行し、データキューにデータを有しなければ、スレッドは一定の時間スリープした後にもう一度試す。
【００７３】
本方法におけるステップS11からS18までに関与する具体的な実施形態はネットワーク管理の性能、アラーム、逆構成等の場合のみに限定されず、データ収集を行う必要がある全ての場合にいずれも使用できる。以下、それぞれネットワーク管理の性能、アラーム及び逆構成という3種類の場合でのデータ収集の実施形態を説明する。
【００７４】
実施形態一、
ネットワーク管理の性能データの収集について、ネットワーク要素デバイスは性能データファイルをネットワーク管理デバイスに報告し、ネットワーク管理デバイス内のデータ収集装置は性能データの収集及びストレージを行う。
【００７５】
本実施形態のデータ収集装置の中に各モジュールを構成し、具体的に以下の通りである。
【００７６】
A、収集トリガーモジュールを構成し、
タイマにより実現でき、タスクディスパッチングモジュールの作業の開始をウェイクアップすることに用いられる。
【００７７】
B、構成アイテムモジュールを構成し、
具体的には、XMLの構成ファイル及びその解析的カテゴリーを定義し、本実施形態に記載される特性は関連パラメータ、即ち、スレッドプールモジュールのスレッド数、スレッドの最大活動時間及びデータ評価の分解粒度(数量或いは容量)に関し、且つパラメータが取得される機能を提供する。
【００７８】
実際の応用において、パラメータはいずれもXMLの構成ファイルに書き込まれるものであり、これらのパラメータは解析的カテゴリーによってソフトウェアに追加する必要がある。
【００７９】
C、タスクディスパッチングモジュールを構成し、
1) タスクディスパッチングモジュールは構成アイテムのスレッド数及び最大活動時間を使用し、
2)データ評価ユニットを構成し、それはデータファイルの総容量を評価するように設置され、
3)計算能力評価ユニットを構成し、それはコンピュータCPU処理速度及びメモリ容量を評価するように設置され、
4)計算ユニットを構成し、それは、相応する計算規則に基づいてスレッドのタスク負荷を算出し、スレッドのタスク負荷に応じて収集された全てのデータファイルを各タスクに割り当て、運行の結果は割り当てられたタスク(即ち、実現されたタスクインタフェースである)であり、割り当てられたタスクをスレッドプールにおけるタスクキューに追加するように設置される。
【００８０】
D、タスクインタフェースを定義して実現し、 
タスクインタフェースにネットワーク要素での性能データファイルを処理する機能を実現する。
【００８１】
タスクインタフェースは、データファイルが解析された後に結果を後続処理モジュールのデータキューにさらに追加することができ、処理結果は後続処理データである。後続処理データとは実際にタスクがデータファイルを解析された結果を意味し、ただもう一度加工することを要する可能性があるにすぎないため、後続処理データと呼ばれる。
【００８２】
E、スレッドプールモジュールを構成し、
スレッドプールは、構成アイテムの推奨値が20の「スレッドプールモジュールのスレッド数」、推奨値が10分間の「スレッドの最大活動時間」を使用する必要がある。
【００８３】
スレッドプールモジュールは割り当てられたタスクをタスクキューに追加することができ、その後、タスクキューからタスクを1つずつ取り出し、相応する処理を行い、処理後のタスクを出力する。
【００８４】
好ましくは、あるタスクが後続処理、例えば、ストレージ等の操作を行う必要があれば、スレッドプールモジュールは処理後のタスクを後続処理モジュールに伝送する。
【００８５】
F、後続処理モジュールを構成し、
データキューを定義し、且つデータのキャッシュメカニズムを構成し、データキューは以降にさらに処理を要するデータを記憶することに用いられる。
【００８６】
処理スレッドを構成し、該スレッドはいつまでも運行するスレッドであり、且つデータキューからデータを取って処理し、ストレージ操作であれば、該スレッドの実行はデータベースの記憶過程によってデータをデータベースの関連テーブルに記憶することができる。
【００８７】
実施形態二、
ネットワーク管理デバイスの逆構成データの処理について、ネットワーク管理デバイスは複数のネットワーク要素デバイスに対して逆構成操作を起こさせ、ネットワーク要素デバイスは逆構成データファイルをネットワーク管理デバイスに報告し、ネットワーク管理デバイス内のデータ収集モジュールは逆構成データの収集及びストレージを行う。
【００８８】
逆構成は、ネットワーク要素デバイスにおける構成データをFTP(ファイル転送プロトコル)方式でネットワーク管理デバイスに報告し、ネットワーク管理デバイスはこれらの構成データを収集し、最後にデータベースに書き込むことを意味している。逆構成操作は、ネットワーク管理デバイスがネットワーク要素デバイスへ命令を出し、ネットワーク要素デバイスが構成データをネットワーク管理デバイスに報告し、ネットワーク管理デバイスが構成データを収集してデータベースに書き込むことを含む。
【００８９】
該実施形態の基本的な方法は実施形態一と類似し、実施形態一との区別は以下の通りである。
【００９０】
a、構成アイテムモジュールは数量評価とタスク分解を採用する。原因は逆構成時に容量の大きさを気に掛けず、収集する必要がある構成データの数のみを気に掛けることである。
【００９１】
b、タスクディスパッチングモジュールにおけるデータ評価ユニットが返したのはデータファイルの総数量である。
【００９２】
c、トリガーモジュールにおけるトリガー条件は逆構成操作であり、タイマではない。
【００９３】
実施形態三、
ネットワーク管理デバイスのアラーム同期データの収集について、ネットワーク管理デバイスは複数のネットワーク要素デバイスに対してアラーム同期操作を起こさせ、ネットワーク要素デバイスはアラーム同期データファイルをネットワーク管理デバイスに報告し、ネットワーク管理デバイス内のデータ収集装置はアラーム同期データの収集及びストレージを行う。
【００９４】
該実施形態の基本的な方法は実施形態一と類似し、実施形態一との区別は以下の通りである。
【００９５】
a、構成アイテムモジュールは数量評価及びタスク分解を採用する。
【００９６】
b、タスクディスパッチングモジュールにおけるデータ評価ユニットが返したのはデータの総数量である。
【００９７】
c、トリガーモジュールにおけるトリガー条件はアラーム同期操作であり、タイマではない。
【００９８】
本実施例の方法は全ての「管理者-被管理者」モードの環境に適用し、且つデータが被管理者から管理者に報告する必要がある限り、本方法を使用することができる。
【００９９】
以上の内容は本発明の好ましい実施例だけであり、本発明を限定することに用いられるものではなく、当業者にとっては、本発明に各種の変更及び変化を行うことができる。本発明の精神及び原則の内で行われる如何なる修正、均等置替、改善等は、いずれも本発明の保護範囲の内に含まれるべきである。
【産業上の利用可能性】
【０１００】
従来の技術に比べ、本発明は資源競争の可能性を除去し、タスクの処理効率を向上させ、磁気ディスクのディレクトリに出入りするIO操作効率を向上させ、システム効率を損失しない前提でデータ収集機能の効率を向上させ、スレッドが長時間運行して異常が現れる可能性を低下させ、及びコンピュータの作業負荷が大きすぎる状況或いは完全に利用されていない状況を回避する。
【図１】
0005584780.tif 000002
【図２】
0005584780.tif 000003
【図３】
0005584780.tif 000004
【図４】
0005584780.tif 000005