Ankündigung

Einklappen
Keine Ankündigung bisher.

Platte mittels php & mysql füllen, so bis 500GB-Test

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Platte mittels php & mysql füllen, so bis 500GB-Test

    Hallo,
    erstmal Hallo Nett, das es dieses Forum gibt und das es auch Leute hier hat, die Wissen haben.

    Programmiere seit ewigen Zeiten(gut 40Jahren) procedural etliche Programmiersprachen, d.h. komme bis jetzt noch prima damit aus(Will da auch nix mehr dran ändern). Administriere Mysql-DB im kleinen Rahmen seit ca.10 Jahren. Soviel zu Vorkenntnissen; Ergo kein totaler Frischling
    Habe Probleme bei einem kleinen Proggi in PHP, Version 7.3.11, OS=Debian 4.9.168-1+deb9u5 (2019-08-11) x86_64, HW=amd64 mit MariaDB 10.1.41, für mich entdeckt und hoffe auf ein paar Tipps.

    Da ich grundsätzlich nicht die Funktionalitäten der benutzten Produkte in Frage stellen möchte, halte ich mich mit sinnfreien Behauptungen zurück

    Projekt Belastungstest:
    Ich erzeuge über eine 4-fache For-Schleife 4-stellige Passwörter aus 62 unterschiedlichen Zeichen(A..Z, a--z, 0..9) und schreibe diese nebst md5 und crypt hash auf die Platte. Ergo sollten ca. 62*63*63*63 Passwörter erzeugt werden können.
    Wenn das funzt, gebe ich noch eine For-Schleife dazu für 5-stellige Passwörterm falls es nöig ist an die 500GB-Grenze zu kommen.

    Problem 1) Spätestend ist immer bei 214000 bis 217000 Inserts(d.h. neuen Datensätzen) ist schluß. Was könnte die Ursache sein? 8 Kerne, Memory 16GB auf Maschine, davon benutzt ca. max 650MB bei zu Verfügung stehend min 730MB Ram für PHP.

    Problem 2) Bei bereits vorhandenen Daten: Angenommen das Passwort(Unique indiziert) existiert schon, so wird jedoch öfters, trotz binären Vergleiches, ein SQL-Statement erzeugt, welches gerne das gefundene Passwort nochmal inserten möchte(Passiert beim Durchlauf des Scriptes, dann springt das Programm zu früh aus For-Schleife(Welche ist nicht nachvollziehbar)) und die , auch guten Values aus dem Insert, werden nicht eingefügt. Es darf angenommen werden, das im Code kein Fehler vorliegt(Habe mich schon mehrere Tage mit unterschiedlichen Programmversionen diesbzgl. beschäftigt). Beim Durchlauf mit je einem Insert-Datensatz klappt es bis zur 217000der Grenze fehlerfrei. Bei Inserts mit mehreren Values, getestet von 2 bis 1000 Sätzen je Insert. Es werden nicht gefundene Passwörter in der DB benutzt(Zumindest erfolgt eine korrekte Abfrage). Bei Fehlern ergibt die Nachforschung, das einige bereits vorhandene Passwörter im Insert mit drinnen sind. Mittels HeidiSql gecheckt. Unter welchen Umständen kann sowas passieren?

    Wenn es jemanden interessiert stelle ich gerne den Code zur Verfügung. Muss den dann erstmal schön machen bevor ich den zeigen kann.
    Das Problen ist irgendwie merkwürdig und ich würde es erstmal nicht glauben, wenn es mir selbst nicht passiert wäre.
    Har schonmal jemand von solchen oder ähnlichen Problemen gehört oder Erfahrungen damit?

    Bevor nun jemand auf die Idee kommt, warum ich so ein Zeugs in eine DB klopfe ist ganz einfach. Ich möchte anhand eigener Daten selbst herausfinden, wie sehr mein Server belastet wird mit massig Anfragen auf grosse Datenbanken. Dazu werde ich mir noch einiges einfallen lassen, um herauszufinden, was er so verträgt und was noch im Rahmen ist, um noch akzeptabel meine Webseiten abrufen zu können Interessiert mich derzeit dafür.

    Gruß Joe


  • #2
    Zitat von JoeDorm Beitrag anzeigen
    Programmiere seit ewigen Zeiten(gut 40Jahren) procedural etliche Programmiersprachen, d.h. komme bis jetzt noch prima damit aus(Will da auch nix mehr dran ändern). Administriere Mysql-DB im kleinen Rahmen seit ca.10 Jahren. Soviel zu Vorkenntnissen; Ergo kein totaler Frischling
    Dann sei erlaubt in Frage zu stellen, warum man sich für eine solches Vorhaben für PHP entscheidet?

    Zitat von JoeDorm Beitrag anzeigen
    Ich möchte anhand eigener Daten selbst herausfinden, wie sehr mein Server belastet wird mit massig Anfragen auf grosse Datenbanken. Dazu werde ich mir noch einiges einfallen lassen, um herauszufinden, was er so verträgt und was noch im Rahmen ist, um noch akzeptabel meine Webseiten abrufen zu können
    Klingt für mich nach DDoS
    Competence-Center -> Enjoy the Informatrix
    PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

    Kommentar


    • #3
      Es werden nicht gefundene Passwörter in der DB benutzt(Zumindest erfolgt eine korrekte Abfrage). Bei Fehlern ergibt die Nachforschung, das einige bereits vorhandene Passwörter im Insert mit drinnen sind. Mittels HeidiSql gecheckt. Unter welchen Umständen kann sowas passieren?
      ?


      so, ich hab das nicht verstanden.
      aber mir fehlen auch alle relevanten infos

      Ich möchte anhand eigener Daten selbst herausfinden, wie sehr mein Server belastet wird mit massig Anfragen auf grosse Datenbanken. Dazu werde ich mir noch einiges einfallen lassen, um herauszufinden, was er so verträgt und was noch im Rahmen ist, um noch akzeptabel meine Webseiten abrufen zu können Interessiert mich derzeit dafür.

      Achso, ob du da einen effektiven weg gehst ?
      so reinnaus Interesse, wie stark ist Dein server und wieviel queries meinst Du schafft der
      - aufgrund der fehlenden paltten perfomance
      - aufgrund der schwachen cpu
      - aufgrund des geringen ram

      Kommentar


      • #4
        Sorry aber aus deiner Beschreibung kann man nicht entnehmen, ob du die Platte selbst vollschreiben willst - oder ob du die Datenbank aufblähen willst, bis die Platte voll ist ...
        In letzterem Fall musst du per EInstellungen der Datenbank auch erlauben, so groß zu werden.

        Bezüglich Fehler im Script ... das wird schon kein Syntax-Fehler sein - da meckert der PHP-Interpreter, wenn du ihn lässt (erzwinge Ausgabe aller Fehler) .. sondern eher logische Fehler .. daher wäre es nett, wenn du relevante Codeteile mal hier anführst.

        Wenn es nur darum geht, die Festplatte vollzuschreiben, würde ich persönlich auf shell-script oder gar schnöde auf dd zurückgreifen
        "Irren ist männlich", sprach der Igel und stieg von der Drahtbürste

        Kommentar


        • #5
          Moin,
          Ich erzeuge über eine 4-fache For-Schleife 4-stellige Passwörter aus 62 unterschiedlichen Zeichen(A..Z, a--z, 0..9) und schreibe diese nebst md5 und crypt hash auf die Platte. Ergo sollten ca. 62*63*63*63 Passwörter erzeugt werden können.
          Wenn das funzt, gebe ich noch eine For-Schleife dazu für 5-stellige Passwörterm falls es nöig ist an die 500GB-Grenze zu kommen.
          Würde da nicht eine einfache For-Schleife reichen? Also... for $i < 15 Millionen
          In der weiteren Beschreibung unten steht ja auch, dass dann eine der Schleifen verlassen wird, das erscheint mir alles ein bisschen komplizierter als es eigentlich sein muss.

          Problem 1) Spätestend ist immer bei 214000 bis 217000 Inserts(d.h. neuen Datensätzen) ist schluß. Was könnte die Ursache sein? 8 Kerne, Memory 16GB auf Maschine, davon benutzt ca. max 650MB bei zu Verfügung stehend min 730MB Ram für PHP.
          So Dinge wie max_execution_time auch angepasst? Auch in der richtigen php.ini? Die vom webserver oder für cli je nach Aufruf


          Ansonsten sind doppelte Passworte an sich ja kein Problem, im Normalfall gibt es ja noch einen Usernamen oder ähnliches dazu, und können bei nur 4 Zeichen wohl auch öfter mal vorkommen. Ich würde da einfach keinen Unique Constraint draufsetzen.
          Relax, you're doing fine.
          RTFM | php.de Wissenssammlung | Datenbankindizes | Dateien in der DB?

          Kommentar


          • #6
            Hallo,
            zur Beruhigung, kein DDos auf dem Plan; Für DDos soll es sinnvolle Listen mit Passwörtern geben, aber daran habe ich weder Bedarf noch Interesse.
            Ich möchte mit einer DB den Plattenspeicher füllen, also nicht mit DD.

            Was mit evtl. weiter hilft ist max_execution_time, denn so 1 Stunde ist da jedesmal Ende. Hätte ich auch drauf kommen können.

            Habe festgestellt, das die Abfrage, ob ein Passwort schon vorhanden ist um dann ggf. ein neues dazu zu tun, kostet mehr Performance, als einen Insert mit vorhandenem Passwort bei Index Unique gegen die Wand laufen zu lassen.
            Leider muß man dann einzelne Inserts machen, da ansonsten bei einem doppelten Eintrag in den Values, offensichtlich alles nicht gespeichert wird; Und wenn ich das ausmerze mit den doppelten, erfordert es eine Abfrage auf vorhandene Einträge, was dann länger dauert.

            Problem 2 habe ich gelöst.

            Es geht nun einigermaßen flott voran aber die max_execution_time scheint da nochwas abzuwürgen.
            Bis die Platte voll ist, wird wohl, auf Grund der Einzel-Inserts noch ein Monat Laufzeit vergehen.
            Zudem machen die Browser bei paralellem Aufruf des Scripts bei 6(Chrom/Opera) und 8(Firefox) Sockets zu.
            Es laufen derzeit 8+6+6 Instanzen und die Belastung ist auf dem Server minimal.
            Es ist müssig, aber ich bin ja mit 62 noch jung

            Gibts da keine einfache Möglichkeit x Instanzen über ein Script laufen zu lassen?

            Möglicherweise kann man auch das komplette Erzeugen direkt ohne php in MySql machen, was die Angelegenheit wohl ernorm beschleunigen könnte, denn die benötigten Methoden/Funktionalitäten sind auf den ersten Blick im Sprachumfang mit drin.

            Vielen Dank erstmal.
            Werde mitteilen wie es weiter geht.

            Aber vielleicht hat noch jemand eine sinnvolle Idee, um die Sache zu beschleunigen...

            Kommentar


            • #7
              Es laufen derzeit 8+6+6 Instanzen und die Belastung ist auf dem Server minimal.
              wäre ja auch noch schöner, wenn ein paar trivilae inserts dein 386er db-server an die wand fahren könnten.

              mir ist immer noch nicht klar was du vor hast und genau warum.

              Zudem machen die Browser bei paralellem Aufruf des Scripts bei 6(Chrom/Opera) und 8(Firefox) Sockets zu.
              Das sollte auch nimimalm sein und nirgends ins gewicht fallen.

              wie dem auch sei,
              -es gibt eine mysql console da kann man browser, webserver und den gazen scheiss aussen vorlassen.
              -aktretschmar bspw. postset hier ab und an sql code, bei dem er schnell man ne masse in die db schreibst
              -man kann im netz suchen
              -es ist fraglich ob du auf die art und weise zu performance einbusen kommst

              Kommentar


              • #8
                Moin,
                ich verstehe das mit den doppelten Einträgen immer noch nicht so ganz, bzw. was daran das Problem wäre diese einfach zu erlauben.
                14 Millionen Zeilen zu schreiben sollte eigentlich nicht sehr lange dauern. Vielleicht wäre es doch gut wenn du mal dein Script postest.

                Ansonsten wären Transaktionen noch eine Möglichkeit die Inserts zu beschleunigen.
                Relax, you're doing fine.
                RTFM | php.de Wissenssammlung | Datenbankindizes | Dateien in der DB?

                Kommentar


                • #9
                  Zitat von JoeDorm Beitrag anzeigen
                  Aber vielleicht hat noch jemand eine sinnvolle Idee, um die Sache zu beschleunigen...
                  Schreib die Daten in eine CSV/Textdatei und importier die mit LOAD DATA (SQL Befehl). Dann ist das eine Sache von ein paar Minuten.

                  Zitat von JoeDorm Beitrag anzeigen
                  Bevor nun jemand auf die Idee kommt, warum ich so ein Zeugs in eine DB klopfe ist ganz einfach. Ich möchte anhand eigener Daten selbst herausfinden, wie sehr mein Server belastet wird mit massig Anfragen auf grosse Datenbanken.
                  Wenn du nicht grade eine "Passwort Cracking"-Seite betreibst, wird das ziemlich nichts sagend werden. Wenn du nur Queries ausführst, die über ein Index ein Datensatz abrufen, kommst du da auch auf einem "kleinen" System locker in den 6stellige Bereich mit Queries pro Sekunde. (natürlich nicht in einem einzelnen Thread)

                  Zitat von JoeDorm Beitrag anzeigen
                  Habe festgestellt, das die Abfrage, ob ein Passwort schon vorhanden ist um dann ggf. ein neues dazu zu tun, kostet mehr Performance, als einen Insert mit vorhandenem Passwort bei Index Unique gegen die Wand laufen zu lassen.
                  Das kommt drauf wie du Performance definierst. Du schaust hier nur auf die Laufzeit eines einzelnen Prozesses und stellst fest, 2 Abfragen dauern länger als 1 Abfrage. Das ist bei einem System was auf hohe Parallelität ausgelegt ist, ein schlechter Indikator für Performance. Bei einer Datenbank die ACID erfüllt, ist ein Schreibzugriff bei weitem teuerer als ein Lesezugriff, selbst wenn nix geändert wird.

                  Kommentar


                  • #10
                    Hallo,
                    14776336 Datensätze sind angelegt und die Einträge auch ordentlich durcheinander aber indexiert.
                    Einzel-Abfrage auf Passwort bei Leerlauf dauert 0.0015 Sekunden. Unter Last 0,005 Sekunden.
                    Vielleicht ist das nochlangsam, kann ich aber nicht einschätzen.

                    Bemerkenswert ist, das die mitgeführte ID, autoincrement, derzeit nach der Aktion auf ca. 150 Mio. steht.
                    Über mytop sah ich das, obwohl nicht angefordert beim Insert, sichtbar ein Update Insert ausgeführt wurde. Anders kann ich mir das mit der ID auch nicht erklären, warum die bei jedem versuchten Schreiben auf einen ggf. schon vorhandenen Datensatz, hochzählt wird. Weiß ich also nicht, sondern vermute nur, das das Value für die crypt() Methode unterschiedliche Werte bei gleichem Passwort erzeugt und Differenzen per Update automatisch behandelt werden. Wenn dem so ist, sollte man das wissen.

                    So langsam vergeht mir die Lust an dem Projekt, nachdem bei letztem Script zwar schon bis zu 2 Mio Inserts für eine Instanz php-script herauskommt, aber nur mit Tricksen, mit verändertem Char-Bereich.
                    Habe schon festgestellt, das bei Massenanfragen die CPU-Last ordentlich hoch geht, aber insgesamt, das währenddessen die Wordpress-Domains kaum Verzögerung haben.
                    Also scheint mir das Unterfangen nunmehr sinnfrei. Da müsste ich hunderte von Usern oder mehr gleichzeitig simulieren. Der DDos-Schutz würde mich zudem aussperren

                    Danke für die Tips und Kommentare
                    Joe

                    Kommentar


                    • #11
                      Zitat von JoeDorm Beitrag anzeigen
                      Zudem machen die Browser bei paralellem Aufruf des Scripts bei 6(Chrom/Opera) und 8(Firefox) Sockets zu.
                      Warum rufst du so ein Script auch mit einem Browser auf? Ein Browser ist für sowas halt überhaupt nicht geeignet, aus mehreren Gründen.

                      Kommentar

                      Lädt...
                      X