February 2005 ~ Creation Zone

Friday, 11 February 2005

Solaris: How to get rid of [English/European] bar underneath every window?

Posted on 22:08 by Unknown

[English/European] bar will be shown underneath every window, if en_US.UTF-8 (en_US.UTF-8 is a Unicode locale for American English) has been chosen as the default locale, during the installation of OS.

How to get rid of it?
Choose C (7-bit US-ASCII English locale) locale

Temporary workaround: Select Options -> Langauges -> C at the CDE/GNOME/JDS login menu button
Permanant fix: Remove the LANG line in the /etc/default/init file and then reboot the system; then C locale will be used as the system's default locale. Or simply replace en_US.UTF-8 with C in /etc/default/init

Of course, play with other locales if neither C nor en_US.UTF8 works for you

Posted in | No comments

Monday, 7 February 2005

Solaris: lofiadm - Mounting an ISO image on Solaris file system

Posted on 17:00 by Unknown

On Solaris 8 and later versions, it is not necessary to create CD's for the downloaded ISO images. Instead of burning the image to a CD-ROM to access its contents, it is easy to mount the image directly into the file system with the help of lofiadm and mount commands

lofiadm administers lofi, the loopback file driver. lofi allows a file to be associated with a block device. That file can then be accessed through the block device. This is useful when the file contains an image of some file system (such as a floppy or CD-ROM image), because the block device can then be used with the normal system utilities for mounting, checking or repairing filesystems



Govinda% unzip sol-10*.zip

Archive:  sol-10-ccd-GA-x86-iso.zip

  inflating: sol-10-ccd-GA-x86-iso.iso



Govinda% su

Password:

Given an ISO image in /export/home/techno/sol-10-ccd-GA-x86-iso.iso, a loopback file device (/dev/lofi/1) is created with the following command (note: pathname of the iso should be absolute, but not relative):

#  lofiadm -a sol-10-ccd-GA-x86-iso.iso /dev/lofi/1

lofiadm: pathname is not an absolute path -- sol-10-ccd-GA-x86-iso.iso



#  lofiadm -a /export/home/techno/sol-10-ccd-GA-x86-iso.iso /dev/lofi/1

The lofi device creates a block device version of the file:

# lofiadm

Block Device             File

/dev/lofi/1              /export/home/techno/sol-10-ccd-GA-x86-iso.iso

And then mount the block device on /mnt with the following command:

# mount -F hsfs -o ro /dev/lofi/1 /mnt

Tip:

All the above commands can be combined into a single command as follows:

mount -F hsfs -o ro `lofiadm -a /export/home/techno/sol-10-ccd-GA-x86-iso.iso` /mnt



# ls /mnt

components  installer   README      volstart

Once done using the files from CD image, unmount the lofi block device

# umount /mnt

Finally remove the association of loopback file device as follows:

# lofiadm -d /dev/lofi/1



# lofiadm

Block Device             File

Resource:

Solaris man page of lofiadm

Posted in | No comments

Friday, 4 February 2005

Building ICU 2.2 & Xerces 2.1 on Solaris 10 for x86

Posted on 14:56 by Unknown

set the following environment variables & create the directories as shown below:

setenv TZ PST8PDT
setenv ICUROOT <root directory of ICU source>
setenv ICU_DATA $ICUROOT/source/data/
setenv XERCESCROOT <root directory of xerces source>
setenv XALAN_USE_ICU true
setenv XALANCROOT <root directory of xalan source>

mkdir -p $ICUROOT/lib/sol/release
mkdir -p $ICUROOT/lib/sol/debug
mkdir -p $ICUROOT/bin/sol/release
mkdir -p $ICUROOT/bin/sol/debug
mkdir -p $XERCESCROOT/lib/sol/release
mkdir -p $XERCESCROOT/lib/sol/debug
mkdir -p $XALANCROOT/lib/sol/release
mkdir -p $XALANCROOT/lib/sol/debug
Install "gmake"
Get it from http://www.sunfreeware.com for S10 x86

______________________________

Building ICU 2.2 on Solaris 10 x86
______________________________

Download ICU 2.2 source code & 2.2 patch from:

