Nee daar is al heeeeeeeeeeeeeeeeeeeeeeeel veel over gespeculeerd en geschreven en geprobeerd, en microsoft is er zelf ook mee bezig geweest. Conlusie daar was dat het niet hielp.
Het haalt gewoon RAM weg wat anders beter gebruikt had kunnen worden. Het is geen virtual memory, het is een pagefile en dat is heel wat anders.
Netzoiets als je pagefile uitzetten wat sommige mensen denken te doen, windows gaat dan dan gewoon naar andere bestanden pagen (alleen niet naar pagefile.sys!), plus dat sommige programma's gewoon een pagefile nodig hebben.
Kortom niet kloten, stel je minimum pagefile lekker ruim in als je de ruimte hebt, en maak de max waarde flink veel groter, voor de zekerheid.
Voor de details:
edit:
Putting a pagefile in a RAM drive is a ridiculous idea in theory, and almost always a performance hit when tested under real-world workloads.
You can't do this unless you have plenty of RAM -- and if you have plenty of RAM, you aren't hitting your pagefile very often in the first place!
Conversely, if you don't have plenty of RAM, dedicating some of it to a RAM drive will only increase your pagefault rate.
Now you might say "yeah, but those additional page faults will go faster than they otherwise would because they're satisfied in RAM." True, but it is still better to not incur them in the first place. And, you will also be increasing the page faults that have to be resolved to exe's and dll's, and the pagefile in RAM won't do diddly to speed those up. But thanks to the pagefile in RAM, you'll have more of them...
Also: the system is ALREADY cacheing pages in memory. Pages lost from working sets are not written out to disk immediately (or at all if they weren't modified), and even after being written out to disk, are not assigned to another process immediately. They're kept on the modified and standby page lists, respectively. The memory access behavior of most apps being what it is, you tend to access the same sets of pages over time... so if you access a page you lost from your working set recently, odds are its contents are still in memory, on one of those lists. So you don't have to go to disk for it.
Committing RAM to a RAMdisk and putting a pagefile on it makes fewer pages available for those lists, making that mechanism much less effective.
And even for those pagefaults resolved to the RAMdisk pagefile, you are still having to go through the disk drivers. You don't have to for pagefaults resolved on the standby or modified lists.
I'll give you another argument, if you don't buy the above: The people who wrote the NT core code, including the memory management code are some of the smartest folks I've ever encountered in the business. Many of these people have been working on virtual memory operating systems for over thirty years. And the implementation of paging IO has been the subject of much research and study, not just by them but by many other people who do operating systems for a living.
Trust me when I tell you that if these thought that any mechanism that you can approximate by shoehorning a "pagefile on RAMdrive" into the system would help, it would be in the memory management code already!
Do you think these folks work in a complete vacuum? Do you think they are not aware of things people are trying to speed up the system? Do you think they don't evaluate those things? Do you really think they haven't tried pagefiles on RAMdisks in the MS labs? Do you really believe that they wouldn't incorporate an equivalent strategy right into the OS if they thought it would improve performance?
Well, if you think any of those things, you're simply wrong.
Putting a pagefile on a RAMdisk is a self-evidently absurd idea in theory, and actual measurement proves it to be a terrible idea in practice. Forget about it.
[
Voor 92% gewijzigd door
maratropa op 16-04-2004 19:27
]
:strip_icc():strip_exif()/u/13072/Avator_klein.jpg?f=community)
:strip_icc():strip_exif()/u/21247/oranje.jpg?f=community)
/u/4501/crop5bdb35c450e89.png?f=community)
:strip_exif()/u/2603/icon.gif?f=community){kind=icon}
Dit topic is gesloten.