SUMMARY: tmpfs - mirrored swap with vxvm = mirrored physical ram? performance question - Iplanet Directory Server

From: Jeffrey Liu <jliu2_at_hanwave.net>
Date: Tue Feb 26 2002 - 17:14:51 EST
All,

Basically, swap is physical memory + disk.
Disk is mirrored, but physical memory is not.

Question regarding how to find if something is residing in
physical memory or on disk wasn't really answered.  Seems that
it's a bit tricky to do so.


Answers below, with original post at the end.

Thanks!
Jeff

----------------------------------------------
I do not think so.. mirroring should only take place
on the drives and not the physical memory.

..Chintu

Jeffrey,

Put simply...

	virtual memory = physical memory + swap

tmpfs is backed by virtual memory, not specifically by swap. If you take
the commendable step of mirroring swap along witht he rest of your system
disk, then you can survive a single system disk failure.

If you want redundancy (of a sort) for memory, use ECC - it's the RAID of
memory.

> Q2: For large processes running under /tmp, how do we tell if it is
>     residing on disk or in physical memory?

Short answer is I don't really know. If you can look at the page fault
rate for memory used by this process, then that should tell you how much
of the process' memory has been paged.

This is vastly oversimplified. The virtual memory architecture is complex
and clever and abstract ideas like "this process has 50MB" and "10MB of it
stays in memory" are approximations at best.


-Andrew-
-- 
 ________________________________________________________________
|  -Andrew J. Caines-   703-886-2689    Andrew.J.Caines@wcom.com |
| Unix Systems Engineer, WorldCom  Andrew.J.Caines+page@wcom.com |


> The question is:  If we mirror swap with Veritas Volume Manager
> (or with ODS for that matter), will this mean that tmpfs, especially
> the physical memory portion of tmpfs, will also be mirrored?

No. As far as the vm is concerned, the mirrored disk is just a block device.

> The server in question has 4G of physical memory and running Solaris 2.6.
> We have 2G of swap allocated on the boot disk.

[snip]

>
> regards to tmpfs, and the 4G isn't enough, or is it the fact that
> the disk slice allocated to swap is only 2G (Solaris 2.6) and it's
> hitting the limit that way.

In your case, you need to allocate enough swap so that your totall VM size is
[max alloc memory] + [max tmpfs size].
I personally would be creating at least 6G swap, with a maxsize=2g option on
the /tmp mount. That gives you enough space to theoretically page out the
entire contents of /tmp, and physical memory to swap, but you may need more


> Q2: For large processes running under /tmp, how do we tell if it is
>     residing on disk or in physical memory?

Awkward I think. You can trace it down from the in kernel vnode pointer, but
it's not that straight forward. I'd recommend doing suns solaris internals
course if you want to look that closely. There may be an easy way to do it,
it's been quite a while since I've looked that closely. :-)

T.



*All* VM (virtual memory) blocks that happen to be paged out will be
mirrored.

*All* VM blocks that *don't* happen to be paged out will *not* be
mirrored (because they're not on disk at all!).

There's no particular difference between tmpfs and any other chunk
of VM; what mirroring swap does is allow the box to keep running
in the face of a disk failure that happens to involve swap.

-- 
Jay Lessert                               jay_lessert@accelerant.net
Accelerant Networks Inc.                       (voice)1.503.439.3461
Beaverton OR, USA                                (fax)1.503.466-9472


All,

I have checked various FAQs, sun-manager archives, and sunsolve, but
I haven't seen too much information regarding tmpfs being mirrored
with regards to the effect on physical memory.

The question is:  If we mirror swap with Veritas Volume Manager
(or with ODS for that matter), will this mean that tmpfs, especially
the physical memory portion of tmpfs, will also be mirrored?

The server in question has 4G of physical memory and running Solaris 2.6.
We have 2G of swap allocated on the boot disk.
We have configured Iplanet LDAP server to run with it's dbcache
files under /tmp/iplanet due to suggestions from SUN/Iplanet.


swap -s
total: 1890480k bytes allocated + 13352k reserved = 1903832k used,
3638040k available

swap -l
swapfile             dev  swaplo blocks   free
/dev/vx/dsk/swapvol 136,5      16 4194272 1644128

df -k /tmp
Filesystem            kbytes    used   avail capacity  Mounted on
swap                 5257672 1620848 3636824    31%    /tmp

ls -l /tmp/iplanet
total 2931104
-rw-r-----   1 root     other     708608 Feb 26 01:30 __db_lock.share
-rw-r-----   1 root     other    1500000256 Feb 26 14:24 __db_mpool.share
-rw-r-----   1 root     other       4096 Feb 20 10:40 __db_txn.share

top
last pid: 27234;  load averages:  1.33,  1.38,  1.26    14:31:58
101 processes: 97 sleeping, 1 running, 3 on cpu
Memory: 4096M real, 62M free, 1247M swap in use, 801M swap free
  PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
29577 root      19  58    0 1632M  998M sleep  25.8H  4.95% ns-slapd

ps -eo rss,vsz,pcpu,args
1022400 1670856  7.9 ./ns-slapd -f /iplanet/config/...

rss   The resident set size of the process, in kilobytes.
vsz   The total size of the process in  virtual  memory,  in
           kilobytes.


Lately, when the heap size for those dbcache files reach around 1.8G
the LDAP server hangs.  I'm just wondering if this may be related to
the possibility that physical memory is also being "mirrored" with
regards to tmpfs, and the 4G isn't enough, or is it the fact that
the disk slice allocated to swap is only 2G (Solaris 2.6) and it's
hitting the limit that way.
The configuration of LDAP is out of my hands (a political thing since
another group controls LDAP).


To recap:

Q1: Mirroring swap - does that mean that tmpfs, the physical memory
    part is also mirrored?

Q2: For large processes running under /tmp, how do we tell if it is
    residing on disk or in physical memory?


Any thoughts would be greatly appreciated.

Thanks,
Jeff
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Tue Feb 26 17:29:30 2002

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:35 EST