Storj - Potential?

[GhostTyper]

Am 21.5.2020 um 16:51 schrieb Heisenberg420:

Die Nodes die ich im Datencenter laufen hab sind nicht der Rede wert.. Irgendwie wollen die nicht so richtig. Kann das ein Zeichen dafür sein dass sich in dem Netz schon Nodes befinden?

Ja, kann sein.

Sag' mal IP-Bereich? Gerne auch per PM.

Also meine laufen ganz gut, außer dass ich seit 3 Tagen wieder kaum Traffic hab'.

[Heisenberg420]

Der Traffic ist ein Witz xD

Was aber noch mehr Witz wie ich finde ist:

Mein Node 1 wurde heute Nacht von allen Satelliten suspendiert, auf Nachfrage per Nachricht warum, da mein Log zwischen 1.30 Uhr und 9.30 Uhr nicht geschrieben wurde bekam ich nur ne lasche Antwort "Das sei kein Geheinmis, ich soll nach Failed Audits suchen. Findet Ihr den Fehler? Wie soll ich ins Log schauen wenn keines vorhanden ist?

 

Generell ist es ziemlich dumm (sorry anders kann ich es nicht nennen) von Storj die Nodes ohne irgendeine Info zu suspendieren. Man weiß doch gar nicht warum.

Mal ne Info dabei WARUM wäre nicht schlecht damit man auch mit der Fehlerbeseitigung beginnen kann oder man weiß was man falsch gemacht hat.

 

Mitterweile wurde die Suspendierung aufgehoben. Hä? Was war da jetzt los? Ich stehe völlig im Dunkeln. Aber das ist die Logik von Storj.. und so wird das Forum von Tag zu Tag weiter mit Themen vollgemüllt warum man suspendiert oder sogar disqualifiziert wurde.

 

Warten wir es mal ab wie es mit Storj weitergeht 😂 Denn wenn es so weiter läuft wie bisher wird das nix. Der Repair Traffic lohnt sich diesen Monat wenigstens, da scheinen mittlerweile viele auszusteigen.

 

[micro1]

Ja der Traffic ist low. Ich frage mich ob es wirklich Kunden gibt. Aber Storj sagt ja das bereits vorhanden Hardware verwendet werden soll. Also ist jeder Cent Gewinn 

[GhostTyper]

vor 2 Stunden schrieb Heisenberg420:

Der Traffic ist ein Witz xD

😕 Auf storj4, 5 und 8 hatte ich diesen Monat ingress von insgesamt 14 TB.

Ich gehe Mal meine Verdienste und meinen Traffic durch:

Node    Disk Frei/Ges.     Egress     USD
storj0   2.1 /  5.5 TB   196.7 GB   $6.71
storj1   2.1 /  5.5 TB   140.9 GB   $5.61
storj2   2.6 /  8.0 TB   167.5 GB   $6.35
storj3   2.2 /  8.0 TB   172.1 GB   $6.01
storj4   4.7 /  8.0 TB   299.0 GB  $11.47
storj5   4.7 / 10.0 TB   308.3 GB  $11.63
sotrj6   2.4 /  8.0 TB   156.7 GB   $6.06
storj7   2.7 /  8.0 TB   211.3 GB   $7.06
storj8   7.4 /  8.0 TB   476.5 GB  $18.15
storj9   0.6 / 20.0 TB    30.8 GB   $0.96
storja   0.0 /  0.7 TB     1.5 GB   $0.04
storjb   0.0 /  0.7 TB     1.3 GB   $0.04
Total   31.5 / 90,4 TB  2163.8 GB  $80.09

Das heißt, ich kann ungefähr von bisschen über 250 USD pro Monat ausgehen, wenn alles voll wird und der Egress ungefähr gleich bleibt.

storj9 ist sehr neu, storja und b sind zum Aufwärmen gedacht.

vor 2 Stunden schrieb micro1:

Ich frage mich ob es wirklich Kunden gibt.

