Do you have the LargeSystemCache set to 0 or to 1? HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
If the machine is *not* running anything and is "just a file server" the you want LargeSystemCache=1 and DisablePagingExecutive=1 If it runs any applications at all (that is, anything that did not come with the default install of the OS) then you want LargeSystemCache=0 and DisablePagingExecutive set depending on whether or not you want the OS itself to be swappable (which depends on how much memory you can afford -- if you can afford more than 4 GB, set DisablePagingExecutive=1 to increase performance by forcing the OS kernel to remain in V:R memory (the parts in V=R always remain resident)). You should also make sure all the "I can't afford more than 256 KB of RAM" features that do nothing other than slow the system down when you have suffient resources such as SuperFetch, Prefetch, etc. are disabled. They really adversely affect performance unless disabled. So, you have not yet said what the *real* issue is. Is this causing a preformance issue (which would include VirtAlloc failures or Commit Failures -- also known as Out of Memory errors), or are you just upset that the RAM for which money was paid is actually being used for something? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı > -----Original Message----- > From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] > On Behalf Of Jamie > Sent: Friday, 26 May, 2017 12:41 > To: SQLite mailing list > Subject: Re: [sqlite] Memory Issue - GLOBs and Windows Active Mapped File > > > https://support.microsoft.com/en-us/help/2549369/performance-degrades- > when-accessing-large-files-with-file-flag-random-access > > > > Although the optimization is good, it sounds like it is the typical > Microsoft designed-by-flock-of-idiots software. There is absolutely no > way that this should *ever* happen unless the cache was designed by > complete utter morons. Of course, knowing the history of this the code > that "works properly" was probably patented IBM technology that had to be > removed and re-written (defectively) by Microsoft after they stole OS/2 to > develop Windows NT ... > > > > And I know that this "bug" is present still in Windows 10 1607. Don't > know if they have fixed it in 1703, but I kind of doubt it. Instead they > added "page compression" (that you cannot disable) to create even more > problems. > While there is a lot of controversy with how Windows handles Disk Cache, I > don't think the problem I'm experiencing is related to that. I don't > believe Windows will ever set an Active File Mapping for Disk Cache, since > these are often tied to running processes/applications. > I think the problem may be related to reading byte data (BLOBs) from a > Database, since the Active File Map only seems to occur after reading > BLOBs from a table, which is why I considered sqlite or the sqlite.net > library may be reading from the disk with the wrong parameters or not > properly freeing the resources after they've been used for reading BLOBs. > I created that simple program (the one that just reads BLOBs over and > over) just to help narrow down the problem. > > To reiterate, the Active File Maps only seem to appear and persist for > files/tables that I have read byte data (BLOBs) from. Which is why I think > the problem is related to sqlite and reading byte data (BLOBs). > > > On Friday, May 26, 2017 1:04 PM, Keith Medcalf <kmedc...@dessus.com> > wrote: > > > On Friday, 26 May, 2017 08:27, Jamie <eqrecov...@yahoo.com> said: > > >> <https://msdn.microsoft.com/en- > us/library/windows/hardware/dn567645.aspx> > >> says that there is a different kind of file cache for a random-access > >> file, and that it shows up as active mapped pages. > >> https://support.microsoft.com/en-us/help/976618/you-experience- > performance-issues-in-applications-and-services-when-the-system-file-> > cache-consumes-most-of-the-physical-ram > > > These pages are describing an unrelated problem with a Windows > Service(s), > > as those active pages under the category for METAFILE, and not under > > Mapped File. > > https://support.microsoft.com/en-us/help/2549369/performance-degrades- > when-accessing-large-files-with-file-flag-random-access > > Although the optimization is good, it sounds like it is the typical > Microsoft designed-by-flock-of-idiots software. There is absolutely no > way that this should *ever* happen unless the cache was designed by > complete utter morons. Of course, knowing the history of this the code > that "works properly" was probably patented IBM technology that had to be > removed and re-written (defectively) by Microsoft after they stole OS/2 to > develop Windows NT ... > > And I know that this "bug" is present still in Windows 10 1607. Don't > know if they have fixed it in 1703, but I kind of doubt it. Instead they > added "page compression" (that you cannot disable) to create even more > problems. > > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
