On 2002.07.25 00:28 Rahul wrote: > interestingly... the "b" column of *my* AIX also shows "2" > continiously > !!!!! > > kthr memory page faults cpu > ----- ----------- ------------------------ ------------ ----------- > r b avm fre re pi po fr sr cy in sy cs us sy id wa > 0 2 200034 3088 0 0 0 0 0 0 555 2139 1592 1 3 95 1 > 0 2 200279 2822 0 2 0 0 0 0 561 2048 313 2 2 95 2 > 1 2 200654 2397 0 1 0 0 0 0 568 7397 8371 16 14 68 3 > 1 2 200718 2077 0 3 0 0 0 0 675 3235 1394 8 5 82 5 > 0 2 200034 2778 0 0 0 0 0 0 541 1428 271 0 1 98 0 > 0 2 200034 2777 0 0 0 0 0 0 566 1540 311 1 2 97 1 > 0 2 200034 2777 0 0 0 0 0 0 531 3556 251 10 6 84 0 > 2 2 200034 2770 0 0 0 0 0 0 550 2942 2847 4 4 90 1 > > all systems are running fine without any IO (or other performance ) > problems... !! > > regards > Rahul
From that report (sar -B, I believe) I can see that, at least from the memory perspective, the system is running fine. You've only had a few page-in IOs (pi column), which indicates that the system is doing something, you don't have any page-out, which indicates that the page deaemon is not stealing pages and free memory at the more or less constant level means that at the given period the monitored system has had sufficient memory for the tasks given to it. Sar -u, monitor (jAIX version of "top") or some other tools will give you the CPU utilization of the system from which you can draw further conclusions (if you are having very high system CPU rates, check your devices, something is either overused or faulty, I've seen things like that with faulty network cables, what caused retransmits and interrupts, which are, of course, serviced in the kernel mode). You should also look into sar -b, which gives you the idea about your IO subsystem (you should know approximately how many IOs per second can your disk subsystem survive without checking into Betty Ford's clinic. That type of information is usually collected from the vendor and divided by 2 to be useful.) Useful reports can be obtained from sar -d, iostat -d -x and vmstat commands. You should monitor at peak usage periods, not during the lunch break. Do not neglect /var/log/messages and dmesg, as they can frequently tell you what's going on. Eliminate all your X11 stuff from the server machines. Remember that the God has created terminfo and vi long before CDE, GNOME, gtop and alike. If you see users executing programs like xtetris, xsnake,xinvaders,asteroids, xv, gnuchess or alike, feel free to execute them in public as a warning to the other would be perpetrators. NFS is a thing to avoid on the RDBMS servers (very CPU intensive) as well as compilers, linkers, javac and alike (ditto). In other words, you should have a capable and knowledgeable tyrant (SA for short) who would constantly monitor your servers and who knows what he's doing. Preferably, you'll get somebody from Simon Trevaglia's (my hero) school of thought. Experience tells me that sites which have people like that are normally functioning well with close to 100% uptime (I know, I know). -- Mladen Gogala -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Mladen Gogala INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
