いつもパソコンの前

先日のServermans@VPSの問題発生後今度は「VPSサーバ管理ツール」のログインが不安定になりました。更には深夜時間帯に「MyDTI」の「契約中サービス」タグ中のプランの「確認・変更」がシステムエラーになりVPSの再起動もできない状態になってしまった。
（･･･以前、全ての設定をSSHでやっていたら、管理ツールにログインするたびに自動的になんかしら設定が変えられてしまい、しまいにはOS自体が起動しなくなると言う事態に陥ってしまい、泣く泣く初期化したため、設定は全て「VPSサーバ管理ツール」出行っています。状態のチェックや設定状況の確認なんかはその限りではないですけどね。）
サポートに泣き付くも、翌日昼には、「MyDTI]は元通りになっていたので再起動はできるようになりました。しかし不安定な状態は尚も続いているので、サーバー状況を確認する方法をとりあえず確立しないとな～･･･という感じです。

状況を整理すると、

まだ基本的な設定をしただけでこれからメールサーバーやデータベースなどを追加していこうとした矢先の問題なので、まともにサーバー自体動作してないんじゃないか？と疑ってしまうところですが、･･･結局自分で調べて何が原因か突き止めなさいということなんだけどね（～～）
仕様に関しては殆ど公開しない方向のようで、つかみどころがない。
唯一引き出せた調査の仕方が、「user_beancounters」により「failcnt」が出た場合は設定を見直す必要があるということ。
本来「何処に問題があるのか」を知りたいのにその方法は「サーバー管理してるぐらいだから判るでしょ？」と言うもの。設定もしていないのに最初っから内部でウニョウニョ動いているモノ達の存在や問題解決策までの責任を押し付けられてしまうって寸法。
楽しようと思って逆に苦労している気がします（～～）
これなら自宅サーバーの方がまだ安定動作期待できるし･･･等と言っていても仕方ないので、現状の確認をば･･･

縦軸は確認項目で、横軸は左から現在値-最大値-（何らかの）基準値-境界値-失敗それぞれのリソース値を示しています。
具体的な使い方としては、サーバーの設定変更や追加などを行う際に、その前後で「user_beancounters」の値を取得して追加した設定の妥当性を検証すると言う感じでしょうか？
「held」と「limit」を定期的に確認し予防することもできますし、
「failcnt」が発生した項目について、「maxheld」を確認し、「limit」に収めるためにどの程度設定値を絞るか検討することもあるでしょうか？

これから設定を開始するなら、問題を未然に回避できる方法として有効です。
それ以降の調査については、何か動かして調査させるようなことしてたら本末転倒になりそうなので、netstatなどLinuxコマンドで地道に調べるしかなさそうですね。

ちなみにこれはPostgreSQLサーバーを起動したあとに取得した値です。それ以前では「failcnt」は設定されていなかったので、DBはMySQLだけで我慢しましょう･･･と言ういうことでしょうね。
もちろん、PostgreSQLを停止したら、それ以上「failcnt」が増えることはありませんでしたが、下には戻りません。
「failcnt」の初期化には、「サーバーの再起動で対応を行ってください」とのことでした。
そんなことしてたら、しょっちゅうサーバー再起動を繰り返すことになりそうですが、ま、その辺りは適宜に対応と言うことで･･･。
※項目の詳細などは「user_beancounters」で検索すると見つかると思いますのでそちらをご参照ください。