メール検索遅くないですか？	No.16886
CHERRYVOICE さん　04/03/04 22:47
別スレッドではお世話になってます。CHERRYVOICEです。 ようやくOEから鶴亀に移行する決心が付き、メールの移行など行ってます。 本格的に使い始めて思ったのですが、メール検索が遅いです。 OEから移行したメールが2万件ほどありますが、全メール対象として、 Fromの1条件のみで検索しても、終わるまでに1分40秒以上かかりました。 一回検索が終わると次は3秒程度で終わるのですが、別の作業をやったり OS立ち上げなおしたりすると、また1分40秒以上かかります。 本文の検索をしているならそれぐらい重いのも分かるのですが、 Fromなどのヘッダ領域での検索でこんなに時間がかかるのはちょっと 違和感を感じてしまいます。 同じことがOEでは4秒で終わりましたので、鶴亀独自の何かがあるの かなぁ、と思ってます。それとも、私のマシンが異常なんでしょうか？ Win2000  Pen4 2.0GHz、メモリ1GB 使用バージョン  3.21

[ △ ]

RE:16886 メール検索遅くないですか？	No.16894
秀まるお2 さん　04/03/05 13:37
検索している最中に、鶴亀本体ウィンドウのステータスバー部分に、例えば 　「メール一覧作成中 - XXXX」 　みたいなのが出るでしょうか？。これが出ると遅くなります。 　例えば、パソコンに複数OSをインストールしてて、それぞれのOSでメール一覧 の表示関係の設定が違っていたりすると、OSを起動する度にメール一覧の作成し なおしが起動してしまうことがありますけど。 　あと、From:部分からメールアドレスだけを検索したいなら、「検索・メール アドレス検索...」を使った方がはるかに高速になります。ただし、上記「メー ル一覧の作成中...」が出てしまうなら問題外です。

[ △ ]

RE:16894 メール検索遅くないですか？	No.16909
CHERRYVOICE さん　04/03/05 21:50
こんばんは、コメントありがとうございます。 CHERRYVOICEです。 >　検索している最中に、鶴亀本体ウィンドウのステータスバー部分に、例えば > >　「メール一覧作成中 - XXXX」 > >　みたいなのが出るでしょうか？。これが出ると遅くなります。 タイトルバーにも、ステータスバーにも、そのような表示は出ません。 ステータスバーには通常どおりフォルダ内のメール数が表示されたままです。 メール一覧がlist.binのことだとしたら、検索の前後で更新日付が 変わってませんでしたので、作成し直したということはないと思います。 >　例えば、パソコンに複数OSをインストールしてて、それぞれのOSでメール一覧 >の表示関係の設定が違っていたりすると、OSを起動する度にメール一覧の作成し >なおしが起動してしまうことがありますけど。 OSはWin2000のみです。 鶴亀は最近入れたばかりなので、設定を複数持っているということも ないです。 このコメントからすると、やはり検索に1分40秒かかるのは通常あり得ない ことなんでしょうか？ とりあえず本日確認した内容含め状況を整理します。 ・検索は受信フォルダとそのサブフォルダ全体に対して実施 ・受信フォルダ内のサブフォルダ数は19 ・検索中のCPU使用率は4〜5%程度で推移。特に処理が重いわけではない？ ・検索結果一覧で、「検索中 - フォルダ名（○○/○○）」という表示の   推移が目に見えて遅い。大体150件/秒くらいで推移。   途中で引っかかっているわけではなく、まんべんなく遅い。 ・ウィルスバスターのリアルタイムモニタはOFFにしても変化なし あとほかに、こちらで調べられることがありますでしょうか？ >　あと、From:部分からメールアドレスだけを検索したいなら、「検索・メール >アドレス検索...」を使った方がはるかに高速になります。ただし、上記「メー >ル一覧の作成中...」が出てしまうなら問題外です。 メールアドレス検索は、アドレス一部だけの入力ではヒットしてくれない ので、今ひとつうまく使えていませんね。。

[ △ ]