Welche Daten hast Du denn um fest zu machen, dass es, oder dass es keine Kunden gibt? Ich denke, da musst Du ihnen vertrauen.

[Heisenberg420]

vor 2 Stunden schrieb micro1:

 Aber Storj sagt ja das bereits vorhanden Hardware verwendet werden soll. Also ist jeder Cent Gewinn 

Natürlich, was den Verdienst angeht beklag ich mich auch nicht. Der Repair Traffic macht diesen Monat den fehlenden Traffic bei mir fast wieder gut.

Die Fehlersuche ist nur schwierig

Die Suspendierung ist ja eine gute Sache, aber es muss ein Grund her der gleich im Dashboard einsehbar ist. Für viele ist hier dann schon oft das Ende weil sie einfach nicht wissen was sie tun sollen, ich weiß ja heute auch nicht was ich getan habe um suspendiert zu werden und was ich getan habe damit die Suspendierung wieder entfernt wurde 😂

Ich denke dass es auch bald wieder mehr wird, in den letzten Tagen wurde ja wieder viel an den Satelliten gearbeitet das heißt dass auch bald wieder (schätze ich) Test Daten kommen werden. Immerhin.

Kunden wird es auch früher oder später geben, Duplicati hat Storj ja bereits integriert. Die Frage ist wie groß ist Storj bereits? Wieviele PB hat das Netzwerk? Es gibt ja keine Statistik bis auf storjnetinfo und ich denke es gibt zum jetzigen Zeitpunkt einfach zu viele SNOs für zu wenige Kunden. Deshalb war der Vorschlag im Forum m.M. nach gar nicht mal so falsch die SNO Anmeldung eine Zeit lang zu deaktivieren.

[GhostTyper]

vor 43 Minuten schrieb Heisenberg420:

Deshalb war der Vorschlag im Forum m.M. nach gar nicht mal so falsch die SNO Anmeldung eine Zeit lang zu deaktivieren.

Ich hab' das zwar nicht gesehen im Forum, finde das aber generell nicht so gut. Die Mehrheit des Traffic ist halt noch Test-Traffic, aber so lange dieser wenigstens da ist, ist ja alles gut. Und man kann schon gut Ingress haben in so einem Fall...

Ich kannte die storjnetinfo-Statistik noch nicht. Finde es aber interessant, dass die meisten Nodes aus Deutschland kommen. XD

vor 48 Minuten schrieb Heisenberg420:

Der Repair Traffic macht diesen Monat den fehlenden Traffic bei mir fast wieder gut.

Wie viel % Repair-Traffic hast Du?

[skunk]

vor 15 Stunden schrieb Heisenberg420:

Mein Node 1 wurde heute Nacht von allen Satelliten suspendiert, auf Nachfrage per Nachricht warum, da mein Log zwischen 1.30 Uhr und 9.30 Uhr nicht geschrieben wurde bekam ich nur ne lasche Antwort "Das sei kein Geheinmis, ich soll nach Failed Audits suchen. Findet Ihr den Fehler?

Die Antwort ist korrekt. Derzeit kann man nur für Failed Audits suspendiert werden. Auch ohne ins log zu schauen kannst du dir bereits sicher sein, dass deine Storage Node nicht ordentlich läuft. Warum das so ist, kann dir niemand sagen. Remote Support und so.... Der Fehler ist, dass du Remote Support erwartest.

vor 16 Stunden schrieb Heisenberg420:

Wie soll ich ins Log schauen wenn keines vorhanden ist?

Logdatei hast du konfiguriert? Falls nicht dann wäre das die Lösung um beim nächsten mal eine Logdatei zu bekommen. Falls du eine Logdatei hast aber da nichts drin steht, so würde ich mal darauf tippen, dass deine Festplatte, auf die du die Logdatei schreibst, nicht verfügbar war oder voll war. In dem Fall würden auch die Audits versagen. Ich halte auf meinen Storage Nodes so 30GB frei damit das nicht passiert.

