Beiträge von frank_m

    Hallo,


    ich hab in meinem Mediacenter im Moment eine 3TB, eine 4TB und eine 8TB Platte. Im Moment sind die einfach mit ext4 formatiert als einzelne Volumes. Gut 50% der Kapazität der Gesamtkapazität sind genutzt.


    Frage wäre nun, ob man die Platten sinnvoll in einen Verbund bringen kann. Einfach nur RAIDxyz hätte in der Konstellation einen großen Kapazitätsverlust zur Folge. Gibt es logische Filesysteme, die Redundanzinformationen wie z.B. Paritiybits auf die Volumes verteilen können? Irgendwas mit 3/4 oder 4/5 der 15 TB würde gut sein. Kann ZFS sowas? LVM? BTRFS? Man findet viel zur Kombination aus striped und mirrored Volumes, aber auch das hilft mir nicht weiter.

    Das Ganze ist ein kleiner Server zum Herumspielen von mir und einem Freund, der hatte das damals eingerichtet.

    Das sind die beliebtesten Ziele für Hacker, die den Server dann dafür nutzen, um SPAM zu versenden oder für Botnetze. Anschließend landen die Netcup Subnetze dann wieder auf irgendwelchen Blacklisten, worunter dann alle leiden.

    Denk dran: Du bist verantwortlich für deinen Server und all den Unfug, den andere damit machen. Das kann im Zweifel sehr teuer werden. Und daran, wie oft Netcup auf solchen Blacklisten landet, erkennt man, wie häufig es in der Praxis tatsächlich vorkommt. Das ist keine Panikmache oder so. Sieh dich im Forum um, es ist voll davon.

    Hi wahrscheinlich nicht wie mache ich das ?

    Das kommt auf die Firewall an, die du nutzt. iptables, ufw, nftables, ... Irgendwas wirst du ja eingerichtet haben, um dein System vor Zugriffen von außen zu schützen. Immer dran denken, bei netcup gibt es keine Systemfirewall oder sowas. Im Schnitt wird dein System 1x pro Sekunde attackiert. Du hast doch eine Firewall eingerichtet, oder? Ansonsten weißt du ja nun, was du vor deinen IPv6 Versuchen zu tun hast.


    Nein das wusste ich nicht was wäre hier die alternative?

    Es gab einige Versuche mit Scripten, die in regelmäßigen Abständen Datenverkehr von den betroffenen IPs erzeugten, um die Neighbor Tabellen in der netcup Infrastruktur aktuell zu halten. Diesem Ansatz liegt die Vermutung zugrunde, dass diese Tabellen die Ursache für das Problem sind, was nicht abschließend geklärt ist.-


    Wirklich gut funktioniert es nur mit einem zusätzlichen /64 Netz, was man sich auf den Server routen lässt. Dann braucht man weder ndppd noch gibt es Probleme mit Paketverlusten.

    Die Firewall hast du entsprechend konfiguriert, dass Forwarding auf die docker hosts erlaubt ist?


    ndp ist nötig, das hast du ja schon herausgefunden. Aber dass es trotzdem zu Paketverlusten beim Zugriff auf intern genutzt IPv6 Adressen kommt, hast du auch gelesen?

    So, ich habe noch ein bisschen experimentiert.


    Die Ergebnisse bei UNION und UNION ALL sind bei mir identisch. Das ist nicht verwunderlich, denn die Tabelle sollte eigentlich immer nur einen Messwert für die Kombination aus id und ts haben. Die Abfragen mit UNION ALL sind aber ca. doppelt so schnell, wie mit UNION.


    Ich bin mir aber nicht sicher, ob ich daraus einen Request an das SQL Plugin vom iobroker mache. Denn es ist denkbar, dass andere Datenquellen die Datenbank anders befüllen, und da könnte das UNION ALL möglicherweise problematisch sein. Grundsätzlich funktioniert es ja.

    Es gibt fürs Query Log sogar einen Parameter 'log_queries_not_using_indexes':

    Genau damit habe ich die Aufrufe ja gefunden, um sie dann mit "explain" bzw. nun mit "explain analyze" zu untersuchen.


    Und genau da stehe ich jetzt. Anhand von "explain analyze" weiß ich, dass ein "UNION ALL" deutlich fixer ist, als ein "UNION". Nun muss ich ja die aufrufende Software modifizieren, da wo das SQL Statement zusammengebaut wird. Denn ich werde ja kaum dem SQL Server sagen können, dass er UNION ALL anstatt UNION ausführen soll.

    Versuch mal in den Statements UNION ALL nur zum Spaß...

    Das macht aus den knapp 700 ms bei "Union materialize" 180 ms ... In der Gesamtabfrage sinkt die Zeit von gut 870 ms auf 305.


    Verwende beim SELECT unbedingt mal ein SQL_NO_CACHE.

    Das hingegen hatte keinen Einfluss. Die gesamte Abfrage dauerte 30 ms länger.


    Und teste es keinesfalls mit einer Dummy-Tabelle, die nur ein paar Testeinträge enthält, da werden Indizes Dank dem Optimizer oft gar nicht verwendet.

    Ich teste das auf der produktiven Tabelle mit den 13 Mio Einträgen. Die Daten da drin sind nur für mich privat zum Spaß, und ggf. auch noch als Backup in der Herstellercloud verfügbar.



    Bleibt die Frage: Das Ganze ist ja Bestandteil des eChart Plugins vom ibroker. Vermutlich muss ich da jetzt in den Sourcecode und schauen, wo die SQL Statements zusammengebaut werden?

    Ich hab den Aufruf einmal mit einem Index auf ts und einmal ohne gemacht. Das Ergebnis war allerdings bis auf wenige ms identisch.




    Auf der einen Seite scheint das Einsammeln der Daten aus den drei Select Statements nicht allzulange zu dauern. Die beiden Limits sind sehr kurz, und die Filter Zeile mit 156 ms auch ok. Aber eine Ebene höher dauert das Union materialize plötzlich fast 700 ms. Wenn ich die Beschreibung richtig verstanden hab, dann hätte ich dort in etwa die Summe der drei Selects erwartet.

    Die zusätzlichen 170 ms für den Table Scan und das Sortieren sind meines Erachtens wieder ok.


    Was dauert an dem Union materialize so lange und kann man das optimieren?

    Hallo,


    die Frage in Kurzform: macht es Sinn, einen zusätzlichen Index auf Spalten zu erzeugen, die schon im Primary Index enthalten sind?


    Lange Version:

    Ich hab eine Datenbank im iobroker, in der ich u.a. die Daten meiner Wetterstation sammle, und in die ich auch die Daten aus der Cloud des Anbieters der Wetterstation importiert habe. Die Datenbank hat die Spalten:

    id - der Messwert (z.B. Außentemperatur)

    ts - ein Timestamp

    value - der eigentliche Messwert zum jeweiligen Zeitpunkt


    Im Primary Index sind id und ts, das hat iobroker bei der Einrichtung so angelegt. Die SELECT Statements für die Visualisierung sehen z.B. so aus:

    SQL
    SELECT ts, val FROM `iobroker`.ts_number WHERE  `iobroker`.ts_number.id=7 AND `iobroker`.ts_number.ts < 1659175200000 AND `iobroker`.ts_number.ts >= 1656583200000 UNION ( SELECT ts, val FROM `iobroker`.ts_number WHERE  `iobroker`.ts_number.id=7 AND `iobroker`.ts_number.ts < 1656583200000 ORDER BY `iobroker`.ts_number.ts DESC LIMIT 1) UNION ( SELECT ts, val FROM `iobroker`.ts_number WHERE  `iobroker`.ts_number.id=7 AND `iobroker`.ts_number.ts >= 1659175200000 ORDER BY `iobroker`.ts_number.ts ASC LIMIT 1) ORDER BY ts ASC;


    An sich funktioniert das. Abfragen über einen Zeitraum von 2 Jahren dauern ca. 0,4 Sekunden. Allerdings tauchen die Statements im Log für "queries-not-using-indexes" auf, und ich weiß nicht, wieso. Denn wenn ich mir so ein SELECT Statement mit EXPLAIN ansehe, dann steht dort sogar, dass der PRIMARY Key benutzt wird - bis auf das UNION Result am Ende. Ist das der Grund?


    Frage ist nun, ob die Abfragen beschleunigt werden können, indem man zusätzliches Indizes einführt, z.B. über die Spalte id oder ts. Ich hab das mal probiert, und die Anzeige in phpmyadmin wird spürbar beschleunigt (vermutlich, weil die ausschließlich nach ts sortiert wird). Die Anzeige im iobroker profitiert allerdings nicht.

    Wenn ich mich recht erinnere, binded sich systemd-resolvd auf den Port 53, was es unmöglich macht Unbound zu starten.

    Ja, aber nur auf der IP 127.0.0.53. Damit sind andere DNS Dienste auf dem Host möglich.


    Code
    tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      102        18173      1040/systemd-resolv
    udp        0      0 127.0.0.53:53           0.0.0.0:*                           102        18172      1040/systemd-resolv

    Ich meine mich ganz wage zu erinnern, dass hier im Forum erst vor einer Weile auch wegen Virtio und SCSI hin und her getestet wurde und dass irgendeine Einstellung mittlerweile standard sein soll.

    Ja, das war so, wenn man ein Standard-Image installiert, z.B. Ubuntu 22.04. Dann wurden die für dieses Image optimalen Einstellungen gewählt. Aber später im Betrieb wurden die Einstellungen nicht automatisch verändert. Und bei der Installation von DVD auch nicht.

    Wenn man das Optimierungs-Target ändert ("Windows", Linux"), dann könnte ich mir vorstellen, dass solche Änderungen implizit mit geändert werden.

    i'm using UFW, do i need to go through nftables ?

    Yes, of course (in case you are using nftables and not iptables). Who knows, which other tools have manipulated the settings.


    every other port stays close no matter what i do in UFW.

    And which server is running on port 3000? Check it with "netstat -tulpen" or "ss -tulpen".



    //Add:

    There is no server running in Port 3000. That is the reason why the port is closed.

    ... nachdem ich einen PC-Bildschirm gefunden habe, der einen RJ-45 Anschluß hat - wozu?

    Vermutlich hat der Monitor einen USB-C Anschluss. Dann können neben der eigentlichen Bildübertragung auch USB Anschlüsse und Netzwerk übertragen werden. Ggf hat der Monitor sogar USB-PD drin, dann ist es eine komplette Docking-Station im Monitor. Ein USB-C Kabel ins Notebook und ab dafür!

    Naja, dafür bekommst du hier für den gleichen Preis 4x so viele CPU Cores, 4x so viel RAM und gut 3x so viel Festplattenkapazität. 933 im Single Core sieht man hier auch häufig, liegt halt dran, was die Nachbarn so machen.


    Wenn dir die 7 GBit/s nach New York so viel wert sind, dann kannst du das Angebot ja annehmen. Alle anderen Parameter sind schlechter.