んー、やっぱり連続稼働させてると重くなってくるなあ…
サービス再起動すると一気に軽くなる
これ定期的にサービス再起動させるように cronjob 組んだほうがいいのかな
連続稼動させているとマストドンが重くなってくる現象、もしかしたら DB_POOL が低いのが問題かもしれないと教えてもらいました
ところで DB_POOL ってどれくらいまであげたらいいんでしょうかね
鯖缶のみなさんはいくつにしてます？
@noraworld rack-timeoutがタイムアウトしないならPumaのプロセスあたりの最大スレッド数と同じでいいんですが、タイムアウトするとデータベース接続が巻き添えで行方不明になっちゃうことがあるので、Pumaを再起動するまでに何回rack-timeoutがタイムアウトするかなあ、とか想像しながらその分を足してます。データベース接続のプールが足りなくなるとActiveRecordが５秒だけ待ってアプリログにその旨エラーを記録してくれます。
そのほか、アプリのプロセスがメモリを使いすぎてスワップを使い始めも、応答が遅くなりそうな気がします。
@zundan ありがとうございます！
基本的にだいたいの予想をつけて増やしてみて調整するって感じになりそうですね。ちなみに増やしすぎると弊害はあるんでしょうか？
@noraworld PostgreSQLサーバ側には最大いくつ接続を受け付けられるか、という限界があって、アプリがではその接続数をPumaとSidekiqとNodeとで分け合ってることになります。そのかねあいで、DB_POOLをいくらくらいまで増やせるか決まりそうです。
@zundan 最大接続数と、Puma、Sidekiq、Node それぞれの接続数を調べることってできますか？
@noraworld PostgreSQLは接続ごとにプロセスだったかスレッドだったかを起動するので接続数が大きくなるとリソースが足りなくなります。借りてるサーバだとプランで限界が決まってたりするのですが自前だと性能を測りながら増やしてみるしかないのかな？Puma、Sidekiq、Nodeは最大がそれぞれDB_POOL×プロセス数、スレッド数、スレッド数だろうと思いますがちゃんと確かめたことはありません。暇だとさぼるし。マニュアルみたいなものを探した方が早いかもですね。
@zundan なるほどです うちは借りているサーバなので確かめてみます。具体的にいくつが最適なのかはよくわからないので、いろいろ値を変えて試してみたいと思います