Memory Usage in a IBM Server running RHEL 3
Samuel Victor
AMD Opteron Server. The Server is running Red Hat Enterprise Linux 3.
The server came loaded with 3GB of RAM and upon constant analysis I
found that it using less than 1GB of RAM while it shows a iowait of
94%. Kindly let me know how to resolve the issue.
08:07:30 up 1 day, 17:03, 1 user, load average: 4.46, 3.45, 3.63
189 processes: 187 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: cpu user nice system irq softirq iowait
idle
total 2.5% 0.0% 2.9% 0.0% 0.3% 94.0%
0.0%
Mem: 3094216k av, 768436k used, 2325780k free, 0k shrd,
160108k buff
322528k active, 102208k inactive
Swap: 6289408k av, 0k used, 6289408k free
143228k cached
And I also noticed a couple of errors as shown below in the dmesg
output
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
....... : Delivery Type: 0
....... : LTS : 0
.... register #01: 00030011
....... : max redirection entries: 0003
An unexpected IO-APIC was found. If this kernel release is less than
three months old please report this to linu...@vger.kernel.org
....... : PRQ implemented: 0
....... : IO APIC version: 0011
.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 001 01 1 1 0 1 0 1 1 B9
01 001 01 1 1 0 1 0 1 1 C1
02 001 01 1 1 0 1 0 1 1 C9
03 000 00 1 0 0 0 0 0 0 00
IO APIC #3......
.... register #00: 03000000
....... : physical APIC id: 03
....... : Delivery Type: 0
....... : LTS : 0
.... register #01: 00030011
....... : max redirection entries: 0003
An unexpected IO-APIC was found. If this kernel release is less than
three months old please report this to linu...@vger.kernel.org
....... : PRQ implemented: 0
....... : IO APIC version: 0011
.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 000 00 1 0 0 0 0 0 0 00
02 000 00 1 0 0 0 0 0 0 00
03 000 00 1 0 0 0 0 0 0 00
Jonathan Edwards
> The following is the top output from a IBM eServer 325 running on a
> AMD Opteron Server. The Server is running Red Hat Enterprise Linux 3.
> The server came loaded with 3GB of RAM and upon constant analysis I
> found that it using less than 1GB of RAM while it shows a iowait of
> 94%. Kindly let me know how to resolve the issue.
>
Is CONFIG_X86_4G set in the /boot/config file?
Samuel Victor
Jonathan Edwards <jon...@qx.net> wrote in message news:<pan.2005.03.13....@qx.net>...
Michael Heiming
In comp.os.linux.setup Samuel Victor <samvi...@yahoo.com>:
> The following is the top output from a IBM eServer 325 running on a
> AMD Opteron Server. The Server is running Red Hat Enterprise Linux 3.
> The server came loaded with 3GB of RAM and upon constant analysis I
> found that it using less than 1GB of RAM while it shows a iowait of
> 94%. Kindly let me know how to resolve the issue.
First of, are you running the latest patches + update kernel
available from rhn? 'uname -r' should tell concerning the kernel.
> 08:07:30 up 1 day, 17:03, 1 user, load average: 4.46, 3.45, 3.63
> 189 processes: 187 sleeping, 2 running, 0 zombie, 0 stopped
> CPU states: cpu user nice system irq softirq iowait
> idle
> total 2.5% 0.0% 2.9% 0.0% 0.3% 94.0%
> 0.0%
Might be just one or another cron/anacron job left over, updatedb
or so, perhaps stuck on a nfs mount? Check what processes 'ps
faux' are most likely for the problem.
> And I also noticed a couple of errors as shown below in the dmesg
> output.
Again, there have been numerous kernel updates for RHEL 3.0, the
problem you are seeing might be resolved some time ago, but alas
without knowing 'uname -r' your kernel version, hard to tell.
BTW
Please don't post a problem completely unrelated to sendmail, to
the sendmail ng, thx.
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 288: Hard drive sleeping. Let it wake up on
it's own...
Jonathan Edwards
You might want to try rebuilding the kernel with it set. Here is the
descrption of the option:
CONFIG_X86_4G:
This option is only useful for systems that have more than 1 GB
of RAM.
The default kernel VM layout leaves 1 GB of virtual memory for
kernel-space mappings, and 3 GB of VM for user-space applications.
This option ups both the kernel-space VM and the user-space VM to
4 GB.
The cost of this option is additional TLB flushes done at
system-entry points that transition from user-mode into kernel-mode.
I.e. system calls and page faults, and IRQs that interrupt user-mode
code. There's also additional overhead to kernel operations that copy
memory to/from user-space. The overhead from this is hard to tell and
depends on the workload - it can be anything from no visible overhead
to 20-30% overhead. A good rule of thumb is to count with a runtime
overhead of 20%.
The upside is the much increased kernel-space VM, which more than
quadruples the maximum amount of RAM supported. Kernels compiled with
this option boot on 64GB of RAM and still have more than 3.1 GB of
'lowmem' left. Another bonus is that highmem IO bouncing decreases,
if used with drivers that still use bounce-buffers.
There's also a 33% increase in user-space VM size - database
applications might see a boost from this.
But the cost of the TLB flushes and the runtime overhead has to be
weighed against the bonuses offered by the larger VM spaces. The
dividing line depends on the actual workload - there might be 4 GB
systems that benefit from this option. Systems with less than 4 GB
of RAM will rarely see a benefit from this option - but it's not
out of question, the exact circumstances have to be considered.
Bill Davidsen
> The following is the top output from a IBM eServer 325 running on a
> AMD Opteron Server. The Server is running Red Hat Enterprise Linux 3.
> The server came loaded with 3GB of RAM and upon constant analysis I
> found that it using less than 1GB of RAM while it shows a iowait of
> 94%. Kindly let me know how to resolve the issue.
How about telling us what issue you're trying to resolve... You have
excess memory, excess CPU, and your i/o system is heavily loaded. If you
want a quick fix, dowload setiathome and run that, it will use up the
CPU and memory, and the waitio will go away.
On the other hand, if you want more useful advice, how about a more
useful question? What application are you running, and is it actually
performing poorly, or what? What kernel, what distro, what disk and
network hardware?
--
-bill davidsen (davi...@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me