ftp://www-126.ibm.com/pub/icu/2.2/icu-2.2.tgz
ftp://www-126.ibm.com/pub/icu/2.2/icu-2.2-patch.zip
cd $ICUROOT/source
chmod +x runConfigureICU configure install-sh
./runConfigureICU SOLARISX86 --disable-64bit-libs --enable-layout --prefix=<installation-directory>
(by default layout will be disabled)
Edit icudefs.mk:
i) Add -lCrun link flag to DEFAULT_LIBS
ii) Add -L$(top_builddir)/data/out/build to LIBICUDT

104c104
< DEFAULT_LIBS = -lpthread -lm -lCrun
---
> DEFAULT_LIBS = -lpthread -lm
154c154
< LIBICUDT= -L$(top_builddir)/data/out -L$(top_builddir)/data/out/build -L$(top_builddir)/stubdata

-l$(ICUPREFIX)data$(ICULIBSUFFIX)$(SO_TARGET_VERSION_SUFFIX)
---
> LIBICUDT= -L$(top_builddir)/data/out -L$(top_builddir)/stubdata

-l$(ICUPREFIX)data$(ICULIBSUFFIX)$(SO_TARGET_VERSION_SUFFIX)

Edit runConfigureICU & configure files and remove the "-g" flag for RELEASE builds
./runConfigureICU SOLARISX86 --disable-64bit-libs --enable-layout --prefix=<installation-directory>
gmake
gmake check (optional)
gmake install

_______________

Building Xerces 2.1
_______________

Download the source for Xerces 2.1 from:
http://archive.apache.org/dist/xml/xerces-c/Xerces-C_2_1_0/xerces-c-src2_1_0.tar.gz
Copy the unicode header files from ICU source distribution. Please note that Solaris 10 ships ICU 2.1 and failing to copy
the headers as shown below may result in undefined symbol errors:

