Date: Mon, 27 Jul 1998 13:03:11 -0700 (PDT) From: Ian Kallen <ian@gamespot.com> To: David Wolfskill <dhw@whistle.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Checking RAM Message-ID: <Pine.BSF.3.95q.980727125929.782I-100000@mail.gamespot.com> In-Reply-To: <199807271745.KAA25470@pau-amma.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
While it might indeed be useful to fetch the last reboot's dmesg output (stuff it into /var/log/dmesg.reboot or something), you can get the physical ram from "sysctl hw.physmem" -Ian On Mon, 27 Jul 1998, David Wolfskill wrote: :>> 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? -- We do not colonize. We conquer. We rule. There is no other way for us. -- Rojan, "By Any Other Name", stardate 4657.5 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?Pine.BSF.3.95q.980727125929.782I-100000>