Festplattenbenchmark mit bonnie++

Vor einigen Wochen haben Killian und Ich eine Serverwartung durchgeführt. Dabei haben wir nach der Aktualisierung einen sehr simplen Festplatten-Benchmark mittels dd durchgeführt. Im Nachhinein interessierte es mich, welche Performancewerte denn mein Arbeitslaptop bringen würde. Da ich genauere und ausführlichere Performancewerte haben wollte, suchte ich nach Benchmarktools. Nach einiger Recherche im Internet fand ich das Tool bonnie++, welches sich perfekt für einen Festplattenbenchmark eignet.
bonnie++ ist in den meisten Repositories verfügbar oder kann auf der Homepage heruntergeladen werden. Mit “aptget install bonnie++installiert man bonnie++ auf einem Debian/Ubuntu basierten System. Nun kann man schon mit den Tests starten!

Um  aussagekräftige Werte zu bekommen, muss man den Filecache so gering wie möglich halten. Man erreicht dies indem man Datasets schreibt, welche größer als der zu Verfügung stehende RAM ist (bonnie++ nimmt als Defaultwert  2 x RAM). Als Folge muss man also mindestens 2 x RAM freien Festplattenspeicher haben!

Wenn man bonnie++ ohne Parameter startet wird das Tool ausgeführt und liefert ein leicht unübersichtliches Ergebnis:

user@user-notebook:~$ bonnie++
Writing a byte at a time...done
Writing intelligently...done
Rewriting...done
Reading a byte at a time...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
user-notebook 15664M 658 99 290591 40 180714 21 1909 99 498792 39 8705 159
Latency 38628us 193ms 269ms 22258us 14790us 5094us
Version 1.97 ------Sequential Create------ --------Random Create--------
user-notebook -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
 files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency 589us 1486us 935us 814us 71us 452us
1.97,1.97,nb-user-notebook,1,1524129932,15664M,,658,99,290591,40,180714,21,1909,99,498792,39,8705,159,16,,,,,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,38628us,193ms,269ms,22258us,14790us,5094us,589us,1486us,935us,814us,71us,452us

Falls man über eine GUI verfügt, kann man sich den Output auch in eine HTML-Datei speichern und diese über einen Webbrowser öffnen. Dies geht mit folgendem Befehl:

bonnie++ | tail -n 1 | bon_csv2html > $(date +"%Y.%m.%d.%S.%N")_bonnie.html

Die nun erstellte HTML-Datei listet alle Werte strukturiert auf und kann zugleich als Vergleichswert für spätere Tests verwendet werden.

Es ist auch möglich bonnie++ mit individuellen Einstellungen zu starten, im Folgendem die wichtigsten Parameter:

  • -r: Größe des Arbeitsspeichers in Megabyte und somit auch die Größe des zu erstellenden Datasets
  • -n: Anzahl der Dateien die zu einem Dataset zusammengesetzt werden
  • -x n: Der Test wird “n-mal” ausgeführt
  • -s: Definiert die Größe des Datasets in Megabyte
  • -b: Schaltet “write buffering” aus und führt einen “Sync” am Ende jeder bonnie++-Operation durch

(Alle Parameter mit ausführlicher Beschreibung findet man im Manual)
Man sollte bonnie++ mehrmals am Tag ausführen, denn nur so können Anomalien abgefangen werden und man erhält einen aussagekräftigen Durchschnittswert.
Quellen: UbuntuWiki, OCH-Group, JamesCoyle

Philipp Dorschner
Philipp Dorschner
Junior Consultant

Philipp hat im September 2017 seine Ausbildung zum Fachinformatiker gestartet. Er hat sogar schon eine Ausbildung im Gepäck und zwar zum technischen Assistenten für Informatik. Danach hat hat er sein Abi nachgeholt und anschließend begonnen Wirtschaftswissenschaften zu studieren. Da sein Herz während des Studiums ständig nach technischen Inhalten geschrien hat, wechselte er zu Verfahrenstechnik. Aber auch dieses Studium konnte Ihn nicht erfüllen, weshalb er sich für die Ausbildung bei NETWAYS entschieden hat, "back to the...

NETWAYS Web Services: Nextcloud 13 now up and running!


A lot of Nextcloud users have waited for the new Nextcloud 13 version to be available. Now our NWS team has implemented it for all Nextcloud apps on our platform.
Nextcloud 13 will bring you the following enhanced functions to your cloud:

  • Video and Text chat
  • End-to-end Encryption
  • Refined User Interface
  • Improved Performance
  • Improved File Sync and Share

 
