## Slow to query after sitting for a few hours

Discussion related to "Everything" 1.5 Alpha.
DerekZiemba
Posts: 13
Joined: Thu Sep 27, 2018 4:46 pm

### Slow to query after sitting for a few hours

If I haven't performed a query in Everything for an hour or so (ex: window open but haven't changed the query for a while) or if it's been sitting in the background and I then change the query or open a new window it will get stuck Querying... for up to a minute. This never happened on v1.4. I've been using 1.5 for months and it's been this way for months.
Is this a known issue?

The database size is 554MB & the screenshot shows the # of items it's dealing with
Capture.PNG (9.54 KiB) Viewed 1456 times
Attached are Everything-1.5a.ini, Temporary Excludes-1.5a.csv, & Filters-1.5a.csv
Attachments
Everything.zip

void
David Carpenter (Developer)
Posts: 9392
Joined: Fri Oct 16, 2009 11:31 pm

### Re: Slow to query after sitting for a few hours

Thanks for the bug report DerekZiemba,

This can occur if Everything is paged to disk.
Searching for content (eg: Text Plain Line Count / MD5) may exacerbate the issue.

It might be the Text Plain Line Count column and the MD5 column.

Please try removing these column from all your filters and also removing it from the current result list.
Does the issue persist?

Note: The Text Plain Line Count property will read all the file content to calculate the number of lines.

void
David Carpenter (Developer)
Posts: 9392
Joined: Fri Oct 16, 2009 11:31 pm

### Re: Slow to query after sitting for a few hours

To prevent Everything from being paged to disk (not recommended):
• In Everything, type in the following search and press ENTER:
/min_working_set_size=0xfffffffffffffffe
• Type in the following search and press ENTER:
/max_working_set_size=0xfffffffffffffffe
• Type in the following search and press ENTER:
/virtual_lock=1
• Type in the following search and press ENTER:
/restart
The default settings are:
/min_working_set_size=0
/max_working_set_size=0
/virtual_lock=0

min_working_set_size
max_working_set_size
virtual_lock

DerekZiemba
Posts: 13
Joined: Thu Sep 27, 2018 4:46 pm

### Re: Slow to query after sitting for a few hours

Searching for content (eg: Text Plain Line Count / MD5) may exacerbate the issue.
It might be the Text Plain Line Count column and the MD5 column.
The MD5 column is only present in the "Executable" category and is not an indexed property. Searches with that column present do not seem to be impacted, it just slowly populates the MD5 column in the background for the items currently scrolled in to view, which is nice.
The "Plain Text Line Count" is under most categories and is indexed according to the rules below. Would only removing the column be enough? Also, I really like this feature...

Code: Select all

Maximum size: 1800KB
Include only files:
*.txt;*.ini;*.md;*.bat;*.cmd;*.sh;*.csv;*.json;*.config;*.xml;*.yml;*.js;*.jsx;*.jsm;*.ts;*.tsx;
*.css;*.htm;*.html;*.ps1;*.psm1;*.psd1;*.cs;*.vb;*.rb;*.c;*.cc;*.cpp;*.cxx;*.h;*.hpp;*.hx;*.java;
Exclude folders:
C:\Windows\;C:\ProgramData\;C:\Program Files\;C:\Program Files (x86)\;C:\msys64\;\AppData\;\node_modules\;
\packages\;\resources\;\*cache*\;\tmp\;\temp\;\.git\;\.svn\;\obj\;\.nuget\;\Nuget\;\NuGetFallbackFolder\;
\locale\;\_locale\;\locales\;\_locales\;\locales-src\;\lang\;\langpack\;\language*\;
\de\;\de-DE\;\en_CA\;\en_GB\;\es\;\es-ES\;\fr\;\fr-FR\;\fr_CA\;\it\;\it-IT\;\ja\;\ja-JP\;\ko\;
\ko-KR\;\pl\;\pt-BR\;\ru\;\ru-RU\;\tr\;\zh-CHS\;\zh-CHT\;\zh-CN\;\zh-TW\;\zh-Hans\;\zh-Hant\