RE:16909 メール検索遅くないですか？	No.16920
Iranoan さん　04/03/06 14:22
CHERRYVOICE さん今日は、Iranoan です。 　私の環境は Windows98 で OS 自体は若干軽くなりますが、 > Win2000  Pen4 2.0GHz、メモリ1GB という環境に比べ、AMD K6-II 400 [MHz], 256 [MB] という圧倒的に貧弱な環 境です。それでも 4 万通強のメールでも 20 [s] とかかりませんでしたので > やはり検索に1分40秒かかるのは通常あり得ない は、やはり通常あり得ないと思います。念の為、クラスタのチェックをする設 定にしてスキャン・ディスクを行ってみては如何でしょう? 可能性は高くあり ませんが、鶴亀のメール・ファイルが書き込まれた部分のクラスタだけに不良 があると、OutLook Express で早くても、鶴亀でだけ遅いということが起きま す。

[ △ ]

RE:16920 メール検索遅くないですか？	No.16927
秀まるお2 さん　04/03/06 22:45
ハードディスクに不良クラスターがあると、たしかに極端にディスクアクセス が遅くなります。 　あと他には、 　−　アンチウィルスソフトとの相性問題 　　　　　--> アンチウィルスソフトを停止させて試してみる。 　−　Windows2000/XPでのインデックスサービスのせい 　　　　　--> インデックスサービス（Indexing Service）を停止させて 　　　　　　　試してみるか、またはハードディスクのプロパティ上で、 　　　　　　　「このディスクにインデックスを付けて検索を高速にする」 　　　　　　　オプションをOFFにする。 　というのが考えられます。 　検索してる時にタスクマネージャを表示しておいて、そこでCPU使用率を観察 するというのも１つの手かもしれません。もしかしてそのときに鶴亀メール以外 のプロセス（アンチウィルスソフトなど）がCPUを食っているなら、それが原因 てことになります。 　あともう１つありました。もしかしてIDEハードディスクのDMA転送 （UltraDMA33〜UltraDMA133）が無効になっていてPIO転送になってると、ハード ディスクアクセスが極端に遅くなってしまうことが考えられます。

[ △ ]

RE:16927 メール検索遅くないですか？	No.16930
CHERRYVOICE さん　04/03/07 03:00
こんばんは、CHERRYVOICEです。 コメントありがとうございます。 問題があるのは会社のPCなので、詳細はまた月曜日に確認してみます。 とりあえず、本来はそこまで遅くないはず、ということが分かりましたので、 改善の余地ありってことで安心しました。

[ △ ]

RE:16927 メール検索遅くないですか？	No.16951
CHERRYVOICE さん　04/03/08 22:53
こんばんは、CHERRYVOICEです。 本日調査してみた結果です。 > スキャン・ディスクを行ってみては如何でしょう? 特に不良はありませんでした。 >　−　アンチウィルスソフトとの相性問題 >　　　　　--> アンチウィルスソフトを停止させて試してみる。 以前にもリアルタイム検索停止は試したのですが、今日はソフトそのものを 終了させて実験してみました。結果は変わらず、検索は遅いままでした。 >　−　Windows2000/XPでのインデックスサービスのせい 試してみましたが、検索は遅いままでした。 > CPU使用率を観察 以前にも書きましたが、CPU使用率は平均4〜5%で推移しています。 特に何かの処理で重くなっているということではないようです。 > IDEハードディスクのDMA転送（UltraDMA33〜UltraDMA133）が無効に 無効になっているということはありませんでした。 HDDはIBM IC35L040AVER07-0で、UDMA100までサポートしているはずが 何故かUDMA33で動いていたようですが、PIOモードになっていると いうことはなかったです。 念のためHDBenchで計測したところ、Read/Writeともに22000前後でした。 今回の現象が、 ・起動時一発目だけが遅く、二回目以降は問題ない ・CPU使用率は高くない。 ということから、どう考えてもHDD周りだと思うのですが、キャッシュが 効いているのかと思い、一回検索を行って検索が早くなったところで 同じドライブから40MB程度のファイルを開いたあと検索を行っても、 検索は早いままでした。 （キャッシュの問題かどうかは、このような試し方で良いんでしょうか？） 最後に、ホームディレクトリを"D:\TuruKameData"に置く設定となっていたので、 ホームディレクトリを丸ごとCドライブにコピーしたあと、ホームディレクトリの 設定を"C:\TuruKameData"にして実験してみたところ、劇的に症状が改善 されました！ ちなみにCドライブはMAXTOR 6L040L2、UDMA100でHDBenchはRead/Writeともに 34000程度で、スコア上はDドライブと大きな差があるわけではありません。 スコア上1.5倍程度の違いしかありませんが、OS起動直後の検索速度は、   Cドライブ：5〜6秒   Dドライブ：1分40秒 というように大きな違いがあります。 ドライブが違うことによって検索速度が大きく変わってくるなど、あり得る のでしょうか？ とりあえずCドライブで使っている限りは快適に使えそうですので当面の 問題は回避できましたが、原因ははっきりしないままです。 何か原因で考えられることはありますでしょうか？ できればシステムドライブとメールを置く場所は分けておきたいので、 ホームディレクトリをDドライブに戻せないかなぁ、と思っています。 よろしくお願いします。

