Oct 31 2019 02:28 AM - edited Oct 31 2019 03:16 AM
There is a folder %localappdata%\Microsoft\Edge Dev\User Data\BrowserMetrics with thousands of 4 MB files like BrowserMetrics-5D3A8F5A-1AF0.pma that fill up my precious SSD disk space.
Can I remove these or prevent or limit the creation? What is the purpose of these files?
I'm currently at Version 79.0.309.5 (Offizielles Build) dev (64-Bit)
I think it would be a good idea to make them sparse files on NTFS volumes or compress the folder by default. In my case compressing the folder reduced the size from 8.55 GB to 462 MB.
Solution:
I disabled the creation of the files by setting the following registry entry:
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Edge]
"MetricsReportingEnabled"=dword:00000000
I checked the policy with edge://policy
All existing files were deleted after a restart of Edge.
See https://docs.microsoft.com/en-us/DeployEdge/microsoft-edge-policies#metricsreportingenabled
Mar 25 2021 07:27 AM
Happened again last night while leaving the browser open overnight, over 76GB of these files
Mar 25 2021 12:46 PM - edited Mar 25 2021 12:57 PM
Yes, I'm up to 14 GB since 3/20/21; almost 3 GB/day. Some of you seem to be having much higher usage by Browser Metrics. I'm hoping for progress by the Microsoft Edge team soon!
Mar 26 2021 12:36 PM
Hey folks,
Quick update here from the team - they're still investigating but have requested some additional information. Even if you've submitted already, if you don't mind submitting again with the new info we'd really appreciate it!
If you could head to edge://policy/ and submit feedback (Alt + Shift + I), check to include the screenshot as well as diagnostic data, attach the information requested above, and add the string "TC0317AR-1010LUO-TMEP908" so we can link it to this issue. If you'd like the team to be able to reach out directly, please check to include your email as well.
Mar 28 2021 01:14 PM - edited Apr 01 2021 11:44 AM
@lexcyn (and @dave260) Have you tried turning on automatic compression for the BrowserMetrics folder, as I detailed above? (If so, do you have anything notable to report?)
Anyone else?
(I haven’t personally seen any ill effects yet from enabling automatic compression.)
PSA: if you can fulfill the data request from @Alexandra-R, please do that first! The sooner the team gets data the sooner they can figure this out.
- Jim
----
Aside: With the explosion (in both usage and number) of plain-text configuration, log, and analytics files in recent years, I wonder if NTFS compression should be used by default in many more places...
[Even with medium-speed SSDs, accessing a compressed file might be faster (fewer IOPS as well), let alone for those poor souls still using HDDs for their boot disk.
I’m not well-versed to know for sure, but memory-mapping files that a program needs extensive access to may contribute to the current disk performance challenges across various ‘modern’ operating systems (in theory and benchmarking, maybe this shouldn’t be a problem due to something like ‘intelligent caching’ in disk and VM systems, but in real-world multi-threaded multi-tasking usage, might not even the most ‘intelligent’ cache prediction system fail to determine user intent in order to optimize performance?).
It shouldn’t be that surprising that browsers such as Chromium-based Edge, in some ways nearly mini-OSs themselves, might end up being a canary for this sort of systemic issue. They are very complex and usage can vary widely by user and time - this isn’t just ‘winword.exe accessing hugereport.doc’ anymore!]
... and all that is aside from the performance impacts of having thousands or more files per process - each one places load on systems and filesystems upon reading (e.g. for each and every file opened, even read-only: verifying access rights, recording ‘atime’ access time, and performing other security/audit logging), writing (most of those same activites, plus updating modification times and file system journals, and perhaps SSD ‘write amplification’), and for purposes of indexing, backup, and security (Windows Defender Real-Time Protection). Many are likely to be left behind when new builds are installed. Sure, some of those things can be disabled on a per-file, directory, or process basis, but... without giving admin rights to the application?
Even if developers of most programs know how to do this, even if allowed to by system security and domain group policy, why would they remember to do this on every release? If using a cross-platform framework, they may not even _be aware_ of these issues, or have an API to address them.
Mar 30 2021 07:51 AM
Mar 31 2021 11:02 AM
Mar 31 2021 12:05 PM - edited Mar 31 2021 01:56 PM
@dave260,
Thanks for the details - interesting. Based on those comments and my own observations, it appears that:
Of note, I checked the BrowserMetrics folders for my installations of the Dev and Canary branches and didn’t notice excess files (but I haven’t used those branches much in the past week).
- Jim
* (if you haven’t, they seem to work nicely with synced Edge profiles, so it’s fairly easy to give them a try!)
[P.S. Even if this is an intermittent problem, or it is identified and fixed soon, perhaps to proactively identify _future_ issues, something as complex and resource-intensive as a modern web browser should be programmed to occasionally police its entire profile/temporary/etc. directories to identify abnormally large or old data sets and either automatically clean them up or (at the very least) report the problem to the user and developer.]
Mar 31 2021 12:27 PM - edited Mar 31 2021 02:21 PM
@lexcynHow far apart are the dates/times on your files? [Unless my quick math is wrong, 12,000 files over 2 days (48 hours) would be 250/hour, or a new file every 15 seconds or less. Even if over 4 days (96 hours), that is 125 files/hour, still over 2 new files _per minute_.]
@dave260 Here's probably why the NTFS file compression isn't working for you:
If you were to turn off compression for your entire BrowserMetrics folder and its contents, and them immediately turned it back on, I think you'd find that all existing files would be greatly compressed, but new files would not. So much for that idea!
Mar 31 2021 12:38 PM
Mar 31 2021 12:59 PM - edited Mar 31 2021 01:48 PM
Okay, here’s a temporary fix* to try if you need the disk space before this gets fixed (I’m not at my computer and so haven’t tested it yet):
If that doesn’t work, instead of step 3 above, try:
3a. Delete the BrowserMetrics folder itself
3b. Create a new empty text file called “BrowserMetrics” in the place of the deleted directory
3c. Make sure the new file does not have a file extension (e.g. “.txt”)
Hopefully that will block Edge from creating new metrics files there.
If you don’t need the disk space right now, though, please don’t do that yet so you can continue helping with the troubleshooting.
- Jim
* Background: the base code from the Chromium project is set to fail gracefully and discard the temporary data if it can’t write to that directory
Mar 31 2021 03:39 PM
@Vovan / Edge team:
The site (pomotodo) that you mention uses something called 'web workers' (the Chromium 'Blink' rendering engine apparently calls them 'Blink Workers').
In my (very limited) understanding, this causes a piece of JavaScript to run on a different thread than the one controlling the display of the page to which it belongs, allowing it to run on a different actual (or virtual) CPU.
If each of these new threads (as many as one or more every time you switch pages?) causes Edge to create a new file in BrowserMetrics (whether intentionally or not), maybe they are crashing or quitting before it can clean up the excess files.
Metrics files from different files are supposed to be automatically collected into a single file, but perhaps that part of the code (e.g. subprocess_metrics_provider.cc, or something that calls / is called by a function or method there or elsewhere) is malfunctioning.
Many (most?) sites these days use 'web workers', but the inconsistent (across the Edge user base) nature of this problem suggests that if they are indeed part of what causes this, something in the JavaScript on certain sites is triggering this (the browser should behave even in the presence of horrible / buggy JavaScript, of course).
- Jim
Mar 31 2021 05:12 PM
Mar 31 2021 05:14 PM
Mar 31 2021 06:12 PM - edited Apr 01 2021 12:24 PM
Note: this reply likely doesn’t directly relate to the BrowserMetrics issue discussed in the rest of this thread
@dave260 : To troubleshoot your CPU usage issue, especially if the ‘Details’ and ‘Services’ tabs of ‘Task Manager’ don’t lead you to the solution, you can always try Microsoft’s free ‘Process Explorer’.
(It’s got a bit of a learning curve, but one should be able to pick up the basics in 5-10 minutes - I’m sure there are gobs of tutorial videos and articles online in addition to the official docs.)
- Jim
P.S. If you’re at all like me, it’s easy to confuse that tool with the similarity named ‘Process Monitor’ - this later one instead monitors and records access by processes to the registry/files/network/etc. It can filter by process or access type (e.g. read vs write vs checking if a file exists), either in real-time or after stopping a recording. I normally use this to figure out why something is slamming the disk and/or network. It could potentially help in your case, too, by showing exactly what a busy process is doing to eat up all that time. (Expect to spend up to maybe 20 minutes figuring out how to use this tool - hint: <CTRL-e>, <CTRL-a>, and <CTRL-x> will be your friends here.) If there’s not much shown in Process Monitor, your app is probably just doing tons of math! ;)
Mar 31 2021 06:33 PM
Mar 31 2021 06:38 PM
Apr 01 2021 01:57 AM - edited Apr 01 2021 01:28 PM
@Alexandra-R (and Edge team devs):
msedge.dll - RelaunchChromeBrowserWithNewCommandLineIfNeeded
Thank you for all the attention you and your team are giving to this!
Happy hunting,
- Jim
Detail [1] from item (3) in above list:
Detail [2] from item (5) in above list:
Beta - Version 90.0.818.22 (Official build) beta (64-bit) --> Normal (working) process, that prevents build-up of "BrowserMetrics-hhhhhhhh-hhhhh.pma" files: CreateFile Desired Access: Generic Read/Write, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Created CreateFileMapping SyncType: SyncTypeCreateSection, PageProtection: PAGE_EXECUTE_READWRITE Result: FILE LOCKED WITH WRITERS QueryStandardInformationFile AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: False, Directory: False SetEndOfFileInformationFile EndOfFile: 4,194,304 CreateFileMapping SyncType: SyncTypeOther ReadFile Offset: 0, Length: 32,768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal ... CreateFile IRP_MJ_CREATE QueryAttributeTagFile IRP_MJ_QUERY_INFORMATION Type: QueryAttributeTagFile, Attributes: AC, ReparseTag: 0x0 SetDispositionInformationEx IRP_MJ_SET_INFORMATION FILE_DISPOSITION_DELETE, FILE_DISPOSITION_POSIX_SEMANTICS, FILE_DISPOSITION_FORCE_IMAGE_SECTION_CHECK IRP_MJ_CLEANUP CloseFile IRP_MJ_CLOSEWhen running the Stable ring version of Edge, "SetDispositionInformationEx" never appears and the files persist.
Apr 01 2021 11:47 AM
@JimGrisham I haven't enabled compression because I am on a corporate device where I do not have that ability - besides, the root cause should be fixed so I will leave as is.
Apr 02 2021 08:29 AM