On Tuesday, October 18, 2005 @ 4:11 AM, Hans du Plooy wrote:

On Tuesday 18 October 2005 13:47, Clayton wrote:

...

I've never had to resize a swap partition before... Do you have unused space? Otherwise you'll have to resize another partiton

too. You have two options:

1. Suppose your swap is /dev/hda2 close all your apps so you can free some memory swapoff /dev/hda2 **insert repartitioning/resizing** (you can delete the swap partition and make a bigger one in it's place mkswap /dev/hda2 swapon /dev/hda2 if the partition number changes, just remember to adapt your fstab

2. Just add another swap partition if you have space or put an extra disc in. Linux can handle multiple swap partitions.

Hans

I didn't think about the fact he might have some free space in between if the swap is first. That would certainly make it easier. And adding a second swap wouldn't seem to be too hard either. Is having 2 swaps equivalent to the size of one more or less a wash performance wise? Greg Wallace

The only performance difference you'll see with two swap partitions is what you get anyway between different parts of the discs, and these days that's hardly noticeable.

Hmmm that's more do-able. I can shrink the existing sda2 by a couple GB and add a new swap partition at sda3... I feel much more comfortable doing that than shrinking sda2 and then moving it to make room at the start of the disk so I can increase sda1. Not sure why that makes me feel better since it's all still mucking about with the partitions... C.

On Tueday, October 18, 2005 @ 5:06 AM, Hans du Plooy wrote:

On Tuesday 18 October 2005 14:57, Greg Wallace wrote:

...

I didn't think about the fact he might have some free space in between if the swap is first. That would certainly make it easier. And adding a second swap wouldn't seem to be too hard either. Is having 2 swaps equivalent to the size of one more or less a wash performance wise?

The only performance difference you'll see with two swap partitions is what

you get anyway between different parts of the discs, and these days that's hardly noticeable.

If the second swap partition is on a different disc, that would make a bigger difference.

Two swap partitions on two separate discs work well. All the servers I've built with two discs in a software raid-1, have the two swap partitions separately instead of a md device (no point in that).

Hans

Thanks for the info. Sounds like this may be a good option for him. Greg W

Clayton, On Tuesday 18 October 2005 06:17, Clayton wrote:

...

Do you have unused space? Otherwise you'll have to resize another partiton

No unpartitoned space. When I set up this system I assumed the 1GB RAM and 1GB swap would be enough, so the rest of the drive got allocated. That said, the Reiser partition is not full.

Current config is: /dev/sda1 = swap /dev/sda2 = / (33% full) (I didn't do a separate /home partition, although I'm wishing I had now)

You should at least consider swapping to a file. It works well enough if the file used is contiguous. That's easily accomplished when the file system is new, much harder later on. It also depends on the file system type you use. For a while I was swapping to a file on an XFS file system, and it worked fine. You should also consider getting more RAM. Unless you're running a lot of processes that mostly sit idle and can be moved to swap without adversely affecting performance, actually using your swap space is what's called "thrashing." If the so-called working set (the amount of RAM being actively referenced by running processes, not just allocated to them but remaining unaccessed) is larger than RAM, no amount of swap will make the system usable.

...

...

second swap wouldn't seem to be too hard either. Is having 2 swaps equivalent to the size of one more or less a wash performance wise?

That's a good question... what is performance like if I squeeze down /dev/sda2 and add a new swap partition at /dev/sda3?

Again, you should not be concerned about performance of swap, 'cause if you're actively using it, you're going to have very bad system performance. In fact, it is by far the most common way to bring a Linux system down: get it to swap or page excessively. Once the X server starts getting paged out, you're done for.

C.

Randall Schulz

On Wednesday 19 October 2005 2:37 am, Clayton wrote:

I'd love to get more RAM... but this is a work PC, and getting the approval for more RAM (even though a low cost item) is a pain.

I am doing a lot of swapping some days.... minimum of one Oracle database running 24x7 (sometimes 2 dBs), various Java based apps, VMWare, multiple files open in OpenOffice... I really do need more than 1GB RAM, but.. you know how it is trying to get sign off on IT purchases. :-P

That's good advice though about the usability... I'm going to use it as an argument for the hardware signoff :-)

C.

I saw that you mentioned using /dev/sda. For a system like this with all that you are doing I'd recommend multiple SCSI drives and a good high performance SCSI controller with as many channels on it as you can get. Along with the maximum main RAM this system will hold of course. A single hard drive is not enough; split that disk I/O out over multiple hard drives and multiple channels. IT justification: How much revenue is this system generating or maintaining for the company? This is one system where a hardware RAID controller may make more sense than software RAID. Due to the overhead of all the applications, having a separate processor to offload disk I/O might be more efficient. Either way (hardware versus software RAID) the SCSI drives would offer a huge improvement. A quad dual-core AMD 64-bit system may change my mind along with the 16-32GB memory support you'd probably get on the mainboard. Ah well, as long as you're wishing for more RAM you may as well help out that swap space too! Stan

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2005-10-18 at 15:17 +0200, Clayton wrote:

...

second swap wouldn't seem to be too hard either. Is having 2 swaps equivalent to the size of one more or less a wash performance wise?

That's a good question... what is performance like if I squeeze down /dev/sda2 and add a new swap partition at /dev/sda3?

No penalty for having two swaps, don't worry. You could also do a full backup of the system, and repartition everything: bigger swap, separate home... - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDVaLFtTMYHG2NR9URAvR0AJ4k/rd4gprgahM1ufb+0eLJGje0KgCfRbso N10ZBV3KWIb+HDCUKbPXGiQ= =Zkkb -----END PGP SIGNATURE-----

Ken Schneider wrote:

On Tue, 2005-10-18 at 16:15 +0200, Hans-Werner Hilse wrote:

...

Hi,

On Tue, 18 Oct 2005 13:47:11 +0200 Clayton wrote:

...

I've never had to resize a swap partition before... For 2.6 kernels I'd suggest a swap file. There's nearly no overhead compared to a swap partition. And you can just add it, no need for resizing other partitions and stuff. It's perfectly possible to keep your existing swap and add the swapfile like

# dd if=/dev/zero of=/swap2G bs=1G count=2 # mkswap /swap2G # swapon /swap2G

remember to put the swap file below the containing partition in your /etc/fstab.

Sorry but you have that backwards. A swap partition is much more efficient than a swap file. You don't have the overhead of the filesystem i/o to deal with. Same reason many databases are run on raw partitions.

Also, with LVM, you can resize the swap partition if needed.

Hi, On Tue, 18 Oct 2005 13:27:06 -0400 Ken Schneider wrote:

...

For 2.6 kernels I'd suggest a swap file. There's nearly no overhead compared to a swap partition. [...]

Sorry but you have that backwards. A swap partition is much more efficient than a swap file. You don't have the overhead of the filesystem i/o to deal with. Same reason many databases are run on raw partitions.

Sorry, but it's not me who didn't his homework lately, see: http://www.kerneltraffic.org/kernel-traffic/kt20050828_319.html#3 Short summary: I was right... Maybe I should quote the most important sentence (by A.Morton): "The kernel generates a map of swap offset -> disk blocks at swapon time and from then on uses that map to perform swap I/O directly against the underlying disk queue, bypassing all caching, metadata and filesystem code." Back in the old 2.4 era, you were of course right. And databases tend to run in userspace that doesn't offer the new path easily, don't they? -hwh