[ △ ]

RE:16951 メール検索遅くないですか？	No.16953
ねむりん さん　04/03/08 23:37
>最後に、ホームディレクトリを"D:\TuruKameData"に置く設定となっていたので、 >ホームディレクトリを丸ごとCドライブにコピーしたあと、ホームディレクトリの >設定を"C:\TuruKameData"にして実験してみたところ、劇的に症状が改善 >されました！ CとDがIDEの同じチャネルにつながってるんじゃないですか？

[ △ ]

RE:16951 メール検索遅くないですか？	No.16954
アルビレオ さん　04/03/08 23:56
アルビレオです。 >最後に、ホームディレクトリを"D:\TuruKameData"に置く設定となっていたので、 >ホームディレクトリを丸ごとCドライブにコピーしたあと、ホームディレクトリの >設定を"C:\TuruKameData"にして実験してみたところ、劇的に症状が改善 >されました！ >ちなみにCドライブはMAXTOR 6L040L2、UDMA100でHDBenchはRead/Writeともに >34000程度で、スコア上はDドライブと大きな差があるわけではありません。 >スコア上1.5倍程度の違いしかありませんが、OS起動直後の検索速度は、 >  Cドライブ：5〜6秒 >  Dドライブ：1分40秒 >というように大きな違いがあります。 >ドライブが違うことによって検索速度が大きく変わってくるなど、あり得る >のでしょうか？ もしかするとOEのデータはCドライブに置かれていて、そのせいで速度が違うだ けではないでしょうか？ >ホームディレクトリを丸ごとCドライブにコピーした これは結果的に鶴亀のデータだけをデフラグしたのと同じような効果があります。 Dドライブにデフラグをかけて、鶴亀のデータをDドライブに戻すと速くなってい るかもしれません。 HDBENCHによるテストでは、(たぶん)テスト用のダミーファイルを作ってそこへ のアクセス速度を測るため、すでに分断化されているファイルへのアクセス速度 の参考にはならないと思います。 また、分断化による速度の低下はディスクアクセスのためCPUの待ち時間が増え るだけなので、時間がかかってもCPU使用率は低いままです。 原因が何にしろ、鶴亀の問題というよりCHERRYVOICEさんのDドライブに原因があ る可能性が高い気がします。

[ △ ]

