Operating System - Tru64 Unix
1752785 Members
6293 Online
108789 Solutions
New Discussion юеВ

Re: Shared Pool 10: ipc/shm_psize_10 = 4000000 (too small)

 
administrador
Advisor

Shared Pool 10: ipc/shm_psize_10 = 4000000 (too small)

Hello world, please your helppppppp!!!!!

How can I change my Share pool memory in order to increase it minimun to 12000000, because when I Bring up my aplication I get below:
Sat Dec 13 14:30:08 2008
***LOG Q00=> DpSapEnvInit, DPStart (00 6416) [dpxxdisp 0795]

relno 31I
patchlevel 710
compiled on OSF1 V4.0 878 alpha
compiled at Apr 12 2003 05:49:28
pid 6416

Profile configuration error detected, use temporary corrected setup
Shared Pool 10: ipc/shm_psize_10 = 4000000 (too small)
Shared Pool 10: (smaller than default 12000000)
Shared Pool 10: (default size assumed 12000000)
MBUF state OFF
MBUF opmode USE
client 0 initializing ....
InitFreeList
block size is 1024 kByte.
EsIUnamFileMapInit: ES base = 0x4800000

Sat Dec 13 14:30:09 2008
EsIOsInit: Extended Memory 1024 MB allocated
1023 blocks reserved for free list.
ES initialized.
***LOG Q0K=> DpMsAttach, mscon ( bisap3) [dpxxdisp 6637]
MBUF set hwid_state to HWID_PENDING
MBUF state PREPARED
MBUF component UP
MBUF set hwid_state to SAP_O_K (S1353317685 )

Sat Dec 13 14:30:50 2008
*** ERROR => W0 (pid 6423) died [dpxxdisp 8564]
*** ERROR => W2 (pid 6426) died [dpxxdisp 8564]

Sat Dec 13 14:31:10 2008
*** ERROR => W1 (pid 6424) died [dpxxdisp 8564]
*** ERROR => W4 (pid 6430) died [dpxxdisp 8564]

Sat Dec 13 14:31:30 2008
*** ERROR => W5 (pid 6432) died [dpxxdisp 8564]

Sat Dec 13 14:31:50 2008
*** ERROR => W3 (pid 6428) died [dpxxdisp 8564]
*** ERROR => W6 (pid 6433) died [dpxxdisp 8564]
my types changed after wp death/restart 0x3f --> 0x3e

Sat Dec 13 14:32:10 2008
*** ERROR => W8 (pid 6437) died [dpxxdisp 8564]

Sat Dec 13 14:32:30 2008
*** ERROR => W7 (pid 6435) died [dpxxdisp 8564]
my types changed after wp death/restart 0x3e --> 0x3c

Sat Dec 13 14:32:50 2008
*** ERROR => W9 (pid 6438) died [dpxxdisp 8564]
*** ERROR => W10 (pid 6440) died [dpxxdisp 8564]
my types changed after wp death/restart 0x3c --> 0x38

Sat Dec 13 14:33:10 2008
*** ERROR => W11 (pid 6442) died [dpxxdisp 8564]

Sat Dec 13 14:33:30 2008
*** ERROR => W12 (pid 6444) died [dpxxdisp 8564]
*** ERROR => W13 (pid 6446) died [dpxxdisp 8564]

Sat Dec 13 14:33:50 2008
*** ERROR => W14 (pid 6449) died [dpxxdisp 8564]

Sat Dec 13 14:34:10 2008
*** ERROR => W15 (pid 6452) died [dpxxdisp 8564]
*** ERROR => W16 (pid 6454) died [dpxxdisp 8564]
my types changed after wp death/restart 0x38 --> 0x20

Sat Dec 13 14:34:30 2008
*** ERROR => W17 (pid 6457) died [dpxxdisp 8564]
my types changed after wp death/restart 0x20 --> 0x0
*** DP_FATAL_ERROR => DpEnv2Check: no more work processes
*** DISPATCHER EMERGENCY SHUTDOWN ***

Sat Dec 13 14:34:40 2008
***LOG Q0M=> DpMsDetach, ms_detach () [dpxxdisp 6838]
MBUF state OFF
MBUF component DOWN
***LOG Q05=> DpHalt, DPStop ( 6416) [dpxxdisp 5577]
Thanks a lot world!!!!
2 REPLIES 2
Rob Leadbeater
Honored Contributor

Re: Shared Pool 10: ipc/shm_psize_10 = 4000000 (too small)

Hi,

I take it you know how to use Google...

Searching for "shm_psize_10" will lead you to this SAP help document, which seems to be relevant...

http://help.sap.com/saphelp_nw04/helpdata/EN/c4/3a6f41505211d189550000e829fbbd/content.htm

Cheers,

Rob
Hein van den Heuvel
Honored Contributor

Re: Shared Pool 10: ipc/shm_psize_10 = 4000000 (too small)

Apparently there is an entry with " ipc/shm_psize_10" in the instance specifc profile, or DEFAULT.PFL.

Removing that line, or changing the value on that line will remove the warning... but nothing else.
The system will run exactly as good (or as bad) as it did with the warning.

So you really have to ask yourself why that line was there, and whether (much) more is needed. Be sure to read a bunch of SAPnotes on the subject, and perhaps pull out a book like Thomas Schneider's "SAP R/3 Performance Optimization" and study the chapters on monitoring and configuring memory areas.

But I would focus on why the instance did not come up properly. Look in dev_w0 and files like that for details? Actually when I worked with this stuff I typically looked at dev_w1. It seemed to have less noise.

Once you have it working a little bit, use transaction ST02 and drilldown friends to figure out actual memory usages.

Check out the most recent changed files in the work directories with a command like:
# -ltr usr/sap//DVEBMGS00 | tail
Sometimes the stdout and steerr in there provide valueable clues.

hth,
Hein.