Memory upgrade from 16 Gig to 32 Gig on 32 bit architucture

[Former Member]

Good afternoon every one:

I am running SAP 4.7 on windows enterprise edition which is a 32 bit architecture. Yesterday we upgraded the memory from 16 to 32 Gigabyte and tried to start the SAP.

However, after starting the SAP, system still shows 16 Gigabyte of memory. As per SAP notes on 32 bit architecture, over 16 gigabyte of memory I do not require /3 GB switch.

My problem is: I can not start SAP application without /3 GB switch, and I can only start SAP with /3GB switch, but this will limit the memory on OS to 16 Gigabyte.

SAP is not denying nor confirming that with 32 bit architecture the maximum memory usage is 16 Gigabyte.

My environment is clustered. I have Database on one node and CI on other. I need to configure my environment the way that on failover situation, application and database to use each 16 Gigabyte. Is this possible?

Please help.

Regards,

KG

[Former Member]

Thank you every one for your suggestions.

[Former Member]

Hi,

It sounds like you are running into the standard windows addressing issue. A process in a 32 bit windows system can only address 2 Gig at a time unless you put in the 3 Gig switch.

Are you using zero memory management? Have you updated the PHYS_MEMSIZE parameter?

Hope that helps.

J. Haynes

Denver

[Former Member]

Denver,

thak you for your reply.

Yes, I am using zero memory mangmnet parameters. I have set the size of

PHYS_MEMSIZE to 0 and also tried it with 32000 KB, However, application would start for few seconds and work processes would start to die.

Regards,

kourosh

[Former Member]

Yeah. I bet if you check the logs for the dispatcher and the work processes you will find that it has run out of shared memory.

[Former Member]

Denver,

I know this is the problem. All the logs are indicating this. How do I fix it?

My undrestanding was with Zero memory mangment and 32 Gig memory, all I need is to take the /3GB switch out and everything should be alright. However /3GB switch is limiting the meory to 16 Gig and I have no use to other 16 Gig.

Do you have any work around for this?

[markus_doehr2]

check note 313347 - Windows editions and memory support and also http://support.microsoft.com/?scid=kb%3Ben-us%3B283037&x=12&y=11

You will be able to address that memory but a single process will still only be able to address 2 GB of memory.

What do you see in dev_w0 when you set PHYS_MEMSIZE to 32000 and start the system?

Markus

[former_member433984]

the best workaround would be to go on 64-bit platform where you will have significantly larger virtuall address space and amount of supported RAM....

[Former Member]

Markus,

I hope you are well, and thank you for replying to this note.

My production server is made of CI/DB on clustered environment and 3 application server which memory just got upgraded to 8 Gig. All on windows 2003 enterprise edition.

CI/DB are using 8 CPU.

As per SAP notes, If we are going to upgrade the memory to more than 32 Gig, I will not require /3GB switch. Which made me to believe, there will be enough memory to be spread around.

So, I have removed the /3GB switch and changed the PHYS_MEMSIZE to 32000 and SAP started momentarily but died after few seconds with shared memory error messages.

I tried setting the PHYS_MEMSIZE to 16000 same issue.

Reason we did upgrade the server memory to 32 Gig was in failover situation, SAP to use approximately 9 to 10 Gig, Database to use around 16-18 Gig and the rest for OS.

Now that I have the memory I am unable to configure the system to do so. I just found another note 327494, section 6, when SQL server 2000 coexists with database and memory >16 Gig, windows edition should be DataCenter. I hate to go to my management and ask for OS upgrade.

We are upgrading the landscape to 64 bit, however, this is a 6 month project.

Note 327494:

6) When SQL Server 2000 coexists as a combined system with either a

Central Instance or an Update Instance Application Server

and there is > 16GB of physical memory,

the following is proposed:

{Windows 2000 should be Datacenter}

SAP AS Memory should be fixed by PHYS_MEMSIZE to 30% of (total

physical memory - 1 GB)

<minMB> = <maxMB> = 30% of (physical main memory - 1 GB)

{1 additional GB should be left for OS management of more AWE}

<minMB> and <maxMB> must be less than 16GB

{this is because the /3GB switch is required by the CI or

Application Server}

<setWS> = 0

<awe> = 1

The Windows Boot.ini should not have the /3GB startup flag set in

order to take full advantage of the available physical memory.

{But consequently, the Application Server work processes memory may

be reduced and only have 2GB of available virtual address space

in contrast to the 3GB that would be availbe with the use of the

3GB switch.}

The /pae startup flag should be enabled.

Also trace file as per your request:

Sun Jan 13 11:41:00 2008

I MtxInit: 0 0 0

M SHM_PRES_BUF (addr: 0C030040, size: 20000000)

I *** ERROR => [MapOsShm] Can't find free space for Shared Memory (Size=262144 KB)

