Wild memory usage and failing to index files with no apparent reason

[silverweed]

I installed VS Chromium about 4 days ago and used it with no problems until today. Today I hit "Code Search" and noticed the index was empty and Vs Chromium was "Busy" reloading it. Note that I had not closed VS since yesterday (when it was working fine).

The indexing is still busy loading but remains totally empty, and looking at the Task Manager I noticed the RAM used by the plugin is oscillating wildly between ~1GB and ~5GB (it scales up from 1 to 5, then it resets to 1 and so on). Restarting Visual Studio doesn't change the plugin's behaviour.

I'm trying to index about 13500 files, fyi.

What baffles me is that this behaviour started with no apparent reason and no dramatic change in the project, and it's also happening to a colleague of mine who installed the plugin the same day as me. It's a particularly annoying situation, as this plugin was INCREDIBLY useful to replace the pathetic default File Search function, and I was enjoying the speedup a lot :(

[rpaquay]

Hmm... I have never seen this behavior before (in 4+ years), so this is strange. 13,500 files should not be a problem (I am currently using VsChromium with an set of repositories of about 1,2M files :))

Did this start happening after you "fetched" (I am assuming you are using "git") a new version of your project? If you go back to an older version, does this still happen?

Another thing that could help is to attach the log files to this bug, just to see if there is a meaningful error logged in there. The log files are located in "%LOCALAPPDATA%\VsChromium". Up to 10 files of 2MB files each are use for logging.

VsChromium.log is used for information/warning/error level logging. VsChromium.errors.log is used for warning/error level logging only.

[silverweed]

Sorry for the delayed answer: unfortunately I cannot attach the log files as they contain NDA-protected data such as file paths. I am using Perforce for version control. The VsChromium.errors file gave several "Skipping file XXX because of an error reading its contents" or "Error reading attributes of file XXX", and even "The system cannot find the file specified", but all those errors were only given on immediate startup, not continuously. Similar errors are in the .log file, but, again, not given in succession: just on startup.

[rpaquay]

In VsChromium.log (the regular one, not the "errors" one), do you see any message similar to this:

[2020-02-03 14:49:08.9768][Server    ][ 11132-7][Info ] ProcessPathsChangedEvent: 1 items left out of 1 after filtering (showing max 5 below).
[2020-02-03 14:49:08.9768][Server    ][ 11132-7][Info ]   Path changed: "<blah blah>", Pathkind=File, Changekind=Created
[2020-02-03 14:49:08.9768][Server    ][ 11132-7][Info ] Some file change events are create or delete events.

I am wondering if there is some disk activity that forces vschromium to rescan the whole directory tree.

[silverweed]

@rpaquay Yes, there are multiple instances of that pattern in the log file. In particular, near the end of the log, that same pattern repeats over and over, saying things like

[2020-01-23 17:50:40.8210][Server    ][ 25312-7][Info ] ProcessPathsChangedEvent: 3 items left out of 4 after filtering (showing max 5 below).
[2020-01-23 17:50:40.8210][Server    ][ 25312-7][Info ]   Path changed: "Z:\XXX.fdb", Pathkind=File, Changekind=Changed
[2020-01-23 17:50:40.8210][Server    ][ 25312-7][Info ]   Path changed: "Z:\XXX.log", Pathkind=FileOrDirectory, Changekind=Changed
[2020-01-23 17:50:40.8210][Server    ][ 25312-7][Info ]   Path changed: "Z:\XXX.suo", Pathkind=FileOrDirectory, Changekind=Changed
[2020-01-23 17:50:40.8210][Server    ][ 25312-7][Info ] All file change events are file modifications.

(the files are not always the same, nor their number). Looks like they're all just modifications, though.

[rpaquay]

@silverweed

Ok, I am still not sure what is going on, but let's see if we can try to isolate the source of the problem:

Can you try to change your "vs-chromium-project.txt" to something along the lines of:

[SourceExplorer.ignore]
*.fdb
*.log
*.suo
# Plus whatever you had here

[SearchableFiles.include]
* # Or whatever you had here

[SearchableFiles.ignore]
# Whatever you had here

And see if this solves the problem.

Also, another question: the "Z:" drive you mention in your previous comment, is this a regular drive or some sort of network share (or something else?).

[silverweed]

@rpaquay Ok, I tried adding a (long) list of ignored extensions and directories, and it looks like now it's working! No more memory spikes and the indexing seems to work perfectly.

One thing I don't quite get is why I need to have two separate lists for SourceExplorer and SearchableFiles, given that I have disabled the Source Explorer integration in the SolutionExplorer.

Anyway, thanks a lot for your help :)

(The Z: drive is a normal ssd drive, just fyi)

[rpaquay]

One thing I don't quite get is why I need to have two separate lists for SourceExplorer and SearchableFiles, given that I have disabled the Source Explorer integration in the SolutionExplorer.

This is merely the result of iterative design, and indeed not obvious. Basically, to build the list of "searchable files", VsChromium first uses the SourceExplorer section to filter out files, then uses the SearchableFiles filter as a 2nd pass filter. The 2 features (source explorer and code search) are not very well isolated because they were designed together, and the ability to disable source explorer only came much later.

I am still puzzled why these file changes were causing so much re-indexing and memory usage spike though. VsChromium has been designed to be much more resilient than that.

I hope I am not asking too much, but would you mind sending a log file "sanitized", i.e. where all file paths are removed? I don't think there is not much else in there in terms of user specific data.

If you can't, then maybe just the lines talking about GC memory, for example:

[2020-02-05 08:53:57.2739][Server    ][17116-66][Info ] << FileSystemSnapshotManager: Computing snapshot delta from list of file changes completed in 35 msec - GC Memory: 475,272,832 bytes.

[silverweed]

@rpaquay here is the file with all the grepped GC lines: vschromium_gc.txt.gz

I hope it's enough for you to get some insight about this.

[rpaquay]

@silverweed thank you for the log file extract. There is not enough information in there to give me hints about what was going on. It looks like you have an enlistment of about 250,000 files. Most of the changes seem to be simple file changes (as opposed to directory deletion, etc.), so VsChromium should be pretty efficient dealing with these changes.

I also see a few "List of projects has changed", which indicate that you maybe closed VS or closed and re-opened the solution you were working with. These operations are heavier because VsChromium has to re-index everything from scratch. I am working on fixing issue #47. This may help if you quickly close and re-open the same solution, for example, if the .sln or .proj files are changed on disk outside of VS.

[silverweed]

Ok, thank you for all your help :)

[rpaquay]

@silverweed I wonder if your issue was somehow related to issues #60 and #61

Maybe give version 0.9.34 a try (it is still pre-release, but I will release it this week unless major issues are found)

[silverweed]

Thanks, I'll give it a try when I have some time available 👍

[rpaquay]

@silverweed I released version 0.9.36 which contains, among other things, a fix for issue where VsChromium does not show an Index or stop responding after using "Find in Files" in VS 2019. Feel free to give it a try when you have a chance.