更新日:2023年11月17日
11月13日に
データベースをアップグレードして負荷対策をしたのですが
改善せずに
WEBサーバー側で502、503のエラーが発生して接続できない事が
多くなってしまいました。
-
うまさくの接続障害が発生しているのでデータベースのグレードアップしてみた
うまさく運用トップ 更新日:2023年11月13日 8月にアクセス負荷対策として サーバー増設したのですが 最近になって、アクセス出来ないエラーが発生している。 その原因と対策をまとめまし ...
502(Bad Gateway)エラーとは
目的のサーバーが正しく作動しておらず
リクエストが拒否されたことを示す。
503(Service Unavailable)エラーとは
Webサーバーへの負担が大きすぎることで停止してしまい
閲覧できなくなってしまったときに表示されるエラーです。
スマホやパソコンで見ると
真っ白な画面に上記のメッセージが出る時がありますが
サーバーではこのような障害が起きていることになります。
どんな状況
大人気のうまさくセレクトのボタンを押すと
WEB1もしくはWEB2を通して、DB1にアクセスして
過去の当選情報を検索して
出現傾向を分析して
数字を生成しています。
当初は、このDB1の負荷が増大して
WEB1とWEB2への応答に答えられずに
障害が発生していたように見えてました。
DB1の状態を見てみると
こんな状態で
LoadAvarageがCPUのコア数の6※を
遙かに上回っていて溺れそうな状態です(😀
※勘違いして以前の記事ではCPUコア5で記載していました。失礼しました。
この状態が長く続くと
WEB1とWEB2で
502、503のエラーが発生していました。
利用者の皆さんからは
急に真っ白な画面で変な英語の文字が出てくるイメージです。
試してみたこと
DB1側は先日、postgreSQL9.4からpostgreSQL14.10に
アップグレードしたばかりなので
今回はWEB1とWEB2側の設定を見直すことにしました。
結構負荷が掛かっていると思っていて
DBをアップグレードすれば少しは改善すると思っていました。
それは甘かった...
2台ともApacheで
php-fpmで動作しているので
php-fpmも設定を確認してみました。
php-fpm設定
プロセス数の制御(static/dynamic)
起動プロセス数の制御方法は2つ。
設定した数を常に起動しておく方法(static)
プロセスの起動に伴うオーバーヘッドがないという利点がある。
ただし、最大同時接続可能数を上げようとすればするほど常に多くメモリを必要とするようになるという短所もある。
起動数を動的に変更する方法(dynamic)
通常時はある程度の数プロセスを起動しておき
同時接続数が増え、プロセス数が足りなくなった時だけ
設定した範囲でプロセスが追加で起動されます。
ネットで調べているとstaticの方が
メモリに対してCPUの処理能力が低いサーバに向いている..
ということみたいです。
CPU 仮想6Core
メモリ 8GB
SSD 400GB
の構成です。
DB1のスペックも同じです。
スペック的にはそんなには低くはないのですが
dynamicだと、プロセスが増えていくので
DB1への負荷増大にも影響しているのでないかということで
staticに変更しました。
プロセス数の最大起動数(pm.max_children)
同時に起動するプロセスの最大数です。
この数値が、サーバーの同時接続可能数を決定します。
よくよく調べてみると
CPUのコア数以上のプロセスを起動させても
意味がないようなので
CPUコア数の6に変更しました。
プロセスを再起動する処理リクエスト数(pm.max_requests)
多くのリクエストを処理すると
プロセスで使用するメモリがどんどん増大していくことがあります。
これを防ぐために
一定数リクエストを処理したプロセスを自動で再起動させることができます。
この設定では、そのリクエスト数を指定します。
各プロセスが1日に処理するリクエスト数は
1日のリクエスト(PV)数 ÷ pm.max_children
(dynamic の場合、1日のリクエスト(PV)数 ÷ pm.max_spare_servers)
1回のページ閲覧に対しては
細かなリクエストが沢山あるので80万リクエストぐらいはありそう。
さらに、うまさくセレクトの番号生成リクエストが
1日あたり、10万回リクエストになります。
合計すると...100万回リクエストに近い..
それを2台のWEBサーバーで処理するので
単純に2で割ると
1台あたりは9万リクエスト
早速計算してみると..
90,000 ÷ 2,500 = 36
1日あたり36回再起動されることになる。
この値が多いか少ないかは
わからないので
とりあえず、値は変更せずに
2,500で運営してみます。
その他の設定値
以下の設定値は
staticの場合には関係ないので特に変更なし
・アイドル状態のプロセス最大起動数(pm.max_spare_servers)
・アイドル状態のプロセス最小起動数(pm.min_spare_servers)
・親プロセス起動時の子プロセス起動数(pm.start_servers)
設定を変更して
php-fpmを再起動しました。
効果は?
設定直後はDB1が不安定になりましたが
データベースを再起動した後は
安定しています。
LoadAvarageも0.xxです。
昨日の昼、購入締め切り時間の18時前後でも
3まで上がってぐらいです。
今のところストレスもなく稼働している感じがします。
この状態でしばらく様子を見ます。
単に数字を表示しているだけではなく
過去の情報を参照して
オリジナルのプログラムで処理されていることが
理解してもらえたかと思います。
だからといって
的中率があがるわけでもないんですよね(汗
うまさくセレクトの待ち時間
ここ最近の接続障害で
うまさくセレクトの
ローディングを0.5秒から1秒に変更していました。
詳しく説明すると
うまさくセレクトのボタンを押すと
番号生成するまで
ローディングといって画面が薄く黒くなり
ぐるぐると丸い画像が回ります。
なぜ、このような対応をしているかといと
連打が出来てしまうと
サーバーの負荷が上がってしまうので
連打を出来ないようにして
少しでも時間の間隔を設けるための機能です。
今回の対応で
負荷問題が改善したように感じるので
とりあえずは0.5秒に戻しておきました。
締め切り間際でボタンを押されている方は
1秒でも遅いと感じると思うので(😀
まじめに取り組んでますので
今後もよろしくお願いします。
サポート支援金の使い道
サポートして頂いたお金は
毎月のサーバー費用
プログラム改修費用
日々の運用費用
に使わせていただきます。
利用者が増えてサーバーの追加や運用作業が増加しており
広告収入だけでは厳しい状況です。
ご支援頂けると非常に助かります。
サポートは100円から5万円の範囲で可能です。
※月額(サブスク)ではなく、1回きりの決済です。
高額当選してもう少し寄付していただける方は
お問合せから連絡ください😀
-
うまさくを気に入ってくれたら支援をお願いします!
ロト・ナンバーズ予想トップ うまさくは全て無料で運営しています。 今のところは有料にするつもりはありません。 ご安心してください! 現在は、広告を貼ることで 広告収入でなんとか維持していま ...
続きを見る
うまさくセレクト