Quick Analysis Guide
Dieser Artikel befasst sich mit On-Premise-Umgebungen mit Performance-Problemen, und der Leitfaden enthält detaillierte Schritte zur Analyse.
Wenn das System einfriert (sich aufhängt) oder insgesamt schlecht funktioniert, befolgen Sie bitte die unten beschriebenen Schritte. In den meisten Fällen reicht es aus, die einfachen Analyseschritte zu befolgen, um die Ursache des Problems zu ermitteln. Diese Schritte müssen durchgeführt werden, bevor das System neu gestartet wird.
Abschließend erstellen Sie bitte ein Ticket in unserem Service Desk und fügen diesem die Protokolldateien und die Ergebnisse der Analyseschritte bei.
Important Parameter Checks
Java Parameters
Der Java-Parameter max heap muss auf einen ausreichend hohen Wert gesetzt werden (>= -Xmx2700m). Ist der Wert zu niedrig, werden im GC-Protokoll, das immer konfiguriert sein sollte, umfangreiche Full GC-Aktivitäten angezeigt. (e.g. for Oracle JDK: -verbose:gc -XX:+PrintGCDetails -Xloggc:<path to log directory>/gc.log).
Für die maximale Heap-Size empfehlen wir mindestens 2700m. Je nach Aktivität und Anzahl der gleichzeitigen Nutzer kann es erforderlich sein, einen deutlich höheren Wert festzulegen (weitere Informationen finden Sie unter Systemanforderungen).
Tomcat Parameters
Der Parameter maxThreads in der Datei server.xml für den Connector muss mindestens auf die Anzahl der erwarteten gleichzeitigen LMS-Benutzer eingestellt werden. Standardmäßig gibt es keine solche Parametereinstellung und der Wert ist 200. Um ihn auf z.B. 1200 zu erhöhen, fügen Sie maxThreads=„1200“ in das Connector-Tag ein.
Als Faustregel gilt, dass der Parameter maxActive in der JDBC-Konfiguration der Datenbank auf die Hälfte von maxThreads gesetzt werden sollte. Ein zu kleiner Wert für maxActive kann leicht zu einem Systemstillstand führen. Bei Oracle sollten die Prozesse und bei PostgreSQL der Parameter MAX_CONNECTIONS etwas höher als die Summe von maxActive aller Knoten eingestellt werden, um einige freie Verbindungen für den direkten DBA-Zugriff zu haben.
Betrieb des LMS mit MS SQL Server
Ad-hoc Analysis
Bitte führen Sie die folgenden Schritte aus, bevor der ILS-Anwendungsserver neu gestartet wird.
Schritt 1: Datenbankabfrage
Führen Sie die Select-Anweisung auf der SQL Server Master-Datenbank aus und speichern Sie die Ausgabe. Falls die Instanz auch Datenbanken von anderen Anwendungen hostet, können Sie den kommentierten Datenbankfilter „and db_name(s.database_id) = “ aktivieren, um die Ausgabe auf die ILS-Datenbank zu beschränken.
select db_name(s.database_id) as dbname, c.session_id, qt.text,
case when rq.total_elapsed_time is null then 0 else rq.total_elapsed_time end as total_elapsed_time,
rq.cpu_time, rq.status, rq.blocking_session_id, rq.wait_type, rq.wait_time,
rq.wait_resource, rq.open_transaction_count, rq.transaction_isolation_level
from sys.dm_exec_connections c CROSS APPLY sys.dm_exec_sql_text(c.most_recent_sql_handle) as qt
left outer join sys.dm_exec_requests rq on c.session_id = rq.session_id,
sys.dm_exec_sessions s
where c.session_id = s.session_id and s.database_id > 4 --and db_name(s.database_id) = <ils_db_name>
order by s.database_id, total_elapsed_time desc;
Bitte stellen Sie sicher, dass die Ausgabe der Spalte „text“ nicht nach 256 Zeichen abgeschnitten wird. Eine Möglichkeit, dies sicherzustellen, besteht darin, die Anweisung im SQL Server Management Studio auszuführen und die Ausgabe auf der Registerkarte „Ergebnisse“ mit Copy&Paste zu speichern. Bitte führen Sie auch die SQL-Anweisungen aus dem zweiten Paragraphen aus. Diese Anweisungen können aber auch nach einem Neustart des Anwendungsservers ausgeführt werden.
Schritt 2: Überprüfung der CPU-Auslastung
Werfen Sie einen Blick auf die CPU-Auslastung sowohl der LMS-Anwendung als auch des Datenbankservers (z. B. mit taskmgr unter Windows). Notieren Sie sich das.
Schritt 3: Speichern der Protokolldateien
Speichern Sie die Log-Dateien clix.log und gc.log sowie die Log-Datei des Webservers (z.B. access.log bei Apache) und alle Log-Dateien der Servlet-Engine.
Wenn Sie TOMEE als Servlet-Engine verwenden, suchen Sie in der TOMEE-Logdatei stdout log nach der Zeichenfolge „Increase max Threads“. Eine Meldung wie „Alle Threads (200) sind derzeit beschäftigt und warten. Increase maxThreads (200)“ bedeutet, dass der Systemstillstand durch einen zu niedrigen Wert des TOMEE-Parameters maxThreads verursacht wurde. Erhöhen Sie dann den Wert dieses Parameters.
Schritt 4: Einen Java-Thread-Dump erstellen
Bei einem Systemstillstand mit unklarer Ursache versuchen Sie, einen Java Thread Dump (Java Stack Trace) zu erstellen.
jstack <pid> > threaddump.txt
wobei <pid> durch die Prozess-ID des Java-Prozesses ersetzt werden muss. Falls Tomcat als Windows-Dienst läuft, kann eine Fehlermeldung wie „nicht genügend Speicherplatz für diesen Befehl verfügbar“ auftreten. In diesem Fall muss jstack mit Hilfe des PSTools-Befehls psexec ausgeführt werden, wie hier gezeigt:
C:\PSTool> psexec –s c:/Programs/…/bin/jstack <pid> > threaddump.txt
Unter Linux / Unix können Sie einen Thread-Dump auch mit kill -3 auf der Prozess-ID des Java-Prozesses erstellen und der Thread-Dump wird in eine der Protokolldateien des Anwendungsservers geschrieben.
Post-Analysis
Bei schlechter Performance kann der folgende Analyseschritt auch nach dem Neustart des LMS-Applikationsservers durchgeführt werden, sofern der SQL-Server noch nicht neu gestartet wurde.
Abfrage der Datenbank
Bitte führen Sie die folgenden SQL-Anweisungen aus und speichern Sie die Ausgabe:
select name, snapshot_isolation_state, is_read_committed_snapshot_on from sys.databases;
select * from sys.dm_os_sys_info;
SELECT TOP 100 total_elapsed_time / 1000 as total_elapsed, total_worker_time / 1000 as total_cpu,
total_elapsed_time / qs.execution_count / 1000 as averaged_elapsed, total_physical_reads as readIOs, qs.execution_count as exec_count,
SUBSTRING (qt.text,qs.statement_start_offset/2+1, (CASE WHEN qs.statement_end_offset = -1 THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2 ELSE qs.statement_end_offset END - qs.statement_start_offset)/2 + 1) as query,
DB_NAME(qt.dbid) as dbname
FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
ORDER BY total_elapsed_time DESC;Bitte stellen Sie sicher, dass die Ausgabe der Spalten nicht nach 256 Zeichen abgeschnitten wird. Eine Möglichkeit, dies sicherzustellen, besteht darin, die Anweisungen im SQL Server Management Studio nacheinander auszuführen und die Ausgabe auf der Registerkarte „Ergebnisse“ mit Copy&Paste zu speichern.
Betrieb des LMS mit Oracle Datenbank
Ad-hoc Analysis
Die folgenden Aktionen müssen durchgeführt werden, bevor der LMS-Anwendungsserver neu gestartet wird.
Schritt 1: Datenbankabfrage
Führen Sie die folgende SQL-Anweisung unter dem ORACLE-Benutzer „system“ aus und speichern Sie die Ausgabe.
set linesize 10000;
set pagesize 1000;
select s.server, substr(s.username,1,20) as username, s.sid, (select l1.sid from v$lock l1, v$lock l2 where l2.sid = s.sid and l1.block = 1 and l2.request > 0 and l1.id1 = l2.id1 and l1.id2 = l2.id2) as bsid, s.status, 0 as aflag, to_char(substr(sql_fulltext,1,4000)) as sql, to_char(substr(sql_fulltext,4001,4000)) as sql_part2, to_char(substr(sql_fulltext,8001,4000)) as sql_part3
from v$session s, v$sqlarea t, all_users u
where s.sql_hash_value = t.hash_value and s.sql_address = t.address and u.oracle_maintained = 'N' and u.user_id = s.user#
union
select s.server, substr(s.username,1,20) as username, s.sid, null as bsid, s.status, 1 as aflag, to_char(substr(sql_fulltext,1,4000)) as sql, to_char(substr(sql_fulltext,4001,4000)) as sql_part2, to_char(substr(sql_fulltext,8001,4000)) as sql_part3
from v$session s, v$sqlarea t, all_users u
where s.sql_hash_value = 0 and s.prev_hash_value = t.hash_value and s.prev_sql_addr = t.address and u.oracle_maintained = 'N' and u.user_id = s.user#
union
select 'summary', 'zsort' as username, (select current_utilization from v$resource_limit where resource_name = 'sessions'), (select max_utilization from v$resource_limit where resource_name = 'sessions'), (select limit_value from v$resource_limit where resource_name = 'sessions'), (select count(*) from v$session) as sid, '' as sql_part1, '' as sql_part2, '' as sql_part3
from dual
order by username, aflag;Schritt 2: Überprüfung der CPU-Auslastung
Werfen Sie einen Blick auf die CPU-Auslastung der ILS-Anwendung und des Datenbankservers (z. B. mit taskmgr unter Windows). Notieren Sie sich das.
Schritt 3: Speichern der Protokolldateien
Speichern Sie die Logdateien clix.log und gc.log sowie die Logdatei des Webservers (z.B. access.log bei Apache) und alle Logdateien der Sevlet-Engine.
Wenn Sie TomEE als Servlet-Engine verwenden, suchen Sie nach der Zeichenfolge „Increase maxThreads“ in der TomEE-Protokolldatei stdout log. Eine Meldung wie „All threads (200) are currently busy, waiting. Increase maxThreads (200)“ bedeutet, dass der Systemstillstand durch einen zu niedrigen Wert des TomEE-Parameters maxThreads verursacht wurde. Erhöhen Sie dann den Wert dieses Parameters.
Schritt 4: Einen Java-Thread-Dump erstellen
Bei einem Systemstillstand mit unklarer Ursache versuchen Sie, einen Java Thread Dump (Java Stack Trace) zu erstellen.
jstack <pid> > threaddump.txt
wobei <pid> durch die Prozess-ID des Java-Prozesses ersetzt werden muss. Falls Tomcat als Windows-Dienst läuft, kann eine Fehlermeldung wie „nicht genügend Speicherplatz für diesen Befehl verfügbar“ auftreten. In diesem Fall muss jstack mit Hilfe des PSTools-Befehls psexec ausgeführt werden, wie hier gezeigt:
C:\PSTool> psexec –s c:/Programs/…/bin/jstack <pid> > threaddump.txt
Unter Linux / Unix können Sie einen Thread-Dump auch mit kill -3 auf der Prozess-ID des Java-Prozesses erstellen und der Thread-Dump wird in eine der Protokolldateien des Anwendungsservers geschrieben.
Post-Analysis
Im Falle einer schlechten Leistung können die folgenden Analyseschritte jederzeit durchgeführt werden.
Schritt 1: Datenbankabfrage
Führen Sie die folgende SQL-Anweisung unter dem ORACLE-Benutzer „system“ aus und speichern Sie die Ausgabe.
set linesize 1000;
set pagesize 1000;
select * from
(select parsing_schema_name, round(elapsed_time/1000) as elaptotal, round(elapsed_time/executions/1000) as elapexec,
round(cpu_time/1000) as cputotal, round(cpu_time/executions/1000) as cpuexec, round(user_io_wait_time/1000) as iowaittotal,
buffer_gets, disk_reads, executions, last_active_time,
to_char(substr(sql_fulltext,1,4000)), to_char(substr(sql_fulltext,4001,4000)), to_char(substr(sql_fulltext,8001,4000))
from v$sql
where parsing_schema_name not in ('SYS','SYSTEM','SYSMAN','MDSYS','CTXSYS','EXFSYS','DBSNMP','DEC_REP','XDB') and executions > 0
order by elaptotal desc)
where rownum <= 100;Schritt 2: Elementare Oracle-Parameter und Statistiken
Führen Sie die folgende SQL-Anweisung unter dem ORACLE-Benutzer „system“ aus und speichern Sie die Ausgabe.
set pagesize 20;
select substr(name,1,30) as name, substr(value,1,30) as value from v$parameter
where name in ('processes', 'shared_pool_size', 'memory_target', 'sga_target', 'pga_aggregate_target', 'optimizer_features_enable')
union
select 'db_cache_size_MB' as name, cast(current_size as varchar(30)) from v$buffer_pool
union
select substr(name,1,30) as name, cast(value as varchar(30)) from v$sysstat
where name in ('db block gets', 'consistent gets', 'physical reads')
union
select substr(name,1,30), cast(value as varchar(30)) from v$sysstat
where name like 'sort%';Schritt 3: Oracle SQL-Optimierungsstatistiken
Falls die Oracle SQL Optimizer-Statistiken nicht regelmäßig aktualisiert werden, geben Sie den folgenden Befehl in das Oracle SQL-Dienstprogramm ein (ersetzen Sie „ILSDB“ durch den Oracle-Benutzer der ILS-Datenbank):
exec dbms_stats.gather_schema_stats('ILSDB',null,false,'FOR ALL COLUMNS SIZE 1', null,'DEFAULT',true);Betrieb des LMS mit PostgreSQL Datenbank
Ad-hoc Analysis
Die folgenden Aktionen müssen durchgeführt werden, bevor der ILS-Anwendungsserver neu gestartet wird.
Schritt 1: Datenbankabfrage
Führen Sie die folgende SQL-Anweisung in der ILS-Datenbank aus und speichern Sie die Ausgabe.
Im Falle einer PostgreSQL-Version kleiner als 13 entfernen Sie die Spalte leader_pid aus der Select-Liste, da sie noch nicht existiert.
select datname, pid, leader_pid, state, xact_start as ta_start, query_start as q_start, wait_event_type, wait_event,
case when wait_event_type = 'Lock' then (select string_agg(cast(pl2.pid as varchar(9)),',') from pg_locks pl, pg_locks pl2 where pa.pid = pl.pid and pl.locktype = pl2.locktype and pl.relation is not distinct from pl2.relation and pl.page is not distinct from pl2.page and pl.tuple is not distinct from pl2.tuple and pl.virtualxid is not distinct from pl2.virtualxid and pl.transactionid is not distinct from pl2.transactionid and pl.classid is not distinct from pl2.classid and pl.objid is not distinct from pl2.objid and pl.objsubid is not distinct from pl2.objsubid
and pl.pid != pl2.pid and not pl.granted and pl2.granted) else null end as blocking_pid,
query
from pg_stat_activity pa
where datname = (select current_database())
order by state, query_start;Schritt 2: Überprüfung der CPU-Auslastung
Werfen Sie einen Blick auf die CPU-Auslastung der ILS-Anwendung und des Datenbankservers (z. B. mit taskmgr unter Windows). Notieren Sie sich das.
Schritt 3: Speichern der Protokolldateien
Speichern Sie die Log-Dateien clix.log und gc.log sowie die Log-Datei des Webservers (z.B. access.log bei Apache) und alle Log-Dateien der Servlet-Engine.
Wenn Sie TomEE als Servlet-Engine verwenden, suchen Sie nach dem String „Increase maxThreads“ in der TomEE-Logdatei stdout log. Eine Meldung wie „Alle Threads (200) sind derzeit beschäftigt, warten. Increase maxThreads (200)“ bedeutet, dass der Systemstillstand durch einen zu niedrigen Wert des TomEE-Parameters maxThreads verursacht wurde. Erhöhen Sie dann den Wert dieses Parameters.
Schritt 4: Einen Java-Thread-Dump erstellen
Bei einem Systemstillstand mit unklarer Ursache versuchen Sie, einen Java Thread Dump (Java Stack Trace) zu erstellen
jstack <pid> > threaddump.txt
wobei <pid> durch die Prozess-ID des Java-Prozesses ersetzt werden muss.Falls TomEE als Windows-Dienst läuft, kann es zu einer Fehlermeldung wie „nicht genügend Speicherplatz für die Verarbeitung dieses Befehls verfügbar“ http://kommen. In diesem Fall muss jstack mit Hilfe des PSTools-Befehls psexec ausgeführt werden, wie hier gezeigt:
C:\PSTool> psexec -s c:/Programme/.../bin/jstack <pid> > threaddump.txt
Unter Linux / Unix können Sie einen Threaddump mit kill -3 auf der Prozess-ID des Java-Prozesses erstellen und der Threaddump wird in eine der Protokolldateien des Anwendungsservers geschrieben.
Post-Analysis
Im Falle einer schlechten Leistung können die folgenden Analyseschritte jederzeit durchgeführt werden.
Schritt 1: Datenbankabfrage
Führen Sie die folgende SQL-Anweisung in der ILS-Datenbank aus und speichern Sie die Ausgabe.
Im Falle einer PostgreSQL-Version kleiner als 13 müssen Sie die Spaltennamen total_exec_time und mean_exec_time in total_time und mean_time ändern.
select query, round(total_exec_time::numeric, 2) AS total_time, calls, round(mean_exec_time::numeric, 2) AS mean,
round((100 * total_exec_time / sum(total_exec_time::numeric) OVER ())::numeric, 2) AS percentage_total_time
from pg_stat_statements
order by total_time desc
limit 100;Damit dies möglich ist, muss der folgende PostgreSQL-Konfigurationsparameter gesetzt sein
shared_preload_libraries='pg_stat_statements'
gesetzt sein und auf der Datenbank wurde nach dem Anlegen folgende Anweisung ausgeführt (siehe Dokument ILS_Installation_Win_TomEE_IIS_DE.pdf Abschnitt 4.1.3.1 und 4.1.3.2):
create extension pg_stat_statements;
Schritt 2: Elementare PostgreSQL-Parameter
Führen Sie die folgende SQL-Anweisung unter dem PostgreSQL-Benutzer „system“ aus und speichern Sie die Ausgabe.
select substring(name,1,30) as name, substring(setting,1,30) as value
from pg_settings
where name in ('max_connections', 'shared_buffers', 'effective_cache_size','work_mem');