helmi
2022 年 1 月 26 日午後 3:23
1
ハードウェアのスケーリングを継続する方法について、皆様の経験をお聞かせください。
当社の基盤となるデータは以下の通りです。
現在220万件の投稿があり、毎月約8万件増加しています。
ユーザー数は35,000人で、毎月約1,500人増加しています。
現在、HetznerのVMで8コア専用、RAM 32GBで稼働しています。12月にNginxのワーカー接続数で初めて制限が見られ始め、デフォルトの768から1536に引き上げました。昨日再びその上限に達し、現在3072に引き上げました。これらの変更後、システムは再びスムーズに動作していますが、サーバー使用率100%の限界に近づいています。
db_work_mem は 80MB、db_shared_buffers は 8192MB に設定されています。利用可能なメモリをまったく使い切れていませんが、もっと使用してメリットを得られる余地があるかどうかは不明です。ご意見をお聞かせください。
#~> free -m
total used free shared buff/cache available
Mem: 31360 6105 1241 8423 24013 16412
Hetznerでの次の簡単なスケーリングオプションは、16コアと64GBのRAMですが、コスト的には問題ありません。しかし、垂直スケーリングを続けることがまだ理にかなっているのか疑問に思っています。アプリケーションとデータベースを別々のサーバーに分割する方が、はるかに理にかなっているのではないか、あるいは多くの困難をもたらすのではないかと考えています。
どなたかそのような経験をされた方はいますか？どのような経験をされましたか？
Falco
2022 年 1 月 26 日午後 6:11
2
スケールアップを検討されている理由は何ですか？APIの応答時間メトリクスは低下していますか？
helmi:
サーバーの利用率が100%に近づいています。
ここで参照されているリソースは何ですか？CPUですか？ディスク容量ですか？メモリですか？
「いいね！」 2
RGJ
2022 年 1 月 26 日午後 6:35
4
ページビューはどのくらいありますか？
インターネットで見つかるアドバイスはすべて無視して、メモリの40〜50％に設定してください。
sar の出力を共有してもらえますか？
「いいね！」 2
helmi
2022 年 1 月 26 日午後 8:17
5
Falco:
なぜスケールアップを検討しているのですか？
将来を見据えているからです。今すぐスケールアップする必要はないかもしれませんが、成長率や過去のリソース需要の増加を見ると、次のステップについて考えておくことは、現時点で計画を立てることになります。
主にCPUです。今日のアップデートの後、ピーク時の負荷は約8〜9から、現在約6程度に戻ってきています。
RGJ:
ページビューはどのくらいありますか？
月間1200万ページビューで、1年前の月間650万ページビューから増加しました。
後ほどsarの出力についてお伝えします。実行していませんでした。
Falco
2022 年 1 月 26 日午後 8:20
6
具体的にどのプロセスがCPUを使用しているかを調査する必要があります。考えられる原因は以下の通りです。
UnicornのWebワーカー
PostgreSQL
Sidekiq（画像最適化のバックグラウンドジョブなど）
Redis
nginx（可能性は低い）
原因に応じて、負荷を軽減する方法を提案できます。
「いいね！」 5
helmi
2022 年 1 月 26 日午後 8:33
7
CPU時間を見ると、主にユニコーンのワーカーだと思われます。
「いいね！」 1
Falco
2022 年 1 月 26 日午後 8:57
8
専用のCPUの件はやめて、こちらの商品を使ってみてはどうでしょうか？
お客様のニーズにもっと適していると思います。
「いいね！」 2
helmi
2022 年 1 月 27 日午前 7:52
9
すでにそのオプションについて考えていました。以前は非専用CPUを使用しており、「アップグレード」しても専用CPUではあまり進歩しませんでした。
「いいね！」 1
RGJ
2022 年 1 月 27 日午前 10:30
10
CPUがボトルネックになっているかどうかわかりません。その間、sarの出力を共有してもらえますか？
helmi
2022 年 1 月 27 日午後 12:09
11
はい、そうですが、まだピーク時間ではありません。明日までには対応できる見込みです。
昨日、ワーカー接続を増やしてからCPU使用率は確実に低下しましたが、どの程度かはまだわかりません。
12:00:01 AM CPU %user %nice %system %iowait %steal %idle
08:45:01 AM all 40.22 2.21 7.44 0.27 0.00 49.86
08:55:01 AM all 42.84 2.89 8.02 0.16 0.00 46.09
09:05:01 AM all 38.81 0.86 7.68 0.12 0.00 52.53
09:15:01 AM all 38.80 0.70 7.66 0.10 0.00 52.73
09:25:01 AM all 38.71 2.14 7.88 0.12 0.00 51.16
09:35:01 AM all 38.74 0.84 7.86 0.09 0.00 52.47
09:45:01 AM all 40.31 1.07 7.95 0.10 0.00 50.57
09:55:01 AM all 40.03 1.37 7.90 0.08 0.00 50.62
10:05:01 AM all 39.00 1.29 7.90 0.09 0.00 51.72
10:15:01 AM all 40.26 2.68 8.07 0.09 0.00 48.91
10:25:01 AM all 41.59 0.93 8.31 0.08 0.00 49.09
10:35:01 AM all 40.39 1.55 8.25 0.07 0.00 49.73
10:45:01 AM all 45.44 2.37 9.08 0.08 0.00 43.03
10:55:01 AM all 50.56 2.20 9.23 0.06 0.00 37.95
11:05:01 AM all 41.82 1.54 8.55 0.08 0.00 48.02
11:15:01 AM all 38.74 1.54 8.11 0.10 0.00 51.50
11:25:01 AM all 45.41 1.59 9.27 0.19 0.00 43.55
11:35:01 AM all 38.45 1.78 8.20 0.11 0.00 51.45
11:45:01 AM all 41.03 1.60 8.48 0.14 0.00 48.75
11:55:01 AM all 40.65 1.17 8.36 0.15 0.00 49.67
12:05:01 PM all 40.03 1.29 8.40 0.13 0.00 50.15
12:15:01 PM all 40.47 1.10 8.19 0.11 0.00 50.13
「いいね！」 1
RGJ
2022 年 1 月 28 日午後 10:34
13
Postgres が十分なメモリを取得できておらず、それが高い %iowait を引き起こしているのではないかと疑っていました。
pfaffman
2022 年 1 月 29 日午前 4:07
14
パフォーマンスの問題を抱えている人を手伝おうとしています。Postgresのバッファサイズを増やしました。少しは役に立ったと思いますが、ミニプロファイラーではまだ300ミリ秒を超えています。CPU使用率は16CPUで約30%です。
「いいね！」 1
helmi
2022 年 1 月 29 日午前 7:22
15
それは変わらなそうですね。2晩にわたって監視しましたが、CPU使用率がそれ以上上がることはありませんでした。Postgresに関するあなたの仮説は正しいかもしれません。
ミニプロファイラーについてですが、目標とする数値はどれくらいでしょうか？現在約300ミリ秒です。以前は500ミリ秒前後でした。
「いいね！」 3
ピークトラフィックの時間帯に関係なく、すべてのケースで50ミリ秒未満 を達成できれば、それを高速なサーバー応答時間と呼びたいと思います。サイトの残りの部分は、すべて初期サーバー応答時間に依存するため、より速くなります。
また、すべての地理的なユーザーから50ミリ秒未満を維持し、一貫性を保つことができれば、非常に理想的です。現在のところ、ジャンプし続けており、ほとんどの場合高いため、それが遅い大きな問題のようです。
helmi
2022 年 1 月 30 日午後 8:01
17
ここ数日の状況は順調でしたが、今日の午後約30分間を除いては。その時間は私もサーバーにいませんでしたが、nginxログでバックエンドからのタイムアウトが報告されました。sarはわずかに高いシステム利用率を示していますが、全体的な高CPU負荷はありません。原因は不明ですが、ユニコーン/Redis/Postgresの円滑な動作を妨げていたようです。
03:55:01 PM all 34.99 1.87 6.67 0.12 0.00 56.35
04:05:01 PM all 33.99 0.35 6.52 0.31 0.00 58.82
04:15:01 PM all 35.24 1.17 7.14 0.13 0.00 56.31
04:25:02 PM all 36.45 0.63 7.15 0.13 0.00 55.65
> 04:35:01 PM all 39.09 0.71 16.78 0.11 0.00 43.32
> 04:45:01 PM all 35.53 0.95 20.16 0.08 0.00 43.27
> 04:55:01 PM all 41.64 4.29 15.44 0.24 0.00 38.39
05:05:01 PM all 36.75 2.47 7.78 0.13 0.00 52.87
05:15:01 PM all 35.96 1.29 7.81 0.10 0.00 54.85
05:25:01 PM all 38.69 1.35 8.00 0.09 0.00 51.87
05:35:01 PM all 37.01 4.53 7.92 0.07 0.00 50.46
>でマークされた行です。
その時間帯に高いトラフィックは見られなかったので、何が原因だったのかはっきりしませんが、本当にその30分間だけの問題でした。
全体的にCPU時間を見ると、Redisがリードしており、一般的にCPUの大部分を使用しています。これについて何かできることがあるか分かりません。通常は20〜25%程度で、時々35%に達します。
1721566 uuidd 20 0 2035M 1458M 1952 S 16.1 4.6 16h22:37 /usr/bin/redis-server *:6379
1721578 www-data 20 0 108M 69100 12516 S 6.7 0.2 6h32:27 nginx: worker process
2853756 1000 20 0 1355M 444M 19356 R 63.7 1.4 2h38:10 unicorn worker[0] -E production -c config/unicorn.conf.rb
2854380 1000 20 0 1267M 409M 18768 S 41.6 1.3 2h19:45 unicorn worker[4] -E production -c config/unicorn.conf.rb
1721598 1000 20 0 592M 285M 5192 S 1.3 0.9 2h08:53 unicorn master -E production -c config/unicorn.conf.rb
575 root 20 0 1747M 20468 5040 S 0.7 0.1 2h01:02 /usr/bin/containerd
2854731 1000 20 0 1280M 399M 17880 S 36.9 1.3 1h57:52 unicorn worker[7] -E production -c config/unicorn.conf.rb
1721841 1000 20 0 592M 285M 5192 S 0.7 0.9 1h49:49 unicorn master -E production -c config/unicorn.conf.rb
2855284 1000 20 0 1287M 425M 18396 S 18.8 1.4 1h35:02 unicorn worker[3] -E production -c config/unicorn.conf.rb
2856414 1000 20 0 1223M 391M 19268 S 13.4 1.2 1h14:50 unicorn worker[2] -E production -c config/unicorn.conf.rb
2856478 1000 20 0 1207M 401M 21120 S 5.4 1.3 58:42.50 unicorn worker[5] -E production -c config/unicorn.conf.rb
2856503 1000 20 0 1215M 389M 18980 S 4.7 1.2 47:22.95 unicorn worker[1] -E production -c config/unicorn.conf.rb
1721581 www-data 20 0 69888 28636 13368 S 0.0 0.1 44:49.50 nginx: worker process
2857467 1000 20 0 1199M 385M 18112 S 4.0 1.2 39:23.87 unicorn worker[6] -E production -c config/unicorn.conf.rb
1721594 _apt 20 0 8479M 20036 18128 S 1.3 0.1 32:55.29 postgres: 13/main: walwriter
580 root 20 0 1747M 20468 5040 S 0.0 0.1 32:15.27 /usr/bin/containerd
全体的な負荷は平均して5ですが、時々8または9まで上昇するのを見かけます。
「いいね！」 2
helmi
2022 年 1 月 31 日午前 7:47
18
ミニプロファイラーに関しては、全体の読み込み時間について話していました。サーバー応答時間（初期リクエスト）は通常、当社の側では10ミリ秒未満です。時々少し上回ることもありますが、最後のチェックでは20ミリ秒を超えることはありませんでした。全体の読み込み時間は、時々800ミリ秒まで速くなり、1000ミリ秒を超えることは非常にまれです。
その地域以外にユーザーがそれほど多くいないため、1つのジオリージョンのみを見ています。
DISCOURSE_ENABLE_PERFORMANCE_HTTP_HEADERS
「いいね！」 4