RE:16954 メール検索遅くないですか？	No.16955
CHERRYVOICE さん　04/03/09 00:26
こんばんは、コメントありがとうございます。 CHERRYVOICEです。 > CとDがIDEの同じチャネルにつながってるんじゃないですか？ 確かそれぞれ、プライマリのマスターとスレーブにつながっていますが、 これはごく普通の状態ではないのでしょうか？ >もしかするとOEのデータはCドライブに置かれていて、そのせいで速度が違うだ >けではないでしょうか？ OEのデータもDドライブに置いてます。 >>ホームディレクトリを丸ごとCドライブにコピーした >これは結果的に鶴亀のデータだけをデフラグしたのと同じような効果があります。 >Dドライブにデフラグをかけて、鶴亀のデータをDドライブに戻すと速くなってい >るかもしれません。 ひょっとしたらそれもあるかもしれませんが、それにしては遅すぎるという 気もします。 それに、断片化によりHDDヘッドのシークが多発しているようでしたら、2回目 以降も検索は遅いはずで、いまいちしっくり来ません。 （それでHDDのキャッシュを疑ったのですが、今日の実験方法に間違いさえ   なければ、その可能性もなさそうです） あ、それから、2万通ほどあるメールはOEからインポートしたばかりですので、 いきなり断片化しまくっているというのはあり得ない気もします。 インポートしたときのフォルダの設定は、メール用ファイルは「可能な限り分割 しない」、「制限サイズは2MB」です。 一応デフラグはやろうと思ったのですが、「分析」までしたところでデフラグの 必要なしと出たので、そこで止めていました。 とりあえず、明日時間があればデフラグをやってみるか、単純にCドライブに 移したものをDドライブに再度コピーし直して試してみます。 >原因が何にしろ、鶴亀の問題というよりCHERRYVOICEさんのDドライブに原因があ >る可能性が高い気がします。 そのような気はしてきているのですが、うまく説明がつかないので首を かしげているところです。 ちょっと質問なのですが、「検索して一覧を作成」で「送り主」を検索した 場合、鶴亀が見に行くファイルはメール本文が入っているtxtファイルでしょうか？ それとも、list.binでしょうか？

[ △ ]

RE:16955 メール検索遅くないですか？	No.16957
CHERRYVOICE さん　04/03/09 01:44
CHERRYVOICEです。 またちょっと考えていたのですが、ひとつ思いついたことがあります。 自分はこれまでHDD内のキャッシュのことしか考えていなかったのですが、 オンメモリでキャッシュされると言うことはあるのでしょうか？ すなわち、鶴亀でメール検索したとき、検索対象のファイルがメインメモリ 上にキャッシュされるという可能性です。 （このへんイマイチ詳しくないので、識者の方フォロー願います） この想像が正しいとすると、ファイルの断片化により一回目の検索に 時間がかかり、二回目の検索が早いという結果もうなずけます。 ファイルの断片化のしやすさから言うと、やはりファイルサイズの大きい、 メール本文が入っているtxtファイルの方を、鶴亀は見に行っているのでは ないかと推測します。 では、何故そのような断片化が発生してしまったか？という点ですが、 先にも書き込みましたように、現在格納されている2万通ほどのメールは OEから「可能な限り分割しない」、「制限サイズは2MB」でフォルダごとに 一括（「フォルダを指定し、フォルダ内の.emlファイルをすべてインポート する」設定）でインポートしたものです。 そのため、19あるフォルダそれぞれに、2MBのtxtファイルが4個前後ある、 という構成になっており、全体でのファイル数はそれほど多いわけでは ありません。従って、各ファイルがバラバラの位置に保存されたから検索が 遅くなったという可能性は無いと思います。 とすると、このひとつひとつのtxtファイルがそれぞれ断片化されている、 という結論になります。 ここまで推論ばかりで話を展開しましたが、結局のところ、鶴亀で「フォルダを 指定し、フォルダ内の.emlファイルをすべてインポート」をすると、 メールをひとつインポートするたびにファイルを継ぎ足していって、その結果 ファイルが非常に断片化されやすくなるのではないか、という点が気になる ところです。 とりあえず、明日の実験結果待ち状態ですが、こんな可能性もあるのではないか？ ということで書き込みさせて頂きました。 詳細はまた明日確認します。

[ △ ]

