Verinice 1.19.1 Performanceprobleme/ DB Inkonsistenz?

StefanieLanger · 4. Mai 2020 um 12:48

Hallo zusammen,

aufgrund von Performanceproblemen habe ich Kapitel 7.2 von "Installation der verinice.PRO-Appliance
" ausgeführt. Hier bekam ich bei create_fk_idx.sql die Meldung:

-bash-4.2$ psql -d verinicedb -f /usr/local/bin/create_fk_idx.sql
psql:/usr/local/bin/create_fk_idx.sql:3: FEHLER:  mehrere Primärschlüssel für Tabelle »allgefaehrdungsumsetzungen« nicht erlaubt
psql:/usr/local/bin/create_fk_idx.sql:7: FEHLER:  mehrere Primärschlüssel für Tabelle »associatedgefaehrdungen« nicht erlaubt
psql:/usr/local/bin/create_fk_idx.sql:10: FEHLER:  mehrere Primärschlüssel für Tabelle »bausteinvorschlag« nicht erlaubt

Dann hängt sich die Putty Anfrage auf. Bei create-indices.sql kommt:

-bash-4.2$ psql -d verinicedb -f /usr/local/bin/create-indices.sql
psql:/usr/local/bin/create-indices.sql:1: FEHLER:  Relation »dependant_id_idx« existiert bereits
psql:/usr/local/bin/create-indices.sql:2: FEHLER:  Relation »dependency_id_idx« existiert bereits
psql:/usr/local/bin/create-indices.sql:3: FEHLER:  Relation »entity_id_idx« existiert bereits
psql:/usr/local/bin/create-indices.sql:4: FEHLER:  Relation »parent_idx« existiert bereits
psql:/usr/local/bin/create-indices.sql:5: FEHLER:  Relation »typedlist_id_idx« existiert bereits
psql:/usr/local/bin/create-indices.sql:6: FEHLER:  Relation »properties_id_idx« existiert bereits
psql:/usr/local/bin/create-indices.sql:7: FEHLER:  Relation »cte_id_idx« existiert bereits
psql:/usr/local/bin/create-indices.sql:8: FEHLER:  Relation »cnatreeelement_id_idx« existiert bereits

Hat jemand eine Idee, wie das zu beheben ist?

MfG Stefanie Langer

jules · 5. Mai 2020 um 09:30

Hallo,

zur Kontrolle können die Skripte /usr/local/bin/check-indices.sql bzw. /usr/local/bin/check_fk_idx.sql genutzt werden.
Die Ausgabe besagt, dass die Indices bereits existieren und können/dürfen nicht nochmal angelegt werden.
Hat sich bezüglich Performance was ergeben?

Gruß
Julia

StefanieLanger · 5. Mai 2020 um 10:18

Hallo Julia,

für check-Indices.sql bekomme ich diese Ausgabe, mit der ich nichts anfangen kann:

bash-4.2$ psql -d verinicedb -f /usr/local/bin/check-indices.sql
   table_name   |       index_name        |    column_name
----------------+-------------------------+-------------------
 cnalink        | dependant_id_idx        | dependant_id
 cnalink        | dependency_id_idx       | dependency_id
 cnatreeelement | cnatreeelement_uuid_key | uuid
 cnatreeelement | entity_id_idx           | entity_id
 cnatreeelement | parent_idx              | parent
 note           | cnatreeelement_id_idx   | cnatreeelement_id
 note           | note_entity_id_key      | entity_id
 permission     | cte_id_idx              | cte_id
 properties     | properties_id_idx       | properties_id
 propertylist   | typedlist_id_idx        | typedlist_id
(10 Zeilen)

bei check_fk_idx.sql ist die Ausgabe:

-bash-4.2$ psql -d verinicedb -f /usr/local/bin/check_fk_idx.sql
CREATE FUNCTION
           conrelid           |      conname       | reltuples
------------------------------+--------------------+-----------
 jbpm4_hist_actinst           | fk_hacti_hproci    |       184
 jbpm4_hist_actinst           | fk_hti_htask       |       184
 jbpm4_hist_task              | fk_hsupert_sub     |        59
 jbpm4_deployprop             | fk_deplprop_depl   |        20
 jbpm4_lob                    | fk_lob_deployment  |        10
 jbpm4_task                   | fk_task_supertask  |         6
 jbpm4_task                   | fk_task_swiml      |         6
 jbpm4_job                    | fk_job_cfg         |         2
 jbpm4_hist_detail            | fk_hdetail_hacti   |         0
 jbpm4_hist_var               | fk_hvar_hproci     |         0
 jbpm4_hist_var               | fk_hvar_htask      |         0
 jbpm4_id_group               | fk_group_parent    |         0
 jbpm4_id_membership          | fk_mem_user        |         0
 jbpm4_id_membership          | fk_mem_group       |         0
 jbpm4_participation          | fk_part_task       |         0
 jbpm4_participation          | fk_part_swimlane   |         0
 jbpm4_swimlane               | fk_swimlane_exec   |         0
 jbpm4_variable               | fk_var_lob         |         0
 jbpm4_variable               | fk_var_exesys      |         0
 jbpm4_variable               | fk_var_task        |         0
 jbpm4_variable               | fk_var_execution   |         0
 allgefaehrdungsumsetzungen   | fk861776933016efb8 |         0
 allgefaehrdungsumsetzungen   | fk86177693d66c9577 |         0
 associatedgefaehrdungen      | fk152d4be33016efb9 |         0
 associatedgefaehrdungen      | fk152d4be3d66c9577 |         0
 configuration                | fk733374f68a5411fe |         0
 configuration                | fk733374f69c11251  |         0
 notokgefaehrdungsumsetzungen | fk8dbf68853016efba |         0
 notokgefaehrdungsumsetzungen | fk8dbf6885d66c9577 |         0
 configuration                | fk733374f6af34d1af |         0
 configuration                | fk733374f6357f9dc7 |         0
 configuration                | fk733374f67727d1de |         0
 jbpm4_execution              | fk_exec_instance   |         0
 jbpm4_execution              | fk_exec_parent     |         0
 jbpm4_execution              | fk_exec_subpi      |         0
 jbpm4_execution              | fk_exec_superexec  |         0
 jbpm4_hist_detail            | fk_hdetail_hvar    |         0
 jbpm4_hist_detail            | fk_hdetail_hproci  |         0
 jbpm4_hist_detail            | fk_hdetail_htask   |         0
