スポンサーリンク

根拠がないなぁ

公式の会議の場で毎分700通のメールを捌けると公言されたウチの会社のメールサーバー。 以前管理していたボクの感触では即時性を要求するのなら100通程度が限界だと思っていたので驚いた。 んで、試しに今日の真っ昼間に空メールを外部のサーバーに1280通送ってみた。 外部のサーバーでは転送設定がかかっていて、送られたメールは会社に戻ってくるので遅延量が判るようにしていたのだが…
1280通はメーラーから約3分でサーバーへ転送された。 だが、それからが大変だった。 約半分の600通が受信完了するまでに30分以上かかってしまった上に、そのうちサーバーが音を上げてしまったのである。 結局、サーバーは再起動され正常に戻ったのだが、それから残りの分を受信してみると1280通全てを処理しきるまでに1時間以上かかっていた。(再起動前までにサーバーには送り返されていた)
真っ昼間だったから社内の利用が多かったりとか、ウェブアクセスが多くてプロキシとしての動作でプロセスを喰われていたりとか、バックアップ中だったのでプロセスを喰われていたりとかしていたので多少の遅延はあるだろうとは思っていたけど… 受信したメールのヘッダを確認すると1秒間に2〜3通の処理しかされていなかったようだ。 単純に計算すると、毎分200通程度と言うことになる。 ただ、ウチのメールサーバーから出ていく段階で約5分程度の遅延が発生して間引かれていたので、実質的にどうなのかというのはハッキリとは判らない状況。
でも、空メールでこの性能では真っ当なメールで毎分700通も遅滞なく処理をするのは実質的に不可能ではないかと推測できる。 根拠のない数字が変に一人歩きすることに疑問を感じているのだが、ウチの情報システム部門は本当に大丈夫なのかと心配になってくる。
ちなみに、今日の障害に関しては原因追及が出来たのかどうかよく判らないが、ボクのところへの問い合わせはなかった。 そして、遅延発生から復旧までに2時間を要していた。 何故かというと、一番パワーを喰うバックアップ作業を停止させなかったためである。 担当者が惰性で仕事をしているために切り分けなんて出来るわけもないし、もちろん停止の仕方も知らないし、UNIXサーバーなのにUNIXのコマンドを知らなかったというオチが付いてしまったからだ。 あ〜、GW前にあれほど勉強しろと言ったのになぁ…
早くクビ切った方が良いよ。 マジで。 あんた方、ナメられてるわ。

working
スポンサーリンク
本館「五十オヤジの戯言日記」

コメント

タイトルとURLをコピーしました