From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 3 04:19:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11D06106566C for ; Sat, 3 Dec 2011 04:19:08 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 94E9A8FC14 for ; Sat, 3 Dec 2011 04:19:07 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so2592512wgb.31 for ; Fri, 02 Dec 2011 20:19:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=CbYNQLTAU5WcrC4mb12R/Klz+U1+rHxx9hBkSPcDvtM=; b=HnMWvPx3IJdFO5BSxDCrTm4hfLctPoe3f5n+WpgmxbHWdcj2tsrcQZNMFnapya9bPr MLuJpPlczdyei/CyTAlMPjK8fZcAo7NIl9bUV/NpfhfjqK3dgwnsvBLO+XnCV9glGpoF jXuXZAgtSTe9l0y5hQr6F+j7F/upIZqEhXUZo= Received: by 10.180.24.65 with SMTP id s1mr1443315wif.59.1322885944722; Fri, 02 Dec 2011 20:19:04 -0800 (PST) Received: from DataIX.net (ppp-21.171.dialinfree.com. [209.172.21.171]) by mx.google.com with ESMTPS id fg15sm13840380wbb.7.2011.12.02.20.19.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Dec 2011 20:19:03 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id pB34ItYQ059772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 23:18:55 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id pB34Il2u059771; Fri, 2 Dec 2011 23:18:47 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Fri, 2 Dec 2011 23:18:47 -0500 From: Jason Hellenthal To: Steven Hartland Message-ID: <20111203041847.GC38979@DataIX.net> References: <547298A3C38F407887E1AAAAC487DF6D@multiplay.co.uk> <4ED8E9D0.4070006@FreeBSD.org> <2537A2099932494E9E7019B53EBDAA34@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2537A2099932494E9E7019B53EBDAA34@multiplay.co.uk> Cc: freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: Invalid memory stats from vmstat and sysctl vm.vmtotal? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 04:19:08 -0000 On Fri, Dec 02, 2011 at 05:13:05PM -0000, Steven Hartland wrote: > ----- Original Message ----- > From: "Andriy Gapon" > > >> Totalling up RSS from ps axo "rss" gives a total in the region of that if > >> the vm stats are out by a factor of 4, in this case it should be: 8132557 > >> which is 7.75GB a much more realistic value. > >> > >> Am I totally missing something or is there problem here? > > > > Likely more of the former than of latter. Those virtual sizes are not > > sufficiently explained, but you have been warned that those are not physical > > sizes, so I am not sure why you try to compare the virtual figures with the > > physical figures. > > My miss-understanding was due to what "virtual" actually meant. > > > Here's an example. Let' say you mmap-ed a 1GB file into a process memory space, > > here you immediately increased your virtual size counts by 1GB, even if you hadn't > > accessed any bytes in the file yet and so none of them were in physical memory. > > The same applies to anonymous memory. > > > > P.S. the above is reveled by a cursory look through the code (which is publicly > > available btw) :-) > > Yer I did have a dig around before posting and ended up the code for vm.vmtotal, > which is where vmstat gets its info from but that's just a summation of each object's > size from vm_object_list. Thats where I got lost without an insight into what > a vm_object.size actually represents. > > Your info about mmap'ed files helped point me in the right direction as it > identified space that shows as virtual but doesn't show in swap or real ram, > which is what I was missing. > > Given this starting point the following links provided me with addtional > information:- > http://www.freebsd.org/doc/en/books/arch-handbook/vm.html > http://www.freebsd.org/doc/en/books/design-44bsd/overview-memory-management.html > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/ > http://www.cse.chalmers.se/edu/course/EDA203/unix4.pdf > > I was under the incorrect impression that Virtual Memory (VM) was so named as it > was a unified physical memory and swap (virtual memory), but its not that simple, > as other items such as file-backed objects also count to this total which would > never show in physical or swap allocation of other tools such as top and swapinfo. > > So what I believe is now the big cause of virtual memory uplift vs the memory > totals shown by ps / top is that the vm totals include things like file backed > memory mapped process binaries, shared libs etc many multiple times. > > This would explain why this specific machine shows the applification more than > others here as it runs thousands of very small lightweight processes. > > Thanks for pointer Andy, I now understand a lot more about the BSD VMS :) > > What do people think about expanding that entry in the man page of vmstat to > clarify just what active "virtual pages" really means? > > Regards > Steve > Thanks for your research Steve. That makes perfect sense and additions to the documentation are surely needed.