[
https://issues.apache.org/jira/browse/SOLR-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488469
]
Yonik Seeley commented on SOLR-207:
-----------------------------------
I tried both versions out, and the "find" version was quicker (on Linux at
least).
System time was about the same, but "ls" had much higher user time.
$ time find . -maxdepth 1 -name 'snapshot.*' | grep -v wip | head -1
./snapshot.20070411235957
real 0m0.009s
user 0m0.002s
sys 0m0.008s
$ time ls -r . | grep snapshot\\. | grep -v wip | head -1
snapshot.20070412114504
real 0m0.050s
user 0m0.043s
sys 0m0.009s
> snappuller inefficient finding latest snapshot
> ----------------------------------------------
>
> Key: SOLR-207
> URL: https://issues.apache.org/jira/browse/SOLR-207
> Project: Solr
> Issue Type: Bug
> Components: replication
> Reporter: Yonik Seeley
> Attachments: find_maxdepth.patch
>
>
> snapinstaller (and snappuller) do the following to find the latest snapshot:
> name=`find ${data_dir} -name snapshot.* -print|grep -v wip|sort -r|head -1`
> This recurses into all of the snapshot directories, doing much more disk-io
> than is necessary.
> I think it is the cause of bloated kernel memory usage we have seen on some
> of our Linux boxes, caused
> by kernel dentry and inode caches. Those caches compete with buffer cache
> (caching the actual data of the index)
> and can thus decrease performance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
