I installed Everything 1.4 on a high-performance desktop (AMD Ryzen 9 7950x, 128 GB RAM DDR4, SSD Samsung 980 Pro 4.0 x4). I indexed a single directory on drive C: that has 40.000 objects (directories and files). I tried to search in the content of the files for string "1234" but without success.
Here is what is happening
- Everything initially uses 8 MB of RAM then when searching in the content it reaches 74.3 MB.
- The activity on the disk increases somewhere to 25% for 20 seconds after which it stops.
- Querying... still appears in the status of the Everything window even the process takes 0% of CPU and the same RAM is used. I left it in this state for an hour but it didn't show anything in the result window. Please note I created before 4 text files with 1234 content just to help finding them in different locations.
- I repeated the steps above and when Everything was no longer active 0% CPU, 74.3 MB RAM I tried to stop the search, without any luck. I pressed Cancel, I deleted the search word and pressed Enter. From this moment the process appears in the Task Manager as "Not working" and I had to end it.
To avoid this issue from the very beginning I had to disable the "Search as you type" option because it becomes non-functional immediately.
Has anyone else faced this issue? On the other hand Windows Search searches files content and found the files without adding to its index any location.
I will evaluate switching to version 1.5 even it is in alpha state.
Not responding when searching short string in the files content
Re: Not responding when searching short string in the files content
I replaced version 1.4 with 1.5 and I was not able to reproduce this issue.
Version 1.5 immediately found the files containing the 1234 string. CPU usage was around 50%, when the program reaches 1GB of RAM starts again from 100 MB. This is happening a few times I guess the developer set up some rules to avoid memory overflow. Disk activity is around 33%. Windows Search results is far behind, a white ball for Everything in this case.
I will keep using version 1.4 in production but I will avoid searching for files content. When version 1.5 is stable I will replace it. Anyway I will continue to use 1.5 just for supplying feedback and bugs report (if I found any). Version 1.5 is a huge step forward comparing with 1.4.
Version 1.5 immediately found the files containing the 1234 string. CPU usage was around 50%, when the program reaches 1GB of RAM starts again from 100 MB. This is happening a few times I guess the developer set up some rules to avoid memory overflow. Disk activity is around 33%. Windows Search results is far behind, a white ball for Everything in this case.
I will keep using version 1.4 in production but I will avoid searching for files content. When version 1.5 is stable I will replace it. Anyway I will continue to use 1.5 just for supplying feedback and bugs report (if I found any). Version 1.5 is a huge step forward comparing with 1.4.
Re: Not responding when searching short string in the files content
In version 1.5 it is very hard to cancel a content search. I pressed Cancel, I deleted the query string nothing happened. An annoying window comes over and over asking me to Terminate Everything?. If I press Terminate it continues to ask me in a loop. I have to end the task to stop this.
Content search needs a seriously revise in my opinion.
Content search needs a seriously revise in my opinion.
Re: Not responding when searching short string in the files content
Everything doesn't understand file content.
Everything uses system iFilters to read file content.
System iFilters can be installed by third parties.
What is your current setup under Tools -> Options -> Content?
Please try reducing what is indexed.
Everything will store content in memory.
If you are able to reproduce this issue, please check the current filename being indexed under Tools -> Options -> Properties.
(Hover over the filename shown in the top right)
What is the type of file shown?
Please consider searching your system index from Everything with si:
Everything uses system iFilters to read file content.
System iFilters can be installed by third parties.
What is your current setup under Tools -> Options -> Content?
Please try reducing what is indexed.
Everything will store content in memory.
If you are able to reproduce this issue, please check the current filename being indexed under Tools -> Options -> Properties.
(Hover over the filename shown in the top right)
What is the type of file shown?
Please consider searching your system index from Everything with si:
Re: Not responding when searching short string in the files content
In Tools > Options > Content I checked only "Index file content" and I left all the others as they were determined by you.
On a desktop with a last-generation processor, 128 RAM DDR4 and NVMe x4, content indexing takes a very long time. For almost 500,000 indexed objects around 250 GB in total, the processing time was around 12 minutes. Everything even ends up using 4 GB of RAM, but the AMD Ryzen 9 7950X processor was only used 10%. Computing power is needed for such operations. After finishing indexing Everything occupies almost 2 GB of RAM, but the content filter: no longer creates problems and immediately displays the result.
Obviously storing it in memory will help with fast processing, but what happens to it being stored on a volatile memory? Must it be redone again at the next startup? No, it seems the database stored on disk contains the files index content and is loaded when the application runs again. In my case it is 2 GB. I personally do not search for content daily if the name of the files fully defines the content, but only in certain situations.
Would it be necessary to analyze what happens if content indexing is not selected in Options? It is exactly the situation that I described in the first post, the full indexing of the content leads to the instability of the program, perhaps such an attempt should be prevented, especially if that computer does not have enough resources for a fast processing.
On a desktop with a last-generation processor, 128 RAM DDR4 and NVMe x4, content indexing takes a very long time. For almost 500,000 indexed objects around 250 GB in total, the processing time was around 12 minutes. Everything even ends up using 4 GB of RAM, but the AMD Ryzen 9 7950X processor was only used 10%. Computing power is needed for such operations. After finishing indexing Everything occupies almost 2 GB of RAM, but the content filter: no longer creates problems and immediately displays the result.
Obviously storing it in memory will help with fast processing, but what happens to it being stored on a volatile memory? Must it be redone again at the next startup? No, it seems the database stored on disk contains the files index content and is loaded when the application runs again. In my case it is 2 GB. I personally do not search for content daily if the name of the files fully defines the content, but only in certain situations.
Would it be necessary to analyze what happens if content indexing is not selected in Options? It is exactly the situation that I described in the first post, the full indexing of the content leads to the instability of the program, perhaps such an attempt should be prevented, especially if that computer does not have enough resources for a fast processing.
Re: Not responding when searching short string in the files content
Thank you for your feedback cata_solo,
Please note, when context indexing is enabled, content: will only search your indexed content.
Use the fromdisk: search modifier to bypass your indexed content.
The default content indexing settings will only index the following file types:
*.doc;*.docx;*.pdf;*.txt;*.xls;*.xlsx
If content indexing is disabled, content: will search all files.
If the file content is unknown, the content is treated as binary.
Everything will search the binary content for ASCII, ANSI, UTF-8 and Unicode text.
The can lead to unfortunate circumstances where Everything may end up reading very large files.
Clearing the search should terminate most content searches.
However, there are some iFilters where Everything will have to wait for the content search to complete. (no cancel mechanism)
What is most likely happening here is content: is trying to read a really large file or a system iFilter is broken for a file type other than *.doc;*.docx;*.pdf;*.txt;*.xls;*.xlsx
Debug logs may help find the problem file:
For example: ext:pdf;doc;docx;txt;xlsx;xls dm:thisyear content:"foo bar"
Please note, when context indexing is enabled, content: will only search your indexed content.
Use the fromdisk: search modifier to bypass your indexed content.
The default content indexing settings will only index the following file types:
*.doc;*.docx;*.pdf;*.txt;*.xls;*.xlsx
If content indexing is disabled, content: will search all files.
If the file content is unknown, the content is treated as binary.
Everything will search the binary content for ASCII, ANSI, UTF-8 and Unicode text.
The can lead to unfortunate circumstances where Everything may end up reading very large files.
Clearing the search should terminate most content searches.
However, there are some iFilters where Everything will have to wait for the content search to complete. (no cancel mechanism)
What is most likely happening here is content: is trying to read a really large file or a system iFilter is broken for a file type other than *.doc;*.docx;*.pdf;*.txt;*.xls;*.xlsx
Debug logs may help find the problem file:
- In Everything, from the Tools menu, under the Debug submenu, check Start Debug Logging.
- From the Tools menu, under the Debug submenu, check Verbose.
- Perform your content: search.
- wait for Everything to hang.
- Open your %TEMP%\Everything Debug Log.txt
- What is the last line containing:
content <filename>
For example: ext:pdf;doc;docx;txt;xlsx;xls dm:thisyear content:"foo bar"
Re: Not responding when searching short string in the files content
Thank you very much for the tips. I will implement all of them to check what is happening.
Re: Not responding when searching short string in the files content
1.38tb diskcata_solo wrote: ↑Tue Nov 29, 2022 11:07 pm In Tools > Options > Content I checked only "Index file content" and I left all the others as they were determined by you.
On a desktop with a last-generation processor, 128 RAM DDR4 and NVMe x4, content indexing takes a very long time. For almost 500,000 indexed objects around 250 GB in total, the processing time was around 12 minutes. Everything even ends up using 4 GB of RAM, but the AMD Ryzen 9 7950X processor was only used 10%. Computing power is needed for such operations. After finishing indexing Everything occupies almost 2 GB of RAM, but the content filter: no longer creates problems and immediately displays the result.
Obviously storing it in memory will help with fast processing, but what happens to it being stored on a volatile memory? Must it be redone again at the next startup? No, it seems the database stored on disk contains the files index content and is loaded when the application runs again. In my case it is 2 GB. I personally do not search for content daily if the name of the files fully defines the content, but only in certain situations.
Would it be necessary to analyze what happens if content indexing is not selected in Options? It is exactly the situation that I described in the first post, the full indexing of the content leads to the instability of the program, perhaps such an attempt should be prevented, especially if that computer does not have enough resources for a fast processing.
5,350,000 files,used 500mb ram