Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[teodorom]

Hi,
checking the behaviour of my computer (Windows 10, build 19044, x64, 4GB RAM, paging file on SSD) I discovered a strange behaviour of the "Page Faults/sec" counter.
During the first 20 minutes or so of playing the pattern is as in the first image, then it becomes like in the second image.
The amazing thing is that this behaviour continues even if the playing has been stopped. To revert to the "good" behaviour one has to restart MC.
This happens with the latest version (29.0.38), but also with the previous one (28.0.106). Independently of the "memory playback" mode chosen.
Strange, isn'it?
Thanks

• 
• 

[Hendrik]

4GB memory is on the low side these days, which is probably low enough that Windows starts aggressively paging to the pagefile, and anytime it needs to access something from there, a page fault is generated.
Unless you can actually observe an adverse effect from them, they are just normal operation of the memory management in the OS. Applications can't control them. Having more memory will avoid them.

[teodorom]

Thanks, this was my first hypothesis too.
But why it happens after 20 minutes of playing and it continues even after the playing is stopped?

[teodorom]

No, sorry about that.
There is enough memory: only 55% of the total memory is used (more if I load the entire album in memory).
I'm trying with another product (guess what), which has the reputation of being much more resource intensive than MC and after half an hour the "Page Faults/sec" is constant.
Let me guess that you allocate some kind of memory and you forget to deallocate it, so after a while the computer memory  has some problems.

[zybex]

Like Hendrik said, unless you're experiencing specific issues, that's just normal Windows behavior. Windows is constantly running stuff in the background, specially during idle time. Many activities result in sporadic page faults, it's just the way the memory subsystem works. It's not a problem.

MC itself may be doing background activities that result in page faults - for instance, auto-import scanning for new files. Simply browsing your MC collection without playing anything requires DB reads, which may very well trigger page faults due to memory-mapped DB loading. When files are open with memory mapping all accesses to the file generate a page-fault which triggers reading a specific sector of the file. Again, this is NORMAL behavior. Additionally, each time a process opens a file it may trigger the antivirus to scan it - guess what, it also uses memory mapped files. You can't really compare page faults between 2 different applications, as they're... entirely different applications. Duh.

Your chart has 2 light-blue traces (MC and Defender), so it's not clear which one is triggering the most page faults. The highlighted black trace for MC has an average value of 117 page faults/sec, corresponding to about 500 KB/sec of data. That's peanuts, your SSD can handle 1000 times that. During playback of a file you may see that 5 second pattern - it just means MC is reading the next chunk of ~2 MB of the current or next file. It may be more or less, depending on the bitrate of the current playing file, and many other factors related to how MC loads and plays each file.

Let me guess that you allocate some kind of memory and you forget to deallocate it, so after a while the computer memory  has some problems.

A memory leak would be obvious just by looking at the process memory usage, which would be constantly growing. Page Faults would only come after all memory was exhausted, and by that point your system would be unusable. If it were instead a one-time buffer allocation that was not released, then it would also not result in Page faults, it would just be a small growth in total memory usage by the process.

TLDR: nothing to see here, carry on.

[teodorom]

Like Hendrik said, unless you're experiencing specific issues, that's just normal Windows behavior. Windows is constantly running stuff in the background, specially during idle time. Many activities result in sporadic page faults, it's just the way the memory subsystem works. It's not a problem.

I agree, but in this computer I have stopped all the unnecessary services. Only 43 left!

MC itself may be doing background activities that result in page faults - for instance, auto-import scanning for new files. Simply browsing your MC collection without playing anything requires DB reads, which may very well trigger page faults due to memory-mapped DB loading.

The "auto-import" in stopped: I import new files one by one, by hand.

When files are open with memory mapping all accesses to the file generate a page-fault which triggers reading a specific sector of the file. Again, this is NORMAL behavior. Additionally, each time a process opens a file it may trigger the antivirus to scan it - guess what, it also uses memory mapped files.

That behaviour is present even when I load the entire album in memory.

Your chart has 2 light-blue traces (MC and Defender), so it's not clear which one is triggering the most page faults.

The black line is referring to MC. Page faults caused by Defender are rare and unrelated

However, the average value of 117 page faults/sec indicated for MC corresponds to about 500 KB/sec of data. That's peanuts, your SSD can handle 1000 times that.

Yes, I agree. But I hope that you agree with the fact that I should constantly see the behaviour in the first picture (random spikes of unequal height).
There should be no reason for that change (constant frequency spikes of equal height) after 20 minutes (or so).
Thanks

[zybex]

No, you can't assume the pattern to remain constant. Windows itself may decide to change memory access strategy after an application does the same thing for some time - windows detects a pattern and optimizes for it. That alone can explain your observations. But really, this is most likely related to memory-mapped loading, and not something to be concerned about. It has zero impact.

If you wish to investigate further I suggest you use Process Monitor to figure out what MC is doing. Be advised that this tool captures a huge amount of data and it may not be easy to make sense of it unless you know the tool well enough. You can also look at the MC debug logs, it also prints information about what MC is doing.

