Java startup VERY SLOW on PI7.1 w EHP1 sp5

[Former Member]

Gurus,

We just did a brand-new install of PI7.1 w EHP1 sp5. This is AIX 6.1 64-bit with oracle 11g. Like I said, the abap/java stacks have been patched to sp5.

Now when i restart SAP, the java takes FOREVER to start. It goes quickly to "Starting apps", logs a few more lines in dev_server0 then ...that's it.

I do see this error in the j2ee/cluster/server0/log/applications_00.0.log

MasterMethod: An error occurred during the System Landscape Directory synchroniz

ation: CIM_ERR_FAILED: HTTP

And in the same dir, the defaultTrace_00.1.trc I see lots of errors:

Warnings:

The metamodelrepository container reports that doesn't support parallel operations, which slows down the deploy, update

and remove operations with applications.

Solution: Please contact the container holder to fix these warnings.#

#2.0^H#2011 01 15 13:48:21:405#0-600#Error#com.sap.esi.esp.service.server.ESPServiceInterfaceAbstract#

#BC-ESI-WS-JAV#tc_esiesp~srv#7E38378AFB0F000D000000000013C07E#6805050000001496##com.sap.esi.esp.service.server.ESPServiceI

nterfaceAbstract####51FEC84B20E011E09A097E38378AFB0F#51fec84b20e011e09a097e38378afb0f#51fec84b20e011e09a097e38378afb0f#0#Se

rvice Runner [tc_esiesp~srv]#Plain##

There is problem reading the hostname from the ClusterManager. This could lead to improper wsdl links.#

#2.0^H#2011 01 15 13:48:50:246#0-600#Error#com.sap.esi.esp.service.server.ESPServiceInterfaceAbstract#

#BC-ESI-WS-JAV#tc_esiesp~srv#7E38378AFB0F0012000000120013C07E#6805050000000474##com.sap.esi.esp.service.server.ESPServiceI

nterfaceAbstract####685B4FF820E011E0AD3B00000067D63A#685b4ff820e011e0ad3b00000067d63a#685b4ff820e011e0ad3b00000067d63a#0#De

ploy Parallel Start Thread#Plain##

The stored configuration is not compatible with the new deployables, for webservice interface : -75155fbc:10ad5cf7c56:-7fff

_KMIndexSvcIt has different operation count : 7 than before : 6#

#2.0^H#2011 01 15 13:49:01:245#0-600#Info#com.sap.archtech.daservice#

#BC-ILM-DAS#sap.com/tc_TechSrvXML_DAS#7E38378AFB0F0015000000020013C07E#6805050000000841#sap.com/tc_TechSrvXML_DAS#com.sap

.archtech.daservice#J2EE_ADMIN#0##685B4FF820E011E0AD3B00000067D63A#685b4ff820e011e0ad3b00000067d63a#685b4ff820e011e0ad3b000

00067d63a#0#Application [6]#Plain##

MasterMethod: An error occurred during the System Landscape Directory synchronization: CIM_ERR_FAILED: HTTP response code:

503 Service Unavailable

[EXCEPTION]

com.sap.sld.api.wbem.exception.CIMCommunicationException: CIM_ERR_FAILED: HTTP response code: 503 Service Unavailable

But again, all this aside, it's like the J2EE/java instance just stops logging altogether and then stays at "startup apps" forever. At least i'd like to see dev_server0 or some other java related log in the WORK dir to be logging something.

That JSTART process is still running, but not using nearly the high CPU it was using when it got to the starting apps part.

I saw a previous post about the applicationthreadmanager and bumping it up to 300 threads. but in my system, it is already set like that in configtool.

Thanks

NICK

Any pointers greatly appreciated.

[marksmyth · Accepted solution]

Hello

We will forward this thread to the Netweaver Administrator forum. You should get a better response on that forum.

Regards

XI/PI Moderator

[Former Member]

Like I said, the abap/java stacks have been patched to sp5

It is possible that the first start after applying patches is taking much longer than usual. It could be more than an hour. During that time java code is synced between the database and the filesystem. Typical is relatively high cpu/database activity.

Cheers Michael

[Former Member]

Thanks. Turns out there was some shared memory segment hanging around after the "stopsap". When I removed it using ipcrm -s <semaphoreID>, and then issued startsap, it came up quick.

--NICK

[Former Member]

Ok, good to hear, btw there usually is a dedicated sap command called cleanipc to cleanup the shared memories. It is a good practice to use it after patching the sap kernel. Just in case you didn't know...

sidadm> cleanipc <instnr> remove
sidadm> cleanipc <scs_instnr> remove

Cheers Michael