cp $ICUROOT/source/common/unicode/*.h $ICUROOT/include/unicode/
cp $ICUROOT/source/common/icucfg.h $ICUROOT/include/icucfg.h
cd $XERCESCROOT/src/xercesc
pushd $ICUROOT/lib

foreach i ( $ICUROOT/lib/sol/release/*.so*)
ln -s $i
end

popd
Fix needed to allow compilation for DOMDocumentImpl.cpp

cp $XERCESCROOT/src/xercesc/dom/impl/DOMDeepNodeListImpl.hpp $XERCESCROOT/include/xercesc/dom/impl
cp $XERCESCROOT/src/xercesc/dom/impl/DOMDeepNodeListPool.hpp $XERCESCROOT/include/xercesc/dom/impl
Edit Makefile.incl:
Add -lCstd link flag to all ALLLIBSs

138c138
< ALLLIBS = -mt -licuuc -licudata ${LIBS}
---
> ALLLIBS = -mt -licuuc -licudata -lCstd ${LIBS}
140c140
< ALLLIBS = -mt ${LIBS}
---
> ALLLIBS = -mt -lCstd ${LIBS}
144c144
< ALLLIBS = -mt -licuuc -licudata ${LIBS}
---
> ALLLIBS = -mt -licuuc -licudata -lCstd ${LIBS}
runConfigure -psolaris -ccc -xCC -minmem -nsocket -ticu -rpthread -z-DXERCES_TMPLSINC -C --prefix=<installation-directory> -d
Note: -d builds a debug build; if needs an optimized release build, remove -d.
gmake
gmake install

** Note **

Failing to make the changes as mentioned above leads to undefined symbols

eg.,


% ldd -r libxerces-c.so.22.0
        libicuuc.so.22 =>        /export/home/sunperf/icu/lib/sol/release/libicuuc.so.22
        libicudata.so.2 =>       /usr/lib/libicudata.so.2
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libicudata.so.22 =>      (file not found)
        libm.so.2 =>     /usr/lib/libm.so.2
        libCrun.so.1 =>  /opt/SUNWspro/prod/usr/lib//libCrun.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libmd5.so.1 =>   /usr/lib/libmd5.so.1
        libscf.so.1 =>   /usr/lib/libscf.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libdoor.so.1 =>  /usr/lib/libdoor.so.1
        libuutil.so.1 =>         /usr/lib/libuutil.so.1
        symbol not found: __1cDstdEcout_                (./libxerces-c.so.22.0)
        symbol not found: UCNV_FROM_U_CALLBACK_SUBSTITUTE_2_1           (./libxerces-c.so.22.0)
        symbol not found: UCNV_FROM_U_CALLBACK_STOP_2_1         (./libxerces-c.so.22.0)
        symbol not found: u_strlen_2_1          (./libxerces-c.so.22.0)
        symbol not found: u_toupper_2_1         (./libxerces-c.so.22.0)
        symbol not found: u_isspace_2_1         (./libxerces-c.so.22.0)
        symbol not found: ucnv_open_2_1         (./libxerces-c.so.22.0)
        symbol not found: u_tolower_2_1         (./libxerces-c.so.22.0)
        symbol not found: ucnv_openU_2_1                (./libxerces-c.so.22.0)
        symbol not found: ucnv_getMaxCharSize_2_1               (./libxerces-c.so.22.0)
        symbol not found: ucnv_getMinCharSize_2_1               (./libxerces-c.so.22.0)
        symbol not found: ucnv_close_2_1                (./libxerces-c.so.22.0)
        symbol not found: ucnv_toUnicode_2_1            (./libxerces-c.so.22.0)
        symbol not found: ucnv_setFromUCallBack_2_1             (./libxerces-c.so.22.0)
        symbol not found: ucnv_fromUnicode_2_1          (./libxerces-c.so.22.0)
        symbol not found: ucnv_fromUChars_2_1           (./libxerces-c.so.22.0)
        symbol not found: ucnv_toUChars_2_1             (./libxerces-c.so.22.0)
        symbol not found: __1cDstdNbasic_ostream4Ccn0ALchar_traits4Cc___Fflush6M_r1_            (./libxerces-c.so.22.0)
        symbol not found: __1cDstdNbasic_ostream4Ccn0ALchar_traits4Cc___Fwrite6Mpkcl_r1_                

(./libxerces-c.so.22.0)
        symbol not found: u_charType_2_1                (./libxerces-c.so.22.0)
        symbol not found: icudt22_dat           (/export/home/sunperf/icu/lib/sol/release/libicuuc.so.22)

____________
These instructions may work on Solaris 10 for SPARC as well

Posted in | No comments

Thursday, 3 February 2005

Solaris 9 or later: More performance with Large Pages (MPSS)

Posted on 18:00 by Unknown

3 simple steps to improve the performance of any native application on Solaris 9 or later versions:

Run the application; and collect trapstat data with maximum load on the system
```
trapstat -T 10 10
```
Check the %time spent on dTLB misses
Preload mpss.so.1 interposing library of Solaris and configure the application to use large pages. This can be done by writing a simple wrapper wround the invokation of application

You can check the supported page sizes on your machine by typing "pagesize -a". Common page sizes on SPARC systems: 8K (default), 64K, 512K, 4M

Wisely choose the page size for the application; else lot of resources may get wasted thereby degrading the performance of the system

Create the wrapper script as follows Or add the following lines (upto export MPSSCFGFILE ..) to your script, if you have one:
```
	#!/bin/ksh

	LD_PRELOAD=mpss.so.1

	MPSSCFGFILE=/tmp/mpsscfg

	MPSSERRFILE=/tmp/mpsserr



	export MPSSCFGFILE MPSSERRFILE LD_PRELOAD



	exec <application name> <args to application>
```
Then create a simple configuration for MPSS:

eg., If myapp is the name of the application, the following line creates the mpss config file to let the application use 4M pages for heap (default: 8K pages) and a 64K stack (default: 8K)
```
	echo "myapp*:4M:64K" > /tmp/mpsscfg
```
Finally, run the application by executing the wrapper script. And collect the trapstat statistics and measure the difference in performance

With the help of large pages, the application's performance may improve due the reduced number of dTLB misses.

eg.,

The following data was collected by running Siebel with default 8K pages on Sun's v480 server:



sdcv480s002:/export/home/sunperf/perf_tools/%grep ttl trapstat-vanilla.txt

      ttl |    918305  5.2      9363  0.4 |   1148524  8.0     66553  3.2 |16.7

      ttl |    990784  5.6      9888  0.4 |   1202256  8.4     67298  3.3 |17.6

      ttl |    960221  5.4      9764  0.4 |   1192122  8.3     68607  3.3 |17.5

      ttl |    982697  5.6      9934  0.4 |   1232264  8.5     69221  3.3 |17.8

      ttl |   1007827  5.7     10295  0.4 |   1273141  8.8     72519  3.5 |18.5

      ttl |   1011441  5.7     10031  0.4 |   1222785  8.5     69450  3.4 |18.1

      ttl |    961155  5.4      9469  0.4 |   1191395  8.2     65668  3.2 |17.2

      ttl |   1019467  5.8     11088  0.5 |   1265553  8.9     77352  3.8 |18.9

      ttl |   1009262  5.7     10638  0.4 |   1276510  8.9     74925  3.6 |18.7

      ttl |   1021536  5.8     10554  0.4 |   1280768  8.9     72188  3.5 |18.6

The following data shows the reduced number of dtlb, dtsb misses with 4M pages:



sdcv480s002:/export/home/sunperf/perf_tools/%grep ttl 771mpss-trapstat.txt

      ttl |   1497319  8.4      1082  0.0 |    131236  1.1      2577  0.1 | 9.7

      ttl |   1305635  7.4      1020  0.0 |    117982  1.0      2483  0.1 | 8.5

      ttl |   1626490  9.2      1028  0.0 |    145789  1.2      2754  0.1 |10.6

      ttl |   1424718  8.0      1063  0.0 |    130317  1.1      2665  0.1 | 9.3

      ttl |   1411515  8.0       982  0.0 |    126710  1.1      2532  0.1 | 9.2

      ttl |   1443108  8.1       925  0.0 |    128753  1.1      2577  0.1 | 9.4

      ttl |   1512549  8.5      1037  0.0 |    131343  1.1      2518  0.1 | 9.8

      ttl |   1246909  7.0       834  0.0 |    107194  0.9      2299  0.1 | 8.1

      ttl |   1387027  7.8      1004  0.0 |    126112  1.1      2636  0.1 | 9.1

      ttl |   1477135  8.3       989  0.0 |    126294  1.1      2477  0.1 | 9.6

And the application with 4M pages, performed nearly 7% better compared to the vanilla run

Posted in | No comments

Wednesday, 2 February 2005

Siebel on Sun Solaris: Know the process resource limits

Posted on 15:01 by Unknown

Symptom:
On Solaris OS, none of the Object Managers start up with total MaxTasks > 9200 thereby limiting the maximum number of users to 9000 (assuming one task per user and some overhead tasks for other server components) per single instance of Siebel server

Resolution:
On Solaris, for any user process, the maximum data segment or heap will have a soft/hard limit of 2G, by default. Similarly, stack will have a soft limit of 8M and a hard limit of 2G i.e., 2G address space will be reserved for the stack itself.

Those limits on system resources inhibit the growth of heap beyond 2G and may force the process to die, if it couldn't get the requested resources

So, the solution to the above mentioned problem is to increase the limits for data segment and reducing the limits for stack . From Siebel's perspective: adding the following two lines in $SIEBEL_ROOT/bin/start_server script (at any place, but before invoking siebsvc process) will fix the issue and lets the customer to configure the maxtasks to more than 9200; thereby, eliminating the need to install another Siebel server to get around this problem


 ulimit -s 512
 ulimit -d 4194303

Those two lines limit the stacksize to 512K and datasize to 4G respectively

Please note that the above settings may allow the customer to set more number of maxtasks; but obviously not to a very large number, as the 32-bit process can grow upto 4G only. Also the total number of allowed MaxTasks may vary from server to server depending on the available virtual memory (physical memory + swap space)

Detailed explanation of the problem & the suggested solution


srvrmgr:sdcv480s002> list param maxtasks for comp FINSObjMgr_enu

PA_ALIAS PA_VALUE PA_DATATYPE  PA_SCOPE   PA_SUBSYSTEM       PA_SETLEVEL PA_DISP_SETLEVEL     PA  PA  PA  PA PA_NAME
-------- -------- -----------  ---------  ------------------ ----------- -------------------  --  --  --  -- -------------
MaxTasks 620      Integer      Subsystem  Process Management Comp level  Component level set  N   N   Y   N  Maximum Tasks

1 row returned.

srvrmgr:sdcv480s002> change param maxtasks=9500 for comp FINSObjMgr_enu
Command completed successfully.

After this change, siebel server process, siebsvc fails to start up with an ENOMEM error i.e., there is not enough room in the address space of the process to fulfill one of the mmap() requests by siebsvc.

Truss output of siebsvc:

...
27763:  open("/export/home/sunperf/18306/siebsrvr/admin/siebel.sdcv480s002.shm", O_RDWR|O_CREAT|O_EXCL, 0700) = 9
27763:  write(9, "\0\0\0\0\0\0\0\0\0\0\0\0".., 1119830016) = 1119830016
27763:  mmap(0x00000000, 1119830016, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) Err#12 ENOMEM <= failed; not enough addr space
...

sdcv480s002:/tmp/%ls -lh "/export/home/sunperf/18306/siebsrvr/admin/siebel.sdcv480s002.shm"
-rwx------   1 sunperf  other       1.0G Feb  2 12:07 /export/home/sunperf/18306/siebsrvr/admin/siebel.sdcv480s002.shm*

prstat output before siebsvc dies:
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
 27763 sunperf  1087M 1082M sleep   59    0   0:00:12 3.8% siebsvc/1

From the above outputs, it is clear that siebsvc couldn't grow more than 2G, though it is allowed to go upto 4G (siebsvc is a 32-bit process; so, it will have a 4G address space in the VM system when the process gets created)

So, it is worth looking at the output of "limit" (in Csh) or "ulimit -a" (in ksh), which shows the limitations on the system resources available to the current shell and its descendents


% limit
cputime         unlimited
filesize        unlimited
datasize        unlimited
stacksize       8192 kbytes
coredumpsize    unlimited
descriptors     256
memorysize      unlimited

Even though the soft limit for the datasize was reported as "unlimited", it defaults to 2G on Solaris. The following simple C program illustrates it with the help of sys/resource.h API


    #include <stdio.h>
    #include <stdlib.h>
    #include <stddef.h>
    #include <sys/time.h>
    #include <sys/resource.h>

    static void showlimit(int resource, char* str)
    {
        struct rlimit lim;

        if (getrlimit(resource, &lim) != 0)
        {
            (void)printf("Couldn't retrieve %s limit\n", str);
            return;
        }

        (void)printf("Current/maximum %s limit is: \t%lu (%luKB Or %luMB) / %lu (%luKB Or %luMB)\n", \
             str, lim.rlim_cur, (lim.rlim_cur/1024), (lim.rlim_cur/(1024 * 1024)), \
             lim.rlim_max, (lim.rlim_max/1024), (lim.rlim_max/(1024 * 1024)));
    }

    int main()
    {
        showlimit(RLIMIT_DATA,  "datasize");
        showlimit(RLIMIT_STACK, "stacksize");

        return 0;
    }

%./showlimits
Current/maximum datasize limit is:      2147483647 (2097151KB Or 2047MB) / 2147483647 (2097151KB Or 2047MB)
Current/maximum stacksize limit is:     8388608 (8192KB Or 8MB) / 2147483647 (2097151KB Or 2047MB)

Output of "showlimits" confirms the fact that the datasize has been limited to 2G under the current shell; so, obviously the process cannot grow beyond 2G, and may die if it needs more than 2G address space

So, to resolve the problem under discussion, the limit for the datasize has to be increased. As the process is allowed to take upto 4G virtual address space, it is better to set the limit to the max allowed size. Fortunately, this step doesn't need the intervention of a sys admin; and a normal user can set the limits for the shell, at his wish

"ulimit -d 4194303" in ksh or "limit -datasize 4194303" in Csh would set the limit for datasize to 4G. But $SIEBEL_ROOT/bin/start_server script is the ideal place to have this command, as it invokes siebel server process (siebsvc)

So, I made the change in "start_server" script and tried to start siebel servers again. Surprisingly, siebsvc failed to startup inspite the increase in datasize limit to 4G, with the same ENOMEM error message


...
28958:  open("/export/home/sunperf/18306/siebsrvr/admin/siebel.sdcv480s002.shm", O_RDWR|O_CREAT|O_EXCL, 0700) = 9
28958:  write(9, "\0\0\0\0\0\0\0\0\0\0\0\0".., 1119830016) = 1119830016
28958:  mmap(0x00000000, 1119830016, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) Err#12 ENOMEM <= failed again
...

"plimit <pid of siebsvc>" showed 4G data limit for siebsvc ("plimit" command shows the resource limits of running processe(s)


% plimit 28958
28958:  siebsvc -s siebsrvr -a -g sdcv480s002 -e siebel -s sdcv480s002
   resource              current         maximum
  time(seconds)         unlimited       unlimited
  file(blocks)          unlimited       unlimited
  data(kbytes)          4194303         4194303
  stack(kbytes)         unlimited       unlimited
  coredump(blocks)      unlimited       unlimited
  nofiles(descriptors)  65536           65536
  vmemory(kbytes)       unlimited       unlimited

"pmap <pid of siebsvc>" reported nearly a little over 1G as the total VM address space in use for siebsvc


% pmap 28958
00010000      16K r-x--  /export/home/sunperf/18306/siebsrvr/bin/siebsvc
00022000       8K rwx--  /export/home/sunperf/18306/siebsrvr/bin/siebsvc
00024000 1094592K rwx--    [ heap ]
7E000000    4856K rw-s-  dev:118,0 ino:405547
7E880000     600K r-x--  /usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.2
7E924000      16K rwx--  /usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.2
7E930000       8K rwx--    [ anon ]
...
...
7F9D0000       8K rwx--    [ anon ]
7F9E0000       8K r-x--  /usr/lib/libnls.so.1
7F9F2000       8K rwx--  /usr/lib/libnls.so.1
7FA00000    1600K r-x--  /usr/lib/libCstd.so.1
7FB9E000      32K rwx--  /usr/lib/libCstd.so.1
7FBA6000       8K rwx--  /usr/lib/libCstd.so.1
7FBB0000       8K r-x--  /usr/lib/libxnet.so.1
7FBC0000     160K r-x--  /usr/lib/ld.so.1
7FBF6000      16K rwx--  /usr/lib/ld.so.1
FFBF4000      48K rwx--    [ stack ]
 total   1112576K

However, interestingly "pmap -r " showed that 2G of virtual address space is reserved for stack of siebsvc; so, eventually memory allocation for heap was impacted by 2G reserved space for stack.


% pmap -r 28958
00010000      16K r-x--  /export/home/sunperf/18306/siebsrvr/bin/siebsvc
00022000       8K rwx--  /export/home/sunperf/18306/siebsrvr/bin/siebsvc
00024000 1094592K rwx--    [ heap ]
7E000000    4856K rw-s-  dev:118,0 ino:405547
7E880000     600K r-x--  /usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.2
7E924000      16K rwx--  /usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.2
7E930000       8K rwx--    [ anon ]
...
...
7F9D0000       8K rwx--    [ anon ]
7F9E0000       8K r-x--  /usr/lib/libnls.so.1
7F9F2000       8K rwx--  /usr/lib/libnls.so.1
7FA00000    1600K r-x--  /usr/lib/libCstd.so.1
7FB9E000      32K rwx--  /usr/lib/libCstd.so.1
7FBA6000       8K rwx--  /usr/lib/libCstd.so.1
7FBB0000       8K r-x--  /usr/lib/libxnet.so.1
7FBC0000     160K r-x--  /usr/lib/ld.so.1
7FBF6000      16K rwx--  /usr/lib/ld.so.1
7FC00000 2097152K rwx--    [ stack ]
 total   3209680K

To be more precise, 1G VM space is already in use by siebsvc & nearly 2G space was reserved for stack, which leaves only less than 1G for the heap of the process. So, when siebsvc tried to memory map the huge 1G+ shared memory (shm) file, the VM system couldn't allocate the required space and ultimately the process died

Again, from the output of "showlimits", it is clear that the stack could grow upto 2G in size (ie., the hard limit for stacksize). But even with very high load on the siebel servers, it is very rare to see more than 64K stack size being used by siebsvc. So, it is better to limit the stack size as well to any value < 1M

"ulimit -s 512" in ksh or "limit -stacksize 512" in Csh would set the limit for datasize to 4G. But again, $SIEBEL_ROOT/bin/start_server script is the right place to have this command, as it invokes siebel server process (siebsvc)

After making the necessary changes, the VM was system able to fulfill the 1G+ memory allocation for mmap() request of siebel server process (siebsvc). Some interesting outputs were shown below:


prstat output for siebsvc:
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
 29255 sunperf  2155M 2148M sleep   59    0   0:00:31 2.7% siebsvc/3

Truss output of siebsvc:
...
29255:  open("/export/home/sunperf/18306/siebsrvr/admin/siebel.sdcv480s002.shm", O_RDWR|O_CREAT|O_EXCL, 0700) = 9
29255:  write(9, "\0\0\0\0\0\0\0\0\0\0\0\0".., 1119830016) = 1119830016
29255:  mmap(0x00000000, 1119830016, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0xF8000000 <= succeeds
...

% plimit 29255
29255:  siebsvc -s siebsrvr -a -g sdcv480s002 -e siebel -s sdcv480s002
   resource              current         maximum
  time(seconds)         unlimited       unlimited
  file(blocks)          unlimited       unlimited
  data(kbytes)          4194303         4194303
  stack(kbytes)         512             512
  coredump(blocks)      unlimited       unlimited
  nofiles(descriptors)  65536           65536
  vmemory(kbytes)       unlimited       unlimited

% pmap 29255
29255:  siebsvc -s siebsrvr -a -g sdcv480s002 -e siebel -s sdcv480s002
00010000      16K r-x--  /export/home/sunperf/18306/siebsrvr/bin/siebsvc
00022000       8K rwx--  /export/home/sunperf/18306/siebsrvr/bin/siebsvc
00024000 1094664K rwx--    [ heap ]
FE000000    4856K rw-s-  dev:118,0 ino:405506
FE800000     600K r-x--  /usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.2
FE8A4000      16K rwx--  /usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.2
FE8B0000       8K rwx--    [ anon ]
...
...
FF970000       8K rwx--    [ anon ]
FF980000    1600K r-x--  /usr/lib/libCstd.so.1
FFB1E000      32K rwx--  /usr/lib/libCstd.so.1
FFB26000       8K rwx--  /usr/lib/libCstd.so.1
FFB30000       8K r-x--  /usr/lib/libxnet.so.1
FFB40000     160K r-x--  /usr/lib/ld.so.1
FFB76000      16K rwx--  /usr/lib/ld.so.1
FFBFA000      24K rwx--    [ stack ]
 total   1112624K

% pmap -r 29255
29255:  siebsvc -s siebsrvr -a -g sdcv480s002 -e siebel -s sdcv480s002
00010000      16K r-x--  /export/home/sunperf/18306/siebsrvr/bin/siebsvc
00022000       8K rwx--  /export/home/sunperf/18306/siebsrvr/bin/siebsvc
00024000 1094664K rwx--    [ heap ]
FE000000    4856K rw-s-  dev:118,0 ino:405506
FE800000     600K r-x--  /usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.2
FE8A4000      16K rwx--  /usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.2
FE8B0000       8K rwx--    [ anon ]
...
...
FF970000       8K rwx--    [ anon ]
FF980000    1600K r-x--  /usr/lib/libCstd.so.1
FFB1E000      32K rwx--  /usr/lib/libCstd.so.1
FFB26000       8K rwx--  /usr/lib/libCstd.so.1
FFB30000       8K r-x--  /usr/lib/libxnet.so.1
FFB40000     160K r-x--  /usr/lib/ld.so.1
FFB76000      16K rwx--  /usr/lib/ld.so.1
FFB80000     512K rwx--    [ stack ]
 total   1113112K

srvrmgr:sdcv480s002> list param maxtasks for comp FINSObjMgr_enu
PA_ALIAS PA_VALUE PA_DATATYPE  PA_SCOPE   PA_SUBSYSTEM       PA_SETLEVEL PA_DISP_SETLEVEL     PA  PA  PA  PA PA_NAME     
-------- -------- -----------  ---------  ------------------ ----------- -------------------  --  --  --  -- -------------
MaxTasks 9500      Integer      Subsystem  Process Management Comp level  Component level set  N   N   Y   N  Maximum Tasks

1 row returned.

Posted in | No comments

Creation Zone

Friday, 11 February 2005

Solaris: How to get rid of [English/European] bar underneath every window?

Monday, 7 February 2005

Solaris: lofiadm - Mounting an ISO image on Solaris file system

Friday, 4 February 2005

Building ICU 2.2 & Xerces 2.1 on Solaris 10 for x86

Thursday, 3 February 2005

Solaris 9 or later: More performance with Large Pages (MPSS)

Wednesday, 2 February 2005

Siebel on Sun Solaris: Know the process resource limits

Popular Posts

Categories

Blog Archive

About Me