vor 16 Stunden schrieb Heisenberg420:

Generell ist es ziemlich dumm (sorry anders kann ich es nicht nennen) von Storj die Nodes ohne irgendeine Info zu suspendieren. Man weiß doch gar nicht warum.

Mal ne Info dabei WARUM wäre nicht schlecht damit man auch mit der Fehlerbeseitigung beginnen kann oder man weiß was man falsch gemacht hat.

Die Suspendierung ist notwendig um einige Storage Nodes zu zwingen ihr Setup zu korrigieren. Ohne Suspendierung hätten wir nur die Wahl direkt für die Audit Fehler zu disqualifizieren weil wir ansonsten dem Kunden sagen müssten, dass seine Daten gerade nicht verfügbar sind weil einige Storage Nodes aktuell nicht auf Audits und Download Anfragen reagieren. Die Suspendierung ist notwendig um dem Kunden eine Hohe Verfügbarkeit zu garantieren.

vor 16 Stunden schrieb Heisenberg420:

Mitterweile wurde die Suspendierung aufgehoben. Hä? Was war da jetzt los? Ich stehe völlig im Dunkeln.

Wenn es bei einer Suspendierung bleibt, dann sehe ich da erstmal kein weiteres Problem. Du kannst über die API deinen Score im Auge behalten und so erkennen ob dein Score sich positiv oder negativ entwickelt. Auf dem Dashboard wird der Wert derzeit noch nicht angezeigt. Es ist gut möglich, dass du alle paar Tage erneut disqualifiziert wirst solange bis du den Fehler gefunden und behoben hast.

vor 16 Stunden schrieb Heisenberg420:

Aber das ist die Logik von Storj.. und so wird das Forum von Tag zu Tag weiter mit Themen vollgemüllt warum man suspendiert oder sogar disqualifiziert wurde.

Fast richtig. Die Logik von Storj ist es dem Kunden eine hohe Verfügbarkeit und hohe Geschwindigkeit zu bieten. Dazu ist es leider notwendig die schlechten Storage Nodes zu suspendieren oder sogar zu disqualifizieren. Natürlich sind sich die Storage Nodes keiner Schuld bewusst und werden das Forum aufsuchen. Ändern können wir daran nichts.

Die Tücke liegt häufig im technischen Wissen der Storage Nodes. Mein Server ist vor kurzem offline gewesen weil eine Docker Container der Meinung war all mein RAM zu fressen. Einfach nur weil ich vergessen hatte dem Teil ein Limit mit zu geben. Fehler gefunden, behoben und etwas dazu gelernt. Ich arbeite jetzt auch mit ZFS dank der Hilfe eines Kollegen. Jetzt ist es meine Pflicht die gewählten ZFS Parameter auch zu prüfen. Aktuell weiß ich noch nicht wie ich das überhaupt prüfen soll. Das ist für mich noch Neuland.

Was ich damit sagen will ist, dass du nicht drum herum kommst dich in einige neue Themen ein zu lesen. Eine schlechte Herangehensweise ist es die Gesprächspartner alle als Dumm zu bezeichnen. Damit kommt man in der Regel nicht sehr weit.

vor 13 Stunden schrieb GhostTyper:

Welche Daten hast Du denn um fest zu machen, dass es, oder dass es keine Kunden gibt? Ich denke, da musst Du ihnen vertrauen.

Da kannst du einfach nach Satellite gehen. Europe north und saltlake sind aktuell die Satellites mit Testdaten. Europe west, us central und asia east sind dagegen Kunden Daten.

Ich habe diesen Monat etwa eine Woche gebraucht um mein Server ans Netz zu bringen. Ich habe aus Dummheit 3 Versuche gebraucht um die Storage Node ordentlich zu migrieren. Wenn ich jetzt auf mein Dashboard schaue, dann hat ausgerechnet der Satellite mit den Kundendaten eine höheren Download Traffic im Verhältnis zum belegten Speicher. Das könnte aber an den fehlenden 7 Tagen bei mir liegen daher warte ich mal noch einen Monat ab bevor ich ein Resumé ziehe.