Nextcloud users will now profit from a new app called Nextcloud Talk which provides an Open Source platform for audio, video and text communication in real-time as well as in asynchronous mode. Push notifications will help you to never miss a message! Absolute privacy is guaranteed by implementation of end-to-end encrypted calls that are 100% secure peer-to-peer.
Another big innovation is the End-to-End Encryption of content which can now be controlled by the users themselves. In the current Tech Preview release in version 13 it is now possible to encrypt single folders chosen by the users via their Nextcloud client. This prohibits the server side from accessing and seeing the folder or file content. The preview is available in mobile clients for Android and iOS as well as in desktop clients for Windows, Mac and Linux. Nextcloud will continue to enhance its encryption functionality over the next months.

Performance is also an important subject when it comes to the daily use of a certain software. The Nextcloud team has done a lot to make your work and collaboration faster and more comfortable by decreasing for example page load times as well as improving Server-Side-Encryption and external storage performance. For more information on performance enhancements please have a look at Nextcloud’s own blog article
 
For more detailed information on the new Nextcloud release you should visit the Nextcloud website or start your own Nextcloud instance on our NWS platform. Please remember that we offer a 30 day free trial period for every app!
 
 
 
 

Nicole Lang
Nicole Lang
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

Avoiding Common Pitfalls with Apply Rules

When building apply rules for your Icinga 2 configuration there are a few common pitfalls you should avoid:
1. Using apply when you’re really just creating a single object
Rule-based configs are great at simplifying your config. However, there are times when you really just want to create a single object. One common anti-pattern I’ve come across is this:

apply Service "ntp" {
  ...
  assign where host.name == "ntp1.example.org"
}

Now, obviously this will work as intended, however there are two significant problems: Writing a filter rule for a single host is unnecessarily complicated and additionaly there is a significant performance penalty because this rule has to be evaluated for all of your hosts.
A much simpler way to achieve this is to just use a simple object declaration:

object Service "ntp" {
  host_name = "ntp1.example.org"
  ...
}

2. Using too many assign where rules
Apply rules are intended to be used to make your config more general by putting your hosts into certain classes (“all ntp servers”, “all database servers”, etc.) and then assigning services and notifications to each member of a certain class. However, for some reason people sometimes do this instead:

apply Service "web" {
  ...
  assign where host.name == "web1.example.org"
  assign where host.name == "web2.example.org"
  assign where host.name == "web3.example.org"
  ...
  assign where host.name == "web73.example.org"
}

The obvious problem here is that this is a maintenance nightmare – and as we’ve already learned “assign where” rules aren’t exactly free in terms of performance.
Unlike in our first example the solution isn’t to unroll this filter by creating an “object” definition for each of the hosts. Instead you should use some of the great filtering capabilities that come with Icinga 2. Here’s a short list of just some of the filters that are available:
1. CIDR matching (using the cidr_match function)
2. Regular expressions (using the regex function)
3. Wildcard matches (using the match function)
4. and last but not least: custom variables
In this particular example I’m going to use wildcard matching and custom variables:

object Host "web1.example.org" { }
object Host "web2.example.org" { }
object Host "web3.example.org" { vars.no_web_check = false }
apply Service "web" {
  ...
  assign where match("web*.example.org", host.name)
  ignore where host.vars.no_web_check
}

This assumes that all of your “web” hosts should have a “web” service by default. Using “ignore where” we can make sure that certain hosts don’t get the service.
3. Reusing “assign where” filters
This is pretty much the opposite problem compared to our previous example. Instead of using the same filter expression dozens of times in the same apply rule this is about unnecessarily repeating the filter in multiple apply rules:

apply Service "mysql" {
  ...
  // All db hosts except those in the dev subnet
  assign where match("db*.example.org", host.name) && !cidr_match("172.16.23.0/24", host.address)
}
apply Service "postgresql" {
  ...
  // All db hosts except those in the dev subnet
  assign where match("db*.example.org", host.name) && !cidr_match("172.16.23.0/24", host.address)
}
apply Service "mssql" {
  ...
  // All db hosts except those in the dev subnet
  assign where match("db*.example.org", host.name) && !cidr_match("172.16.23.0/24", host.address)
}

