Seite wählen

NETWAYS Blog

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  | 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
Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

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

#osdc moa 5 starts w/ @roidelapluie from @inuits on managing a R&D lab with @ForemanProject /mif pic.twitter.com/soED2QNoKO

— netways (@netways) April 28, 2016


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.

Allan Jude and Benedict Reuschling just started their talk "Interesting Things you can do with ZFS" /mn pic.twitter.com/i0J9ub6Rkw

— netways (@netways) April 28, 2016


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.

.@mesosphere DC/OS #osdc pic.twitter.com/60PdU1Ljq7

— netways (@netways) April 28, 2016


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.

Real life @elastic stack demo from @purbon 's sports activities 🙂 #awesome #osdc /mif pic.twitter.com/XAA83HqTCG

— netways (@netways) April 28, 2016


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 🙂

@dev_el_ops talking about @puppetize testing at #osdc (rspec, rspec-puppet, beaker) pic.twitter.com/J8ZA7LIPqT

— mika (@mikagrml) April 28, 2016


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

. @bytebot from @mariadb is now on stage, talking about Tuning Linux for your Database! /mn pic.twitter.com/F6bQtRIM8p

— netways (@netways) April 28, 2016


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

An introduction into SDN with @madkissTM at #osdc/be pic.twitter.com/InUn6I6Klp

— netways (@netways) April 28, 2016


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!

@dnsmichi @bortzmeyer @jpmens I`m actually writing a book on the topic pic.twitter.com/uRhqhNV1J2

— Kris Buytaert (@KrisBuytaert) April 28, 2016

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:
[code lang=“shell“]wget http://mysqltuner.pl
chmod +x mysqltuner.pl
./mysqltuner.pl[/code]
Output:
[code lang=“shell“]
>> MySQLTuner 1.0.0 – Major Hayden
>> Bug reports, feature requests, and downloads at
>> 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)[/code]
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 startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er 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 seinen beiden Söhnen und seiner Tochter.