Bei der Arbeit mit dem VMware Perl SDK oder darauf basierenden Skripten wird schnell ersichtlich, dass die Laufzeit selbst für eigentlich simple Aufgaben enorm lange ist. Warum dem so ist, warum das für Monitoring-Zwecke unschön ist und wie man dem oft erlebten Phänomen etwas entgegenwirken kann, wollen wir hier kurz beleuchten. Primär interessant für Skript-Schreiber, als Hintergrundwissen aber auch für Skript-Benutzer, die sich schön öfter über die Laufzeit ihrer Perl Skripte gewundert haben.

Resourcen-intensiv und l a n g s a m

Gutes Beispiel für das Problem ist das in Perl geschriebene check_esx3.pl von OP5, was von Haus aus nicht nur lange läuft, sondern die ausführende Maschine auch merklich unter Last setzt. Ebenso das hier kürzlich vorgestellte check_snapshots.pl. Ein dstat Mitschnitt auf dem Monitoring-Host zeigt beim Skript-Aufruf eine über Sekunden gesättigte CPU und nicht unerheblichen Speicherverbrauch (>100MB!). Merke: Das alles, nur um eine Liste von verwaisten Snapshots zusammenzustellen. Der interessante Abschnitt reicht von 17:07:01 bis 17:07:08.

-----time----- ----total-cpu-usage---- ------memory-usage----- -net/total-
  date/time   |usr sys idl wai hiq siq| used  buff  cach  free| recv  send
25-02 17:06:58|  0   0 100   0   0   0|  95M   55M  207M  142M| 546B  840B
25-02 17:06:59|  0   0  99   0   0   1|  95M   55M  207M  142M| 564B  204B
25-02 17:07:00|  7   1  92   0   0   0| 102M   55M  207M  135M| 758B  456B
25-02 17:07:01| 90   9   1   0   0   0| 154M   55M  207M   83M|2259B 1045B
25-02 17:07:02| 50   4  46   0   0   0| 174M   55M  207M   63M| 419k   18k
25-02 17:07:03| 76   9  14   0   0   1| 214M   55M  207M   23M|2770k   37k
25-02 17:07:04|100   0   0   0   0   0| 214M   55M  207M   23M| 120B    0
25-02 17:07:05| 99   1   0   0   0   0| 214M   55M  207M   23M| 240B    0
25-02 17:07:06|100   0   0   0   0   0| 217M   55M  207M   20M| 120B   42B
25-02 17:07:07| 99   1   0   0   0   0| 220M   55M  207M   17M| 180B    0
25-02 17:07:08| 61   2  37   0   0   0|  96M   55M  207M  141M|1356B 4531B
25-02 17:07:09|  1   0  99   0   0   0|  96M   55M  207M  141M| 300B    0
25-02 17:07:10|  0   0 100   0   0   0|  96M   55M  207M  141M|  60B    0

Das wiederum ist lediglich die Sicht des Monitoring-Hosts, sowohl auf dem vCenter System als auch auf den ESX-Servern sind ähnliche Last-Spitzen zu sehen. Die Laufzeit bei einer VMware Landschaft mit 4 ESX Hosts und ca. 100 VMs beträgt etwa 8 Sekunden.

real    0m7.578s
user    0m6.666s
sys     0m0.251s

Spielt man das jetzt hoch und überlegt sich, mehrere, dedizierte, Perl-basierte Checks laufen zu lassen, kann man sich schnell errechnen, dass dem Monitoring-Host (mit Nagios, Icinga oder Co) schnell die Puste ausgehen wird.

Es geht auch schneller

Der Schlüssel liegt im Standard-Verhalten des Perl SDKs beim Datenaustausch, denn bei Abfragen von VMs werden per se alle zugehörigen Daten vom vCenter/ESX abgefragt – auch wenn ein kleines Subset für den konkreten Zweck eines Skriptes ausreichen würde. Ergo müssen vCenter/ESX all diese Daten aufbereiten und übers Netz schicken, während die Perl SDK Routinen auf der Empfängerseite all die erhaltenen Datenstrukturen (benötigt oder nicht) parsen und intern in Objekte umwandeln müssen. Alles sehr CPU- und Zeit-aufwändig.

Dass es auch zielführender und schneller geht, verrät ein kleiner Absatz des vSphere SDK for Perl Programming Guide auf Seite 34 (“Filtering Views Selectively Using Properties”).

The view subroutines—get_view(), get_views(), find_entity_view(), and find_entity_views()—can accept a properties argument that consists of a list of property paths for retrieval from the server.

Man kann also bei der Abfrage angeben, welche konkreten VM-Daten benötigt werden. Testen wir das mal in der Praxis.

Testweise angewandt auf check_snapshot.pl

Naiv angewandt auf das check_snapshot.pl Skript ergibt sich ein nicht zu verachtender Unterschied: Laufzeit reduziert auf 2-3 Sekunden, Speicherverbrauch reduziert um ca. 50MB.

-----time----- ----total-cpu-usage---- ------memory-usage----- -net/total-
  date/time   |usr sys idl wai hiq siq| used  buff  cach  free| recv  send
25-02 17:07:24|  0   0 100   0   0   0|  96M   55M  207M  141M| 240B    0
25-02 17:07:25|  0   0 100   0   0   0|  96M   55M  207M  141M| 120B    0
25-02 17:07:26| 54   7  39   0   0   0| 131M   55M  207M  106M|2541B 1147B
25-02 17:07:27| 91   7   2   0   0   0| 174M   55M  207M   63M|5847B 2346B
25-02 17:07:28| 64   1  35   0   0   0|  96M   55M  207M  141M| 319k   18k
25-02 17:07:29|  0   0 100   0   0   0|  96M   55M  207M  141M|  60B    0
25-02 17:07:30|  0   0 100   0   0   0|  96M   55M  207M  141M| 240B    0

real    0m2.326s
user    0m2.062s
sys     0m0.163s

Einzige Änderung hierfür ist eine hinzugefügte Zeile, über die wir spezifizieren an welchen Daten wir konkret interessiert sind.

my $vms = Vim::find_entity_views(
    view_type => 'VirtualMachine',
    filter => $filter,
    properties => ['summary', 'snapshot'] 
);

Das lässt sich ggf. noch weiter optimieren, denn aus der Summary benötigen wir für die Zwecke des Skriptes nur den Namen. Aber immerhin, bereits mit dieser einfachen Änderung ist viel erreicht. Stolperfalle bei der Verwendung von properties ist natürlich, dass auch nur die tatsächlich angefragten Properties im weiteren Skript-Verlauf zur Verfügung stehen. Bei Trial&Error sowie Data::Dumper Programmierung sollte man sich das nochmal bewusst machen.

Fazit

Sobald man weiß, worin sich die Langsamkeit der meisten Perl SDK Skripte begründet, kann man dagegen angehen und das properties Flag beim Abfragen einer VMware Landschaft bietet dazu eine einfache Möglichkeit. Kleine Änderung, große Wirkung.

1 Kommentar zu „VMware Scripting: Perl SDK beschleunigen“