今夜、１時間から２時間くらいこのブログ止めます。システムメンテナンスを行います。多分００時頃から２時頃まで作業すると思います。バックアップとったりして実施するので、実質作業は３０分から１時間くらいでしょうか。

上記みたいな画面は、出さずにやっちゃいます。そーりーぺーじ、切り替えるのがめんどくさいというだけ・・・（爆）

内容は、モジュールのバージョンアップとパフォーマンスチューニングを実施する予定です。ここ数日コロナで外に出られてないので、ブログのメンテナンスばかりやっています。

サーバ設定の方向性が決まったので、今日夜にでもやってしまいます。若干レスポンスがさらに上がればいいなと思っています。メモリーもかつかつでやっているので、もう少しメモリーチューニングやって、だめなら３GBまであげてしまおうと思っています。

それでは、よろしくお願いいたします。

The post 今夜2時間くらいこのブログ止めます first appeared on ～下町物語～.

Nginxパフォーマンスチューニング

たいした話ではないけど、nginxでphp-famを使ってPHPを処理させる構成は一般的ですが、時々下記の様なエラーが出る事がある。

readv() failed (104: Connection reset by peer) while reading upstream,

ちょっと数が多いわけじゃないけど、この辺りを発生しないようにパフォーマンスチューニングを施したいと思います。発生原因については、下記のホワイトボードの通り簡単な図を書いてみました。Visioとかでかけよって話もあるんだけど、ちょっと色々時間短縮の為、ごめんなさい汚い字でｗ

という事で、Nginxからphp-famの間が指定のDefault値待っても帰ってこない場合、Nginxさんは、タイムアウトとしていったんセッションを切ってしまうのです。その際どのような動きになるか？PHPで処理している画面はまっしろですね。そのサイトを見ている人とシステムの利用者様に取って見ると、あれ？出てこない！ってなるわけです。

要因について

処理を返せない要因は、色々あると思うのです。

1. PHPの複雑な処理によって時間がかかる（PHPコーディングの問題）
2. Access過多により応答を返せていない問題
3. ネットワークセッションに対する問題もあるかも（ただ、今回はNginxとphp-fpmはソケット通信）
4. CPU性能やメモリー不足でSwapなどしている様なスペックの問題
5. DB肥大化によって、query処理に時間がかかっている問題
6. そもそもworkerプロセス数の不足

今回発生した状況を考えて見ると、DBからAccessログを引っ張ってきて、再集計してグラフを書く処理を流したのですが、Accessログの肥大化によりquery処理に時間がかかって、Default値の10秒を超えてしまった為発生した模様です。

対応方針

とりあえず、処理に時間がかかる場合発生しているので、該当のセッションを維持出来る時間を延ばす方向。

設定変更(CentOS7 + Nginx + Php-fpm)

vi /etc/php-fpm.d/www.conf

○下記文字列を検索、Default値はコメントアウトされているが、おそらく10秒がDefault値で設定されている
　;pm.process_idle_timeout = 10s;
　pm.process_idle_timeout = 30s;　　このように修正する

○php.iniの修正
　vi /etc/php.ini
  max_execution_time = 30
  max_execution_time = 60　このように修正する

○php-fpmを再起動する
　systemctl restart php-fpm

動作確認して問題無い事を確認する。

The post ngixn パフォーマンスチューニング first appeared on ～下町物語～.