Hi,
We have been seeing strange DB2 behavior on Sun Solaris 2.10. DB2
seems to crash and complaint about not enough memory, while sar & top
clearly indicate that at the time of crash, there was 4G of swap and
~600M of RAM available.
We are not sure how and if DB2 on Solaris requires swap space. I must
add, that we have a 8G RAM and 4G swap system, we don't believe in the
old school of swap=2*RAM.
Tx

Solaris is very strange in handling memory allocation. You HAVE to use
at least the same amount of swap space as you have physical memory.
Solaris 'shadows' all memory allocations to the swap space.

I had the same problem on a Solaris box with 256GB memory.
I only created 4GB of swap, since I had 100GB free physical memory and
as soon as I allocated more than 4GB of RAM - game over.

This is a Solaris thing, your problem is not DB2 related.

Please increase the swap space to 8 GB. This will solve your problem.

Cheers,
Helmut

On 11/08/2010 04:33 PM, runner wrote:

--
Helmut K. C. Tessarek
DB2 Performance and Development

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/

"Helmut Tessarek" <tessarek (AT) evermeet (DOT) cx> wrote

Any recommendation on swap space for Linux?

Hi Mark,

This depends. Linux does not need to have the same amount of swap space as
Solaris does.

Most people suggest 2-3 times the physical memory for swap space, but I have a
different opinion.

The following opinions expressed here (this post) represent my own and not
those of IBM.

As soon as the system starts to swap, it is most likely not too responsive
anymore, so it does not matter how much swap space you have. You might delay a
crash or kernel panic, if you have a large enough swap space, but this does
not really help either. I have seen boxes which had to be turned off and on
again (not DB2 related), because paging operations did not even allow you to
do a shutdown or reboot.
Every database admin should know about the physical memory requirements of his
database(s).
In a production environment everything goes straight to hell, as soon as the
system begins to swap.

Furthermore the size of swap space also depends on the OS'es swapping and
paging strategy. There are kernel parameters to tune swapping. Filesystem
caching is another interesting topic. Linux tends to use all free physical
memory as a cache for the filesystem, which should be freed in favor to
application memory allocation requests. I have seen situations where this did
not happen.

To put it in a nutshell: If the system is paging, something is wrong and
performance is gone. In some cases the system might even hang for hours. The
larger the swap space, the longer the hang. :-)

--
Helmut K. C. Tessarek
DB2 Performance and Development

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/

"Helmut Tessarek" <tessarek (AT) evermeet (DOT) cx> wrote

We typically have 64 GB of memory and our Linux admins usually create about
a 8 GB swap space. Not reasonable to have 2-3 times.

We have been tuning Linux parms to limit swapping (some of which are not
well documented by IBM, i.e. only in some Redbooks), but even when we
absolutely know that DB2 is using less than half the memory on the machine,
we still see some swapping. This seems to have gotten better with 9.5
Fixpack 6a and 9.7 Fixpack 3a, which automatically set more Linux kernel
parms (more than before).

Linux swapping with DB2 (and Linux memory in general) seems to have been a
problem for IBM to understand and document correctly (although maybe fixed
in latest fixpacks). I think this was one reason why STMM has not worked as
well as it should in the past.

Hi Mark,

This sounds fine to me. I wouldn't use more swap space either.

I would like to know, what is causing the swapping. Is it DB2? If yes, which
part of DB2? There are parameters to limit the memory usage. Which
parameter/memory area is ignoring those limits? If it is not DB2, which
process/thread is causing the swapping?


--
Helmut K. C. Tessarek
DB2 Performance and Development

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/

"Helmut Tessarek" <tessarek (AT) evermeet (DOT) cx> wrote

I am not sure whether there is a lot of swapping, just that some swap space
always seems to be used regardless of how little memory DB2 is configured to
use. Usually swap space starts to go over zero after a week or so after
instance restart.

But the good news is that with the latest kernel parm changes and latest
fixpacks, swap space is at zero on most of our DB2 servers. I will have to
monitor things after a little while to see if it stays that way.

I don't know which processes were using the swap space, but the assumption
(right or wrong) is that it was from file system caching (even though we
have it turned off on all DMS tablespaces).

Hi Mark

File system caching seems to be an interestic topic on Linux. :-)
Maybe the swapping you see is from file system caching of other
filesystems (not from the DB2 tablespace filesystems). If it is related
to the file systems for DB2 tablespaces, which are set to be NO
FILESYSTEM CACHING, it might be a bug in the DB2 code.

--
Helmut K. C. Tessarek
DB2 Performance and Development

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/

"Helmut Tessarek" <tessarek (AT) evermeet (DOT) cx> wrote

We are seeing less swap space being used (usually zero) using the latest DB2
fixpacks and recommended kernel parms. Some of kernel parm recommendations
do not come from official documentation, and it has been frustrating, but
progress is being made.

I found this in a Red Book or similar IBM doc (don't recall where), but it
is not anyware in the Official DB2 doc or InfoCenter that I know of:

"The recommended values for the file-system caching parameters are as
follows:

swappiness: 0
dirty_ratio: 10
dirty_background_ratio: 5"

Unfortuneately, the Red Hat defaults are much different than the above.