No. You are confusing several issues here.
There is "process size", which is the number of byte addresses that are theoretically valid within a process, as registered in the "process page table". Attempting to reference an address that has no corresponding page table entry causes a SEGV. Because accidentally dereferencing a NULL pointer is a common mistake and NULL is usually represented by binary all zeroes, the first page of a process never has a page table entry. The cache_size and the mmap_size both influence how much of the "process size" is used to hold pages from your database file, by keeping a copy in the cache or mapping memory to the db disk file respectively. Then there is "resident set size" (RSS), which is the portion of "process size" that, at a specific instant, actually refers to an address in main memory. Attempting to reference an address whose page table entry indicates that it is not currently in main memory causes a "page fault". The OS will interrupt program execution, allocate a page in main memory and provide the currently valid contents before restarting program execution at the instruction that caused the page fault. Because main memory is usually much smaller than the combined process size of all currently running processes, the latter compete for main memory. The OS attempts to keep frequently accessed pages in main memory. It also attempts to re-use immutable pages by making them "shared"; it keeps just one copy in main memory and lets multiple processes map that page into their address space. This is where "process set size" PSS comes into play. PSS is a measure of how much memory load is a process' fault. Each resident page that is exclusively used by a single process is that process' fault alone. The portion of cache_size that is used and currently resident falls within that category., as do stack, static non const and heap memory. Each resident page that is used by more than one process is the collective fault of all the processes. The portion of mmap_size that is used and currently resident falls within this category, as do code (most notably libraray code) and static const memory. Since blame is apportioned by current use, the PSS of a given process can and often does change without any action of its own. Creating or terminating a process that runs the same program, calls the same library or uses the same shared memory segment will change the PSS of any given process. IF - you have a system with a large enough amount of main memory - and with a large enough amount of free main memory - and run only one copy of your program - and cache_size or mmap_size respectively are set larger than your db file - and you are running a single copy of your application THEN - running a query than visits every row in your database (i.e. causes a page fault for each page) is likely to cause the PSS of the process to increase by the size of your db file. - running the same query in a second process will cause the RSS of the original process to decrease by about half of the application code size and half the mmap_size SO - both cache_size and mmap_size TEND TO increase PSS, but mmap_size has the potential to split this among several instances of your application runnung with the same db file. If you are running on a system that has severe main memory constraints, both settings will probably just shift the load between file IO and swap/page IO. Note thsat the sum of all RSS of all running processes can never exceed main memory. -----Ursprüngliche Nachricht----- Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Nick Gesendet: Donnerstag, 12. April 2018 09:05 An: sqlite-users@mailinglists.sqlite.org Betreff: Re: [sqlite] [EXTERNAL] Does mmap increase PSS? Thanks for your explanation. I want to get a confirmation that my understanding is correct and that if I use mmap_size=256M and I have only 1 process, then the PSS of the process will always the same as the size of my db file, as unixMapfile(-1) means map the whole file. (A big db file means 256M PSS) Is that correct? In fact I had expected mmap only took up virtual memory instead of PSS. -- Sent from: http://sqlite.1065341.n5.nabble.com/ _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___________________________________________ Gunter Hick | Software Engineer | Scientific Games International GmbH | Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43 1 80100 - 0 May be privileged. May be confidential. Please delete if not the addressee. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
