ITSM CMDB: langsamer CSV Import

[fkotrs]

Hallo zusammen,

leider bekomme ich gerade keinen Account auf dem Bugtracker 'bugs.otrs.org' eingerichtet, da keine Mails bei mir ankommen. Deswegen auf diesem Wege:

Der CSV Import von Assets/CIs in die CMDB ist unglaublich langsam, wenn man mehr als ein paar tausend CIs hat.
Momentan dauert der Import jedes einzelnen CIs ca. 40 Sekunden. In der CMDB sind aktuell ca. 34000 CIs.

Deshalb habe ich mir den Code mal angeschaut, und dabei mindestens 3 Probleme gefunden:

1. History-Tabelle hat nur 255 Zeichen fuer die Aenderung, was bei Aenderungen in Beschreibungen, die laenger als 255 Zeichen sind, zu einem DB-Fehler fuehrt:

Code: Select all

DBD::Pg::db do failed: FEHLER:  Wert zu lang für Typ character varying(255) at /opt/otrs/Kernel/System/DB.pm line 499.
ERROR: OTRS-ImportExport-11 Perl: 5.10.0 OS: linux Time: Thu Aug 21 04:49:37 2014
Message: FEHLER:  Wert zu lang fuer Typ character varying(255), SQL: 'INSERT INTO configitem_history ( configitem_id, content, create_by, create_time, type_id ) VALUES ( ?, ?, ?, '2014-08-21 04:49:37', ? )'

2. Bei vielen geaenderten CIs kommt es zu einem Memory-Problem, da der Cache beim CSV Import zu gross wird.

3. Beim Import wird fuer jedes CI jeweils eine Hashmap mit *allen* CIs in der Datenbank erzeugt, danach eine Liste der CIs, die poterntiell geaendert werden sollen, um danach eine Schnittmenge dieser beiden Mengen zu bilden. Dadurch dauert jeder einzelne CI Import bei uns ca. 40 Sekunden. Nachdem ich dieses Verhalten korrigiert habe, dauert der CI Import jeweils nur 2 Sekunden pro CI (was meiner Meinung nach immernoch viel zu lange ist)

Hier die dazugehoerigen Diffs:

1. History

Code: Select all

--- Kernel/System/ITSMConfigItem/History.pm.org 2014-05-17 13:28:09.000000000 +0200
+++ Kernel/System/ITSMConfigItem/History.pm     2014-08-21 14:23:38.000000000 +0200
@@ -286,6 +286,25 @@
     delete $Self->{Cache}->{CIVersions}->{ $Param{ConfigItemID} };
 
     # insert history entry
+    # Frank Kirschner: crop comment if the comment is too long for the history table
+    if (length($Param{Comment}) > 255) {
+       my($field, $old, $new) = split('%%', $Param{Comment}, 3);
+       my $len = int((255 - length($field) - 4) / 2);
+       if (length($old) > $len) {
+           my $index = int($len / 2);
+           $old = substr($old,0,$index - 2) . '...' . substr($old,length($old) - $index + 2);
+       }
+       if (length($new) > $len) {
+           my $index = int($len / 2);
+           $new = substr($new,0,$index - 2) . '...' . substr($new,length($new) - $index + 2);
+       }
+       my $new_comment = $field . '%%' . $old . '%%' . $new;
+       #$Self->{LogObject}->Log(
+       #    Priority => 'error',
+       #    Message  => 'Comment too long: ID:' . $Param{ConfigItemID} . ' Comment: ' . $Param{Comment} . $/ . ' New Comment: ' . $new_comment,
+       #);
+       $Param{Comment} = $new_comment;
+    }
     return $Self->{DBObject}->Do(
         SQL => 'INSERT INTO configitem_history ( configitem_id, content, create_by, '
             . 'create_time, type_id ) VALUES ( ?, ?, ?, current_timestamp, ? )',

2. Cache loeschen, um Memory-Probleme zu verhindern

Code: Select all

--- Kernel/System/ImportExport/ObjectBackend/ITSMConfigItem.pm.org      2014-05-22 17:21:25.000000000 +0200
+++ Kernel/System/ImportExport/ObjectBackend/ITSMConfigItem.pm  2014-05-27 14:55:50.000000000 +0200
@@ -559,6 +559,9 @@
         next CONFIGITEMID if !$VersionData;
         next CONFIGITEMID if ref $VersionData ne 'HASH';
 
+        # Frank Kirschner: Delete cache, or we will run out of memory
+        undef($Self->{ConfigItemObject}->{Cache}->{VersionGet}->{ $VersionData->{VersionID} });
+
         # translate xmldata to a 2d hash
         my %XMLData2D;
         $Self->_ExportXMLDataPrepare(

3, Alle CIs nur dann holen, wenn keine Einschraenkung bei der Suche gemacht wird:

Code: Select all

--- Kernel/System/ITSMConfigItem/XML.pm.org     2014-05-17 13:28:09.000000000 +0200
+++ Kernel/System/ITSMConfigItem/XML.pm 2014-05-27 13:58:32.000000000 +0200
@@ -609,19 +609,9 @@
     # get like escape string needed for some databases (e.g. oracle)
     my $LikeEscapeString = $Self->{DBObject}->GetDatabaseFunction('LikeEscapeString');
 
-    return if !$Self->{DBObject}->Prepare(
-        SQL  => 'SELECT DISTINCT(xml_key) FROM xml_storage WHERE xml_type = ?',
-        Bind => [ \$Param{Type} ],
-    );
-
     # the keys of this hash will be returned
     my %Hash;
 
-    # initially all keys with the correct type are possible
-    while ( my @Data = $Self->{DBObject}->FetchrowArray() ) {
-        $Hash{ $Data[0] } = 1;
-    }
-
     if ( $Param{What} && ref $Param{What} eq 'ARRAY' ) {
 
         my %OpIsSupported = map { $_ => 1 } ( '<', '<=', '=', '!=', '>=', '>', '-between' );
@@ -717,12 +707,19 @@
             # only the keys which are in all results survive
             my %HashNew;
             while ( my @Data = $Self->{DBObject}->FetchrowArray() ) {
-                if ( $Hash{ $Data[0] } ) {
                     $HashNew{ $Data[0] } = 1;
-                }
             }
             %Hash = %HashNew;
         }
+    } else {
+        return if !$Self->{DBObject}->Prepare(
+            SQL  => 'SELECT DISTINCT(xml_key) FROM xml_storage WHERE xml_type = ?',
+            Bind => [ \$Param{Type} ],
+        );
+        # initially all keys with the correct type are possible
+        while ( my @Data = $Self->{DBObject}->FetchrowArray() ) {
+            $Hash{ $Data[0] } = 1;
+        }
     }
 
     my @Keys = keys %Hash;

Sieht das fuer euch so OK aus?
Und wie bekomme ich das ins Upstream, solange der Bugtracker keine Neuanmeldungen erlaubt?

Danke schonmal,

Frank Kirschner

[fkotrs]

Der Bugzilla von OTRS hat sich nun doch entschlossen mir eine Mail zu schicken, so dass ich diese Bugs einstellen konnte.
Mal sehen, was sich tut

Ciao, Frank

[jojo]

Am besten contributest Du solche Änderungen via Github