(39 Zeilen)

Performanceverbesserungen kann ich bisher nicht feststellen.

BG Stefanie Langer

jules · 5. Mai 2020 um 12:06

die Ausgaben sind so weit in Ordnung. Ich „mag“ es trotzdem nicht, dass die Prüfung nicht bis zum Ende durchgelaufen ist , bezugnehmend auf Ihr Bericht aus dem ersten Post.
Ich schlage vor, alle verinice-Clients zu beenden und Skript /ur/local/bin/create_fk_idx.sql nochmal auszuführen und abwarten bis sich selbst beendet hat.
Die Fremdschlüssel, die bereits angelegt sind, werden nicht nochmal angelegt und dazu gibt es Rückmeldung, wie von mir schon berichtet. Da wo sind eventuell doch noch benötigt werden, werden mit einem Hinweis in der Art, z.B. „HINWEIS: ALTER TABLE / ADD UNIQUE erstellt implizit einen Index »cnatreeelement_uuid_key« für Tabelle »cnatreeelement«“ dann angelegt.

Für die Performance, wie in der Installationsanleitung von uns hingewiesen, kann für die Datenbank-Optimierung mittels Tool „pgtune“, z.B.:
https://centos.pkgs.org/7/epel-x86_64/pgtune-0.9.3-12.da57e00.el7.noarch.rpm.html geprüft werden, ob Ihre Einstellungen ausreichend sind.

Beste Grüße
Julia

StefanieLanger · 5. Mai 2020 um 13:51

Ich teste Ihren Vorschlag und lasse das Skript durchlaufen. Sobald ich Ergebnisse habe, melde ich mich.

StefanieLanger · 6. Mai 2020 um 08:57

Hallo, das Durchlaufen ist nachts abgebrochen (vermutlich als der VPN-Client sich beendet hat). Ich habe den Server nochmal durchgestartet aber bisher keine weiteren Verbesserungen. Für die Installation von pgtune verfüge ich leider nicht über ausreichende Fachkenntnisse unter CentOS. Haben Sie weitere Ideen?

Beste Grüße Stefanie Langer

jules · 12. Mai 2020 um 13:36

Hallo,
mit pgtune kann man wie folgt vorgehen. Herunterladen, z.B.

wget https://download-ib01.fedoraproject.org/pub/epel/7/x86_64/Packages/p/pgtune-0.9.3-12.da57e00.el7.noarch.rpm

Auf dem System mit rpm -ivh pgtune-0.9.3-12.da57e00.el7.noarch.rpm installieren.
In das PostgreSQL-data-Verzeichnis wechseln

cd /var/lib/pgsql/data/

Dort die Original postgresql.conf sichern

cp postgresql.conf postgresql.conf.orig

Anschließend mit pgtune automatisch die Einstellungen prüfen und ändern lassen

pgtune -i postgresql.conf -o postgresql.conf

Um Änderungen wirksam zu machen, soll der PostgreSQL-Dienst neu gestartet werden, davor soll der Tomcat-Dienst gestoppt werden.

systemctl stop tomcat
systemctl restart postgresql
systemctl start tomcat

Bei älteren Datenbanken, wie noch vor der 9-ten Postgres-Version zu beobachten war, könnte auch ein Problem mit den so genannten „verwaisten“ Objekten sein, die die Datenbank träge machen könnten.
Prüfen, könnte man mit vacuumlo ob die Objekte in der Datenbank vorhanden sind.

su -
su - postgres
vacuumlo -n Name_der_Datenbank

Option -n bewirkt, dass die Objekte aufgelistet und nicht gelöscht werden. Gibt es solche Objekte, dann können die mit vacuumlo Name-der-DB gelöscht werden.
Ob Postgres-Dienst die autovacuum-Einstellung bereits aktiv hat, kann dann z.B. so prüfen

ps -ax |grep auto

Auch wenig Speicher für das ganze System bzw. für den Tomcat-Prozess kann die Performance beeinträchtigen.
Den Speicher auf dem System prüfen:

free -mt

Dem Tomcat zugeordneten Speicher prüfen:

systemctl status tomcat

Hier sind die Werte Xms und Xmx zu betrachten.
Die Werte können dann entsprechend über /etc/tomcat/tomcat.conf geändert werden. Nach den Änderungen den Tomcat-Prozess ist neu zu starten.

Die Performance-Probleme könnten aber nicht unbedingt an den technsichen Einstellungen liegen, sondern an den Verknüpfungen zwischen den Zielobjekten
Hilft es irgendwie weiter?

Beste Grüße
Julia

StefanieLanger · 18. Juni 2020 um 06:47

Vielen Dank für die Mühe! Wegen eines Audits konnte ich diese Hinweise noch nicht testen. In diesem Zusammenhang („Performance“) kann ich aber nochmal eine aktuelle Auswertung der VM in den Ring werfen. Obwohl Verinice nachweislich nicht genutzt wurde, ist die CPU Last unglaublich hoch. Möchte man das Tool starten, sind die Wartezeiten ebenfalls sehr lang. CPU%20Last