[wiregate] - √ - RRD Files sind plattformabhängig

[greentux]

Ich habe meinen allgemeinen Web/Media/File/Virtualisierungsserver mal einem Hard- und Softwareupdate unterzogen.
Dabei ist auch Ubuntu 64 Bit auf der Platte gelandet. Diskussionen über 32 vs 64 Bit möchte ich hier nicht führen, es gibt Gründe.

Bis dato hatte ich alle 15 Minuten die rrd-Files vom WG auf den Server geschoben, um sie dort aufbereitet auch anderen Personen (Heizungsbauer, Architekt) zugänglich zu machen.

Dies funktionierte nun nicht mehr, da die rrd-Datenbank plattformspezifisch ist, sprich, rrd die auf i386 (32 Bit), mipsel, mips, arm oder AMD64 (64 Bit) erzeugt wurden, können auf jeweils anderen Plattformen nicht bearbeitet und dargestellt werden!

Ein "workaround" ist, die rrd zu dumpen (auf dem WG) und auf dem Server zu restoren, also als xml zu übertragen. Allerdings ist das dumpen eine zeitfressende Angelegenheit. Meine 100 rrd brauchen dazu auf dem WG mehr als eine Stunde - bei Vollast.

Eine echte Lösung könnte rrdtool 1.5.x bringen, welches dann plattformunabhängig funktionieren kann.

Klar, kann man auch die 32 Bit rrdtools in das 64 Bit System frickeln, was aber auch nicht schön ist.
Bis dahin bleibt mir das drraw auf dem WG, um die rrd etwas aufzubereiten.

Ggf. kommt der ein oder andere mal in die Verlegenheit und muss dann nicht lange suchen.

Ich mich wieder jemand falsch versteht: Das WG kann da nix dafür !!!

[Tuxtom]

Hallo,

Diskussionen über 32 vs 64 Bit möchte ich hier nicht führen, es gibt Gründe.

Gibt es noch Gründe, nicht auf 64Bit zu gehen - die Frage stellte sich beim Aufbau meines Server überhaupt nicht.
- Ubuntu 12.04 LTS 64Bit als Plattform und gleichzeit als NAS
- virtuelle Win7-Maschine, 64Bit, für mein IP-Symcon
- virtuelle Ubuntu-Maschine, 64Bit als Webserver
- virtuelle Ubuntu-Maschine, 64Bit für eMail usw.

hab dem Server natürlich auch mit einem Core-i5 3,1Ghz und 32GB Ram ordentlich Futter gegeben.


RRD ist ein leidiges Thema, damit haben wir uns in der Firma auch bereits rumgeschlagen, weil einer unsere Kollegen als Hobby hat, alles an messbaren Grössen "seines" Systems in RRD-Graphen zu packen, da ist unsere Server irgentwann man in die Knie gegangen und einer mit mehr Power musste her. Klar das der auf 64Bit lief, sonst macht es keinen Sinn.

Nach unzähligen erfolglosen Versuchen, die vorhanden Daten zu migrieren, haben wirs aufgegeben und einen harten Schnitt gemacht. Alle alten Daten gelöscht und mit einer leeren RRD-Installation begonnen.

Wir haben sogar Anfragen an das Entwicklerteam geschickt, aber irgentwie hatten wir den Eindruck, die interessiert das nicht wirklich und die Tipps waren mit einer leeren Datenbasis anzufangen.

Nächster Schritt wird aber sein, das wir RRD komplett entsorgen und auf andere Alternativen umsteigen, wir testen derzeit ein paar System auf die Nutzbarkeit.

[swiss]

