> 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 <[email protected]> wrote:
On Friday, 26 May, 2017 08:27, Jamie <[email protected]> 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
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
