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.

- 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


- 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 


- 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 

-----Urspr√ľngliche Nachricht-----
Von: sqlite-users [] Im 
Auftrag von Nick
Gesendet: Donnerstag, 12. April 2018 09:05
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:
sqlite-users mailing list

 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

Reply via email to