Naja ich will ja die Diskusion um 32bit vs. 64bit nicht entflammen aber ich bin absolut kein Fan von 64bit. Gezwungenermassen habe ich auch PC's mit 64bit Betriebssystem drauf (gibt ja fast nix anderes mehr zu kaufen) aber sobald man sich mit etwas spezielleren Dingen wie Microkontrollerprogrammierung auseinandersetzt ist 64bit eher Fluch als Segen. Ich habe noch keinen günstigen Programmer für ATMEL gefunden der mit 64bit funktioniert Und das Problem habe nicht nur ich... Fast jeder der ein etwas älteres Gerät mit einem Konfigurationstool hat stöst schnell mal auf Probleme. Was ich alles an Software und Tools nicht mehr verwenden kann nur weil die Computerindustrie das Rad neu erfinden musste -.- -> so ein Müll. Und für was? Otto braucht bestimmt kein 64bit BS zumal viele Programme garnicht echt in 64bit arbeiten... Just my 5ct

[greentux]

ich wusste, es geht schief. Mach ich mal zu. Wer das Problem hat, weiss zumindest mal Bescheid.

[greentux]

Ah toll. Man kann als TE gar nicht zumachen. Na dann..

[Chris M.]

Tip: Auch unter meinem 64 Bil Linux laufen unter VirtualBox wunderbar 32 Bit Betriebssysteme.

