あるブランドのゲームにつけられた得点の中央値を求める

SELECT b.id
     , b.brandname
     , b.kind
     , b.lost
     , PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY tokuten) AS median
     , cast ( STDDEV(tokuten) AS INTEGER ) AS stddev
     , count(tokuten) AS count
  FROM userreview u
 INNER JOIN gamelist g
         ON u.game = g.id
 INNER JOIN brandlist b
         ON g.brandname = b.id
 WHERE b.id = 1
 GROUP BY b.id
        , b.brandname
        , b.kind
        , b.lost;
 id | brandname |    kind     | lost | median | stddev | count
----+-----------+-------------+------+--------+--------+-------
  1 | âge(age)  | CORPORATION | f    |     81 |     15 | 13807
PERCENTILE_CONT関数について
順序集合集約関数というものが9.4のときに追加されていて、中央値をたった一行で求められるようになっていました…(以前はウインドウ関数を使う必要がありました。それ以前は、とてもいろいろ書く必要がありました)

(28)No space left on device: AH00023: Couldn't create the proxy mutex

ErogameScapeは2019/07/15時点で以下のApacheが動いています。

Server Version: Apache/2.4.34 (Red Hat) OpenSSL/1.0.1e-fips
Server MPM: event

ちゃんとした契機が不明ですが、Apacheの応答がなくなりました。
通常のpsコマンドの状態は
[ap2@erogamescape13 ~]$ ps ax | grep http
 1489 ?        S      0:01 tail -n0 -F /var/log/httpd/error_log
15179 ?        Ss     0:00 /opt/rh/httpd24/root/usr/sbin/httpd
15183 ?        S      0:00 /opt/rh/httpd24/root/usr/sbin/httpd
15184 ?        Sl     0:00 /opt/rh/httpd24/root/usr/sbin/httpd
17530 pts/1    S+     0:00 grep http
なのですが、事象発生時は
[ap2@erogamescape13 ~]$ ps ax | grep http
1489 ?        S      0:01 tail -n0 -F /var/log/httpd/error_log
10096 ?        S      0:00 /opt/rh/httpd24/root/usr/sbin/httpd
26194 pts/1    S+     0:00 grep http
となってhttpdのプロセスが足りませんでした。
Apacheにはcronで定期的にアクセス出来るかを監視していて、アクセス出来なかった場合、具体的にはトップページの80番ポートでアクセスして応答がなかった場合、httpdを再起動することにしています。
そのcronは動いているのですが、httpdの再起動に失敗しているようでした。

試しに手動でhttpdを再起動してもNGでした。
[root@erogamescape13 ~]# /sbin/service httpd24-httpd stop
httpd を停止中:                                            [  OK  ]

[root@erogamescape13 ~]# /sbin/service httpd24-httpd start
httpd を起動中:                                            [  OK  ]

[root@erogamescape13 ~]# ps ax | grep http
1489 ?        S      0:01 tail -n0 -F /var/log/httpd/error_log
10096 ?        S      0:00 /opt/rh/httpd24/root/usr/sbin/httpd
27178 pts/1    S+     0:00 grep http
試しに10096をKILLして再起動すればいいかな…と思ってやってみましたが、httpdのプロセスを殺すことが出来ただけで、httpdの起動はNGでした。
[root@erogamescape13 ~]# kill -KILL 10096

[root@erogamescape13 ~]# ps ax | grep http
1489 ?        S      0:01 tail -n0 -F /var/log/httpd/error_log
27260 pts/1    S+     0:00 grep http

[root@erogamescape13 ~]# /sbin/service httpd24-httpd start
httpd を起動中:                                            [  OK  ]
※OKになっていますが、実際はhttpdは起動していません。

Apacheのerror_logを確認したところ、同じようなメッセージが、ばーっと出ていました。
[root@erogamescape13 ~]# cat /var/log/httpd24/error_log
[Mon Jul 15 08:00:02.469050 2019] [core:emerg] [pid 17663:tid 140413539801056] (28)No space left on device: AH00023: Couldn't create the proxy mutex
[Mon Jul 15 08:00:02.469161 2019] [proxy:crit] [pid 17663:tid 140413539801056] (28)No space left on device: AH02478: failed to create proxy mutex
[Mon Jul 15 08:00:02.469170 2019] [:emerg] [pid 17663:tid 140413539801056] AH00020: Configuration Failed, exiting
[Mon Jul 15 08:05:02.848324 2019] [core:emerg] [pid 19318:tid 140124209342432] (28)No space left on device: AH00023: Couldn't create the proxy mutex
[Mon Jul 15 08:05:02.848454 2019] [proxy:crit] [pid 19318:tid 140124209342432] (28)No space left on device: AH02478: failed to create proxy mutex
[Mon Jul 15 08:05:02.848466 2019] [:emerg] [pid 19318:tid 140124209342432] AH00020: Configuration Failed, exiting
Apacheの状態を監視してNGだったら再起動するスクリプトが起動したタイミング上記メッセージが出ているので、Apacheを起動する際に上記エラーを吐いて失敗しているようです。
エラーメッセージをgoogleで検索すると以下の記事がひっかかりました。


