私は長年問題なく動作しているQnap 453Aを使用しています！
最近、Lyrionミュージックサーバー9.02をDockerでインストールしましたが、
ほぼ毎日のようにNASを再起動しなければならなくなりました。音楽システムが通信しなくなるためです。NASのどの設定を変更すればこの問題を防げますか？何かアイデアはありますか？
「オフライン」状態についてより詳しく理解するために、どういう意味かご説明いただけますか？Musicサーバーが動作していないのか、それともSMB（または類似のネットワークプロトコル）経由でNASに接続できないのでしょうか？
ご回答いただけると、問題の特定に役立ちます。ありがとうございます！
すべてはハードワイヤード接続です。NASは、私がLyrion（リリオン）ミュージックサーバー9.02をインストールして以来、この動作をしています。
これを修正する唯一の方法は、サーバーを再起動することです。
この原因は何でしょうか？
お客様のNASは有線接続であることを理解しています。Steveが尋ねているのは、最も一般的に使用されているファイル共有プロトコルであるSMB（Server Message Block）経由で接続できないかどうかです。
NASのウェブページにはアクセスできますか？それともサーバーが完全にオフラインになっていますか？
NASにSSH接続して「top」コマンドを実行することをおすすめします。プロセッサの使用状況を確認してください。もしかすると、音楽サーバーが多数のスレッドで多くのプロセッサ時間を消費している可能性があります。topコマンドの平均CPU負荷の行が最も重要で、現在処理されているスレッド数のおおよその目安となります。もし音楽サーバーが多くのリソースを消費している場合、NASがオフラインのように見えることがあります。
ありがとうございます。これが問題かもしれません。動作が停止すると、再起動するまで接続できません。今は動いているので、あなたの提案を試してみます。
結果はまたご連絡します。CPUと一緒に使われるクリティカルスレッドとは何ですか？
ご返信いただきありがとうございます。
またオフラインになってしまいました。
再起動後、リソースモニターを確認しました。
音楽を再生してみると、CPUの使用率は変動しましたが最大で約45%でした。
通常は20%程度ですが、これが問題なのでしょうか？
ただ、音楽を再生していない時にも失敗しています。
使用しているiPengで接続しようとしていますが、これもサーバーに接続できません。
QNAP_Danielが、Docker Composeで誤ったストレージ変数を使用した場合にRAMディスクがゴミだらけになるのを防ぐ方法についてのガイドを投稿しました。もしかしてあなたもこの問題を抱えていますか？
https://www.reddit.com/r/qnap/comments/1lbkhub/guidelines_on_how_to_deploy_yaml_in_container/
問題が発生するCPU使用率は何％ですか？
ありがとうございます
私のリンクはCPU使用率とは関係ありません。これは、コンテナの設定ミスによってRAMディスクがいっぱいになり、システムが応答しなくなる場合の話です。
誤設定されているとは思いません
これが私が使用したアプリです
services:
lms:
image: lmscommunity/lyrionmusicserver
volumes:
- /share/Container/app-data/lms-config/:/config:rw
- /share/Multimedia/Music/:/music:ro
- /share/Multimedia/Playlists/:/playlist:rw
ports:
- “9000:9000”
- “9090:9090”
- “3483:3483/udp”
- “3483:3483/tcp”
つまり、これらのターゲットが存在し、「rw」のものが正しい場所にデータで埋まれば問題ないはずです
問題があるのでしょうか？
ずっと倒れ続けています！
おおよそ1〜2日間
一般的なラムディスクは26%で稼働しています。
音楽システムが稼働中なので、引き続き監視します。
また、ドライブ自体は1/3しか埋まっていません。
どこかに問題があるのでしょうか？
CPU使用率を見ないでください。Load Average（ロードアベレージ）を見てください。これらは異なるものです。Load AverageはCPU使用率の平均ではありません。むしろ、CPU上で実行中または実行待ちのスレッド数の指標です。私のTS-873Aの場合、Ryzenは4コア8スレッドです。つまり、同時に8つのスレッドを処理できます。スレッドの実行に時間がかかる場合、CPU時間を多く使っていなくても、クロックサイクルを消費し続けています。例えば、ロードアベレージが20の場合、実行待ちのスレッドが12個ほどキューに溜まっていることになります。これが原因で、動作が非常に遅くなることがあります。あなたのコンテナがこれを引き起こしているかは分かりませんが、NAS上の他の何かが原因かもしれません。
あなたのTS-453はIntel J6412プロセッサで、4コア4スレッドです。正直なところ、これはかなり低性能なプロセッサです（A57よりは良いですが、i5やi7には遠く及びません）。残念ながら、ほとんどのNASは比較的低性能なプロセッサを搭載しています。そのため、新品でも数百ドルで購入できます。基本的なファイルサーバー用途なら問題ありませんが、アプリケーションをどんどん追加していくと、動作が遅くなります。
多くのNASはA55やA57のARMコアプロセッサを搭載しています。これらは組み込み用途には優れたコアですが、正直なところNASには向いていません。
承知しました。その点を考慮し、引き続き監視を続けます。
正確に負荷を確認するにはどうすればよいですか？
1.) SSHが有効になっていることを確認してください。
2.) コンピューターのコマンドプロンプト（Macの場合はターミナル、Windowsの場合はDOSシェル）から以下を入力します:
ssh username@NAS_IP
ここで、usernameはNASのユーザー名、NAS_IPはNASのIPアドレスです。私の場合は:
ssh jono@192.168.0.1
マシンを安全なホストのリストに追加するか尋ねられた場合は「はい」と答えてください。
プロンプトが表示されたらパスワードを入力します。
これでNASのLinuxシェルに入ることができます。引用符なしで「top」と入力してください。これでNAS上で実行中の主要なプロセスが表示されます。ロードアベレージ（負荷平均）はCPUパーセンテージの下にある上部の数字です:
ここにログインしたままにして、NASが暴走したときにその数字を確認してください。
ありがとうございます！
念のため確認ですが、問題が発生した際は、ネットワーク共有やウェブインターフェースなど、どの方法を試してもNASに全く接続できないということでしょうか？