On 23-11-16 22:15, carlosg(a)gnome.org wrote:
(Talking with my Tracker maintainer hat)
> On 23-11-16 15:36, Michael Catanzaro wrote:
> I don't think that is entirely true. I've recently been trying
> to get gnome3 to run on under-powered machines like cheap ARM
> tablets, and I can do "dnf remove tracker" more or less just
> fine, I loose totem due to some weird dependency chain, and I
> think also gnome-documents which I guess is an issue for some
> use-cases, but most of gnome will stay and work just fine.
> I think that is rather short sighted, although tracker overall
> does well with not hogging the system it is still simply too
> heavy for some systems, both in memory use and in generated
> IOs, take e.g. GNOME3 on a raspberry pi running from a sdcard,
> there you really don't want tracker, so if you say:
I can see how Tracker's extra involved I/O may become noticeable in such hw/scenarios
(mainly coming from tracker-miner-fs I presume), it roots in inotify being notoriously bad
The problem we've at the moment is basically that we perform
pretty poorly on resource constrained devices, part of that
is a shitload of running services (on a 512MB device I need
to disable gdm and use startx because running gdm +
gnome-shell together results in swapping which is very
painful on a sdcard).
My "solution" for that is to just dnf remove a whole bunch
of stuff, tracker only being one of them.
I must admit I've never noticed a problem specifically caused
by tracker, the whole experience just sucks, so I've pretty
much been disabling everything I can.
I would prefer a better solution, but given how very bad sdcards
typically are at random access, something like tracker really
_might_ be a problem.
Question which directories does tracker actually scan / monitor by
But memory, I beg to differ :). Running on massif a from-scratch
indexing of this laptop's homedir, tracker-store peaks at 16MB and runs under half of
that for 67/69 snapshots. tracker-miner-fs peaks at 13MB and sits on half of that
In short only tracker-extract is "expected" to misbehave memory-wise (due to
third party libraries, bugs, leaks in those, ...). The other daemons are rather moderate
in memory consumption, although maybe seen over the "I can do without this"
prism, sure looks like a waste ;).
Worth pointing out too, tracker-extract had for years a hard memory limit, so if anything
asked too much memory, tracker-extract would crash and be eventually (re)started at some
point. I ended up removing it because the many bogus retrace reports, the many "it
didn't index this super-important file" complains and because some file/library
combinations actually needed more memory than given (poppler, if you wonder). If a library
leaks or allocates too much memory, it's a bug in the library and should be fixed
there, or so I thought :).
Is that memory limit still there, but configurable and disabled
now, or ?
Can we re-instantiate it ? I would really like to be able
to offer close to the full gnome3 experience on resource
constrained devices, so I'm wondering if tracker can be
configured to behave a bit nicer there. Maybe we can even
get it to autodetect such systems. E.g. re-instate the
hardlimit on systems with less then 1GB of RAM ?
> "I don't think we'll support running without tracker anytime
> I read:
> "I don't think we will have a usable GNOME3 on the Raspberry
> Pi anytime soon."
Tracker comes from the mobile world, it has been used several times there with success,
and has a number of gsettings that allow it to accommodate to very different workloads
(most of them sacrificing instantness for reduced resources). But Tracker is, by default,
optimized for the desktop.
It would be nice if Tracker worked better out of the box on those setups, however I'd
rather put all my fish on the "fix file notification" pan, as that's IMHO
the key to making Tracker a single size for all.