もしも Herokuを1Dynoで動かしている人で、発言がホームに保存されていないように感じたら、きっと Heroku用に作成されていた1Dyno用Sidekiq起動オプションが消されたからです。
下記のようなコードを使って、環境変数にSIDEKIQ_SPAWN=true とか設定すれば動かせるかと。
https://github.com/ms2sato/mastodon/pull/45/files
本家からコード離れるの嫌な人は1DynoをやめるかHerokuをやめるかじゃないかと思われます。
スレッドの内容からするとHerokuで1Dynoがproductionで現実的ではないと判断されている様子なので復活はなかなか難しい感じかと。
@ms2sato 手元のぼっちインスタンスでは、pumaのスレッド数を5から3くらいに少なくしたほうがswapに突っ込んじゃうと可能性が低そうだなあと感じてます。もうすぐ確かめる！
ref https://mstdn.techdrive.top/@ms2sato/9849
@zundan 返信ありがとうございます！
おそらくSWAPと見間違われたと思いました（違ったらごめんなさい）。
ruby の spawnという関数の話なんです。
通常WEBとSidekiq（非同期処理）を起動するのには複数のrubyプロセス使って行います。v1.2以前のバージョンでは、Herokuの1DynoでSidkiqを使えました（Herokuの提供している仕組みではそれを想定していない）。
それを可能にしていたのは rubyのspawnという関数を使って、WEBのDynoの中に新しくプロセスを立ち上げる仕組みを割り込ませていたからです。
v1.2系でその実装が本家から削除されたので、1Dynoで動かそうとしても、起動時にSidekiqが立ち上がらないため、まともにシステムが動かせないと思います（「ホームの内容が保存されない」と表現したのはもっともわかりやすいと思ったからです）。
いきなり長文でごめんなさい。雰囲気伝わりましたかのう。
@ms2sato ありがとうございます！
1 dynoにSidekiqを詰めようとするとpumaの2プロセス✕5スレッドでらメモリが512 MBから溢れそう、と書きたかったのでした。
こちらではアカウント1つのインスタンスが、puma 2プロセス✕3スレッドで6時間ほど稼働させてみてしてます。R14をもらうとしたらこれからかもですね…。
pumaとSidekiqを同居させるには、シェルからバックグラウンドに送る方法もありました: https://github.com/zunda/mastodon/blob/zunda-ninja-on-heroku/Procfile
@zundan おお、そうでしたか。意図を汲めておらずに失礼しましたー。
うわー！この方法があったのか！惚れる
https://github.com/zunda/mastodon/blob/zunda-ninja-on-heroku/Procfile
人によってフォロー・フォロワーの傾向が違うと思うので、結果違うかもしれないですね。っと、書いててちょっと訂正しないといけないのが
> （メモリ使用量は上昇傾向で、何かあるとR14が発生する）
R14が発生していたのはリソース絞り切る前でした（でもメモリはやっぱりギリギリでしたが）。
バージョンが上がって最適化されたりすれば運用も楽になって行きそうですね。
https://mstdn.techdrive.top/@ms2sato/8524
今はこれとか試したいと思ってたりします。
またその後のこととかも教えてくださーい。