On Sat, Apr 19, 2003, Lucky Green wrote: > David wrote: > > ``Inactive'' just means that the page just hasn't been > > accessed for a while and is a candidtate for replacement. > > However, on a system without swap, the system has nowhere to > > send the page if it is dirty. The only pages that can always > > be discarded and reused are those in the ``Cache'' and > > ``Free'' categories. > > > > So the bottom line is that you really are running out of memory. > > Ah! That was not clear to me from reading the VM docs. It now appears > that the culprit is GBDE. Copying a 700MB file from the GBDE partition > to another drive causes the inactive memory to increase by roughly the > file size. Within about a minute after the copy has completed, the > inactive memory drops from over 700MB to about 500MB and remains there. > Which would explain why the server is running out of memory. Unmounting > the GBDE partition reduces the inactive memory down to 130MB, but still > does not appear to recover all memory used by the copying process. Unfortunately, it's not that straightforward. FreeBSD doesn't separate clean and dirty pages in the inactive queue. Many of the ``inactive'' pages in this case could be data from the large file you just copied, which would be clean and easily replaceable since they have not been modified in memory. With cp(1), this kind of caching by the VM system should not happen for files larger than 8 MB. A (perhaps unlikely) possibility is that GBDE uses some sort of specialized caching to mitigate the overhead of encryption. In any case, it's hard to conclude anything, since the system dynamically tunes the queue sizes based on demand and you can't determine the proportion of clean and dirty pages by looking at the size of the inactive queue. You're only out of memory when all of the pages are dirty. BTW, I assume you have no swap due to the security concerns you voiced previously. Surely you've considered using GBDE to implement a secure swap partition.Received on Sat Apr 19 2003 - 22:49:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:04 UTC