Increase SWAP

[Duffs]

Hi,

I have a HP-UX server that is currently performing very poorly and I need to increase the physical RAM:

# free -m
total used free shared buffers cached
Mem: 504 502 2 1166 178 210
-/+ buffers/cache: 113 391
Swap: 1300 127 1173

The issue I have is that the server was built using the whole disk approach; i.e.
# vgdisplay -v
bash: vgdisplay: command not found

My question is; if I install additional physical memory is it possible to increase the swap size also (with this whole disk config)?

I would imagine that if I added an extra 512MB RAM the swap would need to be increased to at least 2G otherwise this would potentially create more performance issues?

R,
D.

[Matti_Kurkela]

The fact that you're using the "whole disk approach" indicates you're using something older than HP-UX 11.00, i.e. you're still using something that was officially unsupported a *long* time ago.

Without knowing your HP-UX version (and perhaps the hardware model), it's rather hard to know what might be possible. But I guess even old versions would probably allow adding a second disk and using it (or a part of it) as an extra swap/paging area.

Please show the outputs of:

uname -a
model

MK

[Duffs]

Hi MK,

My apologies, the server is actually running RD Linux 6.2 (Zoot).

R,
D.

[Matti_Kurkela]

"RD Linux?" Do you mean RedHat Linux 6.2? (NOTE: no word "Enterprise" in there)

According to Wikipedia, it was released in April 2000, and used kernel version 2.2.14. "Zoot" was the version's codename. Its support situation is roughly equivalent to HP-UX 10.20.

You haven't said anything about the actual hardware, but my guess is it's probably about as old as the OS installation.

"Whole disk approach" is probably not the right expression in this case: it is likely at least the boot disk is partitioned using a standard PC partition table.

To see what's possible and what isn't, it would be necessary to take a look at your disk partitioning and swap configuration:

fdisk -l

swapon -s
or
cat /proc/swaps

Unless your swap partition has unallocated space immediately adjacent to it, you cannot really extend the existing swap space without a major disk reorganization. I would prefer not doing that for such an old system without having a good recovery strategy in place (up to and including "what to do if this old clunker just plain won't boot any more").

But you should be able to create a second swap partition if you have a suitable amount of unallocated space on any disk.

Since you would be creating new partitions on disks that are already in use, a reboot will be required to make the new partition table effective.

A much nicer solution would be to migrate the application(s) running on this system to another, more modern system - but perhaps something is preventing you from doing that. May I ask what that might be?

MK

[Duffs]

Hi MK,

The hardware is an old HP NetServer 1000r and the fdisk is as follows:

# fdisk -l

Disk /dev/sda: 64 heads, 32 sectors, 17366 cylinders
Units = cylinders of 2048 * 512 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 2001 2049008 fd Linux raid autodetect
/dev/sda2 2002 17366 15733760 5 Extended
/dev/sda5 2002 4002 2049008 fd Linux raid autodetect
/dev/sda6 4003 6003 2049008 fd Linux raid autodetect
/dev/sda7 6004 8004 2049008 fd Linux raid autodetect
/dev/sda8 8005 10005 2049008 fd Linux raid autodetect
/dev/sda9 10006 12006 2049008 fd Linux raid autodetect
/dev/sda10 12007 14007 2049008 fd Linux raid autodetect
/dev/sda11 14008 16008 2049008 fd Linux raid autodetect
/dev/sda12 16009 17309 1332208 fd Linux raid autodetect

# swapon -s
Filename Type Size Used Priority
/dev/md0 partition 1332088 130520 -1

I do not know it was possible to create/extend secondary swap space without LVM?

I am currently building a business case to get this migrated onto new hardware and new OS so just analysing the h/w & s/w for this reason.

R,
D.

[Alan_152 · Accepted solution]

The quick/dirty approach would be to install a new hard drive, format it, and reconfigure fstab to us it as the swap file system.

In your case, I would think that the proper approach would be to back everything up, format and rebuild the file systems the way you want them, then restore everything.

First things first, though... install your physical memory and see if performance increases to your satisfaction. You may not need to do anything to your filesystems at all.

[Duffs]

I am going to push through with the new build for this one. It's a lost cause, simply not worth the money and effort to keep a box of this spec managing prod apps - not to mention the lack of support.