Maildir関係のメタバグの
Bug 859011 を開いたものです。
一言でいうと、まだ開発途中の新機能ですから、ユーザー同士の助け合いの為のフォーラムは不適切であり、自力でBugzillaにバグを開いて問題をきちんと報告してデベロッパーに修正のコードを作ってもらう必要があります。
メタバグの
Bug 859011に掲載されているバグの大半が解決して、もういいだろう、と、甘く見て、一度、Maildirに設定するUIをリリース版に入れてしまい、安易にMaildirに設定してしまったユーザーからの問題報告が相次ぎ、それであわてて次のリリースでそのUI
を殺した、という経緯があります。
ある環境で、Maildirでフォルダーの修復が同時に発生した時、2000メールフォルダーまでならば仮想メモリーが足りるが、4000メールフォルダーあたりになると、おそらくOOMでクラッシュ、というような現象に聞こえます。
単純に「メモリーリーク」というのでは無くて、使い終えたファイルハンドル用のメモリーの開放速度よりも、新たなファイルハンドルの要求の速度の方が大きい、といったことのような気がします。
ABCというフォルダーで、中にnnnメールがあれば、
最低限、ABC.msf、ABC(ディレクトリー)、curディレクトリーの下のnnn個のメールデータファイル、のオープン・クローズが入ります。
4000フォルダーあれば、4000 x nnn 個のファイルハンドルが使われます。
そして、ファイルハンドル用のメモリーは、ファイルハンドルの使用をやめた（クローズした）からといって、直ぐに解放されるわけではない。
Maildirの利点は、
(A)４GBの制限がない、
(B)コンパクト(フォルダーの圧縮)が発生しない。
IMAPのOfflineStoreでは、とっくの昔に、4GBの制限は無くなっていてますし、BerkleyStoreでも、52か53か55あたりで4GBの制限がなくなるはずだから、単に、4GBだけの為にMaildirを使う、という必然性は、無くなっています。
IMAPの場合、無理矢理(B)にしてしまったものだから、コンパクトの時にexpungeを送る、という道が閉ざされてしまい、ある場面においては、使い物にならない、という大問題があるのですが、いつまで経っても改善してくれない。
そんな巨大なメールフォルダーを沢山作るのが趣味でなければ、
全てのアカウントがPOP3で、IMAPがらみのいやらしいこともなさそうですし、
(A) 全てのメールフォルダーを、BerkleyStoreに戻す。
(B) どうしてもMaildirが必要な場合は、ダミーのPOPアカウントを作り、それを「疑似ローカルフォルダアカウント」として使い、巨大なフォルダーでコンパクトが発生してほしくないものだけをその下に置く。
といった、運用の工夫をした方が、利口だと思います。
関連づけられたアイデンティティ(差出人情報)を持たない、という、「ローカルフォルダー」という特殊な疑似アカウントよりも、アカウントの削除なども可能な、ダミーサーバーのPOP3アカウントの方が、管理しやすいと思います。
他のアカウント⇒ローカル専用アカウント、の一方通行にして、
そのローカル専用アカウントの中だけで、数少ない巨大なメールフォルダーでメールデータを管理する、
といった感じにして、
各POP3アカウントは単なるメールのダウンローダーとして使う、というふうにすれば、
各POP3アカウントにおける巨大なBerkleyStoreのメールフォルダーファイルを避けられます。
メッセージフィルター、タグ、検索フォルダー、ビュー(絞り込み)などを上手に使えば、べらぼうな数のメッセージフォルダー、というようなのは、避けられます。
また、berkleyStoreならば、10万メールであろうが１ファイルで済むわけですし、メール数が少ない・ファイルサイズが小さいメールフォルダーならばコンパクトによる影響は非常に少ないですし、適材適所、という考えた方もあります。
ご参考までに。
、
ログイン
ユーザー登録
FAQ
検索
