Of course the answer is : Trivial paging question. It's instructive for a 'self made' admin how you can be misled by two words you thought meant the same. I think I'll read more: three years in sunmanagers, blueprints, sunworld, man pages, admin sites, ... aren't enough. There are always concepts that all of you bear in mind and never talk about for the uninitiated to hear about them... How many others? This summary (very instructive) is dedicated to them. Many thanks. ----------------------------------------------------------------------- Michael Schulte <mike@babbage.cs.umsl.edu> Probably because you are not really swapping, you are paging. A true swap moves an entire program out of memory; paging just moves the currently unused portions out of memory. With the amount of RAM in most machines these days, the need to do a swap is very rare in most environments. Your vmstat reports quite a bit of paging (at least page-ins). ----------------------------------------------------------------------- Darren Dunham <ddunham@taos.com> Probably because you're confusing 'swapping' with 'paging'. A solaris machine will almost never 'swap'. Paging kicks in first. It will remove portions (pages) of a process that are least recently used and place them on disk. It uses the "swap" partition for this, and is generally sufficient to get enough RAM to work. Swapping is the originial unix way to get space back, but Solaris will only do it as a last resort. The process is stopped, and *all* private pages are sent to disk. It's faster and a little more drastic, so it almost never occurs. You'll probably want to look at -g statistics first, but they can be a bit difficult to interpret. Unfortunately (or fortunately), paging is quicker than allocating a clean RAM page and then reading in a process, so when executables start, they aren't "read", they're paged in. So the 'page in' statistics also reflect all binary starts times the number of pages in length that are read. I'm not certain how much pgouts occur by processes. So to examine RAM outages, you're pretty much left with observing the page scanner kick in. ----------------------------------------------------------------------- Christophe Dupre <duprec@scorec.rpi.edu> You machine is probably not swapping, but paging. Use sar -g ----------------------------------------------------------------------- Jay Lessert <jayl@accelerant.net> Because it's paging like crazy, not swapping. Solaris seldom swaps (moving entire processes in/out of swap disk) it usually pages (moving individual 8KB(?) VM pages in/out of swap disk on a "least recently used" (LRU) basis. Your vmstat output shows fairly high scan rate (sr). That's the number one sign of memory shortfall in Solaris; the kernel is scanning for VM pages to reclaim/page out. In your case, the sr is really high, and pi (page in) is high, but there's almost no page out (po). That would *usually* mean I/O induced paging, not process-size induced paging, corroborated by the near-zero user cpu time. If so, that's normal for SunOS 5.6/5.7, the I/O system uses all the VM it can find for buffering, even if it just frees the space later (large pi, small po). SunOS 5.8 (at least 2001+ releases) is a little more clever about VM buffer usage. ----------------------------------------------------------------------- Fabrice Guerini <fabrice@bluemartini.com> Perhaps because your machine isn't swapping, but paging. For swapping to occur, you must have either some idle processes, or a lot of processes. ----------------------------------------------------------------------- "Kevin Buterbaugh" <Kevin.Buterbaugh@lifeway.com> Because it's not swapping at all. Swapping is very unusual in Solaris and indicates a very severe memory shortage. Paging, on the other hand, is a very normal activity on Solaris. Basically, the only way something gets read into or written from memory is via paging. Paging may also use your swap partition if you have a minor memory shortage. The key indicator on pre-Solaris 8 systems of a memory shortage is the scan rate (vmstat "sr" column). Yours is very high if you don't have priority paging enabled (look for it in /etc/system if you're not sure), but normal if priority paging is enabled. For more information, I'd recommend picking up a copy of the 2nd edition of the O'Reilly System Performance Tuning book. It's almost entirely dedicated to Solaris. HTH.. ----------------------------------------------------------------------- "Homan, Charles (NE)" <Charles.Homan@GDC4S.Com> "si" and "so" refer to swap activity, and your machine isn't technically swapping; it is paging, which is similar but not the same. Solaris will "swap out" pages of memory that haven't been accessed recently when more memory is needed; that activity is called "paging". Solaris will swap out entire processes when a critical low point in memory is reached, which is a less efficient way to handle memory and is there only for memory emergencies, as it were. That is called "swapping". You can look at the scan rate ("sr" in vmstat) to see how much paging is taking place. ----------------------------------------------------------------------- ORIGINAL MESSAGE It must be obvious, but why 'si' and 'so' in vmstat and 'swpin/s' 'swpot/s' in sar are always 0 in a machine I think is swapping heavily, and swap partition shows some activity in iostat? It's a 450 Sol 2.6, 512 mem 512 swap. sar -w 5 55 SunOS brenda 5.6 Generic_105181-30 sun4u 04/12/02 14:24:15 swpin/s bswin/s swpot/s bswot/s pswch/s 14:24:20 0.00 0.0 0.00 0.0 589 14:24:25 0.00 0.0 0.00 0.0 477 14:24:30 0.00 0.0 0.00 0.0 591 14:24:35 0.00 0.0 0.00 0.0 581 14:24:40 0.00 0.0 0.00 0.0 474 14:24:45 0.00 0.0 0.00 0.0 690 14:24:50 0.00 0.0 0.00 0.0 736 14:24:55 0.00 0.0 0.00 0.0 525 vmstat -S 5 55 procs memory page disk faults cpu r b w swap free si so pi po fr de sr s0 s1 s2 s3 in sy cs us sy id 0 0 10 15464 15920 0 0 884 34 806 2512 1796 11 2 1 0 816 1142 424 7 1 92 0 0 8 319832 7928 0 0 2584 195 550 0 473 20 1 0 0 945 364 250 4 1 95 0 0 8 319824 8816 0 0 1393 297 2272 0 5637 27 4 0 0 1098 684 413 2 1 97 0 0 8 320072 15096 0 0 705 1 1395 0 7260 32 3 1 1 1062 877 440 2 0 97 0 0 8 321152 15904 0 0 196 0 163 0 126 10 0 0 0 749 1336 399 2 0 98 0 0 8 321864 15576 0 0 587 0 524 0 1242 19 2 0 0 866 948 404 4 0 96 0 1 8 321920 15392 0 0 358 0 344 0 3402 27 9 2 0 962 245 227 0 0 99 0 0 8 321920 15784 0 0 24 0 84 0 2227 6 0 0 0 668 204 110 0 1 99 0 0 8 321920 15352 0 0 268 0 62 0 4263 25 5 0 0 862 197 163 0 0 99 0 5 8 321944 9856 0 0 16254 780 3091 0 12086 64 2 1 11 1496 1281 453 3 5 91 0 11 8 321640 9616 0 0 24113 846 14350 5768 36705 123 16 0 1 1963 4909 670 5 12 83 0 10 8 322824 11520 0 0 21872 811 16908 3088 47460 133 19 2 9 2442 6064 932 5 10 85 0 3 8 323224 15760 0 0 1392 6 1952 1840 9430 68 11 8 68 2025 764 926 1 2 98 iostat -xctnp 5 55 | grep c0t0d0s1 extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 5.5 0.7 43.8 25.5 0.0 0.2 0.0 27.7 0 7 c0t0d0s1 33.7 24.2 269.4 976.9 0.0 2.1 0.0 35.6 0 60 c0t0d0s1 26.8 7.4 214.1 423.5 0.0 1.6 0.0 47.1 0 33 c0t0d0s1 25.8 0.0 206.4 0.0 0.0 0.3 0.0 10.2 0 25 c0t0d0s1 _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Mon Apr 15 06:17:47 2002
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:40 EST