[GhostTyper]

vor einer Stunde schrieb skunk:

Da kannst du einfach nach Satellite gehen. Europe north und saltlake sind aktuell die Satellites mit Testdaten. Europe west, us central und asia east sind dagegen Kunden Daten.

Genau. Aber auch nur, wenn man der Aussage von Storj vertraut. ^^

Ich hab': 75% Test-Daten, und 25% Nutzdaten.

[skunk]

vor 4 Minuten schrieb GhostTyper:

Genau. Aber auch nur, wenn man der Aussage von Storj vertraut. ^^

Stimmt der Einwand ist berechtigt. Mir fallen da auch nicht viele Ideen ein um die Aussagen zu überprüfen. Du könntest einen Tardigrade Account anlegen und ein paar Daten hoch und runter laden. Damit kannst du zumindest prüfen ob es überhaupt eine Kundenseite geben kann. Ansonsten bliebe nur noch eine Protokollierung der IP Adressen von denen hoch und runter geladen wird. Ich glaube aber nicht, dass man damit den Unterschied zwischen Test und Echtdaten erkennen kann. Höchstens wenn da ein User Agent mit gesendet wird aber falls du irgend ein User Agent findest, wäre das ein Bug und müsste behoben werden. Im Idealfall hast du keine Möglichkeit zu erkennen wer da gerade Daten zu dir hoch lädt.

[GhostTyper]

vor 1 Stunde schrieb skunk:

Ansonsten bliebe nur noch eine Protokollierung der IP Adressen von denen hoch und runter geladen wird. Ich glaube aber nicht, dass man damit den Unterschied zwischen Test und Echtdaten erkennen kann.

Doch, ich denke, dass man das damit hinreichend gut erkennen kann. Natürlich ohne ultimative Gewissheit, denn folgende Möglichkeiten:

1. StorJ macht sich die Mühe und simuliert viele, viele Clients von unterschiedlichen IP-Adressen (Aufwand!) oder
2. Es sind ganz einfach viele Clients, bzw. zumindest viele Tardigrade-Tester und early adopters.
3. Es gibt keine verschiedenen Clients (verschiedene IP-Adressen) und wir werden alle betrogen.

Wenn man sich jetzt überlegt, was es StorJ bringt "echte" Clients derart aufwändig zu simulieren kommt man zu dem Schluss: Nichts. Denn solange sie Test-Traffic generieren ist der Sachverhalt für den SNO virtuell egal.

Und weil es keinen Grund gibt, dass uns StorJ betrügt gehe ich eher von der einfacheren und wahrscheinlicheren Variante aus: StorJ lügt nicht und meine älteste Node enthält in Wirklichkeit tatsächlich einfach nur 25% echte Daten und 75% Test-Daten. Who cares.

[Heisenberg420]

vor 9 Stunden schrieb skunk:

Der Fehler ist, dass du Remote Support erwartest.

Nein, nur dass jemand seitens Storj ins Log schauen könnte. Bei anderen Usern macht Ihr es ja auch manchmal.

 

vor 9 Stunden schrieb skunk:

Du kannst über die API deinen Score im Auge behalten und so erkennen ob dein Score sich positiv oder negativ entwickelt.

Node 1 Score Node 2 Score 🤷‍♂️

 

vor 9 Stunden schrieb skunk:

Fehler gefunden, behoben und etwas dazu gelernt.

Ich habe seit Wochen und Monaten ständig diesen Fehler im Log