記事によると「セマフォが限界値に達してしまったために新しいセマフォを使ってアプリケーションを起動することができなくなってしまった時にこのエラーが出てくる」そうでした。
ipcs -sでセマフォの確認ができるそうなのでコマンドを実行しました。
[root@erogamescape13 ~]# ipcs -s

------ セマフォ配列 --------
キー     semid      所有者  権限     nsems
0x00000000 0          root       600        1
0x00000000 32769      root       600        1
0x00000000 10944514   apache     600        1
0x00000000 11599875   apache     600        1
0x00000000 11632644   apache     600        1
0x00000000 13205509   apache     600        1
0x00000000 95780870   apache     600        1
0x00000000 95813639   apache     600        1
0x00000000 95846408   apache     600        1
0x00000000 76611593   pgpool     600        6
0x00000000 95944714   apache     600        1
0x00000000 95977483   apache     600        1
以下いっぱい
なんらかの異常でapacheがセマフォを使い切っている模様でした。
apacheが使用しているセマフォを消して、apacheを起動したら、無事起動できました。
[root@erogamescape13 ~]# for i in `ipcs -s | awk '/apache/ {print $2}'`; do (ipcrm -s $i); done
[root@erogamescape13 ~]# ipcs -s

------ セマフォ配列 --------
キー     semid      所有者  権限     nsems
0x00000000 0          root       600        1
0x00000000 32769      root       600        1
0x00000000 76611593   pgpool     600        6

[root@erogamescape13 ~]# /sbin/service httpd24-httpd start
httpd を起動中:                                            [  OK  ]
[root@erogamescape13 ~]# ps ax | grep http
1489 ?        S      0:01 tail -n0 -F /var/log/httpd/error_log
28085 ?        Ss     0:00 /opt/rh/httpd24/root/usr/sbin/httpd
28087 ?        S      0:00 /opt/rh/httpd24/root/usr/sbin/httpd
28088 ?        Sl     0:00 /opt/rh/httpd24/root/usr/sbin/httpd
28360 pts/1    S+     0:00 grep http
この問題が発生したときに備えてApacheを監視するスクリプトにApacheを再起動する前にapacheのセマフォを消すコマンドを追加しました。

Apacheがなぜこのような状態になったのかは分からないです。
契機は、同じサーバーマシンに入っているPostgreSQLを再起動したこと…問題が起こった時に実施したことがそれくらいなのですが、PostgreSQLを再起動したらこの事象が起きるのか、まったくわかりません。








phpだけ404の場合に自分で設定した404用のページが表示されず「File not found. 」とだけ表示される

Apache + php-fpmの環境の話題です。

ErogameScapeではファイルが存在しないURLが指定された場合、ルートディレクトリのindex.phpを表示するように設定しています。
ErrorDocument 404 /~ap2/index.php
PHPをApacheのモジュールとして動かしていた場合には問題が発生していなかったのですが、PHPをCGIとして動作させた場合に以下の問題が発生しました。

phpだけ404の場合に自分で設定した404用のページが表示されず「File not found. 」とだけ表示される。

https://erogamescape.dyndns.org/~ap2/ero/toukei_kaiseki/a
とすると(aは存在しないです)、自分が設定した404用のページが表示されるのに
https://erogamescape.dyndns.org/~ap2/ero/toukei_kaiseki/a.php
とすると(a.phpも存在しないです)、「File not found. 」とだけ表示されてます。
404
php-fpmを動かすのに、ErogameScapeではunixドメインソケット経由で動かしているので設定ファイルに以下の記述をしています。
<FilesMatch \.php$>
    SetHandler proxy:fcgi://php-fpm