Regarding paging to disk:
I have 32GB of ram so haven't considered that. After checking process statistics, paging may be a very likely culprit. I can already see the "Working set" is significantly less than "Private bytes", suggesting 780mb of the 941mb has been paged out.
I like this process more than the others, so I'm going to do the "(not recommended)" thing and hope the system can just find some other process to page out.
I wouldn't call this typical utilization, it actually surprised me to see how little resources were remaining. Apparently having tabs open to charts on pro.coinbase.com causes msedge to eat ream. Usually I see something like Commit charge: ~28GB | Physical memory: ~18GB.

BTW, shouldn't the process paging back in be relatively quick? The time it takes to "Query" when this happens is substantial. A fresh installation using default settings (no indexed properties/content) can build its index and perform its first query in possibly less time.

void
David Carpenter (Developer)
Posts: 9392
Joined: Fri Oct 16, 2009 11:31 pm

### Re: Slow to query after sitting for a few hours

The MD5 column should be fine.

The indexed Plain Text Line Count property should be fine.

It does appear Everything is paged to disk (high private bytes, low working set size)
Is Everything still indexing properties? (status is shown on the right side of the statusbar)

Debug logs might help identify the issue:
• In Everything 1.5, from the Tools menu, under the Debug submenu, check Console.
• Leave Everything running in the background for an hour or so.
• Open a new Everything window.
• After you get a long Querying.... status, what is shown in the debug console? (right click the console window caption and under the Edit menu, click Select All, right click the selected text to copy it to the clipboard)
• Please send the debug output to support@voidtools.com

DerekZiemba
Posts: 13
Joined: Thu Sep 27, 2018 4:46 pm

### Re: Slow to query after sitting for a few hours

In the screenshotted scenario Everything was actually working normally without issue.

The issue is actually very hard to reproduce or deliberately cause. The long "Querying..." episodes happen randomly once then afterwards the frequency of it reoccurring skyrockets or occur nearly every time it has been left unused for a few dozens of minutes. Once it reaches peak annoyance and I consider posting about the issue, it just kinda stops doing it for a while again. I made a post this time only because of the number of prior episodes and was curious if anyone else has experienced this.

The issue has not re-occurred in the past few days. When it does happen the UI remains responsive so I believe I'll be able to open the debug console. When it's stuck in the "Querying..." state no results are displayed. Any newly opened windows will also display "Querying..." and if the search query on any previously opened windows is changed, they too will get stuck "Querying...". After some time, all windows stuck "Querying..." resolve simultaneously.
If I'm remember correctly, Everything's CPU usage while "Querying..." isn't above normal. Perhaps an issue with a synchronization primitive?
-------------
Note that since the last post I performed the steps mentioned to prevent it being paged to disk. I also deleted "Everything-1.5a.db" after realizing I haven't tried rebuilding the database.
Upon next launch it rebuilt the db and spent a while re-indexing properties. The new database size is down to 472mb from 554mb, which I found odd because shouldn't it contain the same data as before?

The last time the database was rebuilt likely would have been due to the release of 1.5.0.1285, when it looks like I went from 1282 to 1289. I do remember thinking that since the DB was being rebuilt, "hmm maybe that'll fix that querying issue". So rebuilding it this time shouldn't prevent the issue from occurring again.

The dates and times I updated are likely to coincide to when the issue has occurred. I likely wouldn't have remembered to check for an update otherwise. It's also an incomplete picture because sometimes instead of clicking "Save to" I've clicked "Open" or there was no update available.

void
David Carpenter (Developer)
Posts: 9392
Joined: Fri Oct 16, 2009 11:31 pm

### Re: Slow to query after sitting for a few hours

Do you have the preview pane shown?

I have noticed some incorrectly installed preview handlers that are missing dlls will cause Everything to freeze on Querying for several minutes.

If I'm remember correctly, Everything's CPU usage while "Querying..." isn't above normal. Perhaps an issue with a synchronization primitive?
There's two different Querying... statuses you should be aware of:

