Indexing nightmare, constantly trying to index hundreds of thousands of messages
I've been using TB since the beginning, so like 20 years now, congrats! (to me 😜) Now I have at least 10 accounts and hundreds of folders and everything was fine until I started archiving some old messages in one account, and TB began creating new archive folders like YYYY/YYYY-MM which were being included in the Global Search/indexer by default. So I went to the properties of each folder and unchecked the option to include it in the Global Search results. I could see in the Activity Monitor the indexing of that folder would stop and go on to the next one, until I disabled all 12. Now TB is indexing over 100,000 messages but it doesn't say what folder these are in, I can't seem to find it.
What I did find is the global-messages-db.sqlite database which, after closing TB, I made a backup of, then I found the folderLocations table with hundreds of rows and the IndexingPriority column which had various values of: -1, 20, 40, 50, and 60. I set them all to -1 and TB is still trying to index over 100,000 messages somewhere. Where? and how to stop its madness?!
選ばれた解決策
just rebuild it. My experience over the last 10 or more years with it, is that GLOD actually messes up it's indexes and keeps stuff after it is deleted, or pointers to moved mail and generally drops the ball on a whole host of other questionable things, so at the first hint of slowness, hanging or dodgy search result I rebuild it. An occasions rebuild post major changers is usually a better result than letting it flog around interminably. A rebuild usually takes less than a day and for some reason does not cause those interminable waits while it works out what to index. It is a good overnight job.
この回答をすべて読む 👍 1すべての返信 (4)
Matt said
https://support.mozilla.org/en-US/kb/rebuilding-global-database
Thanks Matt I guess that is what's happening, but usually the indexing tasks happen in each folder and, in Activity Manager, the task will literally say "Indexing # of ## messages in FolderName" where ## << 100,000 but now the task doesn't specify a folder name and just says: "Indexing # of ## messages" where ## is over 132,000 and must represent every message? Is that normal to see under certain circumstances?
And why would the Gloda suddenly need rebuilding, after I was only archiving messages? Do you know what the max size is? or is 2,066,153,472 bytes too large?
選ばれた解決策
just rebuild it. My experience over the last 10 or more years with it, is that GLOD actually messes up it's indexes and keeps stuff after it is deleted, or pointers to moved mail and generally drops the ball on a whole host of other questionable things, so at the first hint of slowness, hanging or dodgy search result I rebuild it. An occasions rebuild post major changers is usually a better result than letting it flog around interminably. A rebuild usually takes less than a day and for some reason does not cause those interminable waits while it works out what to index. It is a good overnight job.
I found a trove of service notifications that were useless keeping, deleted close to 50k messages probably. After turning the indexer back on, it indexed the new archive folders but now it's gone back to indexing every message I guess, I just don't understand that part. It's normal to index new messages/folders and then go back and recreate the whole index of every message? Got the total under 100k now at least. Ok, I'll let it run over night.