Viel hilft viel? Nicht immer.

Wenn Systeme gesized werden, fällt üblicherweise bald die Frage: “Was brauchen wir denn besonders viel? CPU? Ram? I/O?” Elasticsearch ist ein schönes Beispiel, in dem man einfach antworten kann: “Alles!” Es braucht CPU, Ram, I/O, Platz, Netzwerkdurchsatz und alles möglichst viel. Tatsächlich braucht es eigentlich möglichst viele Maschinen, die dann jeweils von allem etwas mitbringen – daher auch die Empfehlung, immer auf Hardware zu setzen, weil sonst irgendwas zum Flaschenhals wird (z.B. das SAN).

Es gibt aber eine Ausnahme und schuld ist, wie so oft ( 😉 ): Java. Gibt man Java zu viel Ram, stellt es intern die Verwaltung seiner Pointer um und verliert dadurch so viel Performance, dass man noch ziemlich viel zusätzlichen Ram drauf schmeissen muss, um das wieder auszugleichen. Die genauen Zahlen variieren, liegen aber ungefähr so: Wenn man eine Schwelle überschreitet, die zwischen 30 und 32GB liegt, fällt die Performance so ab, dass man erst bei ca. 46GB wieder auf dem Stand von vor Überschreiten der Schwelle ist. Die ca. 16GB sind also verloren.

Da die Schwelle aber variabel ist, trägt man entweder zu niedrig an oder überschreitet sie unbemerkt. Elasticsearch bietet dabei aber eine einfache Möglichkeit, herauszufinden, ob die Schwelle schon überschritten wurde:

$ curl -s -XGET http://elastic02-hot.widhalm.or.at:9200/_nodes | jq '.nodes[].jvm.using_compressed_ordinary_object_pointers'
"true"
"true"
"true"
"true"
"true"

Dabei fragt man über die API eines Knoten den Zustand aller Knoten ab. Wenn so viele true als Antwort kommen, wie Knoten im Cluster sind, dann ist alles ok. Jedes false zeigt einen Knoten, der zu viel Ram zur Verfügung hat. Gesetzt in /etc/elasticsearch/jvm.options. Als Lösung: Einfach weniger Ram eintragen und die Knoten neu starten (immer nur dann, wenn der Cluster gerade im Status “green” ist)

Wer jq noch nicht installiert hat, sollte das nachholen, da damit wunderbar JSON geparsed werden kann. Ein paar Beispiele gibt’s hier.

Den Check würde ich übrigens regelmässig wiederholen. Ich habe noch keine genauen Daten, wie sich z.B. Updates darauf auswirken und ob sie nicht auch wirklich variabel sein kann.

(Photo by Liam Briese on Unsplash)

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

OSDC 2016: More for your datacenter stack

We need more coffee – the first talk of day 2 directly kicked off with automation and challenges. We are using Foreman at NETWAYS and it helps me on a daily basis to deploy development boxes with Opennebula. So it was interesting to find out about insights and challenges by Julien Pivotto with Automating a R&D lab with Foreman: What can be hard?.


Sadly the second talk about Interesting things you can do with ZFS by Allan Jude & Benedict Reuschling was at the same time – again one for the conference archive.


Decisions decisions. Mesos and the Architecture of the New Datacenter by Jörg Schad or Hybrid Cloud – A Cloud Migration Strategy by Schlomo Shapiro. I guess I’m one of those devops hipsters going for Mesos. Although I hear that its implementation can be tricky (hi Sebastian) we’re using it at NETWAYS and I wanted to learn more about it. Especially since Mesosphere recently announced DC/OS.


Ingesting Logs with Style sounds like a swiss army knife presentation style. Logs always remind me of the days when there was not Logstash or Graylog around, just some unacceptable expensive Splunk license and your own central syslog server plus some custom handmade scripts. Pere gave an awesome outlook on what’s coming with Elastic Stack 5.0 including hist sports activities as live demos.


Everyone knows about Docker. Everyone uses it in production already? Or at least tried to until the company’s security team stepped into? Inspecting Security of Docker formatted Container Images to find Peace of Mind provided insights on the most often asked questions when it comes to production deployments.
Right after lunch David Schmitt gave an interesting Introduction to Testing Puppet Modules. Being a developer and writing tests? Meh. The least exciting part right after the documentation bits. Though tests will make your life easier especially with Puppet modules ensuring they won’t break. The talk’s topic also reminds me of Tom de Vylder maintaining the Icinga puppet modules and insisting on rspec tests on every single PR – chapeau 🙂


