Everything Alpha is eating the memory starting with the 1364 version

[cata_solo]

I have been using the alpha version for almost 1 year without any issues. Last week I updated version 1363 to 1364 and today I noticed that 1365 is available. To replace the executable file I have to stop the service and obviously I look at how much memory it consumes.

I noticed with amazement that after about 2 hours since the computer was turned on that Everything was using 625 MB of memory and continues to grow little by little. I replaced it with the 1364 version and encountered the same problem, it eats the memory little by little, it reached 66 MB in just a few minutes.

I put the 1363 version back in place and found that I knew very well that in my case Everything consumes around 1.9 - 2.2 MB. It has been at this value for more than 7 hours.

It is most likely a bug introduced in the 1364 version, I will double check on another computer.

I have attached screenshots so you can see the differences.

[cata_solo]

Please note that I am only replacing the executable file, all the other files including the configuration file remain the same.

I tested only the x64 portable version.

[NotNull]

Good analysis.

Memory leak in the Everything Service since 1364a

I am working on a fix.

Workaround for now would be to restart the service.

[therube]

I'm thinking you are actually looking at two different things.

One, being the Everything Service & the other being the Everything GUI.
The Service will use only a tiny amount of RAM (a few MB), compared to the GUI (hundreds of MB).


(And I wrote that before reading NotNull's response.)

That said... unless you're running Everything in a very constrained situation, 2.2 MB is very very small amount of RAM for the GUI to use.
Actually [in addition to 1363], I [also] happen to have 1365 x86 open - using no .db whatsoever
[start "" Everything1365.exe -instance 1365 -read-only -no-db],
& it (the GUI) is using 4.5 MB of RAM, so (perhaps, potentially) 2.2 could be valid, but I'm still thinking not.

[cata_solo]

As I mentioned, I use Everything Alpha, the x64 portable version, for almost 1 year. At each update, I download the portable archive, kill the process, then copy the executable in place of the previous one. I start the application, the service starts too. Please note that 2.1 MB is using the service, the application is using 9.3 MB. Here I am referring to version 1363.

When I updated to 1364, the service starts eating memory, as it said it reaches 650 MB in about 2 hours. Reverting to version 1363 solves this issue. I repeat, I replaced only the portable executable, the rest of the files are untouched.

I would like the others to check for confirmation the behavior of versions 1363 and 1365 regarding the use of memory, both the application itself and the service.

I'm using as operating system Windows 10 up to date.

[NotNull]

Confirmed. As mentioned before: known issue; will be fixed soon.

[therube]

Ah, I didn't realize it was the Service itself you were showing in each of the screenshots.

(Also didn't realize that the Service would be named the same as the .exe that installed it [E*.*.exe -install-service].
Also didn't realize that the Service actually "changed" between versions, though as a matter of course, I have always -unistall-serivice / -instsall-service with each update.)

What are the implications of using a current GUI with older Service?
As in there is no memory leak when using 1365 GUI with the 1363 Service.
.

Everything 1364 - Service eats memory.png (32.88 KiB) Viewed 1757 times

[NotNull]

Best to wait till @void gets some time to do his magic and fixes this IMO, but if I *had to* guess it is caused by this change:

Everything 1.5.0.1364a improves monitoring NTFS volumes.

Everything will now use OpenFileByID to read changes to files instead of reading directly from the NTFS MFT.

Everything should now update instantly.


The OpenFileByID API call was broken on Windows 10.
Using this API would cause Windows Explorer to stop updating.

Everything will not use this API call on Windows 10 18362 and earlier.
Windows 10 18363 fixed the issue.

Everything will continue to read the NTFS MFT directly for updates on Windows XP and earlier.
(and on Windows 10, 18362 and earlier)

(link)


As you are running an older version of Windows (IIRC), the 1663a service would still be OK-ish.
Reason for this change in 1664a is that Everything might miss some file changes under very specific conditions.
With the older service this might still happen, although still not very likely.


If anything, (temporary) installing 1663a would be the easiest way for now.


( BTW: As expected, Run indexing process as administrator is also affected by this bug. )

[void]

Everything 1.5.0.1366a fixes the memory leak in the Everything Service.

Sorry about the memory leak in 1364 and 1365.
I need to spend more time testing things my end..

The Everything Service was not releasing a buffer when reading file changes.
Each file change would allocate a 64K buffer.

The leak should no longer occur in 1366a.
The Everything Service should only use about 1MB of RAM with no noticeable CPU usage.
The Everything Service will use ~10 MB of RAM when indexing.
Please let me know if you see the Everything Service using more than 1MB or RAM when Everything is not indexing.

[tuska]

Everything 1.5.0.1366a fixes the memory leak in the Everything Service.
...
The Everything Service should only use about 1MB of RAM with no noticeable CPU usage.
The Everything Service will use ~10 MB of RAM when indexing.
Please let me know if you see the Everything Service using more than 1MB or RAM when Everything is not indexing.

Thank you for the prompt fix!

With version 1.5.0.1366a, the memory consumption for the Everything Service remains constant
between 1.2 MB and 1.7 MB on my PC (and is NOT continuously increased anymore).
_________________________________________________
Windows 11 Pro (x64) Version 23H2 (OS Build 22631.2861)

[cata_solo]

Many thanks @void for your support, a great one as usual. For me it was not a big issue as long as this version is in the Alpha stage. Also, the fact that I can do checks based on the previous versions that are public was very important to find out where the problem appeared.

At the moment the application itself when running uses around 7.5 MB (1.6 MB bellow than 1363). The service after an hour is still at 2.2 MB without the application running and it increases by only 0.2 MB when the application is running.

For those who have commented above, I have not used an old service. This because the service uses the version I'm copying over. When I kill the service and then run the executable, the service / background process from the new version will be used.

[Off topic] If you allow me, I would like to ask a question in this post. When a new release has configuration options added, by running the program, the ini file is updated or is it mandatory to access the Options window inside the application and by simply pressing the [OK] button are the new values added to the ini file?

[vsub]

Everything 1.5.0.1366a fixes the memory leak in the Everything Service.

Sorry about the memory leak in 1364 and 1365.
I need to spend more time testing things my end..

The Everything Service was not releasing a buffer when reading file changes.
Each file change would allocate a 64K buffer.

The leak should no longer occur in 1366a.
The Everything Service should only use about 1MB of RAM with no noticeable CPU usage.
The Everything Service will use ~10 MB of RAM when indexing.
Please let me know if you see the Everything Service using more than 1MB or RAM when Everything is not indexing.

I was just about to report this
For some reason the commit charge was usually high and closing programs did not reduce it by much
After looking carefully at the "private bytes" usage of each program,I notest that Everything(the service)is using over 5GB or ram(I have little over 1 million items in the list)

[cata_solo]

It should be mentioned that the process started leaking the memory only if the application was running. As soon as the application was closed, the process remained at the same value from that moment. I am glad that this issue has been solved.