受信データの更新が遅い
受信インターフェースが吐くログの受信完了時刻と、
データベース上の更新時刻に30分以上開きがある。
データベース更新プロセスのログはエラーが発生しない限り何も吐かない。
ということは、何か障害があって遅くなっているわけではないのだ。
それでも遅いのは何故か原因を追求せよとおっさりますか。
それはリソースが足りないからでわないのですか？
リソースが足りないと言い切る根拠を示せとおっさりますか。
それわ私達ソフト屋の仕事ですか？
おたくでやってくださいと言い切る事わ許されませんか？
ぼくわまちがてますか？
なまじ正常に更新されるだけにタチが悪い。
posted by kazufuruk at 9:56:00 午後
4 Comments:
なんの受信データの事か良くわかりませんが。。。メッセージキューに溜まってなければＤＢデーモンのところで溜まってるんでしょう。。。
ひょっとして稼動データですか？
いや、稼働データでは無いです。
稼動は以前のチューニング以来このようなトラブルはありません。
ぢつは大交代データです。
インターフェースのログはインフォメーションレベルで動いていたので、受信してワークファイルに吐いてDBプロセスに要求を投げるところまで綺麗に動いているのがログでわかりました。
しかし、DBプロセスのログはワーニングレベルで運用していたのでどこから何の要求をいつ受信していつ書き込んでいつコミットしたのかが一切わからない状況でした。テーブルの更新日付カラムのdate値から書かれた時間だけがわかる状況でした。
もう設計規模超えてるんでしょうね。接続機器が増えて稼働も増えてますし、ネットワーク監視のプロセスも毎度毎度かなりCPUを食うようになってしまったし。
ちなみに私は結局早朝監視はナシになって通常出勤しています。
設計規模という意味では、料金所数やブース数が増えていない限りはそんなに変わりないんでは？ただ、周りのシステム変更に伴い、ネットワーク監視プロセスなんかが重くなってしまったというのはわかります。
でも、それが原因を引き起こすほどすごい負荷になるとは想像できませんね。(その程度では）
毎朝発生するのかどうか、発生するとしたらそのときのマシン状態や他のマシンとの通信料を見なくては本当の原因はわかりませんね。
設計規模を超えてますというオトシドコロは結論急ぎすぎですか。結局対応に入ったメンバーは残って翌日の事象再現に備えたのですが、事象は再現しませんでした。 snoopやnetstat結果、vmstat結果、スタック状況やメッセージキューのステータスをを自動的に取得するスクリプトを仕込んで再現待ちとなりました。
バックアップの開始時刻を前倒ししていたり、事象が月初めに起きたというのも気になる所ではあります。
コメントを投稿
<< Home