MarcP
(MarcP)
1
単一のプラグインを admin/upgrade からアップグレードする際に、非常に時間がかかります。
通常、完全な再構築は約7分で完了します。
2023-03-02T20:07:00Z からアップグレード中ですが、現在のステータスは以下のとおりです。
HTOP の出力:
編集:2023-03-02T20:44:00Z - まだ同じログ行で停止しています。CPU も同じ状態です。この時点で CLI で再構築を開始しました。
編集2:私のマシンでの再構築にかかる正確な時間を参照するために、再構築完了のタイムスタンプ:2023-03-02T20:51:00Z
「いいね!」 4
はい、少なくとも昨日から同じような状況を経験しています。
現在、アップグレード画面からのアップグレードは、まともな時間ではほぼ不可能です。そのため、コマンドラインからアップグレードせざるを得ません。
MarcP
(MarcP)
3
CLIの再構築が完了しました。
管理者のアップグレードはまだスタックしており、プラグインがアップグレードされていないようです。
[RESET UPGRADE]をクリックし、別のcli-rebuildを開始しました。
「いいね!」 1
Noah
4
私も同じです。プラグインのアップグレード時に非常に時間がかかり、非常に不便です。
「いいね!」 2
Noah
5
これはまだ問題です。
ただし、低スペックのサーバーにのみ影響するようです。
「いいね!」 1
追加の意見として、回答ではなく… 
私は多数のプラグインを搭載した、わずか1GBのDOテストサイトを持っているので、通常はそれほど速くはありません。しかし、最近になって処理に時間がかかっているように感じており、先日@MarcPと同じように奇妙な現象に見舞われ、リセットする必要がありました。
以前は時間を計ったことはありませんでしたが、今日「すべて更新」を設定し、ボタンをクリックした時間を記録しました。午前9時30分に開始し、午前10時15分現在もまだ実行中です。現在、アセットのバンドル処理を行っています。45分以上もかかり続けることは通常ないと言えます。
一時ファイルの削除で権限の問題があったようですが、関連性があるかは不明です。
「いいね!」 4
sam
(Sam Saffron)
11
@david と私で根本原因を特定しました。(過去に @Falco が特定したものと同様です)
アップグレード中のメモリ使用量を制限するために特別な Ruby フラグを使用していますが、これは Ruby 3.2 では機能しなくなりました。
問題の修正には、まもなく PR が公開されるはずです。
「いいね!」 7
sam
(Sam Saffron)
13
注…修正を有効にするには、ニワトリと卵の状況が少しあります。アップグレードを実行すると、古いコードがまだロードされています。
初回は ./launcher rebuild が必要になる場合があります。それ以降は Web アップグレーダーで問題ありません。
これ以外に簡単な方法はありません。@cvx、これは厄介な問題です…技術的には、DockerManager::Upgrader.new(user_id, repo, repo_version).upgrade がシェルアウトして、アップグレード時に新しいアップグレードコードを実行できるようにする必要があります…しかし、それは「ヘビの缶詰」です。
高速な回避策
- Docker マネージャーのアップグレードを開始します。
- スタックしたらキャンセルします。
- シェルから
./launcher restart app を実行します。
- Web からのアップグレードが機能します。
簡単な回避策
./launcher rebuild app を実行します。
これで問題ありません。
編集
このトピックに関する最後の投稿にしたいので、先回りしてこれを閉じます。これにより、人々が回避策を見つけやすくなります。再構築後も問題が続く場合は、フラグを立てて開いてください。
「いいね!」 8