Code reuse is a best common practice when it comes to writing software. This also applies to Icinga 2 and makes your config much more maintainable and pleasant to work with.
Here’s how you can re-use your filter expression in multiple apply rules:

globals.is_prod_database_host = function(host) {
  // All db hosts except those in the dev subnet
  return match("db*.example.org", host.name) && !cidr_match("172.16.23.0/24", host.address)
}
apply Service "mysql" {
  ...
  assign where is_prod_database_host(host)
}
apply Service "postgresql" {
  ...
  assign where is_prod_database_host(host)
}
apply Service "mssql" {
  ...
  assign where is_prod_database_host(host)
}

By using descriptive function names you also gain the advantage of making your code… er, config more readable.

Fronted-Performance optimieren in Chrome – Like a Boss

Nicht nur Frontend Entwickler kennen es: Man freut sich, dass die hollywoodreifen Animationen auf der Webseite oder im User Interface endlich funktionieren. Ein raffinierter Parallax-Effekt verleiht dem Ganzen dann noch den letzten Schliff. Das Problem: Es ruckelt und hakt an allen Enden, die Lüfter seines nagelneuen Rechners fangen an zu drehen. Was tun?
Zum Glück bieten die Chrome-Developer Tools einige hilfreiche Werkzeuge an, um die Performancefresser zu identifizieren. Diese geben nicht nur einen guten Überblick über Performance-Engpässe sondern dokumentieren außerdem die Bildwiederholrate, CPU-Auslastung und das Asset-Handling.

Wo finde ich diese Tools nun?

Wer die Chrome Developer-Tools kennt, ist möglicherweise schon mal über das Timeline Tab gestolpert. Öffnet man die Ansicht das erste Mal, ist es nicht ganz unwahrscheinlich, dass man von der hohen Informationsdichte erschlagen ist. Daher soll dieser Artikel als eine Art Entry-Point für den Einstieg sein. Denn es lohnt sich.
Ist das Timeline-Tab bereits geöffnet und die Seite wird neu geladen, werden die Performance-Daten des initialen Seitenaufrufes bis zum fertigen Rendern der Seite automatisch aufgezeichnet.
Danach kann man einzelne Aufzeichnungen starten, um z.B. die Performance einzelner Interaktionen auf der Seite untersuchen zu können. Dabei sollte beachtet werden: Je kürzer die Aufnahme und je weniger Aktionen aufgezeichnet werden, desto einfacher ist die Analyse.

Überblick

Der Einstieg: Ein kurzer Überblick über die Oberfläche.
Bildschirmfoto 2016-03-30 um 13.07.21

A) Bedienelemente

Die beiden linken Symbole dienen zum Starten und Stoppen der Aufzeichnung. Alternativ kann hierfür das Tastenkürzel cmd + E / Strg + E verwendet werden. Mit den Checkboxen können zusätzliche Informationen an/abgewählt werden, die dann entsprechend mit aufgezeichnet werden.

B) Überblick

Diese Ansicht bietet eine Übersicht über den Verlauf der Seiten-Performance. Sie dient außerdem als Navigation, um den aktuellen Bereich auszuwählen.

C) Flame-Chart

Hier werden die einzelnen Ereignisse und deren Dauer als horizontale Balken visualisiert. Parallele Ereignisse werden nach unten gestapelt. Der findige Beobachter erkennt hier drei unterschiedliche gefärbte vertikale gestrichelte Linien: die blaue Line stellt den DOMContentLoaded-Event dar. Die grüne Linie markiert den ersten Paint-Event und die rote den load Event.

D) Details

Ist kein Ereignis angewählt werden hier die Statistiken für  Zeitraum aufgeführt, der in der Übersichtsansicht ausgewählt ist. Um die Anzeige auf ein Ereignis zu begrenzen, kann im Flame-Chart ein Ereignis ausgewählt werden.
In der Überblicksansicht kann man die Auswahl der Ereignisse eingrenzen in dem man die Regler verschiebt. Die Visualisierungen im Flame-Chart und dem Detailbereich passen sich entsprechend an und beziehen sich nur auf den ausgewählten Bereich.
2016-03-30 16_25_29

Exkurs: Die typische Rendering-Pipeline

In der Regel gibt es fünf verschiedene Schritte bei der Frame-Berechnung, die bei der Entwicklung zu beachten sind. Über diese Bereiche hat  der Entwickler die größte Kontrolle.

