beagled eating lots of VM again

Well, here we are, 3 days after beagled was started and 1 day and 3:05:22 of CPU time later and beagled is up in the 585M/364M of VM/RSS neighborhood. I'd sure love to have beagle with heap-shot running this long to see if it gets this big with it and where the memory is going but it crashes too

Thunderbird backend - disabled by default

Hi Recently 4 major problems have been reported with the thunderbird backend: 1) Heavy memory consumption (while parsing the mork file) 2) Exceptions while parsing the mork file 3) Indexing mails in a non-standard location (there is a bugzilla entry for that, I think) 4) Mail directory found,

Re: beagled eating lots of VM again

Well, here we are, 3 days after beagled was started and 1 day and 3:05:22 of CPU time later and beagled is up in the 585M/364M of VM/RSS neighborhood. I am sure you mentioned this somewhere before, but what backends are you running ? If you have everything on by default, what backends are

Re: stuck in file crawl task loop

On Mon, 2007-01-22 at 17:43 -0500, Joe Shaw wrote: Hi, On Mon, 2007-01-22 at 17:14 -0500, Michael Hill wrote: I'm running the same version here on Feisty, and I've been following Brian's tribulations with interest. Admittedly I'm running a little close to the wire with ~ 6 gigs free on

Re: beagled eating lots of VM again

On Tue, 2007-01-23 at 08:59 -0500, D Bera wrote: I am sure you mentioned this somewhere before, but what backends are you running ? If you have everything on by default, what backends are actually active: beagle-info --index-info (when beagled is running) will print non-zero count for the

Re: Thunderbird backend - disabled by default

Hi, On Tue, 2007-01-23 at 08:41 -0500, D Bera wrote: Recently 4 major problems have been reported with the thunderbird backend: 1) Heavy memory consumption (while parsing the mork file) 2) Exceptions while parsing the mork file 3) Indexing mails in a non-standard location (there is a

Re: stuck in file crawl task loop

Hey, On Mon, 2007-01-22 at 18:09 -0500, Brian J. Murrell wrote: They are whatever comes in Ubuntu's Feisty. Not sure if Kevin is the maintainer there or not. Ah, ok, you're using Feisty packages. That's fine then, that's the official 0.2.14 release. So 0.2.14 has the looping bugs fixed?

Re: beagled eating lots of VM again

Hi, On Tue, 2007-01-23 at 08:30 -0500, Brian J. Murrell wrote: Well, here we are, 3 days after beagled was started and 1 day and 3:05:22 of CPU time later and beagled is up in the 585M/364M of VM/RSS neighborhood. Do you run beagled with --debug-memory? That's a helpful thing to do, because

Re: stuck in file crawl task loop

Hi, On Tue, 2007-01-23 at 10:59 -0500, Michael Hill wrote: On Mon, 2007-01-22 at 17:43 -0500, Joe Shaw wrote: What's filling it? Logs, the text cache, or indexes? The IndexHelper log is 1 G after about 90 minutes. Looks like a bug. Can you send me and dBera the first 1000 and last 1000

Re: stuck in file crawl task loop

On Tue, 2007-01-23 at 11:54 -0500, Joe Shaw wrote: They should be fixed in 0.2.14. So what you're seeing is obviously an uncaught one. Cool. :-) The main reason why it would store inside the DB instead of an xattr is permissions. Right. Beagle will try to convert DB entries to xattrs

Re: stuck in file crawl task loop

]:~$ touch /home/brian/sieve.script and the beagle log reports: 20070123 12:44:43.6572 06019 Beagle DEBUG: *** Add '/home/brian' 'sieve.script' (file) Yet: $ echo 'select * from file_attributes where filename = sieve.script;' | sqlite3 ~/.beagle/Indexes/FileSystemIndex/FileAttributesStore.db

Re: stuck in file crawl task loop

Yet: $ echo 'select * from file_attributes where filename = sieve.script;' | sqlite3 ~/.beagle/Indexes/FileSystemIndex/FileAttributesStore.db bo7X958nykipdPCXJdiA+w|/home/brian|sieve.script|20041206030115|200701161726 17|Beagle.Filters.FilterText|0 Thanks Brian. Joe found a clue from in your

Re: stuck in file crawl task loop

Hi, Hmm, this might be the cause of the loop. The code always checks the sqlite database first because it has to[1], which means that if the old ones aren't being dropped from the DB we could be pulling old information. I will look into it. Joe checked in some fixes and debugging hooks to

Re: stuck in file crawl task loop

Hi, Debajyoti Bera wrote: Hmm, this might be the cause of the loop. The code always checks the sqlite database first because it has to[1], which means that if the old ones aren't being dropped from the DB we could be pulling old information. I will look into it. Joe checked in some

Re: comparison of desktop indexers

Michal Pryc wrote: D Bera wrote: Btw, as requested in the tracker mailing list (http://mail.gnome.org/archives/tracker-list/2007-January/msg00172.html), is it possible to somehow share the test data ? It would provide an excellent tool for testing and development purposes.