ERROR	piecestore	download failed	{"Piece ID": "NOFEAV4IZN6NUU3ORUDDDJL36AMS7RKTG6E6JWOBK5OTIS7VTVDQ", "Satellite ID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Action": "GET", "error": "write tcp 172.17.0.4:28967->176.9.121.114:52414: use of closed network connection", "errorVerbose": "write tcp 172.17.0.4:28967->176.9.121.114:52414: use of closed network connection

Ich hoffe dass du mir das dann endlich mal erklären kannst, denn das ist der einzige Fehler der in meinem Log auftaucht.

 

vor 9 Stunden schrieb skunk:

Eine schlechte Herangehensweise ist es die Gesprächspartner alle als Dumm zu bezeichnen. Damit kommt man in der Regel nicht sehr weit.

Ich wollte damit niemanden persönlich beleidigen. Wenn es aber so rüber kam endsdchuldige ich mich dafür.

 

vor 22 Stunden schrieb GhostTyper:

Ich kannte die storjnetinfo-Statistik noch nicht. Finde es aber interessant, dass die meisten Nodes aus Deutschland kommen. XD

Fand' ich auch sehr Interessant, die Map ist aber nicht korrekt, in meiner Nähe taucht nicht ein Node auf und da müssten mindestens ja 2 sein

 

vor 22 Stunden schrieb GhostTyper:

Wie viel % Repair-Traffic hast Du?

Um die 22GB insgesamt. Ich sehe aber gerade dass das gar nicht viel ausmacht im Payout sondern meine neue Festplatte und die damit mehr genutzen PB*h .

 

Zm Abschluss des Monats einmal die Übersicht.

Node 1

                   Available       Used       Egress     Ingress
     Bandwidth           N/A     1.4 TB     204.1 GB      1.2 TB (since May 1)
          Disk        3.7 TB     3.5 TB

 

Node 2

                   Available       Used      Egress     Ingress
     Bandwidth           N/A     1.1 TB     63.0 GB      1.0 TB (since May 1)
          Disk        6.1 TB     1.1 TB

Node 3

                   Available       Used      Egress     Ingress
     Bandwidth           N/A     0.8 TB     76.8 GB      0.7 TB (since May 1)
          Disk        2.4 TB     1.5 TB

 

[skunk]

vor 21 Minuten schrieb Heisenberg420:

Nein, nur dass jemand seitens Storj ins Log schauen könnte. Bei anderen Usern macht Ihr es ja auch manchmal.

Den Anspruch auf persönliche Fürsorge haben ganz schnell alle User. Dafür fehlt uns schlicht die Zeit.

Bei dir ist der Fall doch recht eindeutig. Das Logging hat versagt. Du musst nur rausbekommen was da vorgefallen ist. War die Festplatte nicht verfügbar, voll oder gab es irgendwelche andere Gründe warum da nichts geloggt wurde. Für Offline sein würdest du nicht suspendiert werden daher ist die Wahrscheinlichkeit für andere Gründe sehr gering. Also tippe ich auf Festplatte nicht verfügbar oder voll. Was genau erwartest du im Satellite Log zu sehen?

vor 29 Minuten schrieb Heisenberg420:

Node 1 Score Node 2 Score 🤷‍♂️

 

Ich meinte eher die storage node dashboard API: https://forum.storj.io/t/storage-node-dashboard-api-v1-3-3/5275

[Heisenberg420]

vor 15 Minuten schrieb skunk:

nicht verfügbar

Ich denke dass das schlicht der Fall war. Ich habe Abends davor noch die alte StorjHDD ausgehängt. Da war noch alles ok aber genau in dem moment als ich das USB Kabel gezogen habe, genau dort hört das Log auf. Also wurde der Laufwerkspfad geändert. Da ich aber die UUIDs eingetragen habe hab ich da gar nicht erst dran gedacht. Ich kann es mir sonst nicht anders erklären.

 

Leider weiß ich noch immer nichts mit dem oben genannten Fehler anzufangen obwohl nun schon mehrfach im Forum und nun auch hier angesprochen.

Zu den Fehlern finde ich diesen ganz Aktuellen Thread im Storj Forum sehr Interessant.

[skunk]

vor 2 Stunden schrieb Heisenberg420:

Ich denke dass das schlicht der Fall war. Ich habe Abends davor noch die alte StorjHDD ausgehängt. Da war noch alles ok aber genau in dem moment als ich das USB Kabel gezogen habe, genau dort hört das Log auf. Also wurde der Laufwerkspfad geändert. Da ich aber die UUIDs eingetragen habe hab ich da gar nicht erst dran gedacht. Ich kann es mir sonst nicht anders erklären.

Leider weiß ich noch immer nichts mit dem oben genannten Fehler anzufangen obwohl nun schon mehrfach im Forum und nun auch hier angesprochen.

Ich kann dir nicht ganz folgen. Auf der einen Seite klingen deine Erklärungen zum USB Kabel ziehen und Laufwerkspfaden einleuchtend vor allem wenn sie wie du sagst mit den Zeiten aus dem Log überein stimmen. Auf der anderen Seite weiß du nichts mit dem Fehler an zu fangen? Hilfe mir mal auf die Sprünge wie ich dir da helfen kann. Wenn du das Problem bereits so gut eingegrenzt hast, dann ist das Rätsel doch gelöst.

vor 2 Stunden schrieb Heisenberg420:

Zu den Fehlern finde ich diesen ganz Aktuellen Thread im Storj Forum sehr Interessant.

Das Thema finde ich auch interessant muss aber zu Protokoll geben, dass es sich dabei um Upload Fehler und nicht um Audit Fehler handelt. Hat mit deiner Situation also eher nichts zu tun. Außerdem sehe ich dort nur die Bestätigung, dass das Netzwerk wie gewünscht funktioniert. Die geringe Anzahl der Fehler und auch die Fehlermeldungen passen recht gut in mein "Weltbild".

[Heisenberg420]

vor 7 Stunden schrieb skunk:

Ich kann dir nicht ganz folgen.

Hat nichts mehr mit der Suspendierung von vor 2 Tagen zu tun. Das Thema ist erledigt.

Aber NOCHMAL zum gefühlten 1000x ^^ da dieser Fehler von anfang an, seit wochen und Monaten besteht und nie drauf eingegangen wird seitens Storj wie man nun wieder mal gut sieht.  😑

ERROR	piecestore	download failed	{"Piece ID": "NOFEAV4IZN6NUU3ORUDDDJL36AMS7RKTG6E6JWOBK5OTIS7VTVDQ", "Satellite ID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Action": "GET", "error": "write tcp 172.17.0.4:28967->176.9.121.114:52414: use of closed network connection", "errorVerbose": "write tcp 172.17.0.4:28967->176.9.121.114:52414: use of closed network connection

WAS SOLL/KANN ICH GEGEN DIESEN FEHLER TUN???

Dieser Error kann auch nix mit der suspendierung zu tun haben sonst wäre mein Node jeden Tag suspendiert. Mit jedem Update bleibt der Fehler ^^

Ich werde das nun auch einfach mal in jedem Post von mir ansprechen bzw. re-zitieren bis ich eine Antwort bekomme 😆

 

vor 7 Stunden schrieb skunk:

IHat mit deiner Situation also eher nichts zu tun.

Hab auch nicht behauptet dass was was mit meinem Fall zu tun hat. Den Thread sollte man einfach mal auf sich wirken lassen.

 

 

EDIT: Oh, ich seh gerade seit 1.5.2 gibts einen neuen Fehler 😂😆

ERROR	piecestore	download failed	{"Piece ID": "RCK4QKDNKDLTLHF4SAW64CL74VDS6GGF7FVAI7NL4TMJIYDILMRA", "Satellite ID": "121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6", "Action": "GET", "error": "usedserialsdb error: context canceled", "errorVerbose": "usedserialsdb error: context canceled\n\tstorj.io/storj/storagenode/storagenodedb.(*usedSerialsDB).Add:35

Was kann / soll ich tun?

Bearbeitet 1. Juni 2020 von Heisenberg420
Nachtrag

[skunk]

Die Fehler deuten darauf hin, dass du zu langsam bist. Ich habe das Problem mit ZFS erschlagen. Es gibt aber sicherlich auch ein paar andere Möglichkeiten die Performance zu erhöhen.

[Heisenberg420]

Die beiden Fehler sind aber kein Grund für eine suspendierung oder gar disqualifizierung richtig?

vor einer Stunde schrieb skunk:

Die Fehler deuten darauf hin, dass du zu langsam bist.

Ich werde mir bald einen SSD Adapter für den Pi zulegen und die DB dann auf die SSD verfrachten, das sollte dann ja denke ich schon eine Menge bewirken.

 

vor 59 Minuten schrieb skunk:

Ich habe das Problem mit ZFS erschlagen. Es gibt aber sicherlich auch ein paar andere Möglichkeiten die Performance zu erhöhen.

ZFS kenne ich noch nicht, hab es aber schon ein paar mal im Storj Forum gelesen. Ich werde mich da bei Gelegenheit mal einlesen.

Hast du sonst noch Tipps zwecks Performance?

 

Achja und schöne Pfingen allen 😊

[skunk]

vor 3 Minuten schrieb Heisenberg420:

Die beiden Fehler sind aber kein Grund für eine suspendierung oder gar disqualifizierung richtig?

Audit Fehler! Ausschließlich Audit Fehler!

vor 3 Minuten schrieb Heisenberg420:

Ich werde mir bald einen SSD Adapter für den Pi zulegen und die DB dann auf die SSD verfrachten, das sollte dann ja denke ich schon eine Menge bewirken.

Warte damit besser noch ein wenig. Die DB kommt demnächst in den RAM. Dann sollte auch dein Pi etwas schneller werden. Darüber hinaus hast du gefragt was du machen kannst. Das heißt noch lange nicht, dass es auch wirtschaftlich sinnvoll ist. Die Kosten für die zusätzliche Hardware muss du dann erstmal rein holen.

vor 9 Minuten schrieb Heisenberg420:

Hast du sonst noch Tipps zwecks Performance?

Nein. Ich bin selber noch am rum spielen und dazu lernen.

[Heisenberg420]

vor 25 Minuten schrieb skunk:

Warte damit besser noch ein wenig. Die DB kommt demnächst in den RAM. Dann sollte auch dein Pi etwas schneller werden. Darüber hinaus hast du gefragt was du machen kannst. Das heißt noch lange nicht, dass es auch wirtschaftlich sinnvoll ist. Die Kosten für die zusätzliche Hardware muss du dann erstmal rein holen.

Den Adapater will ich nicht nur wegen Storj besorgen, sondern weil ich auch weg von der SD will. Gerade aufm Pi4 merkt man wie die SD das System bremst.

Trotzdem erfreulich zu hören dass die DB in den RAM kommen soll.

 

vor 24 Minuten schrieb skunk:

Audit Fehler! Ausschließlich Audit Fehler!

Dankeschön dass du auf all meine Fragen geantwortet hast! 😇

[GhostTyper]

storj0:

                   Available        Used      Egress     Ingress
     Bandwidth           N/A     47.4 GB     30.5 GB     16.9 GB (since Jun 1)
          Disk        3.3 TB      2.2 TB

storj8:

                   Available        Used      Egress     Ingress
     Bandwidth           N/A     77.2 GB     50.7 GB     26.6 GB (since Jun 1)
          Disk      553.5 GB      7.4 TB

Auf allen Nodes ungefähr knapp der doppelte Egress im Vergleich zum Ingress. Von den Test-Satelliten kommt aber noch Traffic. Ich vermute also man hat das Test-Daten-Profil mehr an die allgemeine Realität angepasst.

Sehr Schade für mich, denn mit einem weiteren Monat viel Ingress hätte ich noch einiges an Disks voll bekommen.

[GhostTyper]

Am 4.6.2020 um 08:42 schrieb GhostTyper:

Sehr Schade für mich, denn mit einem weiteren Monat viel Ingress hätte ich noch einiges an Disks voll bekommen.

Ich glaube es kommt seit einem Tag wieder viel Traffic.

[skunk]

und ich bin überrascht wie gut sich mein Server macht. Ich lasse aktuell einen Test mit einem Tool laufen dessen Namen ich hier glaube ich noch nicht nennen darf. Der Name spielt allerdings auch keine Rolle. Interessant ist lediglich, dass das Tool meinen Server kräftig auslastet. Ich habe locker 25% nur IO Wait weil das Tool mehrere hundert GB an Daten bewegt. Meine 4 Storage Nodes interessiert das überhaupt nicht. Ich habe vor meinen 4 Festplatten zwei Intel Optane als Cache und die scheint genau das zu machen was sie soll. Die Logdateien der Storage Nodes sehen aus wie immer. Ich würde sagen Stresstest bestanden^^

[Heisenberg420]

vor 5 Stunden schrieb GhostTyper:

Ich glaube es kommt seit einem Tag wieder viel Traffic.

Jup, seit exakt gestern 20.15 Uhr -> Screen

Wurde auch Zeit, so konnte ich endlich sehen ob sich der Wechsel der Festplatte gelohnt hat.

Ohne SMR läuft mein Node soviel besser 😍

 

EDIT: Beide Nodes zuhause bekommen ordentlich Traffic rein. Node 1 hat heute 72GB Ingress und 8GB Egress. Node 2 liegt bei 64GB Ingress und 5GB Egress.

Bearbeitet 6. Juni 2020 von Heisenberg420

[Heisenberg420]

Momentan macht's wieder richtig Spaß.. 😃

Homenode 1

                   Available       Used       Egress      Ingress
     Bandwidth           N/A     0.8 TB     121.8 GB     655.8 GB (since Jun 1)
          Disk        3.2 TB     4.0 TB

 

Homenode 2

                   Available       Used      Egress      Ingress
     Bandwidth           N/A     0.7 TB     51.4 GB     636.3 GB (since Jun 1)
          Disk        5.6 TB     1.6 TB

 

Node 3

                   Available         Used      Egress      Ingress
     Bandwidth           N/A     663.0 GB     55.9 GB     607.1 GB (since Jun 1)
          Disk        1.9 TB       2.0 TB

 

Node 4 noch nicht der Rede wert.

[GhostTyper]

vor 3 Stunden schrieb Heisenberg420:

Momentan macht's wieder richtig Spaß.. 😃

Du hast ja ziemlich gut Ingress.

Das ist eine meiner Nodes: (storj-8)

                   Available       Used       Egress     Ingress
     Bandwidth           N/A     1.0 TB     281.8 GB      0.7 TB (since Jun 1)
          Disk        7.0 GB     8.0 TB

Die Node ist jetzt also "voll".

Disk usage ist wie folgt:

storj8 ~ # df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sdb        8,8T    7,3T  1,1T   88% /store

Dateisystem     1K-Blöcke    Benutzt  Verfügbar Verw% Eingehängt auf
/dev/sdb       9370050300 7818729692 1079025596   88% /store

storj8 ~ # df -hi
Dateisystem    Inodes IBenutzt IFrei IUse% Eingehängt auf
/dev/sdb         282M     4,8M  277M    2% /store

8.0 TB usage entsprechen also 7.3 TiB auf der Disk. (Ja, das kommt hin.) Allerdings checke ich noch nicht, wie df -h so rechnet, denn 7.3T+1.1T=8.4T != 8.8T.

Die Frage ist jetzt: Um wie viel TB oder GB soll ich die Node jetzt vergrößern, so dass sie noch genug Puffer hat, wenn ich die Disk nicht vergrößere?