[shmnt.c 2130]

I *** ERROR => [CreateOsShm] MapViewOfFile(Key=9,Handle=0x000004E0) failed with Err=0

[shmnt.c 2130]

I *** ERROR => ShmCreate: Create (9,268435456,3) failed [shmnt.c 469]

*****************************************************

• Memory diagnostic *

*****************************************************

Systeminformation

-

---

Processor-Typ : Intel unknown

Processor-Count : 8

Operating System : NT 5.2, Build 3790

Service Pack : Service Pack 1

-

---

NT Pagefile Informations

-

---

Config. minimum size : 32768000 K

Config. maximum size : 32768000 K

Avail. maximum size : 32768000 K

Num	Pagefile	Min.Size	Max.Size	Avail.Max	Curr.Size
1	c:\pagefile.sys	16384000 K	16384000 K	16384000 K	16384000 K
2	d:\pagefile.sys	16384000 K	16384000 K	16384000 K	16384000 K

-

---

NT Task Manager Informations

-

---

Total Handles : 34164

Total Threads : 1441

Total Processes : 151

Commit Charge Total : 1824824 K

Commit Charge Limit : 65691528 K

Commit Charge Peak : 19807628 K

Phys.Memory Total : 33291464 K

Phys.Memory Available : 31966408 K

File Cache : 111172 K

Kernel Memory Total : 95656 K

Kernel Memory Paged : 48112 K

Kernel Memory Nonpaged : 47544 K

-

---

Memory usage of current process

-

---

Total virt.address space : 2097024 K

Avail.virt.address space : 797000 K

Private Pages : 0 K

Total heap size : 18165 K

Virtual memory regions : 0 K

Uncommitted heap memory : 12032 K

Allocated heap memory : 5841 K

Moveable heap memory : 0 K

DDE shared heap memory : 0 K

-

---

Memory usage of all processes

-

---

