ここ数日はサーバの人数1100〜1050、1日間のアクティブユーザ270人くらいで人数はあまり変わってません。ユーザ間のフォローが増えるにつれて、発言、ブースト、お気に入りで発生するFan-outが大量にsidekiqのキューに積まれるのが目立ってきました。defaultキューに処理が溜まるとユーザへの応答性が低下します。Push通知は計算よりも通信待機が多いのでキューを処理するスレッドを増やすのが効果的です。それに必要なのがCPU、メモリ、そしてDBサーバへの接続数です。今回はDBサーバへの接続数を稼ぐために、DBサーバとアプリケーションの間にpgBouncerを設置してみます。なっていますが、この接続一つごとにプロセスを一つ使ってしまいます。pgBouncerを使ってDB接続の中継を行うと、アプリ側に必要な接続数を増やしつつもDBサーバ側のプロセス数を節約することができます。pgbouncerイメージの取得pgbouncerイメージの取得と設定ファイルの雛型の抽出を行います。shでコンテナ中にログインできたら、以下の作業を行います。出力をテキストエディタにコピーしておきます。出力をテキストエディタにコピーしておきます。出力をテキストエディタにコピーしておきます。Mastodonの停止とコンテナの削除あらかじめdbサーバはデータをホスト側のフォルダに出して永続化しておいてください。このあたりは前回の記事で説明しています。http://d.hatena.ne.jp/tateisu/20170416/1492341633また、データベースにはMastodonに必要なデータが既に一通り定義されているものとします。downでMastodonの停止と関連コンテナの削除が行われます。データベースのサービス定義の名前変更docker-compose.ymlを編集します。サービス定義の内、名前が「db:」となっているものを「db_backend:」という名前に変更します。DB_で始まる設定値をテキストエディタにコピーしておきます。pgbouncerフォルダを作成します。パーミッションと内容は先ほどメモしたものに合わせてください。」という行を記述します。パスワードは適当に生成してください。pgbouncer.iniには以下の編集を行います。[database]セクションにバックエンドへの接続を書きます。password=(DBパスワード)」hostに指定するのは、データベースサーバのサービス定義の名前です。先ほどdb_backendに変更しましたね?port,dbname,user,passwordに指定するのは、これまでDB接続に使っていたのと同じ情報です。メモしましたね?[pgbouncer]セクションの以下の情報を編集します。20pgBouncerのサービス定義を追加docker-compose.ymlを編集します。以下のようなサービス定義を追加します。exposeの指定が同じポート番号か確認しましょう。設定値を、bouncerへの接続に適したものに変更します。DB_HOSTに指定する名前は、docker-compose.ymlのpgBouncer用サービス定義の名前と一致させます。[database]セクションに指定した接続情報の左端の名前と一致させます。指定したユーザと一致させます。指定した新パスワードと一致させます。データベースを利用するアプリはこれらの環境変数を使って接続するようになります。問題がなければ成功です。出るポート指定は期待通りになっているか。expose漏れはないか。関するエラーが出ていないか。interfaces!というエラーを出すokhttpのCacheControl.Builder.maxStale()Toastの再利用KotlinのCoroutineScopeのメモ月別アーカイブはてなブログをはじめよう!tateisuさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。