Re: [Tracker] Memory usage for tracker-extract and tracker-miner-fs

[Joe Rhodes <lists joerhodes com>]

Carlos:

Here are the numbers as requested:

 tracker status -a | grep -e "nfo:Folder" -e "nfo:FileDataObject"
  nfo:FileDataObject = 1704170
  nfo:Folder = 286147

As for the Netatlak deal, I was working with the developer.  It seemed that if you ran a query from a Mac 
that would return too many results, it would crash the Netatalk server.  So he put in code that returns 20 at 
a time to prevent that.  So on a volume like this, when you have several hundred results, it takes a LONG 
time for the list to complete.  Again, nothing to do with Tracker.

Cheers!
-Joe

> On Jan 21, 2016, at 7:01 AM, Carlos Garnacho <carlosg gnome org> wrote:
>
> Hey Joe,
>
> On Thu, Jan 21, 2016 at 3:38 AM, Joe Rhodes <lists joerhodes com> wrote:
> > Indeed.  I was mistaken about the memory usage.   Tracker-miner-fs has now stabilized at about 265 MB of 
> > RAM.  I force a re-crawl once every two hours to update the index.
>
> Thanks for the update! would be great if you could provide the output of:
>
>  tracker status -a | grep -e "nfo:Folder" -e "nfo:FileDataObject"
>
> So I have some solid numbers instead of ballpark estimations for cases
> like yours :).
>
> > I've disabled the content searching for now by removing all the rules.  Nothing to do with Tracker.  It 
> > just took too long for the search results to populate on the Mac clients over Netatalk.  In this case, I 
> > *know* the bottleneck is in Netatalk.
>
> Hmm, I guess netatalk queries fall into some performance pitfall, if
> that's the case.
>
> > So for my purposes, 1.7.2 is looking great.   Thanks!
>
> You're welcome :). Thanks for helping us catch this soon.
>
> Cheers,
>  Carlos