RE:16957 メール検索遅くないですか？	No.16958
アルビレオ さん　04/03/09 04:04
アルビレオです。 >自分はこれまでHDD内のキャッシュのことしか考えていなかったのですが、 >オンメモリでキャッシュされると言うことはあるのでしょうか？ >すなわち、鶴亀でメール検索したとき、検索対象のファイルがメインメモリ >上にキャッシュされるという可能性です。 >（このへんイマイチ詳しくないので、識者の方フォロー願います） アプリケーションがキャッシュしているかは作者でないとちょっとわからないで すが、以前list.bin相当の物をメモリ上に作成するというコメントがありました。 また、HDDのキャッシュの他にOSが管理しているキャッシュがあります。 >ファイルの断片化のしやすさから言うと、やはりファイルサイズの大きい、 >メール本文が入っているtxtファイルの方を、鶴亀は見に行っているのでは >ないかと推測します。 list.binの中身を覗いてみると、From:の内容が含まれていました。 >「検索・メールアドレス検索...」を使った方がはるかに高速になります。 というのはこのコマンドの場合はlist.bin(相当のメモリ上のインデックス)から 検索するということでしょう。 逆にいえば通常の検索ではこのデータを使うわけではないので、有効なのはドラ イブに内蔵されたキャッシュとOSのキャッシュだと思われます。 >このひとつひとつのtxtファイルがそれぞれ断片化されている、 >という結論になります。 「ファイルの断片化」というのはひとつのファイルがディスク上のあちこちに散 らばって配置されることを言います。 小さなファイルが散らばっている場合はファイルの断片化に比べれば大した影響 はありません。 >一応デフラグはやろうと思ったのですが、「分析」までしたところでデフラグの >必要なしと出たので、そこで止めていました。 これは鶴亀のデータをDドライブから削除した後に確かめたのではないでしょう か？ 上に書いたように、断片化というのはある程度大きなサイズのファイルがなけれ ば起こりません。 大きなファイルでも更新の頻度が低いとそれほど断片化しませんが、鶴亀の.txt ファイルは送受信のたびに書き換えられるため断片化しやすい性質を持っていま す。 肝心の断片化していたファイルを消した後で「分析」すれば、デフラグの必要が ないと判断することはあり得ます。 >ここまで推論ばかりで話を展開しましたが、結局のところ、鶴亀で「フォルダを >指定し、フォルダ内の.emlファイルをすべてインポート」をすると、 >メールをひとつインポートするたびにファイルを継ぎ足していって、その結果 >ファイルが非常に断片化されやすくなるのではないか、という点が気になる >ところです。 すでに空いている場所が飛び飛びであればそういうことも起こります。 そして空き領域が飛び飛びでも断片化とは判断されません。 メールをインポートしたことが直接の原因ではなく、ドライブの中身が断片化し やすい状態だったということに注意してください。 まだ結論を出すのは早いですが、ドライブの違いだけでこれだけ差が出ているこ とと鶴亀のデータを置いたドライブは断片化が起こりやすいことを考えると、鶴 亀のデータを置いたドライブは定期的にデフラグをかけた方がよさそうですね。 デフラグをする頻度は送受信の程度によって違うのでなんともいえませんが、 データを置いたままならデフラグの「分析」で警告してくれると思うので、月に 一度はチェックしてみるといいと思います。 とりあえず今回はデフラグをかけた後でデータをDドライブに戻してください。 先にデータを戻してからだと余計な時間がかかるだけなので。

[ △ ]

RE:16957 メール検索遅くないですか？	No.16959
秀まるお2 さん　04/03/09 14:36
> > スキャン・ディスクを行ってみては如何でしょう? > 特に不良はありませんでした。 　クラスタースキャンをやってなければ、それをやってみることをお勧めします。 Dドライブのプロパティから「ツール・エラーチェック・チェックする...」を押 して、「不良なセクタをスキャンし、回復する」をONにしてから「開始」ボタン を押す形になります。 　あと、ディスクアクセスは全面的にWindowsがメモリ上にキャッシュするので、 一度アクセスしたファイルは２回目以降は非常に速くアクセスされます。

[ △ ]