Querying...
The search is not complete.
Old results are still visible.

Querying... x objects
The search is partially complete.
Some results will be shown.
Everything is gathering properties to complete the search request.

Which Querying... status are you seeing?
If you are seeing Querying... x objects, it most likely means Everything is stuck trying to read a file property.

Upon next launch it rebuilt the db and spent a while re-indexing properties. The new database size is down to 472mb from 554mb, which I found odd because shouldn't it contain the same data as before?
This is a little odd.
Indexed properties will be allocated as they are read.
There might be indexed properties that have not been read yet.

There might have been indexed properties included from offline volumes in the old database.

Tools -> Debug -> Statistics shows database allocation information.

DerekZiemba
Posts: 13
Joined: Thu Sep 27, 2018 4:46 pm

### Re: Slow to query after sitting for a few hours

Was able to reproduce it today. Believe its memory related as suspected. OmniSharp ate all the memory so Everything64.exe exhibited the issue.
Not sure this is an actual issue now. I don't think it's reasonable to expect Everything to work properly when no memory is available.
Note that while this screenshot was taken, Everything was stuck "Querying...". So 2.73% more accurately defines "CPU usage... isn't above normal"

At the time this gif was taken, it was already "Querying" for well over a minute. The gif is over 2min long.
It was triggered by simply deleting the prior query "test". Towards the end there you can also see a lot of "VirtualLock" entries.
It may be easier to consume the gif as mp4 https://i.imgur.com/sCHLGWX.mp4

Notice towards the end I exit vscode. This freed up ram and then the results list was almost immediately updated.

Attached is the copied console output as well as Everything Debug Log-1.5a.txt

Which Querying... status are you seeing?
If you are seeing Querying... x objects, it most likely means Everything is stuck trying to read a file property.
Just regular "Querying..." as seen at the start of the gif before I interacted with the menu and caused it to get stuck on "Contains help commands." Can also be seen at 1:41 after cancelling the query.
Last edited by DerekZiemba on Tue Feb 01, 2022 1:01 am, edited 4 times in total.

void
David Carpenter (Developer)
Posts: 9392
Joined: Fri Oct 16, 2009 11:31 pm

### Re: Slow to query after sitting for a few hours

Everything allocates room for results as needed.

It's interesting this allocation takes such a long time in a low memory situation.
My guess is memory is being paged to disk to make RAM available.

Normally if Everything is unable to allocate memory it will just throw a fatal error and exit.

I will experiment with an option to preallocate room for the results and get back to you.
preallocating room for results will use additional memory (~8MB per 1 million files)

Please feel free to disable min_working_set_size, max_working_set_size and virtual_lock as it appears Everything is not being paged to disk:
virtual_lock also fails due to low system memory.

In Everything, type in the following searches and press ENTER:

/min_working_set_size=0
/max_working_set_size=0
/virtual_lock=0

void
David Carpenter (Developer)
Posts: 9392
Joined: Fri Oct 16, 2009 11:31 pm

### Re: Slow to query after sitting for a few hours

Everything 1.5.0.1299a adds a mem_trim ini setting.

When disabled, Everything will keep resources available for new result arrays.
Disabling mem_trim will make Everything consume slightly more ram (~8MB per 1million files)

This should prevent Everything from allocating new memory when performing a query.

Please try disabling mem_trim and see if the issue persists:
• In Everything, type in the following search and press ENTER:
/mem_trim=0
• If successful, mem_trim=0 is shown in the status bar for a few seconds.

It is possible Everything will be paged to disk again, in which case, please try re-enabling min_working_set_size, max_working_set_size and virtual_lock:
• In Everything, type in the following search and press ENTER:
/min_working_set_size=0xfffffffffffffffe
• Type in the following search and press ENTER:
/max_working_set_size=0xfffffffffffffffe
• Type in the following search and press ENTER:
/virtual_lock=1
• Type in the following search and press ENTER:
/restart