NEXT IMAGE
ユーザー:匿名希望 さん      総合情報ポータルログイン 総合情報ポータルとは?  
リンコム通信(公開メッセージ)  > メッセージ詳細表示 
公開メッセージ
検索 検索
[ 閉じる ]

前へ前へ      次へ次へ
   レスポンス改善3 (2010年3月)
カテゴリー:無し  登録者:リンコム営業   登録日時:2010/3/8 10:14  表示期限:無期限  

ネクスト活用事例紹介

レスポンス改善3

2010年03月

text by 山田晃生(ITアーティテクチャ)



いよいよ3月、決算月に入り忙しい方々も多いでしょうか?
幸いリンコムは決算が12月なので3月は特別に・・・というわけでは、ないのですが、やっぱり私も忙しい日々です。

今月はレスポンス悪化頻度についてご紹介します。
悪化頻度とは、リンコム ネクストのレスポンスが悪化するタイミングや時間帯などを指しています。
この悪化する状況を把握することにより、原因がぐっと絞り込まれる事が多くあります。

1.レスポンス悪化頻度のパターン
レスポンスの悪化パターンは大きく3つに分けられます。
・ 随時悪い
・ 特定の時間帯悪い
・ 特定の操作時悪い
この他にもあるとは思いますが、だいたいの場合はこの3つのどれか(または複合)に分類されると思います。
それでは個別に問題が発生する原因や対策を考えてみましょう。

今回はまず、随時悪いケースを考えて見ましょう。
リンコム ネクストを操作すると、時間帯やアプリケーションに関わらず、いつも5秒以上待たされてしまう・・・。
こんな場合はリンコム ネクストというより、システム全体を巻き込んだ問題である可能性が高いです。
まずはレスポンスが悪いのはネクストか、ネクスト以外かを切り分けます。切り分けの方法は第1回にも書きました、ストップウオッチとデバッグタイムを比較します。
ここで体感速度並みにデバッグタイムが悪い場合は、いよいよボトルネックの絞込みを行うことになります。
随時悪いということは、システム全体に影響がある箇所での悪化と考えていいでしょう。
そこでどんな操作でも利用することがあるオブジェクトをチェックしていきます。
・ ColdFusionクライアント変数テーブル
・ ColdFusionログファイル
・ ネクストThunderbirdデータ
・ ネクスト本体DBファイル
・ ネクスト監査ログ/アクセスログ
ざっとこんなところでしょうか?

2.ColdFusionクライアント変数テーブルの削除
それではまず、ColdFusionクライアント変数に関してですが、クライアント変数とはColdFusionにアクセスされたクライアント別の情報を一時格納しておく場所です。
このクライアント変数のおかげで、ブラウザを閉じてもネクストログインが保持できたりするわけです。
通常ColdFusionの初期値はOSのレジストリに作るよう設定されていますが、規模の大きい利用に耐えられないためにネクストではこれをDBに作成することを推奨しています。
しかし、長く使い続けている間にこのDBにデータが蓄積してしまいレスポンスの悪化を引き起こす原因になることがままあります。
対策は簡単です。このテーブルデータをすべて削除してしまうことです。
このデータはネクストユーザのログイン情報などを保持していますので、削除を行うとログイン済みのユーザはすべてログアウトされます。
作業を行う場合は自動ログアウトしても問題ない状況(予めユーザに通知したり、利用されていない時間帯に実施など)で行ってください。
削除対象は、クライアント変数DBにある2つのテーブルすべてです。以下のSQLコマンドで行ってください。
TRUNCATE TABLE CDATA
TRUNCATE TABLE CGLOBAL
もし、このDBのデータファイル(mdfやldfなど)が肥大化し数GBに達しているならば、DB毎DROPしてから再CREATEするもの非常に有効です。

3.ColdFusionログファイルの削除
これは稀なケースなのですが、ColdFusionログファイルが肥大化してレスポンスを悪化させる場合があります。
通常はColdFusionログファイルは一定の大きさになれば自動的に別ファイルを生成してファイルの肥大化を行わないようにしてるのですが、以下のログファイルに関しては永遠に大きくなっていきます。
(ColdFusionインストールディレクトリ)\logs\exception.log
(ColdFusionインストールディレクトリ)\logs\dbexception.log
これらのログファイルが何かしらの理由で数GBに肥大化していた場合、ColdFusionシステムに大きな影響を与えます。この場合はファイルの退避を行うようにしてください。
ただ、ログファイルはColdFusionのサービスが掴んでいますので、必ずサービスを停止させてからファイルの退避を行うようにしてください。
参考までにログが肥大化した事例をご紹介します。
その環境ではロードバランサによる不可分散を行っていたのですが、そのロードバランサがサーバの死活監視のためにパケット送信&キャンセルを5秒毎に行っていました。
この時、ColdFusionはリクエストキャンセルのパケットがあったということで、内部でログにそれらを記録していました。
すると、5秒毎にログファイルが1行増えるシステムになってしまい、1分で12行、1時間で72行、1日で1728行を肥大化し、全体のレスポンスを悪化させていく動作どなってしまったケースがあります。
そういったケースもあるので、定期的にメンテナンスすることをお勧めします。

