>> I tried setting mem, bcmem, and icmem all to 1M but no improvement. >> They are not set by default, and trying the configuration shown in the >> man page actually prevents the system from booting (out of memory). >> >> John > > perhaps i'm pointing out the obvious. have you tried something as simple > as ps to identify culprits? > > ps -a|sort +4nr|sed 10q > > on my system, i get > > (names changed to protect the guilty) > > xxx 151013 1:48 0:21 346784K Pread fs ? > yyy 157084 0:11 0:03 299780K Pread fs ? > yyy 162896 0:04 0:01 281240K Pread fs ? > zzz 158720 13:31 2:09 132616K Pread fs ? > [...] > > suprise, suprise. it's upas/fs leading the charge. > (the leading upas/ is of course dropped from the fs entries, > just as it would be for /bin/ls.) > > venti & fossil, being threaded programs sharing a heap, > will appear to be using more memory than they are. ps doesn't > provide any easy way of figuring this out but if /proc/$pid/segment > shows >1 references (the last field) for the Data segment, then > there are that many procs sharing the same heap. baring > enormous executables, text, stacks or numbers of procs sharing > the same heap, this should be pretty close the memory usage > for the entire set of procs. > > - erik
I get venti as the largest process. upas/fs is not a potential culprit because this is a freshly installed terminal, meaning upas/fs reads in ONE email. I did just realize that running a screen at 1280x1024x32 probably consumes a bit of memory too; I'm dropping that down to 1024x768x8 to see how that helps. John
