Date: Mon, 27 Jul 1998 10:45:50 -0700 (PDT) From: David Wolfskill <dhw@whistle.com> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Checking RAM Message-ID: <199807271745.KAA25470@pau-amma.whistle.com> In-Reply-To: <35BC9088.D189FAEF@csl.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Original exchange from -questions; I think what I'm going on about is rather more -hackerish, so that's where this is. dhw] >Date: Mon, 27 Jul 1998 15:36:56 +0100 >From: Adam Nealis <adamn@criterion.canon.co.uk> >> Could someone tell me how you can check the amount of RAM both available >> and in use at a given time on FreeBSD 2.2.6 ? >Try >dmesg | more >soon after a reboot. Should tell you how much RAM was found on the way up. Well, re-booting a production server that's been up for several months just to find out how much real memory the kernel saw may not be a viable option. :-} Granted, someone else suggested "top", which is fine for this particular resource.... However, as a follow-on to a discussion I was having with someone else (where I was doing a bunch of whining about the challenges I was having in "automatically" being able to determine the configuration of a given FreeBSD box), the random idea came up that *IF* the kernel could stash away the results of its probing in some way that might be amenable to access by suitably-privileged processes at times arbitrarily distant from re-boot (i.e, scannning logs & output of dmesg won't do the job), this *might* be sufficiently useful to warrant some effort. I suppose that one way to do a hack that could be adequate for a trial run would be to have /etc/rc run a script that would run "dmesg" & parse it, then stuff the results of this parsing into a file that could be read by a process running under effective GID "operator". The objective would be to record enough information that given the (properly-interpreted) content of the file in question, it would be possible to specify the components to re-construct the machine in question. In turn, the reason for this is for "disaster recovery preparedness". Does this seem as if it might possibly be of use to anyone else? Thanks, david -- David Wolfskill UNIX System Administrator dhw@whistle.com voice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807271745.KAA25470>