System doesnu00B4t start on Windows IA64 PXA > 750 MB

[Former Member]

After increasing the abap/buffersize to values greater than 750 MB, the system won´t start any more:

A  ---PXA-------------------------------------------
A  PXA INITIALIZATION
A  
A Wed Mar 05 20:53:26 2008
A  PXA: Locked PXA-Semaphore.
A  System page size: 8kb, total admin_size: 42224kb, dir_size: 13960kb.
I  *** ERROR => [MapOsShm] Can't find free space for Shared Memory (Size=1000000 KB)
              ERROR_INVALID_ADDRESS: Attempt to access invalid address.  [shmnt.c      2174]
I  *** ERROR => [CreateOsShm] MapViewOfFile(Key=6,Handle=0x000000000000039C) failed with Err=203 
              ERROR_ENVVAR_NOT_FOUND: The system could not find the environment option that was entered.  [shmnt.c      2174]
I  *** ERROR => ShmCreate: Create (6,1024000000,1) failed [shmnt.c      506]

Windows 2003 with SP2

32 GB RAM, 64 GB Swap

Actual hotfixes but IE 7

Hotfix of KB941796

Is it necessary to rebase DLLs on IA64 boxes too?

Markus

[Former Member · Accepted solution]

Hi,

i think yes,

you already consider sap Note 129813 - Windows: Problems due to address space fragmentation

since you used very large abap/buffersize parameters for that you need to change the Basis addresses of the DLLs (rebase).

regards,

kaushal

[markus_doehr2 · Accepted solution]

Yes - but this note is valid for 32bit only - that system is an Itanium-2 machine with 64bit windows:

<quote>

Upgrade the application server to a 64-Bit version. If a 64-Bit version of SAP ABAP Server is available and your hardware will support the required 64-Bit Windows Version, we recommend this upgrade.

<quote>

Markus

[Former Member · Accepted solution]

Hi,

Yes the note for 32 bit windows which suggested to upgrade to 64bit windows,

in your case you used very large abap/buffersize so you can use rebase method on 64 bit also.( SAP Address Space Viewer)

sapadrspcIA64.car is attached to note..

In Windows Server 2003, Windows File Protection (WFP) may prevent the rebasing of system DLLs

for that consider Note 664269 - Rebasing DLLs under WFP

in unix i did not see this type of problem.

regards,

kaushal

Edited by: kaushal malavia on Mar 6, 2008 5:22 PM

[markus_doehr2 · Accepted solution]

I tried that.

I downloaded the viewer, loaded the system DLLs according to the note but I don´t see any dispwork.exe in the process list - I can see SQL Server and other 64bit processes but no dispwork.

So either that tool is not working on IA64 or I am missing something very basic...

Markus

[Former Member · Accepted solution]

Hi,

even i try with IA32 on sql server it's does not show anything.

and one more thing

according to note 853696 Rebasing is not necessary for any 64-bit Windows program running on IA64 or AMD64/EM64T Windows computers

i think you open OSS message for same.

regards,

kaushal

[markus_doehr2 · Accepted solution]

Thanx - I knew I read something about rebasing not being necessary on 64bit systems - I just didn´t find the note - thanx for the hint!

Yes - I created an OSS call already - let´s see what they will tell... I keep you all posted!

Markus

PS: I also never saw those kind of problems on *NIX systems even with a MUCH bigger PXA (2,5+ GB)...

[Former Member]

Try this....and keep lowering the value of em/address_space_MB if it still will not start.

em/address_space_MB = 4096

em/initial_size_MB = 16320

em/global_area_MB = 512

[Former Member]

Hello Markus,

It seems stange to get this problem !

Four our R/3 4.7 system Central instance, we use

Windows 2003 IA64 with SP2

16 GB RAM, 40 GB Swap

The PXA buffer is 1 GB, PHYS_MEMSIZE is set to 11 GB and we never had to rebase DLLs.

Regards,

Olivier

[markus_doehr2]

Yes - and I really don´t think it´s a DLL/rebase problem but a problem generated by some em/ parameter using too huge chunks...

Markus

[Former Member]

Hello Markus!!:

Is a Windows, so you have tried to restart the system??.

In this O.S. may be normal this memory problems.

Alfredo.

[markus_doehr2]

Machine has rebooted already several times - it´s not a Windows-needs-boot-to-run-issue (this time).

The problem seems to be, that one shared memory segment to be created is too big resp. the chunk is too big... I already opened an OSS call...

Markus

[Former Member]

As Very High...... these problems of memory are very difficult to controlate.