nicht angemeldet dedlfix
Rolf B
TS
Der Martin
TS
Rolf B
TS
TS
klawischnigg
TS
TS
TS
Ich habe eine CSV Datenbank die ich gerne ich eine mysql Datenbank einspeisen möchte. Am liebsten über phpmyadmin.
Die Datei hat 10 Millionen Zeilen und ist 890 MB Groß.
Bi jetzt habe ich schon versucht die Datei in mehrere Teile zu zerlegen, aber das bekomme ich auch nicht hin.
Ich bin ziemlich ratlos.
Vieleicht weiß ja der ein oder andere hier, was ich da anstellen könnte um ans Ziel zu kommen.
Maties
Tach!
Ich habe eine CSV Datenbank die ich gerne ich eine mysql Datenbank einspeisen möchte. Am liebsten über phpmyadmin.
Die Datei hat 10 Millionen Zeilen und ist 890 MB Groß.
Das ist aus zweierlei Gründen problematisch. Zum einen hat PHP eine Beschränkung der Upload-Größe, zum anderen hat auch der Webserver eine. Wenn du diese beiden nicht konfigurieren kannst, bist du auf die Maximalgröße beschränkt, was aber nur für die Transfergröße relevant ist.
Wenn du also das Transfervolumen verringern kannst, und damit unter die Grenzwerte kommst, bist du schon einen Schritt weiter. Eine Möglichkeit, das zu erreichen, ist die Datei zippen. Wenn die Daten gut komprimierbar sind, lässt sich eine Menge Größe einsparen.
phpMyAdmin kann mit gezippten Dateien arbeiten. Die nächste Beschränkung könnte eine Quota im Dateisystem sein. Da müsste mindestens die Menge an Platz verfügbar sein, wie die komprimierte und die unkomprimierte Version gemeinsam belegen.
Bi jetzt habe ich schon versucht die Datei in mehrere Teile zu zerlegen,
Das wäre die einzige Möglichkeit, wenn die Größe der limitierende Faktor ist.
Eine Alternative ohne Transferbeschränkung wäre, wenn du Shellzugriff hast. MySQL hat Kommandozeilen-Tools, mit denenn man importieren kann (sollte zumindest, ich hab das nie mit CSV probiert).
aber das bekomme ich auch nicht hin.
Woran genau scheitert es? Das erste wäre, einen Texteditor zu finden, der mit der Dateigröße umgehen kann.
Das CSV-Format ist recht einfach. Die Daten können am Zeilenende getrennt werden. Beachte aber Zeilenenden, die innerhalb von Feldern auftreten können.
Dae einzige, worauf man noch achten muss, ist die erste Zeile. Da können die Feldnamen drinstehen. Die Zeile ist aber keine Pflicht. Ohne sie muss aber beim Import die Reihenfolge der Felder mit den Datenbankfeldern in Übereinstimmung gebracht werden.
Wenn du eine solche Feldnamenzeile hast, solltest du sie auch bei jedem Teilstück als erste Zeile einfügen. Damit sollte der Import prinzipiell gehen.
dedlfix.
Hallo dedlfix,
Das CSV-Format ist recht einfach. Die Daten können am Zeilenende getrennt werden. Beachte aber Zeilenenden, die innerhalb von Feldern auftreten können.
Unabhängig davon, dass Excel diese datei auch nicht einlesen wird (weil zu groß), ist das ja aber ein grundsätzliches Problem. Diese Zeilenumbrüche innerhalb von feldern kann man in Excel über Suchen und Ersetzen alle auf einen Schlag entfernen lassen, wenn das gewünscht ist.
Jörg
Hi,
Ich habe eine CSV Datenbank die ich gerne ich eine mysql Datenbank einspeisen möchte. Am liebsten über phpmyadmin.
Die Datei hat 10 Millionen Zeilen und ist 890 MB Groß.
Auf die Gefahr hin, Blödsinn zu verzapfen, mal meine Idee (mit der Bitte um Korrektur):
Ich selber würde auf meinem Linuxsystem mit split die Datei in n Teilstücke unterteilen, die für php geeignet sind.
Dann würde ich ein Importprogramm schreiben, das eine solche Datei einliest, die Datensätze in die DB einträgt und sich danach mit entsprechendem Parameter selber wieder aufruft (<meta http-equiv="refresh"...> alle php-Varianten werden nicht als wirklch neuer Aufruf gewertet und man läuft ins Script-Timeout) und sich über den mitgelieferten Parameter die nächste Datei schnappt. Das alles so lange, bis alles eingelesen ist.
Jörg
Tach!
Ich selber würde auf meinem Linuxsystem mit split die Datei in n Teilstücke unterteilen, die für php geeignet sind.
Das kann in die Hose gehen. Man kann zwar eine Anzahl Zeilen als Größe angeben, aber split beachtet nicht die Eigenheiten von CSV. Solange keine Zeilenumbrüche in den Feldern sind, ist das aber eine durchaus verwendbare Möglichkeit.
Dann würde ich ein Importprogramm schreiben, das eine solche Datei einliest, die Datensätze in die DB einträgt und sich danach mit entsprechendem Parameter selber wieder aufruft (
<meta http-equiv="refresh"...>alle php-Varianten werden nicht als wirklch neuer Aufruf gewertet und man läuft ins Script-Timeout) und sich über den mitgelieferten Parameter die nächste Datei schnappt. Das alles so lange, bis alles eingelesen ist.
Das Unterbrechen und Fortsetzen beim Erreichen der maximalen Script-Laufzeit ist bereits in phpMyAdmin eingebaut.
dedlfix.
Hi dedlfix,
Das Unterbrechen und Fortsetzen beim Erreichen der maximalen Script-Laufzeit ist bereits in phpMyAdmin eingebaut.
Wenn man die felder komplett unbearbeitet ein lesen kann, ok. Bei meinen Daten müssen die Felder bearbeitet oder je nach Inhalt bearbeitet werden, da scheidet php-myadmin leider aus. Daher dieser Lösungsansatz für den Kollegen.
Jörg
Moin Jörg,
Ich selber würde auf meinem Linuxsystem mit split die Datei in n Teilstücke unterteilen, die für php geeignet sind.
ist „dein Linuxsystem“ dein eigener Rechner oder der HTTP-Server?
Kommst du per SSH an den Server heran? Dann könntest du schauen, ob mysql dort direkt einen CSV-Import bietet (mysqlimport?).
Dann würde ich ein Importprogramm schreiben, das eine solche Datei einliest, die Datensätze in die DB einträgt und sich danach mit entsprechendem Parameter selber wieder aufruft (
<meta http-equiv="refresh"...>) […]
Oder du schreibst ein lokales Python-/Perl-/PHP-Programm, das ohne den Umweg über HTTP auskommt.
Viele Grüße
Robert
Hi,
Bi jetzt habe ich schon versucht die Datei in mehrere Teile zu zerlegen,
Das wäre die einzige Möglichkeit, wenn die Größe der limitierende Faktor ist.
aber das bekomme ich auch nicht hin.
Woran genau scheitert es? Das erste wäre, einen Texteditor zu finden, der mit der Dateigröße umgehen kann.
unter Windows: Textpad. Damit hab ich schon Files mit mehreren GB geöffnet und bearbeitet.
cu,
Andreas a/k/a MudGuard
Wenn ich große Dateien in PHP verarbeite, mache ich das aufgrund der Limitierungen und auch um Rückmeldung während des Prozesses zu erhalten in PHP CLI. Um mögliche memory Probleme zu vermeiden die Datei am besten zeilenweise einlesen.
Was Inserts/Updates betrifft verwende ich wenn nötig mysqli_multi_query. Zum Beispiel Stapel von 100 oder auch mehr Datensätzen. Das kann den Import erheblich beschleunigen. Sollte der MySQL Server entfernt sein, könnte auch noch MYSQLI_CLIENT_COMPRESS hilfreich sein.
Dedlfix' Hinweis auf die MySQL Kommandozeilen-Tools klingt ebenfalls sehr vielversprechend. Habe damit persönlich (außer etwas probieren) wenig Erfahrung, da ich während des Imports die Daten meist noch weiter aufbereiten und/oder abgleichen möchte.
Ich habe eine CSV Datenbank
CSV ist ein weites Feld.
Beschreibe:
Längst nicht jedes „CSV“ ist dafür geeignet, mit jedem Programm importiert zu werden.
Bis jetzt habe ich schon versucht die Datei in mehrere Teile zu zerlegen, aber das bekomme ich auch nicht hin.
Es gibt genug und einfach zu bedienende Programme, die genau dafür da sind. Woran scheiterst Du? Zeilenumbrüche in den Datenfeldern?
Ich bin ziemlich ratlos.
Am Besten lässt Du in diesem Fall die Finger von phpmyadmin. Der ist was für Anfänger, nichts für Leute, welche ein knappes Gigabyte an Daten in eine Tabelle „wuppen“ wollen.
https://www.mysqltutorial.org/import-csv-file-mysql-table/
Und falls Dir - obwohl Du offenbar beachtliche Datenmengen verarbeiten willst - dazu jetzt nur ein „ein es geht nicht anders, weil mein Hoster das nicht unterstützt“ einfällt weil dieser keinen direkt erreichbaren MySQL-Server und/oder keine SSH-Verbindung zum Webserver oder nicht genug Speicherplatz anbietet:
Du kannst auch keinen serienmäßigen Trabant 601 mit Diesel betanken und bei der Formel 1 mitfahren wollen...
Achte auch darauf, dass Deine Verbindung ausreichend stabil sein muss. Es ist besser, die Datei auf den Server hochzuladen und von dort aus einzulesen. Das wieder am besten mit nohub, damit der Prozess auch weiter läuft, wenn Deine ssh-Verbindung abbricht.
Ich bin ziemlich ratlos.
Dir kann niemand helfen, wenn Du Dein Problem nicht vollständig beschreibst. Wenn Du das nicht willst, dann kauf Dir jemanden, der sich das ansieht.
Hallo Maties,
Bis jetzt habe ich schon versucht die Datei in mehrere Teile zu zerlegen, aber das bekomme ich auch nicht hin.
Was bekommst Du nicht hin? Die Zerlegung, oder das Einspielen der Zerlegung?
Monströse Textdateien sollten für notepad++ handhabbar sein. Die aktuelle Version 8.3.2 in der 64-bit Version hat mir gerade eine Datei mit 1,6GB und 24 Millionen Zeilen geöffnet. Ist allerdings ein Windows-Tool.
Andernfalls musst Du Dir einen Filesplitter besorgen, das muss nur einer sein, der an Zeilenenden teilt und nicht blindlings nach einer festen Zahl von Bytes. Ich habe bisher keinen gebraucht, und kann darum keinen empfehlen. Mit etwas Fingerfertigkeit ist so ein Tool auch schnell selbst geschrieben.
Rolf
Hello,
Ich habe eine CSV Datenbank die ich gerne ich eine mysql Datenbank einspeisen möchte. Am liebsten über phpmyadmin.
Die Datei hat 10 Millionen Zeilen und ist 890 MB Groß.
Bi jetzt habe ich schon versucht die Datei in mehrere Teile zu zerlegen, aber das bekomme ich auch nicht hin.
Wenn Du die Zeilentrenner kennst (siehe Raketentipps) kannst Du die Aufspaltung mit fast jeder Hochsprache vornehmen, die auf ein Random-Access-Flesystem zugreifen können.
Du musst eben nur zeilenweise einlesen und nicht mit einem Monsterbefehl die gesamte Quelldatei auf einmal einlesen.
Du liest zeilenweise, zählst mit, schreibst in eine Datei weg und öffnest aller X Leseoperationen eine neue Zieldatei.
Siehe auch fgetcsv()
Glück Auf
Tom vom Berg
Hi,
Hello,
Wenn Du die Zeilentrenner kennst (siehe Raketentipps) kannst Du die Aufspaltung mit fast jeder Hochsprache vornehmen, die auf ein Random-Access-Flesystem zugreifen können.
Random Access ist für diesen Ansatz nicht einmal nötig: Streng sequentielles Lesen, Zeichen für Zeichen, würde auch schon genügen.
Du liest zeilenweise, zählst mit, schreibst in eine Datei weg und öffnest aller X Leseoperationen eine neue Zieldatei.
Genau. Die Crux dabei ist nur, zwischen Zeilenumbrüchen zu unterscheiden, die a) ein Datensatz-Trenner sind oder b) Teil des Feldinhalts sind. Da muss man halt den Kontext ein bisschen im Blick behalten. Vor allem Feld-Delimiter und String-Begrenzer kennen und erkennen.
Und bei inkonsistenten Daten auch einfach mal "Scheiße!" schreien.
Siehe auch fgetcsv()
Das wäre vermutlich einfacher als selbst einen CSV-Parser zu klöppeln. Es sei denn, die Datenquelle benutzt eine so abstruse CSV-Interpretation, dass fgetcsv() damit nicht mehr umgehen kann.
Möge die Übung gelingen
Martin
Hello,
Wenn Du die Zeilentrenner kennst (siehe Raketentipps) kannst Du die Aufspaltung mit fast jeder Hochsprache vornehmen, die auf ein Random-Access-Flesystem zugreifen können.
Random Access ist für diesen Ansatz nicht einmal nötig: Streng sequentielles Lesen, Zeichen für Zeichen, würde auch schon genügen.
Genaugenommen ja. Aber Tape orientied Storage ist heutzutage eher ungewöhnlich.
Es geht ja hier nur darum, in der Anwendungsschicht nicht blockorientiert arbeiten zu müssen und nicht die ganze Datei auf einmal einlesen zu müsen - obwohl man heutzutage ja leicht mal 16GB Arbeitsspeicher zur Verfügung hat. Den hat selbst mein Laptop inzwischen. Ich weiß allerdings nicht, wieviel ich davon mit den verfügbaren Programmen kontrollieren kann. Wo liegen eigentlich die Grenzen bei PHP auf 64-Bit-Systemen?
Siehe auch fgetcsv()
Das wäre vermutlich einfacher als selbst einen CSV-Parser zu klöppeln. Es sei denn, die Datenquelle benutzt eine so abstruse CSV-Interpretation, dass fgetcsv() damit nicht mehr umgehen kann.
Wir hatten das Thema ja kürzlich schon mal erörtert. Eine Datenprobe der Datei wäre also vor weiteren Diskussionen sinnvoll.
Glück Auf
Tom vom Berg
Hallo TS,
Wo liegen eigentlich die Grenzen bei PHP auf 64-Bit-Systemen?
Im physischen Speicher.
Ich habe gerade mal einen kleinen Memory-Hog programmiert und ihm per ini_set ein Speicherlimit von 16G verpasst. Mein physischer Speicher beträgt 8GB, ich habe PHP 8.1 64-bit unter Windows 10 verwendet.
Dann eine Schleife, die ein Array mit 16K langen Strings füllt - solange ich der physischen Speichergröße nicht nahekomme, geht's. Aber dann wird's langsam eng, denn ein lineares Array, das ich immer weiter vergrößere, wird im Speicher regelmäßig umkopiert. Nicht die Inhalte, aber die Array-Kontrollstruktur, und dadurch tobt PHP immer wieder kreuz und quert durch seinen Speicher und lässt ihn nicht unangetastet im pagefile. Mein Windows ist zunächst einmal nicht stehen geblieben, aber es hatte auf einmal immer wieder Aussetzer von 5s-30s. Nicht gut, finde ich, da hat es einem Userprozess zu viel Prio gegeben. Und dabei liegt mein pagefile schon auf einer SSD - eine HDD wäre vermutlich rotglühend geworden.
Und dann kam der Punkt, wo auch 5 Minuten Warten nicht mehr half und ich den Ausschalter betätigen musste. D.h. Memory Overcommitment in einem einzigen PHP Prozess ist nicht gut. Wie es in mehreren parallelen PHP Prozessen aussieht, die in Summe den Speicher overcommitten, habe ich jetzt nicht probiert.
Interessant war aber: Ich konnte für die 16K Strings nicht einfach str_repeat("*", 16384) verwenden. Beim ersten Programmlauf hat er dann brav Speicher belegt, aber ab dem zweiten Lauf ging es deutlich herunter. Offenbar hat der opcache daraus interned strings gemacht und sie wiederverwendet. Mit
MudGuard
Jonny 5$x = "*";
$arr[$i] = str_repeat($x, 16384);
war's mit dem Sparen dann aber wieder vorbei.
Würde mich interessieren, wie Linux damit umgeht.
Hier der Memory Hogger:
<?php
// WARNUNG - NICHT AUF DEINEM WEBSERVER AUSFÜHREN
ini_set("memory_limit", "16384G");
$a = [];
$t = 0;
$mb = 1024*1024;
$chunkSize = 4 * 1024;
for ($c=0; $c<32; $c++) {
$a[$c] = [];
for ($i=0; $i<$chunkSize; $i++) {
$p = "ABC-";
$a[$c][$i] = str_repeat($p, 1024 * 4);
$t += 16*1024;
}
printf("Chunk %3d complete - %6.1f MB in %7d strings, use %9.3f MB\n",
$c, $t/$mb, ($c+1)*$chunkSize, memory_get_usage()/$mb);
}
echo "Hog complete\n";
Bis $c=80 ging's bei mir, und bei $c=109 ist der PC verstorben 😂
Rolf
Hello Rolf,
interessanter Versuch, bei dem wohl jeder Serverbetreiber nochmal in sich gehen muss, und das näher untersuchen.
Insbesondere, was passiert bei mehreren PHP-Prozessen, wenn die alle sehr viel Speicher benötigen?
Schieße ich dann meinen Server oder gar den Host ab?
Beim PHP-Apache-Modul dürfte es ja schon solala durch die maximale Anzahl gleichzeitiger HTTP/s-Requests limitiert bzw. vorausberechenbar sein, ob und wann es krachen könnte.
Edit Rolf B: Fullquote eliminiert
Glück Auf
Tom vom Berg
Ich habe gerade mal einen kleinen Memory-Hog programmiert und ihm per ini_set ein Speicherlimit von 16G verpasst.
ini_set("memory_limit", "16384G");
Demnach eher 16 Tebibytes.
Ich habe seit gestern einen Raspi400 als „Ganztagesrechner“ laufen weil Energiesparen eine der vielen Möglichkeiten ist, um Putin die „friedliche Spezialoperation“ zu „emmerdieren“. (Und 16h/Tag mal gesparte 100W sind immerhin 1,6kWh, also ~50 Cent/Tag oder 15€/Monat oder 180 € per anno, mit denen ich die Inflation etwas ausgleiche.)
Wenn ich den Großen anmache kann ich mir das ja mal ansehen.
Hello,
Ich habe seit gestern einen Raspi400 als „Ganztagesrechner“ laufen weil Energiesparen eine der vielen Möglichkeiten ist, um Putin die „friedliche Spezialoperation“ zu „emmerdieren“.
Da wüsste ich noch 'was:
Все российские солдаты получают убежище и до 30 000 евро, если продадут нам свое оружие. Европейские государства выделяют на это 500 000 000 000 евро.
Glück Auf
Tom vom Berg
Hi there,
Ich habe seit gestern einen Raspi400 als „Ganztagesrechner“ laufen weil Energiesparen eine der vielen Möglichkeiten ist, um Putin die „friedliche Spezialoperation“ zu „emmerdieren“. (Und 16h/Tag mal gesparte 100W sind immerhin 1,6kWh, also ~50 Cent/Tag oder 15€/Monat oder 180 € per anno, mit denen ich die Inflation etwas ausgleiche.)
Und jetzt stell' Dir vor, Du wärst ein russischer Soldat und investierst die 30 TSD Euro, die Du bekommst, wenn Du Deine Waffen niederlegst (so zumindest hab ich das Gefasel von TS verstanden) in den Betrieb von lauter Raspi400 - das würde den Putin aber sowas von ärgern - was glaubst Du, wieviel weniger Energie der dafür liefern müsste! Ich trink' jetzt noch eine Flasche auf die Eroberer des Nutzlosen...
Hello,
[...] (so zumindest hab ich das Gefasel von TS verstanden) [...]
Diese Formulierung entbehrt jeglicher Empathie. Ich fände es neutraler besser:
"so zumindest habe ich TS verstanden".
Und dann würde ich Dir so neutral wie möglich darauf antworten, dass deine Interpretation nicht korrekt ist. Die bis zu 30.000€ soll nicht Jörg bekommen, sondern der Soldat, der in Europa Asyl bekommt und Europa seine Waffen (Gewehre, Munition, Panzer, Flugzeug, Raketenwerfer, ...) "verkauft". Europa will ja aufrüsten und müsste dann nicht erst selber in die Planungs- und Fertigungsphase eintreten, sondern könnte fertige Waffen beziehen, was zusätzlich den Vorteil hätte, dass die "Gegenseite" Kräfte und Material binden müsste für die Nachfertigung, wenn denn überhaupt noch jemand dort bliebe, um sich im Auftrag eines Despotenregimes abmurxen zu lassen.
Und die bei uns notwendigen Fachkräfte würde dies vermutlich auch bringen.
So zumindest habe ich den Hilferuf aus dem Internet mittels Google für mich übersetzt:
Все российские солдаты получают убежище и до 30 000 евро, если продадут нам свое оружие. Европейские государства выделяют на это 500 000 000 000 евро.
Alle russischen Soldaten erhalten Asyl und bis zu 30.000 Euro, wenn sie uns ihre Waffen verkaufen. Europäische Staaten stellen dafür 500.000.000.000 Euro bereit.
Glück Auf
Tom vom Berg
Hi there,
Hello,
[...] (so zumindest hab ich das Gefasel von TS verstanden) [...]
Diese Formulierung entbehrt jeglicher Empathie. Ich fände es neutraler besser:
Ja, den Vorwurf hör' ich öfter. Meine Weinbrüder und Saufkumpane behaupten immer, ich litte am Asperger-Syndrom.
Und dann würde ich Dir so neutral wie möglich darauf antworten, dass deine Interpretation nicht korrekt ist. Die bis zu 30.000€ soll nicht Jörg bekommen, sondern der Soldat, der in Europa Asyl bekommt und Europa seine Waffen (Gewehre, Munition, Panzer, Flugzeug, Raketenwerfer, ...) "verkauft".
Ja, das hab ich ja auch so verstanden. Was ich nicht verstanden habe ist, was der liebe Jörg mit seinem vermeintlichen Energiesparen bewerkstelligen will.
So zumindest habe ich den Hilferuf aus dem Internet mittels Google für mich übersetzt:
Все российские солдаты получают убежище и до 30 000 евро, если продадут нам свое оружие. Европейские государства выделяют на это 500 000 000 000 евро.
Heisst's ja auch. Ich durfte im glücklich verpennten Österreich der siebziger Jahre etwas Russisch lernen. Das war bis jetzt (haha) zwar völlig nutzlos, aber nachdem wir hier nicht einmal eine Fahrstunde von der slowenischen Grenze entfernt sind war's doch irgendwie brauchbar...
Hello,
Ich habe seit gestern einen Raspi400 als „Ganztagesrechner“ laufen weil Energiesparen eine der vielen Möglichkeiten ist, um Putin die „friedliche Spezialoperation“ zu „emmerdieren“. (Und 16h/Tag mal gesparte 100W sind immerhin 1,6kWh, also ~50 Cent/Tag oder 15€/Monat oder 180 € per anno, mit denen ich die Inflation etwas ausgleiche.)
Meintest Du emendieren, oder war das eine Persilflagge *äh* Persiflage?
Der "Kleine" kann leider zu Zeit nur bis 8GB Hauptspeicher, weil fest eingebaut. Aber Swappen könnte er reichlich. Das dürfte auch nicht soviel Performance kosten, wie bei einem HDD-Persistentspeicher. Ich habe inzwischen 256GB als Speicherkarte drinstecken.
Ich vermisse aber noch das 64-Bit Raspbian, oder wie das jetzt heißt. Muss ich gleich nochmal suchen, ob das inzwischen freigegeben ist. Meine Wetterlogs haben inzwiwschen nämlich auch schon 288.223 Messwerte pro Fühler. Und die werden als Textdatei mit Fixed-Field-Length geführt, also jedes Feld und damit jede Zeile ist gleich lang und daher über die (Satznummer * Satzgröße) adressierbar. Die will ich auf DBMS unstellen auf der Raspberry.
Das passt dann wieder zum OP-Thema.
Heise schreibt ja bereits über das 64-Bit-OS für die Raspberry. Jetzt muss ich nur noch finden, wie ich alles aus der 32-Bit-Intallation übernehmen kann. Zwei Karten altes 32-Bit und neue für das 64-Bit-OS wären vorhanden und ein USB-Kartenleser zum Kopieren ...
Das hatt ich schon mal. Nur was müsste ich übertragen oder wie migrieren?
Glück Auf
Tom vom Berg
Ich vermisse aber noch das 64-Bit Raspbian, oder wie das jetzt heißt. Muss ich gleich nochmal suchen, ob das inzwischen freigegeben ist.
uname -a sagt bei mir:
Linux r400.home 5.10.92-v8+ #1514 SMP PREEMPT Mon Jan 17 17:39:38 GMT 2022 aarch64 GNU/Linux
lsb_release -d:
debian GNU/Linux 11 (bullseye)
Das hatte ich schon mal. Nur was müsste ich übertragen oder wie migrieren?
Auspacken, auf Karte schieben, booten, updaten, /etc/apt/sources.list[.d/*.list] anpassen, updaten, Software installieren - und dann die Dienste anhalten und (selectiv) die Daten aus /etc, /var, /home vom Backup kopieren.
Ich hab sowas oft genug gemacht, ich hab gar keinen Plan mehr... :-)
Meintest Du emendieren, oder war das eine Persilflagge *äh* Persiflage
Gewiss nicht. Ich meine und notiere bewusst „emmerdieren“, also „emmerde“ Wöllte man es wörtlich übersetzen käme wohl „es zu Scheiße machen“ heraus. Höfliche Menschen sagen auf teutogermanisch „verübeln“.
Das Wort sollte seit Macrons berechtigtem Ausbruch in Deutschland bekannt sein...
Hello,
Ich habe gerade mal einen kleinen Memory-Hog programmiert und ihm per ini_set ein Speicherlimit von 16G verpasst.
ini_set("memory_limit", "16384G");Demnach eher 16 Tebibytes.
Ich habe seit gestern einen Raspi400 als „Ganztagesrechner“ laufen weil Energiesparen eine der vielen Möglichkeiten ist, um Putin die „friedliche Spezialoperation“ zu „emmerdieren“. (Und 16h/Tag mal gesparte 100W sind immerhin 1,6kWh, also ~50 Cent/Tag oder 15€/Monat oder 180 € per anno, mit denen ich die Inflation etwas ausgleiche.)
Ich habe Rolf so verstanden, dass man in der PHP-Konfiguration auch max. Speichergrößen einstellen kann, die der darunterliegende Host gar nicht unterützen kann. Das ergibt jetzt mehrere Fragen:
Glück Auf
Tom vom Berg
Tach!
Ich habe Rolf so verstanden, dass man in der PHP-Konfiguration auch max. Speichergrößen einstellen kann, die der darunterliegende Host gar nicht unterützen kann. Das ergibt jetzt mehrere Fragen:
- könnntest Du bitte auf deinem Frischling mal ausprobieren, ob das stimmt?
Warum nicht? Speicherverwaltung findet heutzuage durchaus dynamisch statt. Du kannst nicht immer abfragen, wieviel Speicher dir das System zur Verfügung zu stellen gewillt ist. Neben Auslagerungsdateien gibt es im VM-Bereich auch ein Feature namens Dynamic Memory.
- Kennst Du schon eine Möglichkeit, das in PHP selbst ("objektorientiert") abzufangen? Eine solche Konfigurationsmöglichkeit muss auf jeden Fall unterbunden werden!
Verstehe ich grad nicht richtig. Einfach das memory_limit in Ruhe lassen. Wer soll da was regeln, wenn der Programmierer sowohl derjenige ist, der das Memory-Limit ändern kann, als auch die Änderung überwachen soll?
- Wie sollte man generell bei jedem PHP-Scriptstart den verfügbaren Speicher erfragen und bei Mangel darauf reagieren?
Generell ist da nichts nötig. Die meisten Anwendungsfälle nutzen den zur Verfügung stehenden Speicher nicht aus. Lediglich bei Aufgabenstellungen mit erhöhtem Speicherbedarf braucht man sich Gedanken dazu zu machen. Feinplanen kann man das sowieso nicht, weil du nicht wissen kannst, wieviel Speicher die jeweiligen Operationen benötigen. Du kannst das Memoy-Limit nur nach Gefühl und empirisch einstellen. Also, eigentlich kannst du schon die C-Quellen von PHP bezüglich Speicherverbrauch analysieren, aber solch ein Aufwand lohnt sich überhaupt nicht.
dedlfix.
Hello Dedlfix,
deine Antworten beantworten leider nicht die Spezialfälle, die aber immer berücksichtigt werden müssen in dynamischen Systemen, sondern nur eine "Allgemeinmeinung", die vielleicht in statischen Single-User-Systems gelten könnte.
[...]
Mehr dazu, wenn Du nochmal substantiierter geworden bist.
Glück Auf
Tom vom Berg
Hallo TS,
im Normalfall ist PHP auf einen relativ knappen Speicher eingestellt, weil Hatti P. Normalwebrequest kein Übermaß an RAM zum Bearbeiten braucht. Wenn ein Admin mehr einstellt, als gut für das System ist, ist der Admin schuld. Und wenn der User per ini_set Mist macht, dann muss man entweder ini_set abschalten oder sich Suhosin anschauen. Mit mod_php kann man auch php_admin_value verwenden. Ein Standardfeature, um in der php.ini bestimmte Settings zu sperren, scheint's nicht zu geben.
Ein Webserver, der gut beschäftigt werden soll, hat mehrere PHP FastCGI Instanzen laufen, auf die die eingehenden Requests verteilt werden. Kann ich bei meinem kleinen IIS hier jedenfalls relativ problemlos einstellen, der startet dann je nach Bedarf ein bis drölf PHP Instanzen und beendet sie bei Nichtgebraucht auch wieder.
Was soll denn ein solches PHP tun, wenn es zu wenig Speicher feststellt? Soll es andere Prozesse beenden, um Speicher freizubekommen? Soll es den Request ablehnen? Das ist Lastverteilung und Lastoptimierung, und dafür ist es zu spät, wenn der Request bei PHP ankommt. Das muss vorher passieren, entweder vom Webserver gesteuert oder von einer anderen Engine, die sich um Lastverteilung kümmert. Beim IIS kenne ich keine Schalter, um Requests eher in der Warteschlange zu halten wenn der Speicher knapp wird, aber vielleicht gibt's ja andere Loadbalancer, die das können.
Die bessere Idee ist aber, einen Webserver so aufzusetzen, dass man jedem PHP Prozess X MB Speicher zugesteht und ihn so zu betreiben, dass typsicherweise $$N\cdot X$$ MB Speicher frei sind.
Und wenn man - von einem Webrequest angestoßen - wirklich speicherintensive Dinge tun muss, empfiehlt sich der Einsatz eines Application Servers, an den der Webserver die Anfrage delegiert.
Anders ist es bei CRON Jobs, die ein PHP Script laufen lassen sollen. Aber auch da stellt sich die Frage, was passieren soll? Willst Du im PHP unterschiedliche Algorithmen verwenden, wenn viel oder wenig Speicher da ist? Anders cachen? Was tust Du, wenn Du Dich für A oder B entschieden hast, und dann kommt Speicherschwein Herta vorbei und halbiert den freien Speicher? Das ist ein hochkomplexes Thema.
Rolf
im Normalfall ist PHP auf einen relativ knappen Speicher eingestellt, weil Hatti P. Normalwebrequest kein Übermaß an RAM zum Bearbeiten braucht.
Also laut Handbuch ist der Default-Value 128MB.
Ist denn wirklich keiner hier, der meint, dass das für den Zweck („Webseite brauen/Webrequest beantworten“) „eher viel“ ist? Was wollt Ihr denn? Betrachter via Webseite Videos schneiden lassen oder „den gesamten Himmel nach unentdeckten Planeten durchforsten - as a Webservice“? Das Zeug muss ja auch noch durchs Web transportiert werden!
Für Datenbanken gibt es („Heureka!“) Datenbanken. Und für den ganzen anderen Quatsch genug Möglichkeiten mit Datenblöcken (a.k.a. Zeilen) zu arbeiten.
Hallo Raketenwilli,
das memory_limit wird ja im Normalfall nicht ausgenutzt, so dass das den Server nicht unnötig belastet. Aber ich stimme Dir durchaus zu, dass die meisten Webrequests mit deutlich weniger auskommen dürften.
Rolf
Tach!
im Normalfall ist PHP auf einen relativ knappen Speicher eingestellt, weil Hatti P. Normalwebrequest kein Übermaß an RAM zum Bearbeiten braucht.
Also laut Handbuch ist der Default-Value 128MB.
Ist denn wirklich keiner hier, der meint, dass das für den Zweck („Webseite brauen/Webrequest beantworten“) „eher viel“ ist?
Ja, für 80/100 Fällen ist das mehr als ausreichend. Es gibt aber einige Fälle in denen Systeme funktional recht umfangreich sind und dafür eine Menge Speicher belegen, Magento als Shopsystem zum Beispiel.
Was wollt Ihr denn? Betrachter via Webseite Videos schneiden lassen oder „den gesamten Himmel nach unentdeckten Planeten durchforsten - as a Webservice“?
Es reicht ja schon, wenn Lieschen Müller für ihr Weblog mit ihrer Smartphone-Kamera hochlauflösende Bilder erstellt, und die Blog-Software das Bild runterskalieren soll. Falls es überhaupt durch das Upload-Limit passt.
dedlfix.
Es gibt aber einige Fälle in denen Systeme funktional recht umfangreich sind und dafür eine Menge Speicher belegen, Magento als Shopsystem zum Beispiel.
Nein. Das liegt am Subsystem zur Befriedigung des Verkaufsleiters (der sich selbst für einen Marketing-Chef hält). Da werden bei jedem „mouseevent“ Tages-, Wochen-, Monats-, Quartalsberichte und so weiter als Powerpoint-Präsentation erstellt, diese automatisch gestartet, mittels Speex auch kommentiert und sodann als unkomprimiertes AVI im Arbeitsspeicher gehalten und nach dem Login mit „DefaultUser“ und „DefaultPassword“ abgespielt. Die Preise, Passwörter, Adressen und Kreditlimits der Kunden kann man dann auch gleich anpassen…
Es reicht ja schon, wenn Lieschen Müller für ihr Weblog mit ihrer Smartphone-Kamera hochlauflösende Bilder erstellt, und die Blog-Software das Bild runterskalieren soll. Falls es überhaupt durch das Upload-Limit passt.
Lieschen Müller scheitert evtl. an einem Upload-Limit. Letztlich zählt für die Bildverarbeitung aber die zu verarbeitende Pixelmasse. Wenn ich es darauf anlegen würde, kann ich ein hochkomprimiertes JPG mit überschaubarer Dateigröße bauen, was die 128MB Memory-Limit dann dennoch leicht bricht.
Hallo Mitleser,
weswegen man für ein Profisystem solche Aufträge an einen Application Server oder zumindest einen asynchronen Hintergrundprozess delegieren sollte. Sinnvollerweise als Batch-Auftrag, d.h. Lieschen schickt die Datei und bekommt eine Statusseite, die sie refreshen kann und bei fertiger Konvertierung kann sie das Ergebnis downloaden.
Um diese Batches effizient zu steuern ist ein CRON Job vermutlich nicht das richtige Werkzeug - aber ich kenn CRON nicht gut genug um das zu wissen. Da muss man ein bisschen Schmalz reinstecken, um die Last sauber zu steuern, und PHP ist nicht unbedingt das richtige Tool dafür.
Rolf
UHD mit 32 Bit Farbtiefe (RGBA):
3840*2028*4
31150080
also rund 32 MB.
Wenn ich mit dem „Großen“ ein Bildschirmfoto meines Screens auf 2 UHD-Monitoren mache, sieht die Rechnung so aus:
2*3840*2028*4
62300160
also rund 60MB (Gimp speichert das im Raw-Modus mit 24-Bit Farbtiefe auf 45MB)
Selbst eine eine 20 Megapixel Kamera käme im Raw-Modus auf 20M*4 Bytes (32 Bit Farbtiefe) = 80MB. (Die liefern aber eher RGB, also 60 MB)
Fazit: Du müsstest allerhand Kopfstände machen um die 128MB zu schaffen.
Tach!
deine Antworten beantworten leider nicht die Spezialfälle, die aber immer berücksichtigt werden müssen in dynamischen Systemen, sondern nur eine "Allgemeinmeinung", die vielleicht in statischen Single-User-Systems gelten könnte.
Wenn du konkrete Antworten haben möchtest, musst du deine Fragen konkret und nicht allgemein stellen.
Mehr dazu, wenn Du nochmal substantiierter geworden bist.
Gleichfalls.
dedlfix.
Ich habe Rolf so verstanden, dass man in der PHP-Konfiguration auch max. Speichergrößen einstellen kann, die der darunterliegende Host gar nicht unterützen kann.
Ich habe im Handbuch gelesen, dass man mit memory_limit = -1 auch gar keine Speichergrenze festlegen kann.
- könnntest Du bitte auf deinem Frischling mal ausprobieren, ob das stimmt?
Klar geht das. In /etc/php/8.1/cli/php.ini steht besagtes -1 drin.
- Kennst Du schon eine Möglichkeit, das in PHP selbst ("objektorientiert") abzufangen? Eine solche Konfigurationsmöglichkeit muss auf jeden Fall unterbunden werden!
Wozu? Man kann das besser beschränken - Und Rolfs Ausführungen solltest Du Dir auf jeden Fall reinziehen.
Hello,
die MySQLi- bzw. MariaDB-Textschnittstelle erlaubt nur eine begrente Anzahl von Zeilen aka. Value-Gruppen in einem Update- oder Insert-Statement. Man muss also mehrere daraus machen.
Wenn Du dir mal einen Backup-Export des DBMS anschaust, kannst Du das auch erkennen.
Alternativ muss man die Binary-Befehle benutzen, die direkt ohne die Textschnittstelle (SQL) auf eine Datenbasis zugreifen können.
Die müssten das eigentlich können.
Und siehd auch weitere Info
Glück Auf
Tom vom Berg
Hallo TS,
einen Massenimport per INSERT sollte man meiden wie die Russen die Demokratie, vor allem, wenn wie hier massive Massen anfallen.
Je nach DBMS kann man durch den Versuch, per INSERT eine Tabelle zu laden, auch reichlich bemessenen Plattenplatz zum Überlaufen bringen.
Einen Massenimport macht man - wie von Dir verlinkt - per LOAD. Der setzt aber eine gewisse Standardisierung der Eingabedatei voraus, und Jörg meint ja, dass er eine Mischung bunten Bullshits erhält, bei dem er teils erraten muss, was gemeint ist. Dafür schreibt man normalerweise ein Vorverarbeitungsscript, das im Zweifelsfall die Daten aussteuert, mit denen es nichts anfangen kann (sofern das aus Konsistenzgründen möglich ist).
Das alles hat den Zweck, die DB so schnell wie möglich auf Stand zu bringen und die Downtime gering zu halten.
Rolf
Tach!
- ein INSERT-Statement wird ganz oder gar nicht ausgeführt, d.h. die Daten müssen im Transaction Log festgehalten werden -> Extraaufwand auf der Platte.
Das Binary Log, wie es bei MySQL heißt, existiert nur auf Wunsch, ist also im Normalfall abgeschaltet. Es wird vorwiegend bei Replication benötigt.
und Jörg meint ja, dass er eine Mischung bunten Bullshits erhält,
Anderer Thread, anderer OP. In diesem Thrad ging es eigentlich nur darum, eine große Datenmenge zu importieren. So eine große Datenmenge importiert man üblicherweise nicht ständig, also wird Performance auch nicht so die Rolle spielen. Auch dass der OP versucht hat, die Datei per Hand zu teilen, spricht nicht dafür, dass das ein automatisierter und laufzeitkritischer Prozess werden soll.
dedlfix.
Hallo dedlfix,
Das Binary Log, wie es bei MySQL heißt, existiert nur auf Wunsch, ist also im Normalfall abgeschaltet
Ja, sorry, ich bin geistig zu sehr bei professionellen DBMS, wie DB2 oder MS Sql Server. Aber MYSQL muss, wenn Du Transaktionen verwendest, auch ein Log schreiben um die Transaktion zurückrollen zu können. Bei MYISAM würde ich Dir sofort glauben, dass es ein Log nur im Ausnahmefall gibt. Aber InnoDB sollte doch ACID-fähig sein, d.h. muss den ROLLBACK eines Statements ermöglichen.
Anderer Thread, anderer OP.
Ups - Jörg hatte mitdiskutiert und das hat mich dann kalt konfusioniert.
Rolf
Tach!
Aber MYSQL muss, wenn Du Transaktionen verwendest, auch ein Log schreiben um die Transaktion zurückrollen zu können.
Anscheinend muss es das nicht. Ins Binary Log wird bei Transaktionen erst beim Commit geschrieben, und beim Rollback gar nichts.
Each transaction is stored in the binary log in one chunk, upon COMMIT.
Das heißt, auch wenn das Binary Log nicht aktiviert wurde, können Transaktionen stattfinden.
Auch in der Dokumentation zum Binary Log stehen Transactions nicht als Verwendungszweck drin.
dedlfix.
Tach!
Aber MYSQL muss, wenn Du Transaktionen verwendest, auch ein Log schreiben um die Transaktion zurückrollen zu können.
Da es ja die Storage Engines gibt, sind einige Dinge nicht global sondern in der jeweiligen Storage Engine geregelt. Die InnoDB hat ein paar On-Disk Structures, in die es auch irgendwelche Log-Geschichten schreibt. Inwieweit das aber zu Overhead bei Transactions führt oder Bestandteil der normalen Operationen ist, hab ich auf die schnelle nicht rauslesen können.
dedlfix.
Hallo dedlfix,
ja, genau die. Der Redo-Log (zum Recover bei Crashes) und der Undo-Log (für ROLLBACKs). Bei Transaktionen, die viel tun, laufen diese Logs schnell voll.
MYISAM hat keine Transaktionen, deshalb ist das da irrelevant.
Rolf
Tach!
Post!
Aber MYSQL muss, wenn Du Transaktionen verwendest, auch ein Log schreiben um die Transaktion zurückrollen zu können.
Anscheinend muss es das nicht. Ins Binary Log wird bei Transaktionen erst beim Commit geschrieben, und beim Rollback gar nichts.
Richtig!
Im Binlog interessieren nicht abgeschlossene Transaktionen nicht, weil das Binlog ganz stumpf zu Backup- und Replikationszwecken dient.