Javascript

Typischerweise werden Scriptaufrufe verwendet um Werte zu ändern, die dann in Änderungen der Darstellung resultieren. Das kann z.B. die animate Funktion in jQuery sein oder das Hinzufügen von DOM-Elementen. Diese Darstellungsänderungen werden nicht ausschließlich durch Javascript ausgelöst. Es können auch CSS-Animationen, Transistions, o.ä. dafür verantwortlich sein.

Style Calculations

In diesem Prozess findet der Browser heraus, welche CSS-Regeln anhand der Style-Angaben für welche Elemente angewandt werden müssen.

Layout

Darauf folgt in der üblicherweise die Berechnung der Positionen der jeweiligen Elemente und wie viel Platz diese benötigen. Das Layout-Modell des Webs ist so konzipiert, dass gewisse Abhängigkeiten der Elemente untereinander herrschen. Verändert ein Element, welches mit float positioniert ist seine Breite, beeinflusst es die Position und Größe der umliegenden Elemente.

Paint

Im Painting-Prozess werden die Pixel der einzelnen Elemente berechnet. Es berücksichtigt Eigenschaften wie Text, Farben, Bilder, Rahmen. Die Berechnung findet auf verschiedenen Ebenen (Layers) statt.

Composite

Nachdem Painting-Prozess sind die einzelnen Komponenten (Layers) der Seite bereits berechnet. Beim Compositing werden diese Komponenten dann übereinander gelegt. Besonders entscheidend ist dies bei überlappenden Elementen.

1. JS/CSS >Style > Layout > Paint > Composite

