From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18915 invoked from network); 9 Jul 2021 20:24:05 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 9 Jul 2021 20:24:05 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 0796794550; Sat, 10 Jul 2021 06:24:02 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 2A87D93D7A; Sat, 10 Jul 2021 06:23:15 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id E507093D7A; Sat, 10 Jul 2021 06:23:12 +1000 (AEST) X-Greylist: delayed 521 seconds by postgrey-1.36 at minnie.tuhs.org; Sat, 10 Jul 2021 06:23:11 AEST Received: from ste-pvt-msa2.bahnhof.se (ste-pvt-msa2.bahnhof.se [213.80.101.71]) by minnie.tuhs.org (Postfix) with ESMTPS id BBF5693D3C for ; Sat, 10 Jul 2021 06:23:11 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTP id 47B79406D6 for ; Fri, 9 Jul 2021 22:14:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from ste-pvt-msa2.bahnhof.se ([127.0.0.1]) by localhost (ste-ftg-msa2.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBvU17DUas1B for ; Fri, 9 Jul 2021 22:14:27 +0200 (CEST) Received: by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTPA id 1B880406CC for ; Fri, 9 Jul 2021 22:14:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (Postfix) with ESMTPS id 43C7D2E0157 for ; Fri, 9 Jul 2021 22:14:26 +0200 (CEST) Date: Fri, 9 Jul 2021 20:14:25 +0000 From: Michael =?utf-8?B?S2rDtnJsaW5n?= To: tuhs@minnie.tuhs.org Message-ID: <9732faa4-55cf-44c4-9bdc-47c4c9b40c3f@localhost> References: <20210704004757.GB24671@tau1.ceti.pl> <20210705071450.GA12885@tau1.ceti.pl> <20210706231659.GA13225@tau1.ceti.pl> <20210707183222.GA9897@tau1.ceti.pl> <6b736f82-97ed-4e51-9652-e672be4e2c66@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [TUHS] [tuhs] The Unix shell: a 50-year view X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 8 Jul 2021 17:47 -0400, from tytso@mit.edu (Theodore Ts'o): >> I'm going to stick my neck out here by saying that the VSZ and RSS >> values reported by ps, at least for Firefox, are largely meaningless. > > No, VSZ is correct, but it's confusing since it includes things that > you might not expect. VSZ includes *all* virtual memory space > consumed by a process. You may very well be correct. That would, however, seem to me to make it _correct_, but still not necessarily _meaningful_ for trying to determine the amount of memory used by a _specific_ process; and similarly for the RSS. >> I started my usual Firefox instance, which has a handful of plugins, >> about a metric gazillion bookmarks, and has been my main web browser >> profile for years (so it probably has collected some crud over time). >> `ps auxw` reported that process as having a total RSS of a whopping >> 374 GB. > > I don't think that's right. Are you sure it's not 374MB? I started > firefox-esr on my Debian machine, and the PS output is: On this, I believe I must stand corrected. For my previous post, I checked the man page for ps, and noted that RSS and VSZ are both reported in units of 1 KiB. For an attempt just now, the ps output is similarly: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND michael 29890 51.8 0.7 2728696 255456 tty2 Sl+ 21:46 0:06 firefox-esr michael 29942 4.7 0.3 2415008 106448 tty2 Sl+ 21:46 0:00 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 1 -isF michael 29994 38.3 0.7 34043160 240612 tty2 Sl+ 21:46 0:04 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 2 -isF michael 30168 3.2 0.2 2400636 72992 tty2 Sl+ 21:46 0:00 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 3 -isF On my system, unless I need to get a different calculator, 0.7% of memory is either 229 ± <16 or 688 ± <49 MiB, depending on whether it counts only RAM or also includes swap space. The 249 MiB RSS of the main process also much more closely matches the difference that was reported by `free` in my previous experiment. Oddly, when trying the same thing again now, the difference as reported by `free` is 423 MiB, so I'm not quite sure what's going on there, but at least all of those numbers are considerably more _plausible_, both in isolation and in relation to other relevant measurements. I'm honestly not sure how I went from the `ps` output (which wasn't particularly dissimilar from the above, though of course I don't know what the exact numbers were since I didn't record them) and the unit of measurement being KiB, to going from KiB straight to GiB. > That's not because the hello world program actually used half a > megabyte worth of the C library; but rather, almost half a megabyte of > the C library has been paged in to support all of the processes > currently running in the system. It also follows that every process > using shared library is going to have an RSS which is at least 512k. This is definitely a point on which I agree, and which I tried to point out with the mention of shared libraries in my previous post. -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”