隣のビルに勤務していると思われる技術チームがほとんど丸一日を要してようやくメールサーバの復旧を終えたようだ。とりあえず「お疲れ様でした！」と言いたい。何なら今朝スタバでもらった二杯目100円で飲めるレシートをあげてもいいくらいだ。
きっと当事者達はプチ「プロジェクトX」か「24」みたいな修羅場を味わったに違いない。でも月1,680円で会社の基幹業務に利用するにはタダみたいなサービスなので、僕は彼らに文句は言わない。
これほど時間がかかった原因はおそらくとても単純で、クラウド上にたまった大量のメールBOXファイルの"コピー"に時間を要したことだと思う。
最近は"メールをサーバに残す"がデフォだから1アカウントあたり数千数万ファイル溜まってるなんてざらでしょう。ファイルコピーの時間って容量はもちろんのこと、ファイル数が多いと"オーバーヘッド"がバカにならないんですよね。だから大量のファイルが存在するサーバに万が一障害があった場合、復元にとても時間がかかる。
この解決にはメールデータをデータベース化して連続したアーカイブとして取り扱うなど、根本的なメールシステムの設計見直しが必要になるはずです。
ちなみに少し前にWebA****で発生した障害では、結局クラスタファイルシステムの復旧が出来ずにクラウドサービスをやめちゃうくらい深刻な事態になった。クラウドも決して夢のソリューションではないってことですね。
カテゴリ ： サーバー
メモリが足りない？それでいいんです
メモリの管理はサーバ運用における重要なファクターとなっており、サーバが高負荷になったりアプリケーションの不具合があると真っ先に「メモリの残量不足では？」という懸念を抱きます。
管理者がメモリ残量を知るためのLinuxコマンドはtopやfreeがあり、以下のようにいくつかの指標があります。
- 物理メモリ(total)
- 使用メモリ(Used)
- 未使用メモリ(Free)
- Swapメモリ(Swap)
- キャッシュメモリ(Cached)
この中で未使用メモリが不足していたりSwapメモリの使用量が多いとメモリが不足していると判断しがちですが、そうではない場合があります。
OSやアプリケーション（ミドルウェア）はプログラムを展開したりデータ処理を行うためにメモリ領域を必要としますが、処理上一時的に必要なメモリはキャッシュメモリと区別されます。OSの重要な役割として 一度読み込まれたファイルデータは、またすぐに使用される可能性が高いので自動的にメモリ上にキャッシュしておいてくれます。したがってメモリ残が見かけ上は少なくてもキャッシュメモリとして有効に利用されている可能性があるのです。
またSwapメモリですが、その特性上これが発生していること自体を問題視する判断も実は早計となります。OSは各プロセスが、使用頻度が低いつまり必要が無いのに確保したメモリを一定時間経ったらSwap領域に退避してくれる役割もあります。この"すぐには必要とされないメモリ"は上記のキャッシュメモリより優先順位が低い設計になっているようなのでI/O速度が遅いHDDのSwap領域に追いやられます。PCでも久しぶりに操作したソフトが最初やたら重い状態になったりするのは一旦HDDに退避されたメモリが再度実メモリに展開されるロスの為です。
では何をもって"メモリ不足"と判断すればいいのかということになりますが、これはリアルタイムのSwap（ページング）状況を確認するしかありません。
これを観測するにはvmstatというコマンドがあり以下のようにリアルタイムのサーバリソース状況が確認できます。
$ vmstat 2
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 14220 115632 139708 89896 0 1 2 47 0 0 0 0 100 0 0
0 0 14220 115632 139708 89920 0 0 0 68 1002 35 0 0 100 0 0
0 0 14220 115632 139708 89920 0 0 0 0 996 12 0 0 100 0 0
0 0 14220 115632 139708 89920 0 0 0 14 1001 16 0 0 100 0 0
0 0 14220 115632 139708 89920 0 0 0 0 990 13 0 0 100 0 0
0 0 14220 115632 139708 89920 0 0 0 0 994 13 0 0 100 0 0
この中で注目すべきはsi(スワップイン)とso(スワップアウト)の値です。
こちらの例は実メモリが不足してSwapのI/Oが発生している状態です。このような状態になると速度の遅いHDDへのアクセスが頻発し、サービスへの影響も出ているはずです。
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 8 4028 24016 8900 309828 0 0 4314 926 2710 2445 10 21 31 38
1 1 4036 62672 3268 261384 0 6 4758 872 3037 2861 11 29 26 33
0 1 9920 61368 9248 256728 0 2942 4268 3012 2852 2721 7 31 31 32
0 2 11508 58880 15140 257020 260 794 3322 1596 2202 1955 4 9 46 42
1 0 11836 53304 17472 257184 806 164 2478 638 1936 1450 17 5 44 34
2 0 11836 60528 17692 257684 160 0 402 30 1439 772 4 23 67 6
0 0 11836 58928 17880 258152 192 0 502 532 1322 674 8 35 54 3
0 0 11836 62320 17916 258452 352 0 452 0 1493 799 2 1 94 3
まとめると
- メモリが不足しているように見えても、キャッシュが非常に有効に働いて良好な運用状態の場合がある。
- Swapメモリの総量値にはほとんど意味はない。
- 問題視すべきはリアルタイムのI/O発生で、これが発生している場合は致命的なリソース不足となっていることが断言できる。
サーバの時刻設定は何よりも大事
コンピュータの時刻をNTPサーバに問い合わせて自動調整する仕組みは、サーバを初めPC・携帯等の機器でも一般的になってきました。
ちなみにサーバやPCのクロック（時刻）はハードクロックとシステムクロックの二種類ありますが、NTPサーバで自動同期を行ってるのはシステムクロックとなります。しかしこのシステムクロックだけを同期していても不十分な場合があります。
その理由は、万が一サーバに異常が発生して再起動が必要になった場合、OSはブート時に"ハードクロック"を参照してシステムクロックを設定します。この際にハードクロックの時刻がずれていた場合、一時的ですがシステムの時刻が大幅にずれてしまう可能性があります。
システムの時刻ずれがWebサービスやデータベースに及ぼす影響を想像してみてください。
オークションサイトではどうでしょうか？
メールシステムはどうでしょうか？
バッチ処理システムはどうでしょうか？
放送システムはどうでしょうか？
FAシステムはどうでしょうか？
プラント制御システムはどうでしょうか？
勤怠管理システムはどうでしょうか？
いずれも想像したくないデータの不整合障害に発展します。
したがって、サーバ再起動と同時に正確な時刻が設定されるようにするには、NTPでシステムクロックを同期した後、ハードクロックへも常に正確な時刻を設定しておく必要があります。こちらは定期的にcronで実行を行えばよいでしょう。
ちなみにハードクロックを確認・設定するコマンドは以下のようなものがあります。
/sbin/hwclock
/sbin/clock
個人的には「時刻がずれたコンピュータはコンピュータではない」と思っています。そのことにピンとこない人は IT産業には向いていないんじゃないかとさえ思います。
チェックをおススメします
