以前、Sendmail で受信できても送信できない問題を何とかしました!!! | oki2a24 で次のような現象が発生し、頭を抱えましたけれども、単に sendmail を再起動しましたら直った、ということがございました。
- sendmail で受信はできるのに送信はできない。
- メールの再送信はしない。
- sendmail のプロセスは生きている。
- dovecot にアクセスしてクライアントへメール受信させることもできる。
- 送信できなかった時のエラーメールを見ると、「host not found」とある。
- /var/log/maillog を見ると、メール送信時に「stat=Host unknown (Name server: example.com.: host not found)」というエラーが出る。
- sendmail を再起動すると送信ができるようになる。
この原因として、ようやく納得行く回答に行き当たることができました!
- オープンファイル(numfile)のリソース割り当てエラーが頻発した。
- そのため、sendmail のホスト参照機能に不具合が発生。
- よって、受信はできても送信はできなくなった。
なお、自力で調査したわけではなく、次のページにすべて掲載されておりました。サーバホスティングのお仕事の大変さが垣間見えるようですわ♪
しかも、リソース割り当てエラーが頻発しているさまを確かめられるコマンドの解説付きですの!
- /proc/user_beancounters の numfile 行の failcnt を確認し、ゼロでなければ、これが原因で host not found エラーが発生している。
とてもスッキリいたしました♪それにしてもこの /proc/user_beancounters、一体何者なのかしら?整理いたしますの。
/proc/user_beancounters はリアルタイムのリソース消費量を表示する
22:05 分に確認しましたら、ファイルのタイムスタンプも 22:05 分でしたの。
[root@oki2a24 ~]# ll /proc/user_beancounters -r-------- 1 root root 0 Dec 11 22:05 /proc/user_beancounters
/proc/user_beancounters の具体的な例
22:05 分の時のリソース消費量がこちらです。ServersMan@VPS Entry プランですの。ちなみに、failcnt はすべてゼロ!リソース不足は発生しておらず、ほっと一安心ですわ。
[root@oki2a24 ~]# cat /proc/user_beancounters Version: 2.5 uid resource held maxheld barrier limit failcnt 43287: kmemsize 6457561 8370195 35565240 36830248 0 lockedpages 0 4 256 256 0 privvmpages 89593 135946 524288 557056 0 shmpages 768 1453 65536 65536 0 dummy 0 0 0 0 0 numproc 41 53 240 240 0 physpages 41693 57164 0 9223372036854775807 0 vmguarpages 0 0 262144 262144 0 oomguarpages 41694 57164 26112 9223372036854775807 0 numtcpsock 12 47 360 360 0 numflock 5 10 188 206 0 numpty 1 2 8 8 0 numsiginfo 0 6 128 128 0 tcpsndbuf 190128 740960 1720320 2703360 0 tcprcvbuf 192232 458424 1720320 2703360 0 othersockbuf 9312 565280 1126080 2097152 0 dgramrcvbuf 0 20952 262144 262144 0 numothersock 14 37 360 360 0 dcachesize 436635 564479 6819840 7249920 0 numfile 1065 1461 9312 9312 0 dummy 0 0 0 0 0 dummy 0 0 0 0 0 dummy 0 0 0 0 0 numiptent 30 30 256 256 0 [root@oki2a24 ~]#
/proc/user_beancounters の列(タテ)の項目の意味
resource、held、maxheld、barrier、limit、failcnt の意味をメモします。今回は failcnt という失敗回数が問題でしたわね。これがゼロであれば、健全な問題のない状態、と言えますの。
No | 項目名 | 意味 |
1 | resource | 各種リソース名 |
2 | held | リアルタイムなリソース使用量 |
3 | maxheld | 過去のリソース使用量の最大値 |
4 | barrier | 割り当て値 |
5 | limit | 上限(サーバー内のスペック) |
6 | failcnt | 上限を超えた回数 |
/proc/user_beancounters の行(ヨコ)の項目の意味
続いて、各行の項目の意味ですの。今回問題となりましたのは、numfile ですわ。同時に開くことの出来るファイル数、という理解で良さそうですの。
No | 項目名 | 由来!? | パラメータ種類 | 意味 |
1 | kmemsize | kernel memory size | セカンダリ | 特定のVPS プロセスのため内部カーネル構造へ割り当てられる、スワップ不可のカーネルメモリ。 |
2 | lockedpages | locked pages | 補助 | スワップアウトが許されていないメモリ(mlock()システムコールでロックされている)、ページ単位 |
3 | privvmpages | private vm pages | セカンダリ | アプリケーションにより割り当てられるプライベート(または潜在的プライベート)メモリのサイズ。常に複数のアプリケーション間で共用されるメモリはこのリソースパラメータには含まれていません |
4 | shmpages | shared memory pages | 補助 | 特定のVPS のプロセスにより割り当てられる共用メモリの合計サイズ(IPC、共用アノニマスマッピング、tmpfs オブジェクトを含む)、ページ単位。 |
5 | numproc | number of processes | プライマリ | VPS が作成可能なプロセスとスレッドの最大数 |
6 | physpages | Total number of RAM pages used by processes in a container. | 補助 | VPS プロセスが使用するRAMの合計サイズ。このパラメータは、現在はアカウンティング専用です。VPS ごとのRAM 使用を示します。複数の異なるVPS に使用されるメモリページ(共用ライブラリのマッピングなど)。ページに対応する小数部のみが各VPSにチャージされます。全てのVPS のphyspages 使用の合計は、システム内で全てのアカウントユーザーに使用されるページの合計に対応します。 |
7 | vmguarpages | Memory allocation guarantee. | プライマリ | メ モリ割り当て保証、ページ単位(1 ページ4KB)。VPS アプリケーションは追加メモリprivvmpages(補助パラメータの項参照)が設定されたvmguarpages パラメータのバリアを超えない範囲で割り当てることを保証されています。バリアを超えると追加メモリの割り当ては保証されず、メモリ不足の際には割り当て されない可能性があります。 |
8 | oomguarpages | out-of-memory guarantee pages | セカンダリ | メモリ外保証、ページ単位(1 ページ4KB)。VPS プロセスは現在のメモリ消費量(物理メモリとスワップメモリを含む)がoomguarpages バリアに達しない限りは、深刻なメモリ不足が生じても停止しません。 |
9 | numtcpsock | number of TCP sockets | プライマリ | TCP 以外のソケットの数。ローカル(UNIX ドメイン)ソケットはシステム内の通信に使用されます。UDP ソケットは、ドメインネーム サービス(DNS)のクエリなどに使用されます。UDPおよびその他ソケットで使用されます。 |
10 | numflock | Number of file locks. | 補助 | 全てのVPS プロセスが作成するファイルロックの数 |
11 | numpty | Number of pseudo-terminals. | 補助 | 擬似ターミナルの数。ssh セッション、screen アプリケーションまたはxterm アプリケーションなど。 |
12 | numsiginfo | Number of siginfo structures. | 補助 | siginfo 構造の数(基本的に、このパラータはシグナルデリバリキューのサイズを制限する) |
13 | tcpsndbuf | tcp send buffers | セカンダリ | TCP ソケットへの送信バッファの合計サイズ。アプリケーションからTCP ソケットへ送られるデータへのカーネルメモリ割り当て量です。リモートサイドに応答される前の状態です |
14 | tcprcvbuf | tcp recive buffers | セカンダリ | TCP ソケットの受信バッファの合計サイズ。リモートサイドで受信されるデータへのカーネルメモリ割り当て量です。ローカルアプリケーションでは読み込まれていない状態です。 |
15 | othersockbuf | other sockets buffers | セカンダリ | UNIX ドメインソケットバッファ、UDP、およびその他データグラムプロトコル送信バッファの合計サイズ。 |
16 | dgramrcvbuf | datagram recieve buffers | セカンダリ | UDP およびその他データグラムプロトコルの受信バッファの合計サイズ |
17 | numothersock | number of other types of sockets | プライマリ | TCP 以外のソケットの数。ローカル(UNIX ドメイン)ソケットはシステム内の通信に使用されます。UDP ソケットは、ドメインネーム サービス(DNS)のクエリなどに使用されます。UDPおよびその他ソケットで使用されます。 |
18 | dcachesize | dentry cache size | 補助 | メモリでロックされているdentry およびi ノード構造の合計サイズ |
19 | numfile | Number of open files. | 補助 | 全てのVPS プロセスが開くファイルの数 |
おわりに
/proc/user_beancounters の説明としてはこちらのページが最も充実していると感じましたわ。ありがとう存じます♪ただ、すべて英語で難しいですの!
また、以前の件と、今回のお話は、VPS ならではのようですの。次のページにまとめられておりました。「VPS でエラーのときはリソースを確認!」素晴らしい観点です。ありがとう存じます。
メール送信失敗では、エラーメッセージに「通信ソケットがオープンできない」としか表示されません。
通常はネットワークがらみか、postfixのインストール失敗を疑って原因を探りますが、バーチャルサーバの場合は、最初にサーバリソースを疑うべきでしょう。
バーチャルサーバでサービスを運用していると、ついついバーチャルであることを忘れがちなので、いつもリソースを確認するようにしよう。
(私もバーチャルサーバであることを忘れて、無駄な時間を費やしてしまった。)
また、各行の項目情報は、先の続きのページの内容の順番を入れ替えたものです。孫引きとなってしまい、調べ物をする姿勢としてはよくありません。反省しておりますの><。
とあれ、これでまた VPS について勉強になりましたわ♪嬉しいですの♪
以上です。