RE:16958 メール検索遅くないですか？	No.16967
CHERRYVOICE さん　04/03/10 00:20
こんばんは、CHERRYVOICEです。 本日実験した結果をご報告します。 結論から言うと、DドライブからCドライブにコピーしたホームディレクトリを、 再度Dドライブにコピー（もともとDドライブにあったデータはそのまま）して やることで、Dドライブでも検索が早く完了するようになりました。 （デフラグなしでもOKでした。単純なC→Dのファイルコピーなので、断片化は   発生せずにデータ移行できたのだと思います） この結果から見るに、ファイルの断片化が問題であったことは、ほぼ間違いが なさそうです。 いろいろご助言頂いた方、大変ありがとうございました。 ------ ところで、ここで気になったことがあるのですが、今回のように2MB区切りで インポートした場合、それぞれの2MBのファイルは断片化してしまうので しょうか？ 自分は断片化というと、保存しようとするファイルのサイズより大きい 空き領域がなかった場合にファイルが分割されるか、いったん保存された ファイルにデータを追加した際、連続した空き容量がなかった場合に 分割されるか、どちらかしかないかと思っていました。 先の書き込みにも書いていたのですが、もし鶴亀のインポートが「フォルダを 指定し、フォルダ内の.emlファイルをすべてインポート」した場合でも、 一通一通ファイルに追加するようにデータを構成していくなら、どうしても 断片化しやすくなってしまうのではないかと思います。 そうではなく、今回のように2MB区切りと分かっているならば、オンメモリで 2MB分のデータがたまったところでファイルに保存に行くようにすれば、 断片化が最小限に抑えられるのではないでしょうか？ （半分仮定で書いていますので、間違いありましたらご指摘願います） ------ 以下、いただいたコメントへのコメントです。 >>ファイルの断片化のしやすさから言うと、やはりファイルサイズの大きい、 >>メール本文が入っているtxtファイルの方を、鶴亀は見に行っているのでは >>ないかと推測します。 > >list.binの中身を覗いてみると、From:の内容が含まれていました。 >>「検索・メールアドレス検索...」を使った方がはるかに高速になります。 >というのはこのコマンドの場合はlist.bin(相当のメモリ上のインデックス)から >検索するということでしょう。 >逆にいえば通常の検索ではこのデータを使うわけではないので、有効なのはドラ >イブに内蔵されたキャッシュとOSのキャッシュだと思われます。 以前の環境では、確かメールアドレス検索をやっても遅かったと思うのですが、 list.binはそのサイズから言ってあまり断片化しなさそうな気もします。 ここはちょっと疑問のまま？ですが。 >>一応デフラグはやろうと思ったのですが、「分析」までしたところでデフラグの >>必要なしと出たので、そこで止めていました。 > >これは鶴亀のデータをDドライブから削除した後に確かめたのではないでしょう >か？ いいえ、データは残したままにしてありました。 今日も確かめてみましたが、「必要なし」と出てました。 ただ、「必要なし」と判断するのは全体的な割合からOSが見て言っているだけ だと思うので、鶴亀のデータが断片化していないかどうかの確認としては 少々不適切だったと思います。 >すでに空いている場所が飛び飛びであればそういうことも起こります。 >そして空き領域が飛び飛びでも断片化とは判断されません。 >メールをインポートしたことが直接の原因ではなく、ドライブの中身が断片化し >やすい状態だったということに注意してください。 それは確かにそう思います。 ただ、その領域へのファイルの置き方によっては、上にも書いたように 断片化の発生のしやすさが違ってくるのじゃないかと思っているのですが、 どうなのでしょう？ このあたりはファイルシステムの話になってくるのでしょうか。 >まだ結論を出すのは早いですが、ドライブの違いだけでこれだけ差が出ているこ >とと鶴亀のデータを置いたドライブは断片化が起こりやすいことを考えると、鶴 >亀のデータを置いたドライブは定期的にデフラグをかけた方がよさそうですね。 >デフラグをする頻度は送受信の程度によって違うのでなんともいえませんが、 >データを置いたままならデフラグの「分析」で警告してくれると思うので、月に >一度はチェックしてみるといいと思います。 上記のように、デフラグでの「分析」での警告だけでは不十分かも知れません。 ただ、少なくとも昔に受信したメールを改編せずそのまま保存してあれば そのファイルは断片化が進行することはありませんので、最近受信したもの だけについて配慮しておけばよいのかも。 >　クラスタースキャンをやってなければ、それをやってみることをお勧めします。 >Dドライブのプロパティから「ツール・エラーチェック・チェックする...」を押 >して、「不良なセクタをスキャンし、回復する」をONにしてから「開始」ボタン >を押す形になります。 フルオプションでチェックしましたので、不良セクタはなさそうです。 この結果からも、原因が断片化であったのはほぼ間違いないと思います。 >　あと、ディスクアクセスは全面的にWindowsがメモリ上にキャッシュするので、 >一度アクセスしたファイルは２回目以降は非常に速くアクセスされます。 やはりそうなのですね。 現象として納得がいきました。ありがとうございました。