PID	Image	Instance	Work.Set	WS Peak	Priv.Pages	PP Peak	Pg Fault
4			240 K	2104 K	0 K	0 K	4
876	smss.exe		460 K	476 K	168 K	168 K	0
948	winlogon.exe		16876 K	40044 K	12192 K	28976 K	263
992	services.exe		5044 K	5344 K	3052 K	3436 K	9
1004	lsass.exe		12312 K	12312 K	10848 K	10860 K	4
1184	svchost.exe		2988 K	3012 K	1080 K	1108 K	0
1580	svchost.exe		20124 K	22224 K	14768 K	19232 K	21
1992	spoolsv.exe		5120 K	5232 K	3976 K	4040 K	1
632	ALERT.EXE		2324 K	2324 K	748 K	748 K	0
644	awservices.exe		3316 K	3316 K	2720 K	2720 K	0
696	cam.exe		8120 K	8120 K	2408 K	2408 K	1
732	casessrv.exe		2572 K	2572 K	828 K	828 K	0
760	dcevt32.exe		4368 K	4368 K	2500 K	2524 K	1
788	dcstor32.exe		11024 K	11096 K	22484 K	22564 K	12
812	EmcPowSrv.exe		2288 K	2636 K	748 K	2600 K	0
832	rmserver.exe		11820 K	11820 K	9916 K	9916 K	2
852	HbaHsMgr.exe		2136 K	2260 K	640 K	680 K	0
1072	svchost.exe		2240 K	2240 K	640 K	640 K	0
1344	InoRpc.exe		7188 K	7764 K	4868 K	4868 K	5
1356	InoRT.exe		24400 K	25276 K	21684 K	23064 K	20
1452	InoTask.exe		24308 K	27308 K	19824 K	24316 K	15
1684	LogWatNT.exe		1624 K	1624 K	612 K	612 K	0
1796	mr2kserv.exe		2116 K	2224 K	584 K	600 K	0
1820	NaviAgent.Exe		7544 K	8508 K	2696 K	3712 K	4
1868	bpinetd.exe		5172 K	5180 K	2584 K	2608 K	1
2032	omsad32.exe		4396 K	4428 K	1828 K	1872 K	1
2100	BPJAVA-msvc.EXE		3852 K	3852 K	1416 K	1416 K	0
2164	racsrvc.exe		5372 K	5372 K	3044 K	3044 K	1
2316	RACWinVNC.exe		3432 K	3432 K	1204 K	1204 K	0
2392	omaws32.exe		33160 K	33308 K	46276 K	46276 K	14
2408	watchdog.exe		1340 K	1340 K	264 K	264 K	0
2420	snmp.exe		11364 K	11388 K	8656 K	9756 K	4
2428	python.exe		9888 K	10864 K	6408 K	7648 K	5
2472	wmiapsrv.exe		3408 K	3408 K	2016 K	2092 K	0
2868	mssearch.exe		2708 K	6228 K	4068 K	4084 K	2
2876	aws_orb.exe		4520 K	6612 K	2852 K	4952 K	1
2232	aws_sadmin.exe		10724 K	12216 K	10364 K	12052 K	7
1980	aws_snmp.exe		3796 K	3860 K	2992 K	3060 K	0
3220	dmadmin.exe		4940 K	4964 K	3212 K	3296 K	1
3760	svchost.exe		4692 K	4696 K	3456 K	3484 K	1
3904	svchost.exe		4896 K	4916 K	2784 K	23192 K	1
540	caiW2kOs.exe		8880 K	8880 K	6712 K	6712 K	4
584	caiLogA2.exe		4752 K	4752 K	3892 K	3920 K	1
1544	hpaAgent.exe		13604 K	13712 K	10892 K	11008 K	4
3712	prfAgent.exe		12184 K	12340 K	9584 K	9744 K	4
3788	mscsagnt.exe		5168 K	5168 K	4072 K	4072 K	1
1472	winlogon.exe		2612 K	9700 K	4264 K	4360 K	3
4488	caftf.exe		5132 K	5132 K	3004 K	3068 K	1
4576	winlogon.exe		2652 K	9388 K	4224 K	4320 K	3
1756	sapstartsrv.exe		16016 K	16016 K	16376 K	16376 K	4
7724	msg_server.exe	[MS] R3P_00	9768 K	9768 K	9568 K	9640 K	2
7740	disp+work.exe	[DP] R3P_00	92100 K	92100 K	50028 K	50028 K	22
7768	gwrd.EXE	[GW] R3P_00	13424 K	13424 K	9284 K	103824 K	3
7800	icman.EXE		75672 K	75796 K	73980 K	74128 K	21
5104	disp+work.EXE		19316 K	19444 K	51556 K	51688 K	5
7532	disp+work.EXE	[WP] R3P_00	16768 K	16768 K	49524 K	49524 K	4
7604	disp+work.EXE	[WP] R3P_00	16772 K	16772 K	49524 K	49524 K	4
6964	disp+work.EXE	[WP] R3P_00	16780 K	16780 K	49524 K	49524 K	4
1836	disp+work.EXE	[WP] R3P_00	16784 K	16784 K	49524 K	49524 K	4
4376	disp+work.EXE	[WP] R3P_00	16776 K	16776 K	49524 K	49524 K	4
6124	disp+work.EXE	[WP] R3P_00	16772 K	16772 K	49524 K	49524 K	4
7560	disp+work.EXE	[WP] R3P_00	16788 K	16788 K	49524 K	49524 K	4
5244	disp+work.EXE	[WP] R3P_00	16788 K	16788 K	49524 K	49524 K	4
5060	disp+work.EXE	[WP] R3P_00	16788 K	16788 K	49524 K	49524 K	4
2620	disp+work.EXE	[WP] R3P_00	16776 K	16776 K	49524 K	49524 K	4
7592	disp+work.EXE	[WP] R3P_00	16788 K	16788 K	49524 K	49524 K	4
7984	disp+work.EXE	[WP] R3P_00	16788 K	16788 K	49524 K	49524 K	4
7384	disp+work.EXE	[WP] R3P_00	16772 K	16772 K	49524 K	49524 K	4
7364	disp+work.EXE	[WP] R3P_00	16788 K	16788 K	49524 K	49524 K	4
7100	disp+work.EXE	[WP] R3P_00	16788 K	16788 K	49524 K	49524 K	4
	Sum		831208 K		1243704 K

M *** ERROR => ThShMCreate: ShmCreate SHM_ROLL_AREA_KEY failed [thxxhead.c 2393]

M *** ERROR => ThIPCInit: ThShMCreate [thxxhead.c 1912]

M ***LOG R19=> tskh_init, ThIPCInit ( TSKH-IPC-000001) [thxxhead.c 1367]

M in_ThErrHandle: 1

M *** ERROR => tskh_init: ThIPCInit (step 1, th_errno 17, action 3, level 1) [thxxhead.c 9598]

M

M Info for wp 0

M

M stat = 4

M reqtype = 1

M act_reqtype = -1

M rq_info = 0

M tid = -1

M mode = 255

M len = -1

M rq_id = 65535

M rq_source = 255

M last_tid = 0

M last_mode = 0

M int_checked_resource(RFC) = 0

M ext_checked_resource(RFC) = 0

M int_checked_resource(HTTP) = 0

M ext_checked_resource(HTTP) = 0

M report = > <

M action = 0

M tab_name = > <

M

M *****************************************************************************

M *

M * LOCATION SAP-Server cacgcbcrr102_R3P_00 on host cacgsbcrr110 (wp 0)

M * ERROR tskh_init: ThIPCInit

M *

M * TIME Sun Jan 13 11:41:00 2008