Coming from MariaDB Colin Charles provided tipps and tricks on Tuning Linux for your Database.


An Introduction to Software Defined Networking (SDN) by Martin Loschwitz or Bareos Backup Integration with Standard Open Source Tools with Maik Aussendorf?


Finally the last talks for this years OSDC. We already learned about Puppet and Salt, now it is time for Kaiten Zushi – Chef at Goodgame Studios by Jan Ulferts. Florian Lautenschlager with Chronix – A fast and efficient time series storage based on Apache Solr was again my favourite for the conference archive.
 

Thank you and see you in 2017

The conference archive will be made available in the next couple of days. Save the date – 16.-18.5.2017 🙂
PS: Everything is a freaking DNS problem!

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...

MySQLTuner – Wenn es schnell gehen muss

Informationen zur Optimierung einer MySQL Datenbank gibt es im Web in nahezu endloser Fülle. Auch die vorhandene Lektüre, wie z.B. “High Performance MySQL” ist detailliert und gibt auch Einsteigern nützliche Tipps an die Hand um Engpässe auf dem eigenen Server zu ermitteln und idealerweise zu eliminieren.
mysqltuner-logoWer weder die Zeit hat sich intensiv einzuarbeiten, noch diverse Fachbücher zu studieren, dem kann MySQLTuner ein hilfreiches Werkzeug sein. Das Perlscript ermittelt anhand der vorhandenen Statistiken mögliche Bottlenecks und zeigt entsprechende Optimierungspotentiale im Form von Empfehlungen und konkreten Einstellungshinweisen.
Neben der Prüfung verschiedener Hit Ratios errechnet MySQLTuner auch den maximal benötigten Speicher der aktuellen Konfiguration. Hier lassen sich mögliche Probleme bei Nutzung der zugelassenen Connection erkennen und vermeiden.
Installation:

wget http://mysqltuner.pl
chmod +x mysqltuner.pl
./mysqltuner.pl

Output:

 >>  MySQLTuner 1.0.0 - Major Hayden
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.51a-24+lenny1
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 1G (Tables: 86)
[--] Data in InnoDB tables: 176M (Tables: 120)
[--] Data in MEMORY tables: 124K (Tables: 1)
[!!] Total fragmented tables: 17
-------- Performance Metrics -------------------------------------------------
[--] Up for: 16d 1h 27m 51s (212M q [153.460 qps], 2M conn, TX: 27B, RX: 14B)
[--] Reads / Writes: 50% / 50%
[--] Total buffers: 58.0M global + 2.6M per thread (100 max threads)
[OK] Maximum possible memory usage: 320.5M (15% of installed RAM)
[OK] Slow queries: 0% (100/212M)
[OK] Highest usage of available connections: 36% (36/100)
[OK] Key buffer size / total MyISAM indexes: 16.0M/120.5M
[OK] Key buffer hit rate: 99.8% (63M cached / 99K reads)
[OK] Query cache efficiency: 31.3% (8M cached / 27M selects)
[!!] Query cache prunes per day: 23191
[OK] Sorts requiring temporary tables: 0% (87 temp sorts / 103K sorts)
[!!] Joins performed without indexes: 3446897
[OK] Temporary tables created on disk: 0% (830 on disk / 4M total)
[OK] Thread cache hit rate: 99% (1K created / 2M connections)
[!!] Table cache hit rate: 0% (64 open / 47K opened)
[OK] Open file limit used: 1% (20/1K)
[OK] Table locks acquired immediately: 99% (60M immediate / 60M locks)
[!!] InnoDB data size / buffer pool: 176.7M/8.0M
-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    Adjust your join queries to always utilize indexes
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    query_cache_size (> 16M)
    join_buffer_size (> 128.0K, or always use indexes with joins)
    table_cache (> 64)
    innodb_buffer_pool_size (>= 176M)

Beachten sollte man, dass sich nach Änderung von Parametern und Neustart des Servers einige Empfehlungen ändern, die auf Basis von Laufzeitstatistiken ermittelt werden. Es macht also durchaus Sinn, dass System ein paar Stunden mit der neuen Konfiguration zu betreiben, bevor man erneut Rückschlüsse aus den gewonnenen Informationen zieht.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.