Open Source im professionellen Einsatz

Auf den Punkt gebracht

Leserbriefe

Zeitschriften scannen

03/11, S. 116: Beim Nachvollziehen des Perl-Snapshots "Am Fließband" komme ich nicht weiter. Wenn ich das Skript »scan.sh« ausführe, erhalte ich folgende Fehlermeldung:

./scan.sh: Zeile 6: $1: Mehrdeutige Umlenkung

Ändere ich »#!/bin/bash« in »#!/bin/sh« erhalte ich diese Fehlermeldung:

./scan.sh: 7: cannot create : Directory nonexistent

Ich habe mich an Ihre Anleitung gehalten und habe auch die notwendigen Schritte unter dem Punkt "Installation" durchgeführt. Haben Sie einen Tipp für mich?

Tilo Zielke, per E-Mail

Das Shellskript erwartet als Parameter den Namen der Bilddatei, in der es das gescannte Dokument ablegt. Zudem habe ich das Skript für private Zwecke später mit einer vereinfachten Suchfunktion umgeschrieben. Die Originalversion verlangt und verträgt keine Leerzeichen im Magazinnamen, die verbesserte Version auf http://perlmeister.com/tmp/magsafe2 versteht hingegen , erfordert aber andere Zusatzmodule vom CPAN. (Mike Schilli)

Atop-Macken

07/11, S. 72: Vielen Dank für den interessanten Artikel. Ich habe Atop gleich auf einem Teil meiner Server installiert sowie für die Langzeitanalyse das im Schlussabsatz genannte Collectd. Dabei stieß ich auf unerfreuliche Phänomene: Erstens scheint Collectd für seine vielen Auskünfte auch viel Disk-I/O zu erfordern. Zumindest auf Collectd-Servern und -Gateways für mehrere Maschinen steigt die Last extrem, was auf Geräten mit SAS-Platten und Hardware-Raid beziehungsweise externem Raid mit FC-4-GBit/s-Anbindung etwas verwundert (Bonnie++: Blockwrite 285211 K/sec). Zweitens übertreibt Atop in der Anzeige des Disk-I/O zusätzlich: 108 Prozent erinnern regelrecht an sozialistische Zeiten (Abbildung 1). Bei laufendem Bonnie++ können auch über einige Zeit 112 Prozent erreicht werden. Haben Sie eine Erklärung – oder besser eine Lösung – dafür?

Abbildung 1: Beim Festplatten-I/O scheint Atop zu übertreiben, wenn es busy 108% meldet.

Andreas Matthus, per E-Mail

Das erste Problem ist im Aufbau der RRD-Dateien begründet. Jede RRD-Datei enthält eine oder in der Regel mehrere Round Robin Archives (RRA), üblicherweise für unterschiedliche Zeitauflösungen, etwa pro 5 Minuten, pro 15 Minuten, pro Stunde. Bei einer vollen Stunde muss die Software diesen Wert in drei verschiedene RRA der Datei schreiben. Collectd misst alle 10 Sekunden und auch bei wenigen geschriebenen Bytes muss der Rechner komplette Pages aktualisieren. So kommen viele Schreibvorgänge zustande. Daher sollten Sie Collectd mit Caching laufen lassen. Das Plugin erlaubt ein Tuning über die Parameter und . In größeren Deployments dürfte jedoch der Einsatz des Daemon RRD Cached sinnvoller sein.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 1 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Als digitales Abo

Als PDF im Abo bestellen

comments powered by Disqus

Ausgabe 07/2013

Preis € 6,40

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook