Hi,
On 23-11-16 22:15, carlosg@xxxxxxxxx wrote:
Hi Hans,
(Talking with my Tracker maintainer hat)
Hi,
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 for indexers...
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
default ?
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 afterwards.
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 ?
Regards,
Hans
"I don't think we'll support running without tracker anytime
soon."
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.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
