SmartHR最大のRailsアプリケーションにおけるPumaスレッド数を見直しました - SmartHR Tech Blog
こんにちは、SmartHR プロダクトエンジニアのB6です。 「基本機能」と呼ばれるSmartHR最大のRailsアプリケーションでは、アプリケーションサーバにPumaを使用しています。 RailsでPumaデフォルトスレッド数が変更されたのをきっかけに、私たちもスレッド数の設定を見直してみたいと思うようになりました。 本記事では、調整の際に行ったこととその結果について共有いたします。 背景 2024年、RailsでPumaのデフォルトスレッド数を減らすための議論が展開されました（Issue #50450）。議論の結果、I/O比率を25~50%とする一般的なRailsアプリケーションでは、スレッド数3が適切ではないかという結論に至りました。 要点をざっくりまとめると以下のようになります。 CRubyでは、GVLが存在するため、同時に1つのスレッドしかRubyコードを実行できない Pumaの
Ruby のバージョンを 3.1 系から 3.2 系にアップデートしたら Ruby on Rails アプリの動きが変わったのを解決した話 - DIGGLE開発者ブログ
私たちは Ruby on Rails の主要なマルチテナントライブラリ apartment を使ってサービスを提供しています。 Ruby のバージョンを 3.1 系から 3.2 系に上げたときに CSV ファイルを処理する部分でこのテナントの切り替えが意図通りに動作しませんでした。 この事象が興味深かったので共有します。 現在はこの事象に対応済で、私たちの環境は Ruby3.2 系で動作しています。 apartment ではマルチテナント対応部分をほとんど吸収してくれるので、アプリケーションのコードのほうにはあまりマルチテナント特有の処理が出てこず、個別処理のコードに集中できるメリットがあります。 事象が発生したコードは以下のような形式でした。 CSV.parse(filename, headers: true, header_converters: ->(header) { curren
Rails でメモリが右肩上がりに増えて最終的に落ちるのでなんとかしてきた - Qiita
before_fork do require 'puma_worker_killer' PumaWorkerKiller.config do |config| config.ram = 1024 # total RAM available config.frequency = 5 # how often to check config.percent_usage = 0.98 # percent of RAM to use before killing config.rolling_restart_frequency = 12 * 3600 # 12 hours in seconds end PumaWorkerKiller.start end puma_worker_killer の設定値の解説 config.ram = 1024: アプリケーションが利用可能なRAMの総量 config
DockerでNginx+Puma環境の構築（AWS FargateでRails環境をつくる - その2） - 虎の穴ラボ技術ブログ
こんにちは、虎の穴ラボNSSです。 前回「いまさらDocker入門（AWS FargateでRails環境をつくる - その1）」という記事をご紹介しました。 多くの方に読んでいただいたようで大変嬉しかったです。 今回こそは、Fargateを利用してDockerコンテナをデプロイするところまでを紹介いたします。 ...と思ったのですが、デプロイする前の準備がまだまだあったので、 今回は前回同様ローカルマシンで少し違ったRails環境の構築についてご紹介します。 toranoana-lab.hatenablog.com 1. 構築する環境について その1で構築したRails環境をdevelopmentとし、今回構築する環境をproductionとします。 development production ※実際本番デプロイするときはロードバランサーがありますが、ローカルマシンでの実行の際はありま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