3.ネクストThunderbirdデータ移行
Thunderbirdデータとは、リンコム ネクストのシステム情報を格納してあるDBで、ネクストインストール直後の段階では、このデータはmdb形式で提供されています。
mdbというのは、ファイルはDBの形式ではありますがトランザクションの概念のない単なるファイルに他なりません。
そのため、単一の利用ならば問題ないのですが複数人が同時に利用するとファイルロックを行い、他の利用を待たせる動作を行います。
規模の大きな環境かでロックが発生すると、利用ユーザすべてがThunderbird待ちの状態になり、レスポンスが急速に悪化します。 そこで、このデータをDBに移行して運用するようにしてください。具体的な方法はインストールマニュアルを参照してください。

4.ネクスト本体DBファイル
通常、リンコム ネクストのDBはそれほど肥大化することはありません。
1000人で5年間利用していても、1〜2GBいけば大きいほうです・・・ワークフローを利用していた場合、ネクストのDBファイルサイズは一気に膨れ上がります。
これはワークフローでは申請書のデータをすべて暗号化してDBに格納しているためで、申請書の大きさに関わらず1申請書に約24000byte(24kb)のサイズとなるからです。
あるユーザでは2年間の利用で申請書数20万、ファイルサイズ15GBに達したケースもあります。
この件には対策は立てにくいのですが、1ファイルサイズが15GBというのは、WindowsOSが扱うにしても現実的ではありません。
この場合はファイルサイズをなるべく小さく分割し、少しでもデータアクセスの効率がよいシステムを心がけるべきなのでしょう。
また、このファイルサイズとは別に意外と多くのユーザでトランザクションログ(Oracleの場合はアーカイブログ)の肥大化が発生しています。
トランザクションログとは簡単に説明すると、DBに対して実行した命令形を記録するログになります。通常はDBのフルバックアップ(データのスナップショット)状態からの差分を管理するものとして扱います。
しかし、このログをほったらかしにして運用を続けていくと、知らぬ間にどんどん肥大化していき全体のレスポンス悪化を招きます。
現実にDBの本体は500MBなのにトランザクションログが10GBを超えていたような例があり、この場合システム全体が非常に不安定な状態になっていました。
この肥大化したログファイルは削除(SQLServerの場合はフルバックアップ)しても、サイズそのものは小さくなりません。
SQLServer2000ならば、デタッチ後、MDFファイルのみをアタッチすることでトランザクションログの切捨てができましたが、2005以降の場合はDBの再構築を行う必要があります。
こういった状況を防ぐためにも、DBのバックアップをスケジューリングし、定期的なログの切捨てを行うようにしてください。

5.ネクスト監査ログ/アクセスログ
最後にチェックするのは、リンコム ネクストDB内いある2つのログテーブルです。
・監査ログ(log_audit):ネクストのログイン情報(失敗も含む)を記録するテーブル
・アクセスログ(access_log):ネクストでの動作すべてを記録するテーブル
この2つのテーブルは長く運用すればするほどデータが蓄積されていきます。先のワークフローを除けばネクストDBの大半を占めることになるでしょう。
もちろんログテーブルなので、会社のシステムポリシーに従っての扱いになりますが、何年分ものログをいつまでもDBに残しておくのではなく、例えば年1回ぐらいは別のDBやファイルにアーカイビングして、動作の安定化を考えたほうが望ましいと思います。

このように随時レスポンスが悪いというのは、データの肥大化などが原因でシステム全体が不安定になり限界が近い状態を指しているケースが殆どです。
こういった事態を発生させないために、導入当初からバックアップとクリーンアップの運用設計をきちんと行うことをお勧めします。
また、すでに発生している場合は早急にシステムを停止、今まであげたデータのクリーンアップを行うことが必要です。

次回は特定の時間帯のレスポンス悪化についてになります。


リンコム通信へのご意見はこちらからお願いします


リンコム ネクスト・総合情報ポータル
Copyright © 2002-2010 LINKcom corporation. All rights reserved.
グループウェアならリンコム ネクスト