Hi;
Thanks for your replies about my memory question. Here is the original question.
>I've recently had a problem in openwin with scrolling windows. When typing in a
>command I get messages about "memory full unable to complete edit operation".
>the window then disables scrolling. What I can't figure is 1) I thought /tmp
>space was for window buffering and 2) I have top 3.0 running and it only shows
>12MB of memory.( I have 16MB or should have...). I realize I have a minimal
>setup for an IPX.(I'm trying to get more memory). So I'm wondering whats up?
>Does the kernal prevent its memory from being viewable??
>
>I'm hoping for info that can help me make educated decision on configuring and
>using available memory.
>
>I am running 4.1.2 OW3 on a IPX.
>
>I have edited this kernal to free up some space.
>-rwxr-xr-x 1 root 1407537 Oct 26 14:30 vmunix*
>>>
>TOP's print::
>last pid: 16056; load averages: 0.03, 0.19, 0.23 12:11:35
>>66 processes: 64 sleeping, 2 running
>>Cpu states: 0.8% user, 0.0% nice, 4.0% system, 95.2% idle
>>Memory: 12884K available, 11500K in use, 1384K free, 1704K locked
> ^^^^^^ ^^^^^
> usually 300K! as low as 180K.
-----------------------SUMMARY-------------------------------------------------
I believe the problem is solved. I was on the wrong track. I learned a lot
about physical and virtual memory. Thanks to Annette Smith she wrote ::
>Yep, /tmp is for writting window buffers, but the buffer file has a
>20000 character limit by default. If you are producing a lot of
>output... this really goes quick. There is a variable that can be
>placed in the .Xdefaults file to increase this limit, the option is
>text.maxDocumentSize and the values may range from 0 to 0x8000000.
>
>Syntax should be:
>
>OpenWindows.text.maxDocumentSize: value (hex)
>
>Every time I've exceeded the limit, I've gotten the wonderful message
>about memory full. When I've cleared the history log... it works
>again!
I found when I cleared history it did work again but I was doing screen
stuff and quickly filled it up. Using Annettes suggestion seems to have helped.
*****************************************************************************
OTHER SUGGESTIONS ::
-------------------
**1) Everyone seems to think I don't have enough swap but I do. When I set up
the system I set up a swap file in addition to swap space.
My Settings::
-----------
>> pstat -s ::
15452k allocated + 3552k reserved = 19004k used, 40392k available
>> pstat -T ::
281/800 files
325/438 inodes
82/202 processes
19176/59396 swap
**2) From danny@ews7.dseg.ti.com I got this suggestion (which I meant to
do long ago but forgot) ::
>check /var/tmp also--that may be where it goes
>if /tmp is not a link to /var/tmp
**3) I did get one very interesting response from Brett Lymn ::
>One thing to check is your ulimit (I am assuming you run csh here,
>sh/bash semantics are different but the functionality is the same).
>By default there is a limit on how big your data and stack segments
>can grow, check these with the limit command in csh or ulimit in sh or
>it's derivatives. You can reset the limits by saying (in csh):
>
>limit data unlimited
>limit stack unlimited
>
>in your .cshrc then login again and see if the problem goes away.
>>I am not sure that you need to do this with sh but bash has a ulimit
>command that does the same as the csh limit command only the syntax is
>different.
I use TCSH but I intend to check this out and see what happens.
My settings::
-------------
>> limit (tcsh limits) ::
cputime unlimited
filesize unlimited
datasize 524280 kbytes
stacksize 8192 kbytes
coredumpsize unlimited
memoryuse unlimited
descriptors 64
Thanks to all who took the time to answer::
From: csdnet!ilbeig@uunet.UU.NET (Amir Ilbeig)
From: jdschn@nicsn1.monsanto.com (John D Schneider)
From: danny@ews7.dseg.ti.com
From: adam%bwnmr4@harvard.harvard.edu (Adam Shostack)
From: blymn@awadi.com.AU (Brett Lymn)
From: Joe Konczal <konczal@sunmgr.ncsl.nist.gov>
From: tim@ben.dciem.dnd.ca (Tim Pointing, DCIEM)
From: mattson@cs.UCSD.EDU (Jim Mattson)
From: guy@auspex.com (Guy Harris)
From: laugh@dal.fsd.mot.com (Annette D. Smith)
I really appreciate it!!!
-Jim Murff
-------------------------------------------------------------------------------
Jim Murff (murff@irt.com) Voice # (619)622-8878
IRT Corp, San Diego, CA. (619)450-4343
Applications Engineer, System Admin. Fax # (619)622-888
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:19 CDT