</FilesMatch>
apacheが受けた要求をphp-fpmに渡して、php-fpmが処理した結果をapacheが受けて、apacheがクライアントに返却します。
a.phpの要求を受けたapacheはphp-fpmに渡して、php-fpmはa.phpがないので、「File not found. 」をapacheに返し、apacheはそれを見たそのままクライアントに返却するので、自分が設定した404用のページが表示されません。

php-fpmが返してきた「File not found. 」(404)をapacheが上書きする設定が以下のディレクティブです。

設定ファイルに以下の記述すると自分が設定した404用のページを表示してくれます。
ProxyErrorOverride on
※php-fpmがどうやって「File not found. 」という文字列を返しているのかは分かりませんでした…返す文字列を設定しているっぽいファイルは見つけられなかったのでソースに埋め込まれているのでしょうか…



wal_keep_segments

wal_keep_segmentsはリンク先のマニュアルに書いてある通り、
ストリーミングレプリケーションにおいて、スタンバイサーバが過去のファイルセグメントを取得する必要がある場合に備え、pg_walディレクトリに保持しておくファイルセグメント数の最小値を指定します。
です。デフォルトは0です。0だからpg_walディレクトリの配下に何も生成されないかというとそうではなく、最低min_wal_sizeの設定だけpg_walファイルが生成されます。

例えば以下のようなになります。
[root@erogamescape14 pg_wal]# ls -lh
合計 97M
-rw------- 1 postgres postgres  386  5月 30 23:22 2019 0000000A.history
-rw------- 1 postgres postgres  431  6月 26 09:06 2019 0000000B.history
-rw------- 1 postgres postgres  16M  6月 26 10:00 2019 0000000B00000013000000D7
-rw------- 1 postgres postgres  16M  6月 26 10:02 2019 0000000B00000013000000D8
-rw------- 1 postgres postgres  16M  6月 26 09:06 2019 0000000B00000013000000D9
-rw------- 1 postgres postgres  16M  6月 26 09:07 2019 0000000B00000013000000DA
-rw------- 1 postgres postgres  16M  6月 26 09:30 2019 0000000B00000013000000DB
-rw------- 1 postgres postgres  16M  6月 26 09:30 2019 0000000B00000013000000DC
drwx------ 2 postgres postgres 4.0K  6月 26 09:07 2019 archive_status
ErogameScapeではストリーミングレプリケーションを使用しており、PostgreSQLのマイナーバージョンアップの際にはレプリケーションスロットを使用するのでwal_keep_segmentsは0にしていました。

ところが手順を間違えて、primaryのPostgreSQLにレプリケーションスロットを作る前に、standbyのPostgreSQLを止めてしまい、yum updateしている際に6つのWALファイルが全部新しくなってしまった結果、standbyを組み込もうとした際に「もうWALファイルがありません」的なメッセージがでてしまって、組み込めませんでした…
泣く泣く、pg_basebackupからスタートしました。

ErogameScapeでそんなに更新があるのか?と思うかもしれませんが(私もそう思っていました)、統計用のテーブルは全部のデータをDELETEして、INSERTするので、その統計用のテーブルを作り直す際にWALがたくさん生成されます。

以上から、手順を間違えることも考慮してwal_keep_segmentsを適当に設定しておくことにしました。
HDDは余裕があるので、えいやで50(walファイルは1つ16MBなので、50個で800MB)にしました。

