メモリ不足でライブラリ構築に失敗する際の対処方法

273 views
Skip to first unread message

polar...@gmail.com

unread,
Sep 9, 2016, 9:55:39 PM9/9/16
to lightMPD
lightMPDの初回起動でライブラリを構築する際、メモリ不足でmpdのプロセスが終了してしまいます。
一定数以上の曲数があるとメモリが食いつぶされてしまうようです。

# dmesg(抜粋)
Out of memory: Kill process 252 (mpd) score 897 or sacrifice child
Killed process 252 (mpd) total-vm:932248kB, anon-rss:861892kB, file-rss:16812kB

ライブラリ構築時だけでもSWAP領域を追加しようと試みたのですが、swaponコマンドがbusyboxで使用できず断念しました。
他に解決策があれば、教えてください。

構成:
Raspberry Pi3
Sabreberry32
lightMPD v1.0.2
※音楽ライブラリはCIFSでNASからマウントしています。

digi...@gmail.com

unread,
Sep 10, 2016, 10:29:00 AM9/10/16
to lightMPD
polaroidoonさん

lightMPDのkernelではswapを使わないように設定してあるのでswapは使えません。

dmesgを見るとtag_cache が1G近くなっており、このような巨大なライブラリはmpdでは管理できないと思います。

mpdはmusic_deirectoryで指定されたディレクトリ配下の音楽ファイルの情報をdatabase->pathで指定されたファイル(以下,tag_cacheと呼びます)に格納します。
また、tag_cacheがある場合は起動時にそれを読み込みます。従って、tag_cache作成時だけではなくmpd実行時もtag_cacheが読み込める必要があります。

tag_cacheはクライアント(gmpcやmpadなど)からのリクエストによってクライアントに送られます。
クライアントではtag_cacheを元にアルバムや楽曲の一覧を表示します。

仮にswapを増やしてtag_cacheを作れたとしてもクライアントがその様な巨大なtag_cacheを読みこめるかは解りません。ipadやandroid端末では無理だと思います。

mpdではライブラリをスキャンするときはtag部分しか読み込んでませんし、必要がなくなったらすぐに破棄しています。従って、1G近くで out of memory がでると言うことはtag_cacheが1G近くなっていると考えられます。

しかし、tag_cacheが1Gになるという状況が想像できません。

楽曲がそれほど多くないのに、out of memoryが発生するなら、楽曲ファイルの不具合やディレクトリ構造の不具合によりmpdが誤動作している事も考えられます。

参考の為、nasにどれぐらいの楽曲があるか教えて頂けませんか。

polar...@gmail.com

unread,
Sep 10, 2016, 10:15:19 PM9/10/16
to lightMPD
digififanさん

ライブラリは約3,500曲ほどです。
ディレクトリ構成は「/アーティスト名/アルバム名/楽曲ファイル」となっています。

$ find . -type f | grep -e '\.flac$' | wc -l
1305
$ find . -type f | grep -e '\.wav$' | wc -l
1749
$ find . -type f | grep -e '\.mp3$' | wc -l
310
$ find . -type f | grep -e '\.mp4$' | wc -l
0
$ find . -type f | grep -e '\.alac$' | wc -l
0
$ find . -type f | grep -e '\.m4a$' | wc -l
93

同じライブラリでRuneAudioでは動作していたため気にしていませんでしたが,楽曲DBの構成が違うことに気付きました。
mpdは設定次第でDBの方式が選べるのでしょうか。


lightMPDの音はもう手放せないので、mpdに見せるライブラリの楽曲数を削減した方がよいかもしれませんね。

digi...@gmail.com

unread,
Sep 10, 2016, 11:02:43 PM9/10/16
to lightMPD
polaroidoonさん

> ライブラリは約3,500曲ほどです。
この規模ならtag_cacheが1Gに成ることはありません。私は、これ以上のファイルを抱えていますがtag_cacheは10M程度です。
mpdが何らかの障害を抱えているのかもしれません。

mpdが想定していないtagが格納されているファイルがあるように思われます。

ちょっと時間がかかるかもしれませんが、mpdをデバッグモードで動作させるとDBに登録される毎にファイル名を
表示させることができます。
ファイルに問題があれば、そのファイル名を表示後にアボートします。

デバッグモードの起動は以下の方法で行います。

# /etc/init.d/S95mpd stop        <--   mpdを停止する
# mpd --no-daemon --stderr --verbose /etc/mpd.conf      <--- デバッグモードで起動

これでDBのupdateを行うとファイル名が表示されます。

一度、これでファイルのtag を検査したほうがいいと思います。

> 同じライブラリでRuneAudioでは動作していたため気にしていませんでしたが,楽曲DBの構成が違うことに気付きました。
> mpdは設定次第でDBの方式が選べるのでしょうか。
DBの方式が選べるというのが解らないのですが、これはどうゆう意味でしょうか?

もし、lightMPDで対応可能であれば対応したいと思います。

Reply all
Reply to author
Forward
0 new messages