[過去ﾛｸﾞ] /**ファイルシステム総合スレ その7**/ (955ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
201(1): 2007/04/08(日)14:56 ID:+N5qr5Yv(2/3) AAS
updatedb重いよなぁ。
デュアルコアとかマルチプロセッサなら多少は軽減されるだろうか？
ま、どっちにしてもサーバ向けの機能ではないし、いらないっちゃいらない。
202: 2007/04/08(日)15:25 ID:ZmJtdjLW(1) AAS
重いと感じない私は使い方間違ってる？
動作中は確かにディスクアクセスが増えるけど、CPUそんなに使わないし
五分もしないうちに終わるし。
ディスク合計1テラ弱を八割程度しか使ってないから？
ｼｽﾃﾑはP4HT2.8G SATAディスク500GB+400GBです
203: 2007/04/08(日)18:21 ID:kS1N8DBw(1) AAS
updatedb って中身は主として find を呼び出している
シェルスクリプトとして実装されていることが多いですよね。
nice したらそんなに邪魔にならないし、
そんなに邪険にしてやらなくてもいいんじゃないだろうか。
204: 2007/04/08(日)21:30 ID:IVjfIv3g(2/2) AAS
>>201
サーバとデスクトップで区別する理由が分からん。
どっちでも有用だろ。
手動実行しても重たいとは思わないが、
普通はcronでniceつきで回すだろうから全く問題ない。
>>200
rlocateって標準装備してるdist.ってある?
205(1): 2007/04/08(日)21:50 ID:zsJ2r/Ru(1/2) AAS
ちょっと前にさ、locateが速いのはホントにupdatedbのおかげなのか？と思って
・普通にupdatedb + locate
・単なるfind | gzip > list.gz + zgrep
で比較してみた。
そしたら、なんとfind + zgrepの方が、というかlocateよりも
zgrepでリストファイル検索した方が速かった。リスト作るのも
当然findのみの方が速い。updatedbは内部でデータベース作ってる
わけだけど、スペース削減の意味がほとんどない今、もう過去の
遺物かも知れんと思ったよ。
206: 2007/04/08(日)22:05 ID:EmYGF54Z(1) AAS
過去の遺物だろうね。
fedoraではFC3あたりからlocateのサービスが切られてるよ。
それ以前はデフォルトでcronで走るようになってたけど。
207: 2007/04/08(日)22:08 ID:dD+lSYL+(1) AAS
makewhatisも切ってほしい
208(1): 2007/04/08(日)22:44 ID:tkpoMrl5(1/3) AAS
>>205
なんかオレが調べた結果と違うなあ。(ただしFreeBSD上)
手元のPCはディレクトリとか込みで200万ぐらいファイルがあるんだけど、
zgrepで調べたほうが遅くなる。
アルゴリズム的にファイル数が増えるにしたがって差が開くはず。
locateのデータベースはファイルリストをソートし、一つ前のファイルパスと
異なる部分からしか記録してないのでファイルサイズが小さい。
しかも、検索する際にスキャンするデータの大きさはlocatedbのサイズ分だけ
ですむ。
gzipしたファイルを検索する場合は元のファイルの大きさ分スキャンしないと
省10
209(2): 2007/04/08(日)23:31 ID:HNNwKpZg(2/2) AAS
みんなそんなにファイル調べる事あるの？
>>189
コマンドインストールしてるかなら、パッケージ管理用のコマンド使うし
自分がパスを通している所以外にコマンドが入っていることなんてまず無いし・・・
で、動的なファイル検索ならfindを使う。
色々調べ方を指定できるfindの方が便利だし。
つまり、偶にしか使わない機能だから、ちょっと位速くなっても・・・という気分。
210: 2007/04/08(日)23:39 ID:S1gIGviP(3/3) AAS
>>209
一般ユーザで find / するとパーミッションで読めないファイルあるでしょ。
(これはlocateも同じ問題が発生するが)
わざわざ毎回 find / することを防ぐために locatedb 作ってるんだからさ。
locatedb 更新後に追加したら、updatedb 実行すればいいだけだし。
211(1): 2007/04/08(日)23:43 ID:zsJ2r/Ru(2/2) AAS
>>208
こっちはLinux。規模はやっぱり200万ちょっとくらい。
updatedbのデータはもう作らなくなってしまったので今追試は
できないけど、データ構造的にはupdatedbの方が高速になるはずと
いうのは同意。でも、結果はそうでなかったので「？」だった。
「.」で探して全スキャンとかしてみるとどう？
>>209
大抵のファイルのありかは頭に入っているわけなので、
調べる必要がある時は「わからーん」という状況のことが多い。
そういう時にfindではターンアラウンド大きすぎて試行錯誤できず
省3
212(1): 2007/04/08(日)23:52 ID:tkpoMrl5(2/3) AAS
ソースとか溜め込んでるとlocateは便利だよ。
例えば前にコンパイルしたバージョンほげほげのtarballはどこいったって感じで。
あとconfigureでライブラリとかヘッダーファイルがないって言われたときも結構使うね。
Perlのモジュール使ってるときにも元の.pmファイルが見たいときがあるんで使うなあ。
なんとなくだけど、自分でコンパイルしない人はlocate使わないのかも。
213: 2007/04/08(日)23:58 ID:FgPsXoOH(1) AAS
>>212
findだと大変だもんね。
214(2): 2007/04/08(日)23:59 ID:+N5qr5Yv(3/3) AAS
自分でコンパイルするときはどこに何が置かれるのかおよそ把握するし。
ログを残しておけば、それを見ることも出来るし。
コンパイル専用ユーザとか作るのも普通でしょ？
215: 2007/04/09(月)00:04 ID:tkpoMrl5(3/3) AAS
>>211
% time locate / > /dev/null
1.058u 0.014s 0:01.07 99.0% 16+227k 0+0io 0pf+0w
% time zgrep / filelist.sort.gz > /dev/null
2.449u 0.067s 0:02.57 97.2% 97+388k 0+0io 0pf+0w
やっぱzgrepのほうが遅いみたい。
% time zfgrep / filelist.sort.gz > /dev/null
8.372u 0.044s 0:08.45 99.5% 96+379k 0+0io 0pf+0w
% time zegrep / filelist.sort.gz > /dev/null
2.485u 0.029s 0:02.52 99.2% 96+387k 0+0io 0pf+0w
省2
216: 2007/04/09(月)00:05 ID:atKY9uJN(1/4) AAS
>>214
小規模かつ一人でやってんならそうでしょうね。
217: 2007/04/09(月)00:06 ID:vrz2OUFg(1) AAS
>>214
tarball内のファイル名全部を記憶してるわけ？
log取ったあとに移したりすると意味無いから、
ログより新しい情報で無いと使えないことがある。
218(1): 2007/04/09(月)00:12 ID:YK4Cy17y(1) AAS
locateは使った時に便利さが実感できるけど
使わない時は本当に使わないね。
半年くらい前にサウンドデバイスのテストしようとして
locate "*wav" したのが最後だ。
cronで毎日更新してるけどなんかもったいないな。
219: 2007/04/09(月)00:15 ID:atKY9uJN(2/4) AAS
>>218
まぁ、いいんじゃない？
220: 2007/04/09(月)00:17 ID:PFZ7GF/k(1/2) AAS
あー、locateバリバリ使わないとどうにもならなかった事例思い出した。
前任者が勝手コンパイルで入れたsenmdmailの入れ替え。
インストールログが一切なくて、そこらじゅうのマシンのいろんなディレクトリに展開されてる
sendmailの内、どれを使ってコンパイルしたのか分からない。
仕方ないからマシン全てでlocateを実行しましたよ。
findだと日が暮れてたと思う。
結局、コンパイルに使ったソースファイルはどこにもなかったけど。
上下前次1-新書関写板覧索設栞歴
あと 735 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.198s*