---

Hallo Teamcenter 4Tier Anwender,
aufgrund einer bevorstehenden Umstellung auf Teamcenter 8 UA 4Tier möchte ich nach Optimierungspotential suchen bzw. Tuning - Paramater ausfindig machen, um die neue Instanz von Anfang an performanter einrichten zu können. Speziell bei der Einrichtung ORACLE <-> ORACLE .NET LISTENER <-> JBOSS <-> Pool Manager TreeCache sehe ich hier einiges an Optimierungspotential. So ist aus meiner Sicht eine Teamcenter Standard Installation nicht auf optimale Leistung abgestimmt. Bei uns habe ich zum Beispiel festgestellt, dass die Antwortszeiten und die Stabilität der 4Tier Architektur sehr stark von den gwählten Einstelungen abhängen. Zum Beispiel:
- LOCALHOST: Hier habe ich festegestellt, dass man aufpassen sollte, dass in der Windows hosts Dateie der lokale Server auch mit der localhost IP 127.0.0.1 aufgelistet ist, wenn Datenbank und Web Server auf einem Rechner laufen. So wird das Netzwerk zum Teil umgangen. Andernfalls erfolgt jeder Datentransfer erst über das gesamte Netzwerk.
- ORACLE LISTENER: Hier habe ich festgestellt, dass es einen erheblichen Untershied macht, wenn man auch hier auf die Umgehung des Netzwerks achtet.
- JBOSS: Nur mit der Server JVM läuft der auch stabil im produktiven Einsatz. Hier sind die weiteren Optimierungsparameter sehr zahlreich.
- POOL MANAGER: Hier muss man nach meiner Ansicht auf die Time Out Settings achten, da sonst Verbindung unnötig abgebrochen werden.

In diesem Bereich würde ich gerne verschiedene Einstellungen und Szenarien hinsichtlich der möglichen Listungssteigerungen diskutieren bzw. mit anderen Einstellungen abgleichen.

1. Die Windows "hosts" Datei unter C:\WINDOWS\system32\drivers\etc
Hier habe ich den IP Verweis unseres Servers umgestellt von der realen IP auf die LOOPBACK IP 127.0.0.1
#X.X.X.X  vmserv2
127.0.0.1  vmserv2
Und schon war eine Beschleunigung bei fast allen Aktivitäten messbar, bei denen Komponenten zusammspielen, die auf den Server vmserv2 verweisen. Da alle diese Komponenten auf dem gleichen Server arbeiten brachte das schon mal einen Geschwindigkeitseffekt

2. ORACLE sqlnet.ora, tnsnames.ora, listener.ora unter ORACLE_HOME\Network\Admin
Derzeit nutze ich folgende Einstellungen im Test
sqlnet.ora:
SQLNET.AUTHENTICATION_SERVICES= (NTS)
DEFAULT_SDU_SIZE=8192
SQLNET.EXPIRE_TIME=10
disable_oob=ON
BREAK_POLL_SKIP=10000
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

tnsnames.ora:
TC =
  (DESCRIPTION =
    (ADDRESS_LIST=
    (ADDRESS =
(PROTOCOL = BEQ)
(PROGRAM = oracle)
(ARGV0 = oracletc)
(ARGS = '(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))')
)
)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = tc)
    )
  )

EXTPROC_CONNECTION_DATA =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
    )
    (CONNECT_DATA =
      (SID = PLSExtProc)
      (PRESENTATION = RO)
    )
  )

listener.ora:
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (epc_disabled = TRUE)
      (SDU = 8192)
      (TDU = 8122)
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = d:\oracle10.2)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (SID_NAME = tc)
      (GLOBAL_DBNAME = tc)
      (ORACLE_HOME = d:\oracle10.2)
    )
  )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0)(SEND_BUF_SIZE = 15290)(RECV_BUF_SIZE = 15290))
    )
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = vmserv2)(PORT = 1521)(SEND_BUF_SIZE = 15290)(RECV_BUF_SIZE = 15290))
    )
  )