[ △ ]

RE:16967 メール検索遅くないですか？	No.16976
アルビレオ さん　04/03/10 10:31
アルビレオです。 >ところで、ここで気になったことがあるのですが、今回のように2MB区切りで >インポートした場合、それぞれの2MBのファイルは断片化してしまうので >しょうか？ >自分は断片化というと、保存しようとするファイルのサイズより大きい >空き領域がなかった場合にファイルが分割されるか、いったん保存された >ファイルにデータを追加した際、連続した空き容量がなかった場合に >分割されるか、どちらかしかないかと思っていました。 単に2MBのファイルをコピーするならそうなりますが、メールをインポートする 場合はメール一つ一つを.txtファイルに「追記」することになります。 >先の書き込みにも書いていたのですが、もし鶴亀のインポートが「フォルダを >指定し、フォルダ内の.emlファイルをすべてインポート」した場合でも、 >一通一通ファイルに追加するようにデータを構成していくなら、どうしても >断片化しやすくなってしまうのではないかと思います。 メールをインポートしている最中には最終的にどれくらいの大きさになるかわか らないので、あらかじめ必要な大きさを確保してからインポートを始めるような ことは難しいと思います。 >そうではなく、今回のように2MB区切りと分かっているならば、オンメモリで >2MB分のデータがたまったところでファイルに保存に行くようにすれば、 >断片化が最小限に抑えられるのではないでしょうか？ >（半分仮定で書いていますので、間違いありましたらご指摘願います） 断片化は少なくなるでしょうが、リスクは大きくなります。 メール内容のやりとりについては、何らかの原因で異常終了しても内容が消えて しまわないようにできるだけこまめにファイルに書き込んでいるようです。 安全性を低下させてまで断片化しにくい方法を取るのはいいことではないでしょ う。 インポートに限ればインポート元ファイルがあるので安全性は気にする必要はな さそうですが、振り分けなどの複雑な処理が入ることを考えるとインポートのと きだけ特別な処理をするというのはかなり難しいと思います。 それにインポート後に手動で振り分けたら、断片化を防ぐ工夫は無意味になって しまうことは想像できるでしょう。 添付ファイルやエンコードの関係でインポート元のファイルサイズからインポー ト後の.txtに必要なサイズを推測するのが困難だという問題もあります。 >ただ、「必要なし」と判断するのは全体的な割合からOSが見て言っているだけ >だと思うので、鶴亀のデータが断片化していないかどうかの確認としては >少々不適切だったと思います。 私も投稿後にデフラグの分析を確かめてみて当てにならないかもしれないと思い ました。 分析の結果として分断化されたファイルのリストも表示されるので、こちらを参 考にした方がよさそうですね。 デフラグは管理者しか実行できない上に時間がかかります。 鶴亀データの断片化を解消するだけなら、CHERRYVOICEが今回取ったような方法 を使った方が簡単でいいでしょう。 １.鶴亀、常駐鶴亀を終了させる ２.鶴亀データフォルダの内容を階層ごと他のフォルダにコピー 　(できれば別ドライブの方がいい) ３.鶴亀データフォルダの内容を丸ごと削除 ４.コピーした内容を鶴亀データフォルダに戻す これだけで少なくとも鶴亀の検索などは本来の速度を取り戻せるはずです。

