Warren Brown wrote:
> 
> Hello
> 
> While Alex is right that having more memory is
> almost always a good thing, I am confused by
> the results stated.
> 
> Unused processes always get paged out of main
> memory (a good thing).  Disk thrashing after
> this point points to applications that are
> memory intensive.  Vanilla I/A ships with
> plenty of memory resources to its job
> under normal circumstances.  When adding third
> party applications, you will need to do some
> basic system administration to verify the
> system.  Alex pointed you at vmstat to monitor
> disk i/o.  Another command that I use a lot
> is "swap -s" which gives the total virtual memory usage.
> Doing this before and after an application startup
> gives a relative feel for the cost of that application.
> 
> Can you run this command and tell us what your
> situation is ?
> 
> If you take away swap space and you are have quieted
> down the disk drive then I suggest that you may
> have an application (or several) that are no longer
> running that you may not know about.  Offline, Alex
> suggests that you run a "ps" command before and
> after the removal of swap space to verify no
> lost processes.
> 
> Another reason for excess disk traffic are applications
> that write to /tmp (logfiles etc.).  You may
> wish to do a "ls -lart /tmp" to see what the newest
> files are in this directory and maybe by the name
> determine the application that is using this.

Yes, Under Solaris /tmp is a tmpfs which means it is a RAM disk.
Anything file copied to /tmp will consume RAM/swap by the same size of
the file. I have seen many times commercial applications use /tmp for
logs on Solaris (probably just ported the app from another unix). When
the logs grow the machine groans.

Logs on Solaris should be written to /var/tmp which _is_ disk based.
/tmp should be used for small files that need fast access.

use du -s /tmp/* to find if the space is used on /tmp

> 
> >
> >Three words:
> >
> >Buy more RAM.
> >
> >
> >If vmstat reports lots of page faults, you need more RAM.
> >
> 
> <snip>
> 
> >
> >       I have processes running on a AW51E (Ultra 30) that drop into
> >       virtual memory several days after boot.  They then consume the
> >       machine with lots of disk thrashing.  I've experimented with
> >       vfstab and /sbin/swapadd, and eliminated swap.  This stops the
> >       disk thrashing, but it left me with a /tmp directory that is
> >       small and completely memory-based.  I'm wondering if I should
> >       further modify /etc/vfstab, and mount /tmp to /dev/md/dsk/d1?
> >       If anyone has more expert knowledge on how to go about this,
> >       I'd appreciate the help.
> >
> 
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
> 
> Share information about yourself, create your own public profile at
> http://profiles.msn.com.
> 
> -----------------------------------------------------------------------
> This list is neither sponsored nor endorsed by the Foxboro Company. All
> postings from this list are the work of list subscribers and no warranty
> is made or implied as to the accuracy of any information disseminated
> through this medium. By subscribing to this list you agree to hold the
> list sponsor(s) blameless for any and all mishaps which might occur due to
> your application of information received from this mailing list.
> 
> To be removed from this list, send mail to
> [EMAIL PROTECTED]
> with "unsubscribe foxboro" in the Subject. Or, send any mail to
> [EMAIL PROTECTED]

-- 
Darryl Bond

-----------------------------------------------------------------------
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

Reply via email to