Speziell die SDU / TDU Parameter scheinen spürbare Beschleunigungen zu bringen

3. JBOSS
Wenn man den JBOSS über das zusätzliche JBOSS native Package als Windows Dienst implementiert scheinen sich ebenfalls Beschleunigungseffekte zu ergeben. Zudem habe ich derzeit folgende JVM Optionen in der run.bat im JBOSS_HOME\bin im Einsatz

set JAVA_OPTS=
rem use the server Java Virtual Machine
set JAVA_OPTS=%JAVA_OPTS% -server
rem set the thread priority
rem set JAVA_OPTS=%JAVA_OPTS% -XX:ThreadPriorityPolicy=1
rem set the Heap sizes
set JAVA_OPTS=%JAVA_OPTS% -Xmx256m -Xmx256m
rem set the mem size ratio for the younger generation
set JAVA_OPTS=%JAVA_OPTS% -XX:NewRatio=2
rem set the mem size ratio for the Eden Space
set JAVA_OPTS=%JAVA_OPTS% -XX:SurvivorRatio=6
rem Assign fixed space for each Thread
set JAVA_OPTS=%JAVA_OPTS% -XX:+UseTLAB
set JAVA_OPTS=%JAVA_OPTS% -XX:TLABSize=64k
rem how many carbage coolections have to be passed
rem set JAVA_OPTS=%JAVA_OPTS% -XX:MaxTenuring-Threshold=32
rem set mem size for the permanent generation
rem -XX:MaxPermSize=64m
rem Use New Parallel Garbage Collection
rem set JAVA_OPTS=%JAVA_OPTS% -XX:+UseParNewGC
set JAVA_OPTS=%JAVA_OPTS% -XX:+UseParallelGC
set JAVA_OPTS=%JAVA_OPTS% -XX:ParallelGCThreads=2
rem set the garbage collection time
set JAVA_OPTS=%JAVA_OPTS% -Dsun.rmi.dgc.client.gcInterval=3600000
set JAVA_OPTS=%JAVA_OPTS% -Dsun.rmi.dgc.server.gcInterval=3600000
rem ignore System.gc() requests
set JAVA_OPTS=%JAVA_OPTS% -XX:+DisableExplicitGC
rem use the Aggressive Heap memory
set JAVA_OPTS=%JAVA_OPTS% -XX:+AggressiveHeap
set JAVA_OPTS=%JAVA_OPTS% -XX:+AdjustConcurrency
set JAVA_OPTS=%JAVA_OPTS% -Xconcurrentio

rem Activate the Garbage Collection Report
rem set JAVA_OPTS=%JAVA_OPTS% -XX:+PrintHeapAtGC
rem set JAVA_OPTS=%JAVA_OPTS% -XX:+PrintGCTimestamp
rem set JAVA_OPTS=%JAVA_OPTS% -Xloggc:C:\temp\GCdata.log

Auch habe ich festgestellt, dass man immer die letzte JVM als Basis einsetzen sollte. Derzeit ist das bei mir die JVM Version: 17.0-b17 (Sun Microsystems Inc.) aus dem Java SE Development Kit 6u21 Win32 Package.

4. Pool Manager (JBOSS TreeCache)
Hier habe ich noch nichts signifikates gefunden. Derzeit arbeite ich mit den folgenden Einstellungen für JVM in der mgrstartc.bat
set JAVA_OPTS=%JAVA_OPTS% -server -Xms256m -Xmx256m
set JAVA_STACK_SIZE=-Xss64k

In der Testumgebung sind derzeit folgende Parameter inder .properties im Einsatz
CACHE_CONFIG_PATH=TreeCacheTCPtc8test.xml
POOL_ID=PoolA
PROCESS_MAX=30
PROCESS_WARM=1
PROCESS_TARGET=0000 4
MAX_CPU_LOAD=80
ENABLE_CPU_LIMIT_CHECK=0
CPU_CHECK_INTERVAL=10
LOGINS_PER_MINUTE=0
JMX_HTTP_ADAPTOR_PORT=8082

