Hi Nicolas, Thanks. I will collect the ipcs data which you suggested.
Another question,for the "prstat", I found there are three sybase processes as below: # prstat -a PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 10032 sybase 7779M 7762M cpu10 20 0 22:20:52 9.7% dataserver/12 10077 sybase 7779M 7762M sleep 50 0 22:38:45 4.4% dataserver/12 10078 sybase 7779M 7762M sleep 52 0 22:29:03 3.9% dataserver/12 ... Does mean there are total 3 sysbase instance running(or actually only one instance) ? and *each *instance used 7779M vm and 7762M physcial RAM ? Thanks. Best Regards, Simon On Thu, Nov 26, 2009 at 4:24 AM, Nicolas Dorfsman <[email protected]> wrote: > > Le 22 nov. 2009 à 15:35, Simon a écrit : > > Hi Nicolas, > > Thank you. > > I think adding extra swap device would not be helpful in our case,because > the customer appliction created too many stack/heaps,these anonymous memory > has to use swap device as back store,if the physical RAM really > shortage,more swap device only cause page out cost and performance will be > degraded accordingly,right ? > > > Right. Except in one case....DISM use of shared memory. > Take a look to this command : > > # ipcs -ZAm | awk 'NR>1&&$16>0{s+=$10} END{print "total=", s/1024}' > > > If there's something different than 0, your Sybase is using DISM segments. > With DISM, there's a double 'reservation'....one at creation time, and > another at attach time. 'Reservation' doesn't mean 'utilisation', the only > way to have sufficient 'rerservation' space is to add swap. Nothing will be > swapped out because it's only a reservation. It's just a security to be > able to swap out theses segments in case of DR. > > > Nicolas > > > > > > Thanks. > Best Regards, > Simon > > > On Sat, Nov 21, 2009 at 8:01 PM, Nicolas Dorfsman <[email protected]> wrote: > >> >> Hi Simon, >> >> Le 21 nov. 09 à 07:27, Simon a écrit : >> >> >>> # ipcs -a >>> IPC status from <running system> as of Thu Nov 12 12:05:28 HKT 2009 >>> T ID KEY MODE OWNER GROUP CREATOR CGROUP >>> CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME >>> Message Queues: >>> T ID KEY MODE OWNER GROUP CREATOR CGROUP >>> NATTCH SEGSZ CPID LPID ATIME DTIME CTIME >>> Shared Memory: >>> m 3 0xe9032d40 --rw------- sybase staff sybase staff >>> 3 738803712 1314 2125 20:47:22 no-entry 20:47:14 >>> m 2 0x51 --rw-rw-r-- root root root root >>> 1 2000196 2122 8553 15:15:18 15:15:23 13:14:38 >>> m 1 0x50 --rw-rw-r-- root root root root >>> 1 600196 2121 2121 13:14:38 no-entry 13:14:38 >>> m 0 0xe9032d32 --rw------- sybase staff sybase staff >>> 3 7851147264 1314 2125 13:14:40 13:14:40 13:13:42 >>> T ID KEY MODE OWNER GROUP CREATOR CGROUP >>> NSEMS OTIME CTIME >>> Semaphores: >>> s 1 0x51 --ra-ra-ra- root root root root >>> 6 12:05:28 13:14:38 >>> s 0 0x50 --ra-ra-ra- root root root root >>> 6 12:05:28 13:14:38 >>> >> >> I'm not sure about Sybase and ISM/DISM, but you may take a look to >> ISM/DISM segments by : >> >> # ipcs -ZAm | awk 'NR>1&&$16>0{s+=$10} END{print "total=", s/1024}' >> >> DISM segments may suffer of double allocation algorithm. The Workaround >> is to add as many disk-swap-area as your SGBD SHM reservation. >> I've wrote an article on that ( >> http://www.solaris-fr.org/home/docs/base/memoire), but in french for now, >> sorry. >> >> Nicolas > > > >
_______________________________________________ sysadmin-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