実際、どの程度必要なのか…については、実運用環境で試せるなら、pg_walディレクトリのWALファイルの生成時刻を見ればいいのかな…と思います。
[root@erogamescape14 pg_wal]# ls -lh
合計 257M
-rw------- 1 postgres postgres  386  5月 30 23:22 2019 0000000A.history
-rw------- 1 postgres postgres  431  6月 26 09:06 2019 0000000B.history
-rw------- 1 postgres postgres  16M  6月 26 10:00 2019 0000000B00000013000000D7
-rw------- 1 postgres postgres  16M  6月 26 10:06 2019 0000000B00000013000000D8
-rw------- 1 postgres postgres  16M  6月 26 11:07 2019 0000000B00000013000000D9
-rw------- 1 postgres postgres  16M  6月 26 12:10 2019 0000000B00000013000000DA
-rw------- 1 postgres postgres  16M  6月 26 12:30 2019 0000000B00000013000000DB
-rw------- 1 postgres postgres  16M  6月 26 12:49 2019 0000000B00000013000000DC
-rw------- 1 postgres postgres  16M  6月 26 14:07 2019 0000000B00000013000000DD
-rw------- 1 postgres postgres  16M  6月 26 15:30 2019 0000000B00000013000000DE
-rw------- 1 postgres postgres  16M  6月 26 15:30 2019 0000000B00000013000000DF
-rw------- 1 postgres postgres  16M  6月 26 16:17 2019 0000000B00000013000000E0
-rw------- 1 postgres postgres  16M  6月 26 17:30 2019 0000000B00000013000000E1
-rw------- 1 postgres postgres  16M  6月 26 18:30 2019 0000000B00000013000000E2
-rw------- 1 postgres postgres  16M  6月 26 18:30 2019 0000000B00000013000000E3
-rw------- 1 postgres postgres  16M  6月 26 18:55 2019 0000000B00000013000000E4
-rw------- 1 postgres postgres  16M  6月 26 19:26 2019 0000000B00000013000000E5
-rw------- 1 postgres postgres  16M  6月 26 19:41 2019 0000000B00000013000000E6
drwx------ 2 postgres postgres 4.0K  6月 26 09:07 2019 archive_status
見ると、10時に0000000B00000013000000D7が生成されて、19時41分の時点で0000000B00000013000000Eです。16個あれば9時間持つので、standbyを9時間止めててもwal_keep_segmentsは16だったら、まあ…pg_basebackupなしに組み込めるかなあと想定できます。

Git関連書籍

ErogameScapeは2001年に作りましたが、2019年6月までGitを使ったことがありませんでした。
※1人で作っているので…なんとかなってました。大きな修正をする場合は、.bakという拡張子にしてファイルを保存してから開始していましたが、軽微な変更の場合はえいやで書き換えていました。

GitとGitを使うためのGUIの1つであるSourceTreeを学んで滅茶苦茶便利だ!と思いました。
以下の2つの書籍を手を動かしながら読みました。
GitとSourceTreeは道具なので、手を動かしながらやらないといまいち理解が深まらないことと、Gitを使うような何かを作っていないと、すぐに忘れちゃう…と思います。

独習Git
リック・ウマリ
翔泳社
2016-02-26

最初に図書館から借りてやりはじめたのですが、2週間では終わらず…、何回か借りるも終わらず、買ってきて一通り終えることが出来ました。
Gitをコマンドラインを使って操作します。
SourceTreeの話は最後の方に少しだけ出来ますが、ほんの少しだけなのでSourceTreeの使い方はこの本では分かりません。
こなすのに相当時間がかかって途中で心が折れそうになりますが、おそらく…必要最低限のGitの操作を学ぶことができます。
各章に課題があるのですが回答はないので、『独習Git』課題の解答およびヒント - Qiitaを参照させて頂きました。ありがたいです。
自分は、この本だけではGitを使う気になれませんでした…
次に買ったわかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉 [単行本(ソフトカバー)]でSourceTreeのことを知ってGitを使う気になりました。
自分はGUIじゃないときついと思いました。



2019年6月11日時点でレビューが45個5つ星のうち4.6で、AmazonのGit関連書籍のとしては堂々の1位です。
独習Gitを一通り読んだ後に、こちらを読んだらGitを具体的にどのように使ったらいいかがすごくよく分かりました。
●CHAPTER 1 Gitって何?
●CHAPTER 2 個人でGitを使ってみよう
●CHAPTER 3 複数人でGitを使ってみよう
●CHAPTER 4 実用Git 〜 こんなときはどうすればいい?
●CHAPTER 5 Gitで広がる世界
という章構成です。CHAPTER 3まではすんなり頭に入ってきたし、違和感もなかったですが、CHAPTER 4から「おやっ?」と思うことがある…説明が足りていないことがある…ので、その場合は独習Gitで同じことをしている章を読み直して、SourceTreeのこの操作は、Gitでコマンドをうつとこうなるんだなと、理解していきました。
この本だけでは足りないですが、1冊目としてはいいかなと思います。
例えばgit resetのことは載っていないです。
「git reset SourceTree」で検索すると著者のページ(SourceTreeのリセットボタンは、git reset全般を指しているわけじゃない | マンガでわかるWebデザイン)がひっかかりますので、ここを読んでなるほどなあと思いましたが、なるほどなあ…と思えるのは、独習Gitを先にこなしていたからなので…2冊目が必要だと思います。
2冊目として独習Gitだと…心が折れる方が続出しそうな気がしますが…他の本を読んでいないので何がかいいか分からないです。


記事検索