In der TreeCache*.xml steht derzeit
    <attribute name="ClusterConfig">
      <config>
        <TCP start_port="17800" end_port="17800" sock_conn_timeout="2000" />
        <TCPPING initial_hosts="localhost[17810]" port_range="1" timeout="30000" num_initial_members="1" up_thread="true" down_thread="true" />
        <MERGE2 min_interval="5000" max_interval="10000" />
        <FD_SOCK />
        <VERIFY_SUSPECT timeout="3000" down_thread="false" up_thread="false" />
        <pbcast.NAKACK down_thread="true" up_thread="true" gc_lag="100" retransmit_timeout="3000" />
        <pbcast.STABLE desired_avg_gossip="20000" down_thread="false" up_thread="false" />
        <pbcast.GMS join_timeout="1250" join_retry_timeout="2000" shun="false" print_local_addr="true" down_thread="true" up_thread="true" />
        <pbcast.STATE_TRANSFER up_thread="true" down_thread="true" />
      </config>
    </attribute>

Hat jemand signifikant andere Einstellungen und glaubt, dass sein System eine super Perfomance hat. Ich würde gerne andere Parameter testen.

Zudem habe ich bisher noch keine einfache Lösungen gefunden um die Performance des Systems genauer Monitoren zu können. Derzeit läuft hier sehr viel über Trial and Error. Ich würde jedoch gerne verschiedene Bausteine der Umgebung mittel Parser - Skripten und GNUPLOT oder anderen Werzeugen grafisch darstellen.

So würde ich gerne die Antwortszeiten der verschiedenen Bausteine abprüfen. Dden Netzwerktransfer analysieren. Hat jemand hierzu kostenlose Tools im Einsatz?

Gruß

Matthias