[ △ ]

RE:16967 メール検索遅くないですか？	No.16986
Iranoan さん　04/03/10 13:36
CHERRYVOICE さん今日は、Iranoan です。 > この結果から見るに、ファイルの断片化が問題であったことは、ほぼ間違いが > なさそうです。 　これが原因であるなら、ファイル・システムがもし FAT(32) になっている なら、 > Win2000  Pen4 2.0GHz、メモリ1GB との事なので NTFS にすると、断片化する頻度が減ると思います

[ △ ]

RE:16976 メール検索遅くないですか？	No.17061
CHERRYVOICE さん　04/03/13 00:56
CHERRYVOICEです。 宿泊出張のため亀レスになってしまいました。 >インポートに限ればインポート元ファイルがあるので安全性は気にする必要はな >さそうですが、振り分けなどの複雑な処理が入ることを考えるとインポートのと >きだけ特別な処理をするというのはかなり難しいと思います。 >それにインポート後に手動で振り分けたら、断片化を防ぐ工夫は無意味になって >しまうことは想像できるでしょう。 私がやったのはメーラーの移行なので、そもそもすでに振り分けられている ものをフォルダごとにそのまま移行しただけでした。全く振り分け処理は していません。 そもそも大量にインポートする場合はそのようなケースの方が多いと思うので、 振り分けの重要性を考えるよりかは、断片化のリスクを減らす方が重要度が高い ような気もします。 まぁ、このあたりは人それぞれでしょうけど。 ただ、インポートの処理に、通常のメール受信と同じアルゴリズムを使って いるのであれば、それだけ特別な処理をするのが面倒だというのは想像できます。 >添付ファイルやエンコードの関係でインポート元のファイルサイズからインポー >ト後の.txtに必要なサイズを推測するのが困難だという問題もあります。 これはいくらでもやりようがあると思います。 デコード後にいくらでもサイズ計算ができるわけですから。 これ以上はあまりここで議論してても仕方がなさそうなので、この辺にして おきます。 >分析の結果として分断化されたファイルのリストも表示されるので、こちらを参 >考にした方がよさそうですね。 こちらまでは確認できてませんでしたね。 確かにこちらの方が確実でしょうね。

[ △ ]

RE:16986 メール検索遅くないですか？	No.17062
CHERRYVOICE さん　04/03/13 00:57
CHERRYVOICEです。こんばんは。 >　CHERRYVOICE さん今日は、Iranoan です。 >> この結果から見るに、ファイルの断片化が問題であったことは、ほぼ間違いが >> なさそうです。 >　これが原因であるなら、ファイル・システムがもし FAT(32) になっている >なら、 >> Win2000  Pen4 2.0GHz、メモリ1GB >との事なので NTFS にすると、断片化する頻度が減ると思います ファイルシステムは、NTFSでした。

[ △ ]

RE:17061 メール検索遅くないですか？	No.17064
tnobu2 さん　04/03/13 09:49
ファイルの断片化について論議が進んでいるようですが、断片化を防止 させる処理を持たせることはほとんど意味がないと思います。 理由は下記の通りです。 1)ドライブに余裕がある場合は断片化しても速度にあまり影響が出ない 2)断片化防止処理のためにむしろ書き込み処理が遅くなる可能性がある 3)オンメモリで処理して最後に書き出すとハング時のリスクが高くなる 4)複数のアプリが同時にディスクをアクセスしている可能性がある 5)最終的にファイルを管理しているのはOS(Windows)である 結局、こまめにマニュアルでデフラグするか、断片化防止ソフトを導入 するというのが現実的な対応ではないでしょうか。

[ △ ]

---