|
You may be making 30 million memory accesses per second to some memory page - that is one per 80-100 clock cycles - but those are essentially to pages already in RAM. (Actually, even 30 million sounds high: The great majority of memory references hit the cache, and doesn't even go out to RAM.) If you really reference every corner of 120 GByte (30 million 4ki pages) every minute, then you are working with tasks such as weather forecasts or FEM. Not general software development.
If you generated one page fault every 33 microsecond, there would be now way for the disk to serve the requests. Not even a flash disk can deliver 120 Gbytes/sec (30 million * 4 ki) from the paging disk, so within a brief moment, the threads not blocked on a page fault would have the CPU to themselves and run at top speed ... and that claimed 30 million accesses a second would drop to almost zero. In other words: I do not trust your figures at all.
objectvill wrote: I think that not even windows 10 can boot without paging. At boot time, paging is certainly not activated! It needs an OS in place to set up page tables properly; all entries are empty. I don't know how far you will stretch the "boot" time; if it goes all the way up to the login dialog, the OS has certainly done the initialization. You can tell Windows not to use a paging file; then you will never page anythng out to disk. I assume that read-only segments (e.g. code) are still read on demand from the .exe/.dll - the "memory mapped file" mechanism uses the paging tables, and code access is very close to the same thing. So page tables are used, the hardware is there and difficult to overlook. You will have that logical-to-physical mapping in any case, whether you have a page file or not. You may call it "paging" because page tables are used; I do not, when the main purpose is to allow different applications to run in overlapping virtual address spaces which are mapped to distinct physical spaces, not to provide more virtual than physical memory.
As I said before: Take a look at actual physical disk activity. In the old days, each disk had a LED indicating physical activty; today they do not, but the SATA controller may have a head for connecting a LED indicating activity on any of the disks controlled by it. The Resource Monitor can tell you for how large percentage of time the driver is waiting for the disk, but not even that will necessarily indicate physical access: All (magnetic) disks today have fairly large RAM caches, so data may be served at RAM speeds.
You can add up the size of JVM, .net, emulator, editor..., and the sum may come to 120 GByte (i.e. 30 million pages), but they do not "have in memory all the methods and variables and modules". They are out on disk. When you are, say, prompted for parameters, and the code for that dialog happens to not have been used yet (since you started the application), there may be a 3 millisecond delay before it is in place in RAM. Especially for operations that require human intervention of three to four magnitudes higher duration than the page fault handling, the paging means nothing for the performance.
You may monitor page faults and see that in periods, there may be many thousands of them per second. Then you should know how the paging is handled: To sort pages in RAM into "recently referenced" and "not referenced for some time; candidate for yielding if RAM space runs out", at regular intervals, the OS marks all pages in RAM as "not present RAM", by resetting a hardware bit (per page) in the page tables. When the page is reference, an interrupt to the OS is rasied. It looks at the physical RAM address in the page table: OK, this is a valid address, it is not zero, so all that needs to be done is to set the "page present" flag to prevent more such interrupts, and go on.
So you have zillions of page fault interrups that only leads to a flag to be set, no paging operation. If the interrupt handler sees that the RAM address is zero, then it must start a more involved operation. I believe Windows have a third level: A set of RAM pages not used for a LONG time: When it does its regular sweeps resetting the present bit, if the bit was already reset (so the page hasn't been referenced since the previous sweep), the RAM addresses is zeroed in the page table and the page moved to a pool of "standby" pages actually in RAM, that is searched before any disk operation is initiated. If the faulting page is found, its RAM address is inserted into the page table and the page ulinked from the pool.
The OS also keeps a pool of "free" RAM pages: At boot up, all pages are in this pool. As space is being used, for code, data or stack, pages are moved from the free pool into the page tables. When a process terminates, the RAM pages used in physical RAM for the stack and data segments is moved back to the free pool.
If RAM really is crowded, and the requested page is neither flagged as present (so no interrupt is generated), not present but with valid RAM address (so the interrupt handler sets the present flag) or present in the pool of standby pages (so the memory address in the page table must be updated), it must be brought in from disk. This is what causes a real disk access - but that is only a small fraction of the page fault interrupts. If the free pool is not empty, one of its RAM pages is moved to the page table. If the free pool is empty, one a page in the standby pool must yield: Its RAM address is entered int the page tables, its contents overwritten. Its entry in the pool list is removed, so that next time it is referenced, causing a page fault interrupt, it will not be found and must be fetched from disk.
So, you cannot count disk accesses by the number of page fault interrups. You must look at the disk activity.
If you actually manage to generate 30 million page fault interrupts a second, you still may have zero disk accesses: The interrupt handler says: But I have got it here! Take a look in the Memory section of the Resource monitor: Is the Pysical Memory green all the way? (there is a grey part at the bottom; that is DMA buffers for IO equipment.) Is there never any dark blue "Standby", no light blue "Free"? Then you can go to the Disk section and observe how busy your paging disk is. If it is busy more than 20% of the time, then you may have to consider more RAM.
A few points worth noting: If your applications make heavy use of the file system, on the same disk as your page file, a significant part of the disk activity may be other than paging. 20% disk activity may be quite normal with file intensive applications running.
Second: A high number of "real" page faults are perfectly normal when you start a new application. The code and data segments are set up as an extension of the page file, the page tables for all segments set up with reset present flag and zero RAM address. When your application starts up, referencing code and data, each first reference to a page will be treated as a "real" page fault, and the page brought in. For pages from data segments, space in the paging file is not allocated until that page must yield because of RAM crowding, and the page has been modified. Pages from code segments never take any space in the paging file. (For a debugger, the code segments being debugged are data segments!)
Third: Code segments are shared. If you run five instances of your web browser, they address exactly the same RAM pages for the code. (For modified data, each have their own data).
Remember that only actively running code may generate page faults. If you have five instances of your web browser open, you are actively interacting with only one of them, and not with other applications. E.g. a media presentation or animation may run by itself in another window, but the RAM resources it requires are brought in place within milliseconds, and make up a tiny little fraction of the total functionality of the browser. Similar with other systems: When you are not interacting with them, 99+ percent of the time, they will not generate page faults, only when you ask for an operation that you haven't requested for a long time.
It is true that modern software is extremely bloated. But lots of it comes from tons of functions you never need, so they are never brought in from the .exe/.dll file into memory. A lot of stuff is code run once - initialization stuff, or only as a result of explicit user operations taking several magnitudes more time than the page fault, and after two memory sweeps the pages are over in the standby pool, ready for being overwritten by pages from the active working set. So the bloat has far more effect on disk space requirements than on paging.
Now Java and DOM are notorious for building large data structures. But even with those, 8 GByte is a lot. And even if the data structures are large, it is a very special appliaction referencing, say, every single node of the DOM tree all the time. A great deal of it goes first to "not present", then to "standby", and then possibly to the page file on a (single) page by page basis. When a user presses the PageDown key, maybe one or two memory pages have been swapped out. If you have other processes running in the background, they may have had a more urgent need for RAM. So there may be a very slight delay, bringing in that small branch of the DOM tree. Then it is in, and will be present as long as it is used.
I hear you saying that you have an extreme level of paging. I have heard such claims numerous times. When I have dived into it to see if the claims hold water, I have never found a paging disk bottleneck. The typical case is sers who insist that they need more RAM, but when you walk up to them while they work, start Resource Monitor and show them that one third of the RAM they have got is "free", one third is in "standby", and only one third is "in use". You can do that again and again, and every time they say: But wait a second - if I start this and that and that and that, then the "used" part going up, see? Yes, but not in your ordinary mode of working. I am not claiming that it is impossible to overload the RAM, I am just saying that you never do it in you ordinary work.
Those who regularly work with extremely memory intensive tasks like FEM, weather or discrete simulation (an ARM emulator counts only of it emulates down to the gae level - but then you are a hardware developer, not a software developer), they know what they are doing. Also, the software they use cost magnitudes more than 16 or 32 GBytes of RAM. Those are not the ones coming with vague suspicions about unbeliavbly high levels of paging.
|
|
|
|
|
I make a mistake by a factor of 1000, and not a single voice was raised...
30 million accesses a second makes 33 nanoseconds - not microseconds, as I wrote - between each access, on the average. I can assure you that no paging system can serve a hard page fault in 30 nanoseconds. That is like 100 clock cycles. Obviously it cannot be handled. But even referencing a new and swapped out memory page every 100 clock cycles, on the average, appears to be slightly on the high side.
|
|
|
|
|
I just upgraded my new-ish laptop to 32gb. Mostly so I can give my win7 vm up to 24gb RAM.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: I just upgraded my new-ish laptop to 32gb.
I'm very jealous! My stupid cheap laptop only goes to 8GB.
|
|
|
|
|
I have two 8-year old laptops than can only go to 8gb (and they're both maxed out).
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
My newish work laptop came with 32gb of ram, it's one of the few things I like about it; as with a crapton of browser tabs and multiple copies of visual studio on my old 16gb machine I could find myself swapping enough that even with an SSD to read/write to my system started lagging noticeably.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
8gb is fine for Win10. You must have some piece of software that is running in an infinite loop allocating memory for variables until you run out of space.
|
|
|
|
|
Fun fact of the day!
Each process on your PC has something called "Modified Page List Bytes" which is additional RAM that a process is using that is hidden from Task Manager.
This amount happily sits at around 8GB on my 32GB Desktop Machine. This amount cannot be picked up by Task Manager, and requires specialized RAM-based process monitors to detect (RAMMap, in-depth investigation into Windows Performance Counters, etc).
Whilst using such methods can tell you the total amount of invisible RAM being used, there is no way to tell what is using it, if something is leaking it, or even how to easily free it up (Although closing a process will free up its associated modified bytes)
Task Manager can show you at 30% total Memory usage when in reality you could be sitting at 90%+ and start tossing "Out Of Memory" exceptions any moment now. Disable your Pagefile to drastically speed up this process to experience this first hand
Have fun :p
-= Reelix =-
modified 26-Aug-19 13:46pm.
|
|
|
|
|
That's really great information and explains some additional things I've seen in recent past where things have crashed even though I have 0.5-1GB free (according to TaskManager).
Thanks for posting.
|
|
|
|
|
|
Quote Investigator is fantastic! I always enjoy their articles. Just last week I read one on the quote:
To Avoid Criticism,
Say Nothing,
Do Nothing,
Be Nothing
|
|
|
|
|
Even though it is scvhost.exe, it doesn't mean that Windows 10 is at fault.
Exit Android Studio and you will see your RAM freed up.
From my experience, scvhost is generic service something. It can be called by anyone.
|
|
|
|
|
I use Android Studio + Emulator + Firefox + Thunderbird on an older AMD A10 on Ubuntu Linux and the whole thing seldom goes over 6GB of ram.
Sometimes I have IntelliJ open at the same time all well under 8GB.
I guess there's something in your windows.
|
|
|
|
|
Check this out. I was just browsing through a folder and I played an mp4 file and the video played and then out of nowhere I got this message*:
"Because you're accessing sensitive info, you need to verify your password."
https://i.stack.imgur.com/vbbGC.png[^]
What!?!
I couldn't even tell what app was causing this to appear. It seems to be the app that is playing the mp4 video. Crazy, microsoft. Really crazy.
I did not enter my password and the app played the video and everything else works the same. Seems so fake!
*I blotted my valid MS login email out.
|
|
|
|
|
It may be the video player: some of them try to access metadata online I think.
Which player were you using?
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: It may be the video player: some of them try to access metadata online I think.
Again, I believe you are correct.
OriginalGriff wrote: Which player were you using?
That was part of the craziness. It was the built-in win10 one I think?
Can't really tell. There is nothing in the Store App that lets me know what is running. I do see "Movies & TV" so I think that is what it is called.
The additionally weird thing is that I've played the video a number of times again to see if the popup would come back and it didn't.
|
|
|
|
|
Hmmmm,
raddevus wrote: "Because you're accessing sensitive info, you need to verify your password." Do you have OneDrive as your default save location?
raddevus wrote: *I blotted my valid MS login email out *I have X-ray vision.
Best Wishes,
-David Delaune
|
|
|
|
|
I don’t have OneDrive as a default save location on my machine.
I wouldn’t ever want that really.
However, it is possible that the recent big update (1903 recently installed on my machine) May have changed something. However, I checked and that file is in my Downloads directory.
|
|
|
|
|
It is a real popup but I agree that they should make it clear which app is behind it.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
|
How very nice of them to add such an intrusive "feature" (which I'll bet no-one asked for, and which sends reams of personal information to their servers), instead of fixing the 1.3 Billion bugs in the OS.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I had one of those from Office365 a few weeks back. Absolutely no suggestion of what application needed my password.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: I had one of those from Office365 a few weeks back. Absolutely no suggestion of what application needed my password.
Yep, I've seen those too. Super annoying! This is the _new_ UI
|
|
|
|
|
mostly because i hated opening my browser just to answer simple questions.
trouble is, this violates google's ToS.
That's the only reason i haven't posted it here.
That and I use it for less than upstanding tasks as well.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
So ... why are you mentioning it now?
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|