[Diese Nachricht wurde von MAhrens am 03. Feb. 2011 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

VisualJVM.JPG

Hallo 4Tier Anwender,

Wenn man in der run.bat des JBOSS die JAVA Optionen um folgende Parameter erweitert, wird die JMX Remote Steuerung der Java Virtual Maschine aktiviert. Der gewählte Port (hier 1616) sollte vorher natürlich mit netstat abgeprüft werden, ob er schon durch eine andere Anwendung belegt ist.

set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote.port=1616
set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote.authenticate=false
set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote.ssl=false

Zudem muss man nun noch in dem Management Verzeichnis der verwendeten JDK die Passwort Datei erstellen bzw. anpassen (Ein Template liegt bereits vor). Die Eigenschaften der Passwortdatei sollten so eingesetllt sein, dass der JBOSS User auch der Eigentümer der Passwort Datei ist. Er muss volles Schreib- und Änderungrecht auf der Datei besitzen. Alle anderen Anwender müssen aus dem Berechtigungsprofil für diese Datei entfernt werden.

jdk\jre\lib\management\jmxremote.password

Nun sollte der JBOS wie gewohnt ohne Probleme starten.

Auf einem anderen Rechner mit neuerer JAVA JDK Installation findet man im bin Verzeichnis die Datei jvisualvm.exe, welche die Java Visual VM Anwendung startet. Man kann diese aber auch einzeln von ORACLE herunter laden. In dieser Anwendung kann man nun den JBOSS Server als neuen remote Host eintragen und über den vorher gewählten Port (Hier 1616) ansprechen.

Als Resultat erhält man eine grafische Laufzeitübersicht der JBOSS Java VM inclusive der Heap Speicherbelegung und der Prozessübersicht. Damit kann man nun ins Fine - Tuning der Heap Size Parameter für den nächsten JBOSS Start gehen.

Siehe Bild

Gruß

Matthias

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Danke für den sehr intressannten Beitrag!
Muss ich mir mal genauer anschaun...

------------------
Gruß Matthias
------------------------------------
ICQ: 163190295

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Teamcenter Administratoren,

anbei einige Infos zur Steuerung der 4Tier Umgebung. Da ich gerade den Umstieg auf Teamcenter 8 vorbereite greife ich einige ältere Themen wieder auf. So u.a. auch das Skript gestützte Starten und Stoppen des JBoss Web Application Servers.

In unserer Testumgebung habe ich dem JBoss als JBoss native Service eingerichtet, so dass er als normaler Windows Dienst gestartet werden kann. Laut Handbuch soll diese einige Verbesserungen in der HTTP Kommunikation mit sich bringen.

Nun arbeite ich derzeit am Aufbau einer automatischen Startroutine für die verschiedenen Teamcenter - Komponenten. So kann man nun den JBOSS aus einem DOS Skript starten über
...
net start "JBoss Application Server 5.0"
...
wobei hier auf die genaue Bezeichnung des Windows Dienstes geachtet werden muss.

Um nun den PoolManager in Abhängigkeit starten zu können, ist es notwendig zu wissen, wann der JBoss mit seinem Startvorgang fertig ist und der PoolManager (TreeCache) angebunden werden kann. Hierzu kann man das twiddle.bat Skript im JBoss bin Verzeichnis nutzen. Aus einem DOS Fenster ruft man nun
...
twiddle -s SERVER:PORT get "jboss.system:type=Server" Started
...
auf. Diese Abfrage liefert den folgenden String zurück, wenn das Sytstem komplett gestartet wurde:
...
Started=true
...
Man muss vorher aber die JAVA_HOME Umgebungsvariable richtig setzen und das twiddle.bat aus dem JBOss Home\bin Verzeichnis starten. Man sollte auch auf die richtigen Werte für SERVER und PORT achten. SERVER ist der Windows Computername auf dem der JBoss läuft. PORT ist der JNP RMI Port des JBoss, über die er Kommandos entgegen nehmen kann. Diesen Port kann man in der JBoss Konfigurationsdatei jboss-service.xml finden, welche im JBOSS_HOME\server\default\conf Verzeichnis liegt. Dort sollte man nach folgendem Eintrag suchen:
...
<mbean code="org.jboss.naming.NamingService"
      name="jboss:service=Naming"
      xmbean-dd="resource:xmdesc/NamingService-xmbean.xml">

<attribute name="Port">1097</attribute>
      <!-- The bootstrap JNP server bind address. This also sets the default
        RMI service bind address. Empty == all addresses
      -->
...
Im vorliegenden Beispiel ist der Port auf 1097 festgelegt worden.

Nun will man vielleicht zu Wartungszwecken den JBoss saueber herunterfahren. Im Vergleich zum häufig verwendeten STRG+C im DOS Fenster oder zum einfachen Beenden des Windows Dienstes bietet sich die interne JBoss ShutDown Methode an. Diese fährt den JBoss sauber herunter und zieht im nicht einfach den Stecker raus. Das kann man zum einen über die Webseite des JBOss erreichen MBean "jboss.system" / "type=Server" / "Invoke shutdown". Man kann aber auch das folgende twiddle Kommando in einer entsprechenden DOS Box nutzen:
...
twiddle -s SERVER:1097 invoke "jboss.system:type=Server" shutdown
...

Diese Befehel funktionieren natürlich so nur, wenn der JBOSS nicht über eine Benutzerkennung abgesichert ist.

Gruß

Matthias

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Tc_Menu_PSTART.png

Hallo Teamcenter Administratoren,

Als kleiner Tip:

Nach einiger Zeit sammeln sich auf dem Server viele kleine Batch Dateien an, die man für die vielfältigsten Aufgaben nutzt (z.B. Starten der Instanzen, Abfragen des FMS, Clearlocks, etc.). Aus dem Portable USB Application Bereich gibt es das schöne Tool PStart, mit dem man sich schöne Menüstrukturen bilden kann. Dieses kleine Tool kommt mit einer einfache .exe und einer xml Definitionsdatei aus. Wenn man dann noch einige Icons einbaut, so kann man sich eine nette Teamcenter Management Konsole aufbauen.
www.pegtop.de/start/

Gruß

Matthias

[Diese Nachricht wurde von MAhrens am 05. Feb. 2011 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

WireShark.JPG

Hallo Teamcenter Administratoren,

zur Analyse des Netzwerkcerkehrs zwischen den verschiedenen Client / Server Komponenten kann man aus meiner Sicht gut das WireShark Tool einsetzen. Hiermit kann man den ganzen Netzwerkverkehr einer Netzwerkkarte nach verschiedenen Kriterien filtern, analysieren und visualisieren. Somit kann man zum Beispiel den FMS Traffic filtern, etc.

Das ganze ist auch Remote - fähig. D.h. auf dem Server wird ein NetDeviceSniffer Treiber installiert und ein Domain Service gestartet. Mit der WireShark Software kann man dann auf einem Client den Netzwerkverkehrs des Servers in Ruhe analysieren und überwachen.

Gruß

Matthias

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Administratoren,

eine kleine Anmerkung zur Verwendung des "LoopBack" Mechnismus. Ich habe festgestellt, dass der 4Tier Distribution Server sich per default an die erste günstige IP Adresse der Maschine bindet, auf die er arbeitet. Im LoopBack ist dass dann die 127.0.0.1. Diese wird wunderbar an jeden OTW Client übermittelt, der dann ebenfalls bei sich selber einen laufenden Distribution Server Dienst sucht. Das geht natürlich so nicht.

Wenn man aber in der start_server.bat des Distribution Server Stage webapp_root Verzeichnisses den folgenden Eintrag erweitert...
java -cp dist_server.jar com.teamcenter.install.otw.ds.DistributionServer

in Richtung

java -Djava.rmi.server.hostname=XXX.XXX.XXX.X -cp dist_server.jar com.teamcenter.install.otw.ds.DistributionServer

kann man den Distriubution Server gezielt an die phyiscalische Netzwerk IP des Servers binden. Da diese den OTW Clients übermittelt wird, finden diese dann auch den Weg zum zentralen Distribution Server. Somit funktioniert nun das 4Tier OTW auch wieder.

Gruß

Matthias

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo 4Tier Administratoren,

in unserer Installation haben wir festgestellt, dass speziell in der WAN Distanz sich Client Sessions nach einer gewissen Zeit verabschieden. Es sieht so aus, dass der PoolManager / JBOSS TreeCache Parameter SOFT_TIMEOUT_STATELESS hierfür verantwortlich ist, der per default auf 1200 Sekunden steht. Mann kann diesen zwar manuell über die JDMK Web Konsole anpassen. Besser ist, wenn man diesen aber permanent einstellt, so das beim nächsten Systemstart ein korrigierter Wert angezogen wird.

Hierzu erstellt man im JBOSS /bin Verzeichnis eine Datei globalPoolConfig.properties Textdatei.

In unserem Fall hat diese den folgenden Inhalt:
ASSIGNMENT_TIMEOUT=60
CACHE_CONFIG_PATH=TreeCacheTCP.xml
PROCESS_MAX_PER_USER=30
HARD_TIMEOUT_EDIT=28800
HARD_TIMEOUT_READ=28800
HARD_TIMEOUT_STATELESS=28800
QUERY_TIMEOUT=0
SOFT_TIMEOUT_EDIT=28800
SOFT_TIMEOUT_READ=28800
SOFT_TIMEOUT_STATELESS=10800
USER_TIMEOUT_STATELESS=0

Damit wird das Soft Timeout auf 3 Stunden angehoben.

Gruß

Matthias

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP