私の問題ではありませんが、他に何も意味しないということですか？
「いいね！」 1
意図的ではないかもしれませんが、ホストのコンテンツを監査して、暗号通貨マイニングプロセスなどが実行されていないか確認する価値があるかもしれません…
「いいね！」 3
ステップ 1: vfs ドライバーの使用における、既に特定されているパフォーマンスの問題を修正する
「いいね！」 7
この（理想的には）overlay2へのスワップについてですが、現在のインストールをすべて消去して再インストールする必要があります。これは、現在使用しているホストがfuse-overlayfsまたはvfsのみをサポートしており、どちらも推奨されていないためです。
しかし、まもなくoverlay2をサポートするKVMが有効になる予定です。
そのため、推奨されていないfuse-overlayfsの代わりにそれを使用したいと考えています。
さて、Discourseアプリ自体でバックアップを取得できます。これは具体的に何をバックアップするのでしょうか？
バックアップを取得し、新しいサーバーに新しいDiscourseを再インストールし、初期設定後にバックアップで上書きした場合、現在のDiscourseフォーラムから何か（メッセージ、チャット、設定、ユーザー、アップロードされた画像など）を失うことはありますか？
それは機能しますか？
はい、それでうまくいきます。
唯一言及されていなかったのは、新しいDiscourseに現在のDiscourseと同じプラグインがあることを確認することです。app.ymlを再利用すれば、問題ありません。
「いいね！」 3
なるほど、ご指摘ありがとうございます。それに気づかなかったら危なかったです。
さて…
- Discourse管理エリアでバックアップを取る
- 安全のため、もちろんサーバーのバックアップも取る
- yamlファイルのコピーを取る
- サーバーをダンプする
- サポートされている技術で新しいサーバーをセットアップする
- 適切なストレージドライバーでDockerをインストールする
- バックアップされたyamlファイルを使用して、完全に新規のDiscourseインスタンスを再構築する
- バックアップからDiscourseを復元する
バックアップがわずか19.2MBであることに少し驚いています。
すでにいくつかの画像などがアップロードされていますが、試せるのはこれだけだと思います。
週末にこれを試してみて、ストレージドライバーの変更がうまくいったかどうか、また報告します。
「いいね！」 1
これが設定されていることを確認してください。
「いいね！」 1
この特定のオプションは、スケジュールされたバックアップにのみ適用され、手動バックアップには適用されないことに注意してください。手動バックアップでは、常に明示的な選択肢があります。
有効にするもう1つのオプションは、「バックアップにサムネイルを含める」です。
@smileBeda すべてが正常に機能するまで、#4 を延期することをお勧めします。
「いいね！」 3
はい、確かにチェックされていますが、「バックアップに生成されたサムネイルを含める。これを無効にするとバックアップは小さくなりますが、リストア後にすべての投稿を再ベイクする必要があります。」はチェックされていませんでした。
@RGJ… そうですね、良い考えです。新しいエンティティの下にサーバーを作成する必要があるため、さらに手順が必要になりますが、リスクに比べれば些細なことです。
手動バックアップでは画像などが含まれないと理解しているので、自動バックアップをトリガーしてすべてのデータを含めるようにします。
ありがとうございます…
それは誤解です。
手動でバックアップを作成する際には、データベースのみをバックアップするか、アップロードを含めるかを選択するポップアップが表示されます。
スケジュールされたバックアップを作成する際には、アップロード付きバックアップ設定がそれを決定します。
「いいね！」 4
わかりました。以前の「この特定の С настройка（設定）はスケジュールされたバックアップにのみ適用され、手動バックアップには適用されません。」という内容を誤解していました。
ありがとうございます…
「いいね！」 2
こんにちは。このトピックはまだ開いているので、新しい仮想サーバーに移行した後も同じ問題が発生しているため、再利用させていただきます。他の皆さんが言うように、Discourseの再構築に20分以上かかったことはありませんでしたが、この新しいサーバーではリソースが倍増しているにもかかわらず、数時間かかっています。
Metaの数時間にわたるアップグレードに関する他のトピックを確認しましたが、私たちの問題の原因が特定できませんでした。
サーバー：RAM 4GB、CPU 2基、ディスク 50GB。
スワップ：
/$ free
total used free shared buff/cache available
Mem: 3911740 507208 2318476 268 1384032 3404532
Swap: 4095976 45472 4050504
Docker：
/$ sudo docker info
Client:
Version: 26.1.3
Context: default
Debug Mode: false
Server:
Containers: 3
Running: 0
Paused: 0
Stopped: 3
Images: 3
Server Version: 26.1.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version:
runc version:
init version:
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.8.0-31-generic
Operating System: Ubuntu 24.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.731GiB
Name: podkasts
ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
私には普通に見えますが、何か見落としているかもしれません。他にどこを見ればよいでしょうか？
新しいVMが古いVMよりも遅いのは、ノイジーネイバーが、あなたが受け取っていないCPUをすべて使用しているからではないでしょうか？
「いいね！」 1
はい、ありがとうございます。あなたのような経験豊富な管理者でも、上記の情報に明白な問題が見られないのは安心です。そしてはい、物理サーバーと仮想環境の調査を開始しています。少なくともフォーラムは、ユーザーが気づくような問題なく動作しています。再構築時のみ、この深刻なパフォーマンス問題に直面しています。昨日は再構築に4時間かかりました。
「いいね！」 1
この問題が発生した場合、ターミナルウィンドウを2つか3つ開きます。1つは再構築を実行するため、1つは経過時間を記録し、ログの更新間に長い遅延が発生している場所を記録するため、そして最後の1つはマシンのアクティビティを記録するためです。おそらく vmstat 5 を実行します。
ログが疑わしいほど長い間更新されないポイントに達したら、vmstat によって報告されたアクティビティを記録してください。
ログからの適切な抜粋と、メモおよび対応する vmstat の出力をここに投稿してください。
再構築の特定の С части が時間を要している可能性が非常に高いです。やるべきことは、どの С части なのかを見つけ出し、その С части でマシンが何をしているのかを確認することです。
一時停止中に ps auxf を使用してマシンのアクティビティのスナップショットも取得するでしょう。
「いいね！」 4
ありがとうございます。大変良いアドバイスです。次回再構築する際は、この方法で行います。
「いいね！」 2