sabine79 10 Geschrieben 26. März 2007 Melden Teilen Geschrieben 26. März 2007 Hallo *, System: Windows 2003 SP1 SQL2000 SP4 und Tomcat 5.0.28 laufen im Cluster. RAM 4 GB Java sdk 1.4.2.08 Anfragen laufen direkt an den tomcat. Bei einem Lasttest kam es schon bei 50 "Anfragen" zu Problemen. Was kann ich bei einem erneuten Test mitloggen, damit ich herausbekomme wo genau die Probleme sind? (genügend RAM, verursacht SQL oder Tomcat das Problem, CPU, ...) Kennt jemand Tools/Logmöglichkeiten, mit dennen der Tomcat näher unter die Lupe genommen werden kann? gruß, bine Zitieren Link zu diesem Kommentar
Lian 2.473 Geschrieben 26. März 2007 Melden Teilen Geschrieben 26. März 2007 Hallo, handelt es sich um einen Windows Failover Cluster (MSCS) oder um NLB "Clustering"/LoadBalancing? Oder nutzt Ihr Applikationsclustering auf Tomcat Ebene? Ist das eine reine Windows Umgebung? Lief das schon mal ohne Fehler oder ist das Setup neu? Zitieren Link zu diesem Kommentar
sabine79 10 Geschrieben 27. März 2007 Autor Melden Teilen Geschrieben 27. März 2007 Hallo, es ist ein Windows Failover Cluster mit 2 Notes. Und es passiert nur auf windows2003 sp1. Es wurde vorher nochnie getestet. Die Konstellation kommt von einem externen Dienstleister, der es so verkauft hat. Jetzt liegt es an mir und meinen Kollegen das Problem zu lösen. Zitieren Link zu diesem Kommentar
Lian 2.473 Geschrieben 27. März 2007 Melden Teilen Geschrieben 27. März 2007 Ok. Bei einem Lasttest kam es schon bei 50 "Anfragen" zu Problemen. Was passiert genau? Siehst Du Fehler vom Webserver (HTTP 500?), Java oder im Cluster? Wie ist das ganze eingerichtet? Läuft der Tomcat als Generic Script/App/Service im Cluster? Welche Ressourcen sind im Cluster eingebunden? Schau Dir mal das cluster.log an, ob Du Auffälligkeiten entdeckst: Interpreting the Cluster Log Das cluster.log liegt unter %SYSTEMROOT%\Cluster\cluster.log Zitieren Link zu diesem Kommentar
sabine79 10 Geschrieben 27. März 2007 Autor Melden Teilen Geschrieben 27. März 2007 das Clusterlog ist leider schon überschrieben. Werde es beim nächsten Lasttest wegsichern. Im Cluster sind folgende Ressourcen eingerichtet: Tomcat5 Allgemeiner Dienst SQL-DTC DTC SQL Server Fulltext Microsoft Search Dienstinstanz SQL Server Agent SQL-Server Agent SQL Server SQL-Server SQL-Networkname Netzwerkname SQL-IP-Adresse IP-Adresse Gibt es eine Möglichkeit herauszufinden ob der Speicher, der im Tomcat eingestellt ist, auch tatsächlich vom Tomcat belegt werden kann? (Vielleicht muss ja mehr RAM eingebaut werden) Hinweis: RAM insgesamt 4 GB, kein PAE-Schalter in der Boot.ini gesetzt und der SQL-Server darf den max. Spreicher nehmen ( -> 2GB für SQL und 2 für WIndows, was bekommt der Tomcat?) Zitieren Link zu diesem Kommentar
Lian 2.473 Geschrieben 27. März 2007 Melden Teilen Geschrieben 27. März 2007 Ok, ist der Status der Ressource "Tomcat5 Allgemeiner Dienst" online oder failed während der Fehler auftritt? Was sagt das Tomcat log? Schau mal beim nächsten Test im cluster.log, ob Du Einträge zum Generic Service/Allgemeinen Dienst Tomcat findest. Du kannst das cluster.log ruhig größer ansetzen, auf ~32MB ist kein Problem und liefert Dir zum Troubleshooten mehr Daten. Der Tomcat allokiert vom user mode space, also vom dem 2GB Adressraum, den der SQL auch anspricht. Wieviel Speicherverbrauch siehst Du im Task Manager für den Tomcat? Wird der eingebaute Speicher während der Spitzenzeit voll ausgeschöpft? Zitieren Link zu diesem Kommentar
sabine79 10 Geschrieben 27. März 2007 Autor Melden Teilen Geschrieben 27. März 2007 Tomcat steht immer im Cluadmin auf online. das Tomcatlog muss ich mir erst morgen in der Arbeit ansehn. Das mit der Clusterloggröße ist ein guter Tip. Werde das standardmäßig bei allen Servern erhöhen. Werde mir morgen in der Arbeit das Perfmonlog wegen dem Tomcatspeicher mal ansehen. Laut perfmon sind insgesamt während des Lasttest ca. 1 GB noch frei. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.