[teodorom]

But really, this is most likely related to memory-mapped loading

Even when there is nothing more to load in memory (full album loaded)?
Let me check that with my colleagues. I'm a database expert, I'm unable to go that deep.

[zybex]

Another possible reason is Memory Compression - windows just doing housekeeping:

"The "Page Faults/second" includes both soft faults (pages that can be served from/to RAM) and hard faults (pages that must be served from/to the disk). So having a high "Page Faults/second" value doesn't necessarily mean a problem. Examples of soft page faults include turning pages in the transition list (it consists of the standby list and the modified list; they contain temporarily unused memory pages, which are candidates for paging out to the disk (or discarded if they are not modified), but are still in the RAM) into active pages and turning active pages into the transition list. In Windows 10, this could also happen when compressed pages are turned into active pages (as Windows 10 has memory compression).

To see hard faults, you can use Pages/second, Pages Input/second or Pages Output/second counters."

[teodorom]

No, sorry about that.
The command

Code: [Select]

Get-MMAgentgives

Code: [Select]

ApplicationLaunchPrefetching : False
ApplicationPreLaunch         : False
MaxOperationAPIFiles         : 256
MemoryCompression            : False
OperationAPI                 : False
PageCombining                : False
PSComputerName               :
so the Memory Compression is not active.
meanwhile I noticed a correlation among the "Page Faults/sec" and "IO Other Bytes/sec".
The spikes on "IO Other Bytes/sec" are always there, even after hours that MC is idle. So, what is doing?.
I checked the situation this morning and now (MC) is still idle I get the following situation: the two counters are now synchronised!
Please tell me what MC is doing and how I can control it.
I plan to build and sell complete solutions for "music servers" based on MC. This behaviour frightens me.
Thanks

[zybex]

Other IO includes network traffic and device polling, such as talking to the hardware to see if something happened in the last 5 seconds or broadcasting to the network to find if a DLNA device is still up, or if a new device shows up (wrong) traffic to Control functions such as USB drivers and other controllers. You're logging 1KB/sec... Incidentally, talking to hardware can also trigger page faults.

Please tell me what MC is doing and how I can control it.

Again, look at MC logs to find out what it's doing - there are instructions in the forum on how to get the logs.

Those performance counters are extremely low level, and no developer cares about them unless they hit unreasonable levels. Which they have not. You're determined to find a problem where there is none.

I hope you don't plan to ship machines will all those services OFF and with just 4GB RAM, that's asking for trouble.

[teodorom]

I hope you don't plan to ship machines will all those services OFF and with just 4GB RAM, that's asking for trouble.

Why not? My computer works perfectly this way since years, and there is people testing my configuration.

[zybex]

OK, you get an upvote because of Yoda

Memory compression and Page Combining are specifically designed to help in memory starved scenarios, by trading a little CPU power with a large memory gain. Disabling them means that you may start swapping to disk much earlier than needed. In MC use case, it means your machine will be able to handle a smaller library than it would otherwise, before you start seeing huge slowdowns in library operations.

[JimH]

I hope you don't plan to ship machines will all those services OFF and with just 4GB RAM, that's asking for trouble.

I strongly agree. 

[teodorom]

Ok, you meant "Memory compression" and "Page Combining" services! Not all the other services! Notice that, since I'm using the proprietary ASIO driver for the DAC, I can stop also "Windows Audio" (done also by others my "victims").
BTW, now, even with 4GB RAM, the memory usage is 55%. Anyway, I plan to offer 8GB machines.
Even though, now my library has 2160 albums. What I find invaluable in MC is the library and metadata management, and the Audio quality is just comparable to the one of the other, more expensive (and more resource intensive), product.
Yoda is there to get the "Force".

[Awesome Donkey]

BTW, now, even with 4GB RAM, the memory usage is 55%. Anyway, I plan to offer 8GB machines.

Just putting it out there because I deal with these type if things and for years I've been watching the direction of the industry as a whole but, in my opinion, these days having 8GB of RAM should be the recommended "minimum" for new systems. In fact, in some scenarios 8GB may actually be too low now, and I wouldn't be surprised in the least seeing 16GB of RAM quickly becoming the recommended "minimum". This is especially true when running Windows 11 with security features like core isolation and memory integrity enabled.

[teodorom]

I agree, even if I'm amazed by this evolution. When I was in IBM, my first 8088 PC, had 64kB of RAM (no HD, only floppies).

[dtc]

I agree, even if I'm amazed by this evolution. When I was in IBM, my first 8088 PC, had 64kB of RAM (no HD, only floppies).

The navigational computer on the Apollo moon landings had 32,768 bits of RAM memory. In addition, it had 72KB of Read Only Memory (ROM).  That's KB, not MB or GB.

Modern programmers and modern programming languages no longer value compact, small memory code. I remember self modifying code that changed itself to save a few bytes. And using overlays to run a big program in small amounts of memory. Glad those days are gone. Even a phone has 8 GB of RAM these days.