vmstat

[Sajjad Sahir]

vmstat -n
checking re columns showing higher value means shortage of memory
on which basis we have to decide this higher value, if it is higher value what
is the necessary action to take?
also if w showing numbers what is the action i have to take?

[Jeeshan]

check that the re value is changed or not

#vmstat 5

[Sajjad Sahir]

for my information i am asking if it is higher value what are the steps i have to take for action
2. on which basis we are telling it is higher
value

[SUDHAKAR_18]

Check with #vmstat 1 10 command
1=for every one sec. 10=no of times .

Regds,
SHR

[Sajjad Sahir]

Dear
Sudhakar
my question is if vmstat -n showing
re columns higher number what is the next step I have to take
this is my first question i am not asking
vmstat 1 or 2 like this
suppose vmstat
VM
memory
avm free re
62191 2458748 12
see number is 12 if it is higher value
what i have to do?
my question is w columns showing
numbers what I have to do next step(i mean action)

[Mridul Shrivastava · Accepted solution]

If you have device swap actually USED then this means you have processes paged/swapped out to disc, which explains fully why vmstat shows such a high reclaim rate - pages are constantly being swapped in and out. Ideally you want to keep device swap USED to 0%. We do. This means you have sufficient ram for the applications you are running. We dont let any of our servers here ever get to device swap USED >0%.

For example;

Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 1024 0 1024 0% 0 - 1 /dev/vg00/lvol2

This means everything is in memory, great. vmstat shows no page reclaims at all.

As against;

Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 512 27 485 5% 0 - 1 /dev/vg00/lvol2

In this example we have 27MB of processes swapped/paged out to disc, which means were really 27MB of RAM short! As a result vmstat shows page reclaims going on.

Check the vmstat metric po (page out). This is the most important as it indicates actual pages written to the swap area. HP-UX starts every program with pi (page ins) but these come from the program's executable file. But paged outs are real writes to swap. Single digits are OK, double digits are questionable and more than 2 digits is a real shortage of RAM. It means that some processes have been deactivated and one or more pages have been written out to swap.

Note that swap space is utilizied in several ways. The first is reservation, which involves no I/O, just bookeeping. Swap reservation is often confused with swap usage. The second is space for memory mapped files. And the third is real page outs. vmstat and swapinfo are too crude to give a good picture of RAM usage. You really need GlancePlus to get an accurate (and meaningful) picture of RAM.

Standard incantation: check dbc_max_pct in the kernel. If it is 50, that's where a massive portion of your memory has gone. The DBC is supposed to move down towards dbc_min_pct when processes are threatened with deactivation, but depending on patches and OS version, it isn't too reliable. Because it is a percentage of RAM, the amount changes with RAM changes, it is a pain to manage.

[Sajjad Sahir]

Thanks alot Mridual vastava
one more clarification I need see the out put
# vmstat -n
VM
memory page faults
avm free re at pi po fr de sr in sy cs
68711 2458592 12 2 0 0 0 0 0 868 377 70
CPU
cpu procs
us sy id r b w
0 0 100 1 1 0
0 0 100
0 0 100
0 0 100

here re is 12 what i have to take an action
how to eliminate these 12

[Hein van den Heuvel]

>> here re is 12 what i have to take an action how to eliminate these 12

Nothing to do.
Just wait, and it will change.

There is nothing wrong or bad about it not being 0. It could be considered good.
Why do you think it should be elimiated.

Here is a description I just googled:

"Page reclaims -- The kilobytes of pages reclaimed since the last sample. Some of the file system cache is in the free list, and when a file page is reused and removed from the free list, a reclaim occurs. File pages in the free list can be either regular files or executable/library pages. "

But if you really want is eliminated, try this:

$ vmstat -n | awk 'NF==12{sub(" " $3 " ",substr(" ",1,2+length($3)),$0)} 1 '

( I'm shooting for 2 points for technical merit and 1 point for an attempt at being funny. )

Cheers,
Hein.

[Sajjad Sahir]

Dear Hein
what i understood is if higher value of re columns indicate shortage of memory? in that case we have to reduce re value thats why i am asking what we can do in that case?
eliminate?

[Hein van den Heuvel]

The 'official' explanation for re (reclaimed pages) is in my earlier reply.

I interpret that to mean that the buffer cache was ready to walk away from some memory it had used before, but before thsoe pages were actually utilized for something else, the original contents was needed again.

A modest amount surely is just fine.
With modest I'm thinking less than 200/second.

Higher amounts suggest that the buffer cache is not finding a good balance.
I would review the application usage characteristics (Database? fileserver? development?) and dbc_min / dbc_max settings. Maybe put them close by raising dbc_min if the memory is there?

Maybe you can determine a correlation between the re-rate being high and certain activities on the system (backup? Repeasted brute force file scans? ...)

Yours is the first entry that I notice to worry about 're'. For me it never seemed that important. I'll be happy to be proven wrong.

Hope this helps a little,
Hein.