DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Installation and Upgrading

OpenBSD Installation and Upgrading Installing and upgrading OpenBSD.

Reply
 
Thread Tools Display Modes
Old 14th February 2009
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 2,888
Thanked 190 Times in 160 Posts
Default

Quote:
Originally Posted by JohnHicks View Post
I have about 1GB of swap and 150MB for /var so is that enough?
There are no black & white answers to these questions, as it depends upon usage.
  • As for how much swap to allocate, one consideration is whether you wish to retain the contents of core memory if the system crashes. If the answer is yes, then one metric used is that swap needs to be somewhere between the amount of RAM present + 1MB to 2x the amount of RAM present (Personally, I would go with 2x to include full system information...). ie. if a system has 1GB of RAM installed, the corresponding amount of swap should be 1GB+ - 2GB. If you aren't concerned about debugging crashes, then the allocated amount of swap can be less.

    Another consideration is whether there is even enough RAM to run the system. There was a time when RAM was quite expensive such that swapping to disk was considered acceptable given the price. Today, RAM is much cheaper comparatively, so for performance reasons people tend to have more than what is needed by the system itself. Average desktop usage may only require 512MB, so 1GB of RAM will probably mean that the system will never swap. And as an extreme, some people will run with no swap because they have sufficient memory available, & they want the disk space for other reasons; plus, they are willing to live with the risk of having no swap available.

    A third consideration is system usage. A heavily-loaded server may require more memory to service lots of requests, just as a huge application may need a lot of memory to implement whatever it may be doing. Any of these factors has a direct bearing on whether a system will swap memory contents to disk.

    The definitive answer for how much swap should be configured comes down to personal choice tempered by watching the output of top(1). top(1) should become your friend.

    So if the system doesn't need to swap, then everything can hum along with no issue. The problem is whether the system ever needs to swap & insufficient swap space is to be found. In this case, the system will crash -- potentially losing valuable application data. Your role is to determine where you want to be in this risk management spectrum -- deciding on how much disk space to allocate to swap based on the amount of RAM present along with system usage.
  • As for how much space to allocate to /var (or any other partition...), this also depends upon usage. The FAQ frames a number of issues in Section 4.5.2:

    http://openbsd.org/faq/faq4.html#Disks

    ...which you should consider, but if you are new to OpenBSD, you should also consider using a single partition for everything until you have a better idea of your usage patterns. At that point, you can refine how many & how large/small any particular partition should be in size.
If this message helps provide (any) perspective, you should be beginning to see that as a newbie, you will probably not stay with your first installation. Basic installation of the operating system is simple enough such that re-installing isn't too difficult, so get some experience first, & then revisit these questions of how much swap & how large should any particular partition be after you know how you will be using this particular system.
Quote:
It feels like this stuff is over my head...
No one learned this stuff overnight, so give yourself some time to get over the learning curve. Unix provides a lot of knobs such that you can get the most out of your hardware. The flip side is that there are few (if any...) safety nets provided. Learning to ask critical questions & learning how to find answers to your own questions is both necessary & rewarding.

Last edited by ocicat; 14th February 2009 at 01:53 AM.
Reply With Quote
Old 14th February 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,708
Thanked 214 Times in 189 Posts
Default

John, your system has 3/4 of a GB (768MB) of RAM, per your earlier dmesgs.

Your swap space is sufficient for capturing RAM during a dump. Unfortunately, you need at least 768MB free space available in /var (or mounted to /var/crash) in order to have savecore(8) save the dump for gdb(1).

Are you *sure* you want to do all of this?

Once you have sufficient free disk space in /var or /var/crash for savecore(8) to save a copy of RAM, you still won't have sufficient useful information. Why? Because any traces produced by ddb(4) or gdb(1) will only have addresses. You'll want debugging symbols if you want a functional, useful kernel for debugging. To get that, you'll need to compile a custom kernel from -current source, adding this line to your custom configuration file:
makeoptions DEBUG="-g"
as described in options(8). Kernel building is described in detail in FAQ 5. The kernel build will create two kernels; a stripped "bsd" for booting, and a "bsd.gdb" with debugging symbols for use with gdb(1).

If you have all that, the general process is:
  • Set up the sysctl ddb.console=1 in /etc/sysctl.conf and reboot
  • Create the hang situation
  • Cause the kernel to hang to "break" the hang and enter ddb(4). Of course, the kernel must respond to keyboard interrupts for this to happen -- it may not, so before making the storage and kernel changes, test that the kernel breaks into ddb(4).
  • In ddb(4), issue a "boot dump" command. This will save RAM to swap (and you have sufficient swap space right now).
  • On boot, /etc/rc will run savecore(8), which will save the dump to the filesystem in /var/crash (you don't have enough space right now)
  • Run the script(1) command to capture the console to a file.
  • Per crash(8), start gdb(1), point to the dump in /var/crash with the file command, then point to your debugging symbols kernel with target kvm.
  • use the bt command to obtain a backtrace (which will show what the kernel has been up to while hung, it may even show why it was hung. With the gdb symbols, it will show modules and source code line numbers.
  • quit gdb(1).
  • exit the script(1) shell.
  • Clean up the output file, e.g.: # col -b < typescript > my.output
All of this, just to get a backtrace that you can then send in an e-mail to misc.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Annoying blue config dialog _hmp_ FreeBSD Ports and Packages 11 28th December 2008 05:37 PM
shutdown message Mr-Biscuit FreeBSD General 1 16th November 2008 11:59 PM
(ttyv0) message. delboy FreeBSD Security 10 29th May 2008 08:25 PM
Message alerts? ocicat Feedback and Suggestions 2 2nd May 2008 03:25 PM


All times are GMT. The time now is 07:55 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick