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/sunmanagersReceived 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