M * RELEASE 640

M * COMPONENT Taskhandler

M * VERSION 1

M * RC 17

M * MODULE thxxhead.c

M * LINE 9783

M * COUNTER 1

M *

M *****************************************************************************

M

M PfStatDisconnect: disconnect statistics

M Entering TH_CALLHOOKS

M ThCallHooks: call hook >ThrSaveSPAFields< for event BEFORE_DUMP

M *** ERROR => ThrSaveSPAFields: no valid thr_wpadm [thxxrun1.c 730]

M *** ERROR => ThCallHooks: event handler ThrSaveSPAFields for event BEFORE_DUMP failed [thxxtool3.c 254]

M Entering ThSetStatError

M Entering ThReadDetachMode

M call ThrShutDown (1)...

M ***LOG Q02=> wp_halt, WPStop (Workproc 0 5104) [dpnttool.c 357]

[Matt_Fraser]

Really, the best answer is Yaroslav's suggestion, which is switching to 64-bit. This is significantly less expensive than going to Datacenter edition, and significantly easier technically, and it will solve this problem. You state that you are doing this as part of a 6-month project -- can you survive with just 16 GB of ram on the central instance for that six months? Either way, if you're already in a project to switch to 64-bit, then now is not the time to try to also go to Datacenter edition, which would also be a bit of a project, at least as involved as going to 64-bit.

If you're on recent Intel or AMD hardware, then your processors are probably already 64-bit compatible. You do need to 'upgrade' or re-install the OS and the DBMS with the equivalent 64-bit versions (which cost no more than the 32-bit versions). In the case of the DBMS, you can detach the SAP database, uninstall SQL Server, then reinstall with the 64-bit version, then reattach the database. The actual SAP application is the easiest part of all, since all you need to do is switch out the kernel. Nothing needs to happen to the actual database at all. Reinstalling the OS is the hardest part, really. I suspect you could achieve this in less than a six-month project, unless you are also doing other work as part of the same project.

--Matt

[Former Member]

Matt,

I totally understand what you are suggesting. I just hate to present to management, money they spent was no value.

One more question:

When I upgraded the app servers from 4 to 8 Gig, I left out the /3GB switch. App servers would come up and I have not experienced any issue till now. This is telling me address space used is less than 3 gig by app servers processes.

Why is it on CI, I am having this issue? Is there a way of reducing the address space used by SAP processes on CI to use less than 3 Gig? What if, I reduce the number of work processes on CI to minimum and have the app servers pick up the load? Is this possible?

Regards,

KG

[Matt_Fraser]

SAP even states in the same Note you are referencing that they haven't done any experimentation with SQL2000 systems having greater than 8GB memory. I'm not sure why it isn't working for you -- it seems like it should -- but hey, don't tell management they wasted their money! Instead, tell them it was an investment for the future, in anticipation of and preparation for the switch to 64-bit! Trust me, once you make that switch, that 32 GB of RAM will definitely be useful (and used).

I don't think there's any value to reducing the number of work processes on your CI. How many work processes you configure is more a function of how much processing power you have than it is the memory, though of course each process does use some memory. You could consider, though, having the users only logon directly to the 3 app servers and not the CI, if you aren't already doing this. You still need dialog WP's on the CI, though, even if you do this -- you should always have at least an equal number of dialog WP's +1 as to all other types of WP's on that same instance. I don't think this is your problem, though.

As far as your PHYS_MEMSIZE parameter goes, because you need to configure as if a failover has occurred and DB and CI are on the same instance, you really don't want to set PHYS_MEMSIZE to the full amount of memory. This means that even when you run the DB and CI on the separate nodes, the CI can't use the full memory, but at least it does get the full processing power, etc.

I realize this still doesn't solve the problem; hopefully someone else will have a better idea of what's going on.

--Matt

[former_member433984]

Hello KG,

the problem is that you are trying to perform 2 opposite things on 32-bit platform:

1) you want to have 32 GB RAM

2) but if you will allow the system to manage 32GB of RAM you have to deactivate the /3GB option - this leads to shrinking of addressable virtual address space, and as result it is not possible to allocate the contiguous SHM segment:

I *** ERROR => MapOsShm Can't find free space for Shared Memory (Size=262144 KB)

http://shmnt.c 2130

Possible solutions:

1) if you still want to have 32GB you have to screw the SHM segments of SAP system to minimum (to deactivate /3GB option). BUT! you should be aware of this action and be prepared to different memory problems where the various transactions will complain about memory shortage

2) leave everything as it is and run with /3GB (also /USERVA=2900) and 16GB of RAM

3) simply add one more 64-bit DI to your landscape and make it accessible via logon group (CI should not be public for users), this will allow you to have small CI and does not limit the transactions in their memory requests. Plan upgrade to 64-bit (see also note 996600) for future.

best regards