Pasted Graphic
Wenn eine Eigenschaft eines Elements verändert wird, welche dessen Abmessungen oder Position verändert (z.B. height, width, top, left, o.ä, muss der Browser alle oder zumindest alle umliegenden Elemente neu berechnen und zusammengesetzt werden (Layout > Paint > Composite)

2. JS/CSS > Style > Paint > Composite

Pasted Graphic 1

Werden nur Paint-only Eigenschaften geändert (background-image, color, box-shadow), kann der Browser den Layout-Prozess überspringen.

3. JS/CSS > Style > Composite

Pasted Graphic 2

Wenn eine Eigenschaft verändert wird, bei denen der Layout und Painting-Prozess übersprungen werden kann, überspringt der Browser diese Schritte und springt direkt in den Compositiing-Prozess. Darunter fallen z.B. transform oder opacity.
Vor allem für performance-kritische Fälle, z.B. für Animationen oder bei Scroll-Events, bei denen die entsprechenden Funktionen in der Regel besonders oft aufgerufen werden, ist diese Variante besonders erstrebenswert.

Repaintbereiche auf der Seite visualisieren

Im DevTools Hauptmenü gibt es einen Eintrag mit der Bezeichnung More Tools nennt. Wählt man hier die Rendering Settings aus, erhält man weitere Funktionen. Ist die zusätzliche Leiste am unteren Bildschirmrand nicht sichtbar, kann man diese mit der Esc-Taste wieder erscheinen lassen.
Im Teilfenster am unteren Bildschirmrand befindet sich dann eine Check-Box mit dem Titel Enable paint flashing.

rendering-settings

Über das DevTools Hauptmenü können weitere Tools eingeblendet werden.


Aktiviert man diese werden auf der Seite Bereiche markiert, bei denen Painting-Events auftreten. So erhält man in Echtzeit einen guten Überblick, welche Bereiche für mögliche Performance-Engpässe sorgen.
2016-03-30 22_26_11
————
Es gibt einen Talk von Paul Irish, der mehrere Anwendungsbeispiele veranschaulicht.

Florian Strohmaier
Florian Strohmaier
UX Designer

Mit seinen Spezialgebieten UI-Konzeption, Prototyping und Frontendentwicklung unterstützt Florian das Dev-Team bei NETWAYS. Trotz seines Design-Backgrounds fühlt er sich auch in der Technik zuhause. Gerade die Kombination aus beidem hat für ihn einen besonderen Reiz.

Icinga Webinare im Dezember

NETWAYS Webinare Nachdem im Rahmen einer wieder einmal erfolgreichen OSMC sowohl eine neue Version von Icinga 2 als auch Icinga Web 2 veröffentlicht wurde, wollen wir natürlich die Gelegenheit nutzen, diese in unseren Webinaren vorzustellen.
Die Termine im Dezember stehen bereits fest und wir freuen uns wie immer auf eine rege Teilnahme zum Abschluss dieses erfolgreichen Jahres!

Titel Zeitraum Registrierung
Icinga 2 – Neues in 2.4 08. Dezember 2015 – 10:30 Uhr Anmelden
Icinga Web 2: Das neue Interface 09. Dezember 2015 – 10:30 Uhr Anmelden
Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Profiling your application with Valgrind Callgrind: Icinga2

We are using a variety of tools to ensure that our applications do not leak memory, suffer from performance issues or actually trigger unwanted behavior. This tool stack changes over time, and it is also different for web, script and binary applications. Next to the Icinga bits I am responsible for the LConf Backend and other Perl foo here at NETWAYS – I’ve already written about profiling Perl. During Icinga 1.x and 2.x development we’ve come around a couple of tools for profiling memory consumption with Massif or using the Google perftools.
One of our specialties at NETWAYS Development is further that we’re capable of identifying and resolving issues directly – be it performance, memory, locking, race conditions, etc. aside from the code we’re developing and running at customers.

The perfect code vs performance

While the perfect code does not exist, it’s always interesting and also required to refactor your own code parts based on current conditions and requirements. The code in 2.2.4 had one function interface being called, namely AddObject(). This function is merely doing the following for ‘repository add’ and ‘node update-config’:

  • Get all the object names from `repository.d` and checking if the added object already exists
  • Create a new object by attributes and run it against the Icinga 2’s config validation
  • Check if the change already exists by reading the `changes` directory
  • Add the change to the changelog (for calling ‘commit’ later on)

This is perfectly fine for keeping the same functionality shared among several occasions where this code is used. But we’ve run into severe performance issues with like 20000 calls to AddObject() inside one ‘node update-config’ run.

How to tackle the problem

Valgrind provides a tool named callgrind which tracks the function calls and time of a specific binary being run. While this is a bit slower than the Google perftools, it provides more detailed data. The ‘callgring.out.PID’ file can then be visualized in KCacheGrind.
Install Valgrind alongside with KcacheGrind. I’m using Fedora 21, other distributions use similar package names.

# yum install valgrind kcachegrind graphviz

In order to profile Icinga 2 with all debug symbols included, I’m compiling Icinga 2 with debug symbols enabled: -DCMAKE_BUILD_TYPE=Debug (Note: Using Icinga 2 packages you’ll get a separate package).
Valgrind requires a bunch of parameters which are easier being modified in a small script. I’m also running the direct debug build binaries instead of the installed binary here. Generating some sort of huge debug config inside the Icinga 2 cluster and node inventory is left to the reader’s imagination 😉 (I’ll write a different blog post for that sooner or later).

# vim callgrind_icinga2
#!/bin/bash
valgrind \
-v \
--trace-children=yes \
--tool=callgrind \
--simulate-cache=yes \
--collect-jumps=yes \
--dump-instr=yes \
--dump-line=yes \
/home/michi/coding/icinga/icinga2/debug/Bin/Debug/icinga2 node update-config
# sudo ./callgrind_icinga2

If you want to enforce a manual dump before the program ends, you can invoke the following command:

# callgrind_control -d

 

Visualize and analyze the bottlenecks

Opening the callgrind.out file(s)

$ sudo kcachegrind callgrind.out.16903

unveiled that there were certain unnecessary calls to generic functions.

  • Getting objects/changes on each AddObject() call is useless
  • ‘node update-config’ would cause AddObject() to validate each object. But we know already we’re right not parsing user’s input from the cli arguments.

Solve the problem

Refactoring the code and allowing to pass one-time collected objects/changes as well as suppressing configuration validation solved the problem in the end. Still it unveiled that you should sometimes stop feature development and profile your own application 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

LConf bugfix releases & performance improvements

lconf_logoThere was definitely too much happening in 2014, and while there is progress to be seen on Icinga 2 and Icinga Web 2, LConf required some attention & love. Acknowledging bugs doesn’t automatically fix them, and we’d also like to have the Icinga 2 migration export for our customers ready to be used preparing the final migration in 2015. Furthermore we’ll definitely need to get better responding to bugs and feature requests on our redmine bug tracker.
Which is why the LConf taskforce was founded, the week before christmas holidays and even in our English speaking week. Four days full of code, drawings, swearing and whatnot. On the long run, we’ve fixed quite a few LConf backend bugs (not only Icinga 2), banged our head on LConf Icinga Web frontend bugs and finally tried to improve the export performance somehow. We’re also aware that the LConf Standalone Web gets more important these days when integrating it into the upcoming Icinga Web 2. Last but not least we’ve reviewed quite a few user contributed patches and integrated them upstream – thanks for that, keep up the good work!
In order to keep your installations safe, all the remaining bugfixes are applied to the existing 1.4.x branches. Which means we’re releasing the following versions today:

The LConf Export performance problem is addressed separately. Since we were required to change large parts of the code, it is released as beta version on top of the released 1.4.x branch, but as 1.5.0-beta (Changelog, Download). We did test and develop it using a rather huge ldap tree at a customer (25 min average export time down to 5 minutes), but it certainly requires your tests & feedback as well.
Merry Christmas from the LConf taskforce!
Achim, Alex, Michael & Markus

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Icinga 2 Entwicklungsstand 2014 – Webinar Reminder

logo_icinga3Morgen früh um 10:30 Uhr beginnt das letzte Webinar vor der CeBIT. Diesmal wollen wir auf das neue Icinga 2 eingehen und alle bisher vorgenommenen Änderungen der Milestones ansprechen.
Im Webinar werden wir einige Grundkonfigurationen kennenlernen, bis hin zur Einrichtung eines Clusters von zwei Nodes. Natürlich wollen wir im selben Schritt auf einige Unterschiede zu Nagios / Icinga eingehen und die Roadmap für Version 0.0.8 präsentieren.
Wer noch daran teilnehmen möchte, kann sich über unsere Webinarseite registrieren.
Eine Aufzeichnung des Webinars und die gezeigte Präsentation wird anschließend in unserem Webinar-Archiv online gestellt.
Cebit BlogWer Icinga 2 näher betrachten möchte, kann sich entweder über unser Kontaktformular bei uns melden oder uns auf der CeBIT im Open Source Park, Halle 6, an Stand E16 (310) besuchen. Um uns schneller zu finden, gibt es natürlich auch eine Wegbeschreibung.
Bis morgen im Webinar!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Graphing mit Graphite: NETWAYS Webinar

Graphite ist eine Open Source Graphing Lösung, welche sich aufgrund der Flexibilität und Skalierbarkeit auf Augenhöhe mit vergleichbaren Enterprise Lösungen befindet.
Morgen, den 06. November 2013 um 14:00 Uhr, werden wir diese in unserem Webinar vorstellen.
Hier werden wir unter anderem auf das Webinterface, die Handhabung sowie die Architektur eingehen. Die Registrierung erfolgt wie immer über unser Webinar-Center.
Anschließend findet sich in unserem Webinar-Archiv sowie auf unserem YouTube-Channel das Webinar-Video sowie die Präsentationsfolien.
Übrigens: Bereits nächste Woche, am 13. November um 14:00 Uhr, findet unser erstes Webinar zu Icinga 2 statt. Also jetzt jetzt noch schnell registrieren!
Wir freuen uns auf eine rege Teilnahme!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Profiling mit gperftools

Eines der bekanntesten Profiling-Tools unter Linux ist wohl Valgrind. Valgrind instrumentiert die zu profilende Anwendung und kann so jeden einzelnen Funktionsaufruf nachverfolgen. Allerdings läuft die Anwendung dadurch um ein Vielfaches langsamer ab, als wenn sie ohne Profiling gestartet wird.
Abhilfe schaffen hier Sample-basierte Profiler wie z.B. gperftools. Anstatt jeden Funktionsaufruf mittels Instrumentierung “aufzunehmen”, erstellt gperftools in regulären Intervallen Stack-Snapshots der einzelnen Threads und erkennt so, welche Funktionen häufig aufgerufen werden.
Unter Debian kann gperftools per Paketmanager installiert werden:

# aptitude install google-perftools

Über die Environment-Variable CPUPROFILE können wir angeben, wo gperftools seine Profile-Dateien erstellen soll. Mit LD_PROFILE linken wir den Profiler zur Laufzeit in unser Programm:

$ CPUPROFILE=/tmp/profile LD_PRELOAD=/usr/lib/libprofiler.so ./bin/icinga2 -c ../master.conf

Mit google-pprof kann anschließend die Profile-Datei angezeigt werden:

$ google-pprof ./bin/icinga2 /tmp/profile