Thanks for tons of responses. Next, my summary. There are some possible causes and ways of resolution: 1) It's normal behaviour. I'd need more memory. 2) There is a memory leak, and I must monitorize system when it crashes to know which process is failing. 3) There is a memory leak, due to Oracle. Tunning oracle settings /etc/system. 4) There is a memory leak, due ncsd (solaris bug). Install existing patch. In my case, cause has been option 4: a memory leak by ncsd. I've fixed the problem with a patch: 110710-02. Now, system doesn't use so memory. Memory doesn't decreases.It goes up and down. Jordi Renye Thanks again, Next, it follow answers. Answer ------------------------ If you do not have memory leaking apps then it is quite normal for solaris OS, do not worry. it is got allocated into internal buffers and will be reclaimed back by processes when they need it. Read up sun's "solaris memory management" for more info. Answer ------------------------ this is normal. the os manages memory. linux is the same. windows reports memory usage differently. this is in the doucmentation and on the web. Answer ----------------------- This is normal Solaris behavior. Any memory not used by processes is used for file caching. It is made available to processes if there is need. See http://groups.google.com/group/comp.unix.solaris/browse_thread/thread/6878f1f5c68785bb/7fda160bcee2a96d?lnk=st&q=solaris+vmstat+sr+values&rnum=3#7fda160bcee2a96d for a discussion on this by Scott Howard. It is probable the URL above will be split into multiple lines by various things along the email path, so you may have to reconstruct it. A portion is pasted below in case you are unable to get to google groups. ------------------------ Answer t looks like you have an application that is not freeing freeing memory. Try running "top" to identify hte offending application -- if you don't have "top" installed, run prstat. ------------------------ Answer Suggest using prstat or top to identify which process has the memory leak. ------------------------ Answer Knowing that memory is in use doesn't do you much good, does it? You'll need to find out what process or processes are using that memory. You might want to collect 'ps' information, especially the 'vsz' and 'rss' fields. Presumably one or more processes is not releasing memory. ------------------------ Answer Try to identify which process is consuming most of your memory. Try 'prstat' or maybe # ps -eo pmem,pid,args I don't believe in a misbehavior from your Solaris Box. The culpirit can be an application/database you're running... ------------------------ Answer Two things: Change you shmmax and also change the stack size for Oracle. Each instance is demanding over 700MB of memory, you can change that to 256 and see if that helps ------------------------ Answer There was an old bug with nscd when running oracle which caused a memory leak. Check the size of nscd in your process listings. If it's more that a few Mb in size after restarting then you need to modify the nscd.conf file to stop it caching user attr. ------------------------ Answer I'd definitely reduce shmsys:shminfo_shmmax to a number which is less than the amount of physical RAM you have on the machine. ------------------------ Answer You definitely have a memory leak, now you need to find the process that's responsible for it. Replace your monitor process with something like this, run (say) every 30 minutes from cron: #!/bin/sh PATH=/bin:/usr/bin; export PATH umask 022 logfile=`date '+/var/log/memleak/%Y%m%d/%H%M'` d=`dirname $logfile` mkdir -p $d ps -efly > $logfile exit 0 Keep an eye on the RSS and SZ fields in these logfiles. Some program is growing continuously without releasing any memory, and that's what you need to fix. ------------------------ Answer What else is running - it seems that you have some application with a memory leak - run Top for a while (set the seconds to refresh to something like 30) and you should see the memory hog. ------------------------ First post to list jordir@fib.upc.edu wrote: > Dear sirs, > > We have two servers Sun Fire 280R with Solaris 8 with same problem: > server are not releasing memory. > > For example, at Listing 1, we can seee how free memory always are > decreasing > but never increasing. > > Problem is that when server is up during several days, there is small > memory to work, and server is freezed. Not crashed, but I must > reboot pushing reset button. > > In Listint 2, we have a monitor process, that shows free memory before > freeze moment. > > We have patched system with lattest Solaris 8 Recommended. > > Thanks in advanced. > > Jordi Renye > Facultat Informatica Barcelona - Universitat Politecnica Catalunya > (Faculty of Computer Science) > Catalonia - Spain > > Listing 1 > ====== > Memory: 2048M real, 999M free, 828M swap in use, 4886M swap free > Memory: 2048M real, 610M free, 1191M swap in use, 4500M swap free > Memory: 2048M real, 666M free, 1151M swap in use, 4539M swap free > Memory: 2048M real, 651M free, 1164M swap in use, 4525M swap free > Memory: 2048M real, 660M free, 1154M swap in use, 4534M swap free > Memory: 2048M real, 614M free, 1196M swap in use, 4490M swap free > Memory: 2048M real, 582M free, 1203M swap in use, 4482M swap free > Memory: 2048M real, 645M free, 1157M swap in use, 4528M swap free > Memory: 2048M real, 633M free, 1159M swap in use, 4525M swap free > Memory: 2048M real, 608M free, 1181M swap in use, 4503M swap free > Memory: 2048M real, 611M free, 1177M swap in use, 4506M swap free > Memory: 2048M real, 620M free, 1158M swap in use, 4524M swap free > Memory: 2048M real, 609M free, 1167M swap in use, 4514M swap free > Memory: 2048M real, 573M free, 1201M swap in use, 4479M swap free > Memory: 2048M real, 608M free, 1160M swap in use, 4517M swap free > Memory: 2048M real, 606M free, 1160M swap in use, 4516M swap free > Memory: 2048M real, 579M free, 1160M swap in use, 4515M swap free > Memory: 2048M real, 594M free, 1169M swap in use, 4505M swap free > Memory: 2048M real, 599M free, 1164M swap in use, 4509M swap free > Memory: 2048M real, 598M free, 1164M swap in use, 4509M swap free > Memory: 2048M real, 596M free, 1166M swap in use, 4507M swap free > Memory: 2048M real, 594M free, 1166M swap in use, 4506M swap free > Memory: 2048M real, 591M free, 1169M swap in use, 4502M swap free > Memory: 2048M real, 593M free, 1166M swap in use, 4504M swap free > Memory: 2048M real, 592M free, 1166M swap in use, 4503M swap free > Memory: 2048M real, 592M free, 1164M swap in use, 4505M swap free > Memory: 2048M real, 587M free, 1169M swap in use, 4499M swap free > Memory: 2048M real, 588M free, 1165M swap in use, 4503M swap free > Memory: 2048M real, 565M free, 1187M swap in use, 4480M swap free > Memory: 2048M real, 523M free, 1227M swap in use, 4439M swap free > Memory: 2048M real, 556M free, 1191M swap in use, 4473M swap free > Memory: 2048M real, 559M free, 1188M swap in use, 4476M swap free > Memory: 2048M real, 548M free, 1198M swap in use, 4465M swap free > Memory: 2048M real, 565M free, 1179M swap in use, 4483M swap free > # > > Listing 2 > ====== > Memory: 2048M real, 18M free, 1162M swap in use, 3679M swap free > Memory: 2048M real, 19M free, 1125M swap in use, 3715M swap free > Memory: 2048M real, 18M free, 1125M swap in use, 3715M swap free > Memory: 2048M real, 15M free, 1128M swap in use, 3713M swap free > Memory: 2048M real, 18M free, 1126M swap in use, 3715M swap free > Memory: 2048M real, 20M free, 1126M swap in use, 3715M swap free > Memory: 2048M real, 19M free, 1127M swap in use, 3714M swap free > Memory: 2048M real, 18M free, 1127M swap in use, 3714M swap free > Memory: 2048M real, 15M free, 1127M swap in use, 3714M swap free > Memory: 2048M real, 18M free, 1127M swap in use, 3714M swap free > Memory: 2048M real, 19M free, 1127M swap in use, 3714M swap free > Memory: 2048M real, 16M free, 1127M swap in use, 3714M swap free > Memory: 2048M real, 14M free, 1127M swap in use, 3714M swap free > Memory: 2048M real, 16M free, 1127M swap in use, 3714M swap free > Memory: 2048M real, 17M free, 1126M swap in use, 3714M swap free > Memory: 2048M real, 17M free, 1129M swap in use, 3712M swap free > Memory: 2048M real, 15M free, 1128M swap in use, 3713M swap free > _______________________________________________ > sunmanagers mailing list > sunmanagers@sunmanagers.org > http://www.sunmanagers.org/mailman/listinfo/sunmanagers > ---------------------------------------------------------- Second post to list Dear sirs, Perhaps, I must tell it before. We have running Oracle 9i on this server. Next follows output from prstat -U oracle9i PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 1244 oracle9i 17M 6776K sleep 58 0 0:00.00 0.0% tnslsnr/1 1218 oracle9i 765M 721M sleep 59 0 0:00.00 0.0% oracle/1 1216 oracle9i 765M 721M sleep 58 0 0:00.00 0.0% oracle/1 1220 oracle9i 765M 723M sleep 58 0 0:00.00 0.0% oracle/1 1222 oracle9i 766M 719M sleep 58 0 0:00.00 0.0% oracle/1 1210 oracle9i 771M 720M sleep 59 0 0:00.00 0.0% oracle/11 1212 oracle9i 767M 720M sleep 58 0 0:00.00 0.0% oracle/11 1206 oracle9i 766M 720M sleep 59 0 0:00.00 0.0% oracle/1 1214 oracle9i 765M 722M sleep 58 0 0:00.00 0.0% oracle/1 1224 oracle9i 765M 719M sleep 59 0 0:00.00 0.0% oracle/1 1208 oracle9i 769M 722M sleep 59 0 0:00.00 0.0% oracle/18 Perhaps, we have setting better shmsys:shminfo_shmmax variable: set shmsys:shminfo_shmmax=4294967295 because we have only 2Gbytes of RAM. I thought there was a problem specific to Sun fire 280R, because we have two servers that failed. The other server, runs INFORMIX, but in that case variable shmsys:shminfo_shmmax is next: shmsys:shminfo_shmmax=268435456 where server has 2Gbytes too. Is this the problem I suffering? Thanks again. ---------------------------------------------------------- _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Tue Sep 25 10:11:16 2007
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:44:07 EST