Mandalika's scratchpad [ Work blog @Oracle | Stock Market Notes | My Music Compositions ]

Old Posts: 09.04  10.04  11.04  12.04  01.05  02.05  03.05  04.05  05.05  06.05  07.05  08.05  09.05  10.05  11.05  12.05  01.06  02.06  03.06  04.06  05.06  06.06  07.06  08.06  09.06  10.06  11.06  12.06  01.07  02.07  03.07  04.07  05.07  06.07  08.07  09.07  10.07  11.07  12.07  01.08  02.08  03.08  04.08  05.08  06.08  07.08  08.08  09.08  10.08  11.08  12.08  01.09  02.09  03.09  04.09  05.09  06.09  07.09  08.09  09.09  10.09  11.09  12.09  01.10  02.10  03.10  04.10  05.10  06.10  07.10  08.10  09.10  10.10  11.10  12.10  01.11  02.11  03.11  04.11  05.11  07.11  08.11  09.11  10.11  11.11  12.11  01.12  02.12  03.12  04.12  05.12  06.12  07.12  08.12  09.12  10.12  11.12  12.12  01.13  02.13  03.13  04.13  05.13  06.13  07.13  08.13  09.13  10.13  11.13  12.13  01.14  02.14  03.14  04.14  05.14  06.14 


Friday, February 11, 2005
 
Solaris: How to get rid of [English/European] bar underneath every window?

[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
  1. Temporary workaround: Select Options -> Langauges -> C at the CDE/GNOME/JDS login menu button
  2. 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


Monday, February 07, 2005
 
Solaris: lofiadm - Mounting an ISO image on Solaris file system

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


Friday, February 04, 2005
 
Building ICU 2.2 & Xerces 2.1 on Solaris 10 for x86



______________________________

Building ICU 2.2 on Solaris 10 x86
______________________________

  1. 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

  2. cd $ICUROOT/source
  3. chmod +x runConfigureICU configure install-sh
  4. ./runConfigureICU SOLARISX86 --disable-64bit-libs --enable-layout --prefix=<installation-directory>
    (by default layout will be disabled)
  5. 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

  6. ./runConfigureICU SOLARISX86 --disable-64bit-libs --enable-layout --prefix=<installation-directory>
  7. gmake
  8. gmake check (optional)
  9. gmake install



_______________

Building Xerces 2.1
_______________

  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

  2. 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

  3. cd $XERCESCROOT/src/xercesc
    pushd $ICUROOT/lib

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

    popd

  4. 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

  5. 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}

  6. 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.
  7. gmake
  8. 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


Thursday, February 03, 2005
 
Solaris 9 or later: More performance with Large Pages (MPSS)

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

  1. Run the application; and collect trapstat data with maximum load on the system
    trapstat -T 10 10

    Check the %time spent on dTLB misses
    
    
  2. 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

  3. 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


Wednesday, February 02, 2005
 
Siebel on Sun Solaris: Know the process resource limits

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.




2004-2014 

This page is powered by Blogger. Isn't yours?