Ändert zwar nicht das grundsätzliche Problem mit den RRDs - aber wenn's auf einer potenten Maschine ist, sollte sich so harmlos und schnell die Daten in was lesbares konvertieren lassen...
(Oder µC Entwicklungsumgebungen installieren lassen; Programme für's WireGate kompiliere ich übrigens genau so )

[makki]

Hmm, das ist dann wohl so..

Gibt es noch Gründe, nicht auf 64Bit zu gehen

Ja, mindestens 64.
Um nur einige zu nennen:
- das WG ist ein 32bit 586er (vergleiche vorm Widerspruch bitte mit den ARMen der anderen) - und bleibt es auch, weil es schluckt <5W, mag u.a. an dem Verzeicht auf 64Bit-Bloatware liegen
- die Welt braucht es nicht
- Mein Desktop läuft prächtig mit Ubuntu@32bit
uvm.

Makki

[StefanW]

Guten Morgen,

Man kann als TE gar nicht zumachen.

Ich weiß zwar nicht warum dies in der Forensoftware so eingestellt ist, aber ich kann den Thread gerne für Dich schließen.

Allerdings sind wir selbst damit äußerst zurückhaltend, weil das das "Abwürgen" einer Diskussion bedeutet und von manchen als "ärgerlich" aufgefasst wird. Persönlich fand ich das jetzt nicht so uninteressant, weil die verschiedenen Gründe für 32/64 Bit interessant sind. Allerdings ist es auch am Thema vorbei.

@all: Respektieren wir doch bitte den Wunsch des TE, nicht über 32 vs. 64 Bit zu diskutieren sondern OnTopic das Thema Plattformabhängigkeit der RRDs

Aber es ist Dein Thread, wenn Du willst....

Stefan

[greentux]

ich werde heute Nachmittag noch ne kleine Variante der Lösung probieren und hier ggf. posten.
Virtualbox wegen nem rrdtool + perl ist bischen oversized...

[makki]

Also, hab da jetzt auch nochmal gesucht:
(bekannt wars mir schon länger, aber eher wegen arm), mir fällt nichts besseres als dump/restore ein, wenn man die RRDs auf der Maschine braucht.

Was ich nicht verstehe: warum dauert das dumpen von 100 ne Stunde?? Evtl. nen lahmen Stick genommen oder so?
Wenn ich das hier auf einem WG mit satter Grundlast und 128 RRDs (auf ein cifs/smb-NAS) mache:

wiregate1:~# time ./rrddump.sh 

real	9m17.182s
user	2m23.949s
sys	0m53.427s

-> Die meiste Zeit geht auf I/O, weil er schreibt dabei aber halt flockige 456 MB an xml weg, bei 52MB Quell-rrds.. (soviel zum Thema effiziente Datenspeicherung )

Selber Versuch auf ein schnelles NFS-Share:

real	8m51.458s
user	2m23.937s
sys	0m53.515s

(bringt also nix)
Netzwerk-Durchsatz dabei: 9-12 MB/s (MegaByte, nicht Bit also volle 100MBit, mehr geht ned..)

Weils so lustig ist, dasselbe aufm i7 auf/von SSD

markstaller@v3750mm:~/temp/rrd$ time ./rrddump.sh 

real	0m10.159s
user	0m7.072s
sys	0m0.872s

-> Was ich mir so aus der hohlen Hüfte machen würde: eine (statisch gelinkte) rrdtool 32bit binary auf der dicken Büchse, RRD's per rsync holen, lokal konvertieren..

Makki

Edit/PS: ja das hat bei mir was getriggert, weil wir haben etwa 12.000 RRDs im Monitoring, und der restore tut weh (64Bit Ubuntu auf nem Xeon E5502 @ 1.87GHz):

rrdtemp# time ./rrdload.sh 

real	0m29.418s
user	0m28.438s
sys	0m0.536s

Jetzt bin ich mir wieder sicher, das die neue VM dafür 32bittig wird

[greentux]

Ich habe halt 250 MB RRDs (aud die SSD gedumpt) und das dauert dann eben. Ausserdem hat die Kiste dann Last. Und bei Last schlägt vermutlich Monit wieder zu.
Und irgendwie ist das einfach nihct richtig. Dauernd CPU und Netz zu belästigen, weil die RRD-Jungs das Feature seit 1.3 vor sich her schieben
Es betrifft ja, wenn man googled, auch die gnazen Jungs, die ihre Netzwerkmonitoringsysteme verschieben usw.

Egal, ich habe mir ein Mini-chroot in 32 Bit gebaut. Dort läuft nun ein lighttpd, der das nun alles wieder schön ausliefert.


Statisch linken kannste probieren. Mir war die Zeit zu Schade. Ist zwar im configure vorgesehen, die beteiligten Libs machen da aber tlw. nicht mit. Ein rrdtool included ja die halbe Welt. Vermutlich testet das keiner.

Na, denn es läuft. Alles prima.
Jetzt kommt die Windows VBox für unsere prima ETS

[makki]

Gut mit Faktor 5, (gleicht vermutlich Faktor 50 xml) macht das Sinn..
Die CF-SLC macht etwa 10 MB/s beim schreiben - ist keine Rakete, wurde halt auf jahr(zehnte) Stabilität und Datenintegrität ausgesucht, nicht nach Performance.. (braucht man normalerweise ja auch nicht..)

Dämlich finde ich, das es (wenigstens bei den aktuellen Versionen des rrdtool!?) nicht einfach ne Option gibt wie "schreib/lese doch einfach bitte i386" oder so statt mir zu erzählen "This RRD was created on other architecture"
Die Welt ist nicht perfekt..

Makki

P.S.: OT: Mit VirtualBox bin ich für solche Locken wie ETS übrigens sehr zufrieden, wenn man nicht den Fehler macht und sich Linux installiert um dann den ganzen Tag die Windows-VM zu nutzen
PPS: Die Vbox-VM immer vor dem suspend des Hosts suspenden, sonst knatscht bei mir - Stand bis heute - das Netzwerk danach..

[NetFritz]

Hallo
Habe das dazu gefunden.

To transfer an RRD between architectures, follow these steps:

1. On the same system where the RRD was created, use rrdtool dump to export the data to XML format.
2. Transfer the XML dump to the target system.
3. Run rrdtool restore to create a new RRD from the XML dump. See rrdrestore for details.

Gruß NetFritz

[greentux]

Ja das war schon bekannt. Ist aber nicht praktikabel, ausser bei einer Migration.

[JuMi2006]

Ein "workaround" ist, die rrd zu dumpen (auf dem WG) und auf dem Server zu restoren, also als xml zu übertragen. Allerdings ist das dumpen eine zeitfressende Angelegenheit. Meine 100 rrd brauchen dazu auf dem WG mehr als eine Stunde - bei Vollast.

Gibt es da schon neue Erkenntnisse ?
Ich würde gern meine RRDs vom Raspberry auch auf dem Wiregate haben ...

Grüße