CMD: Eingabedatensatz überschreitet maximale Größe?
Ich hab hier folgendes Problem: Muss hier ein paar Texttabellen (alle mit ähnlicher Struktur) mit der Konsole bearbeiten. Das funktioniert in der Theorie auch, allerdings gibt es bei einigen Dateien unerklärbare Probleme. Unter anderem dieser Fehler hier:
Der Eingabedatensatz ?berschreitet die maximale Gr"áe. Erh"hen Sie die maximal zul"ssige Gr"áe.
Allerdings liegt es scheinbar nicht wirklich an der Größe. Bei den meisten Dateien klappt alles ohne Probleme, nur bei etwa 20% tritt o.g Fehler auf. In einzelnen Fällen wird die Datei auch bearbeitet, aber der Vorgang (ohne Meldung) willkürlich abgebrochen. Was bedeutet, dass eine kaputte unvollständige Tabelle herauskommt.
Die Fehler lassen sich dateispezifisch jeweils reproduzieren, sind also keine *zufälligen Abstürze*...
Weiß einer zufällig durch was das verursacht werden könnte oder wie man das Problem behebt?
2 Antworten
Leider hast Du nicht den Betreffenden Code angegeben welcher Deine "Datensätze" verstümmelt.
Batch ist auf Grund diverser Beschränkungen:
- Maximale Länge einer Kommandozeile 8191Zeichen (beinhaltet auch Leer- und Steuerzeichen) . Da %Variablen% vor der Ausführung einer Befehlszeile aufgelöst und als Text übergeben werden, ist sicherzustellen das die Inhalte von %Variablen% durch "Quotes" explizit als Text maskiert werden, da diese Batch-Steuerzeichen: "%!<>|&^=~* enthalten könnten. Dabei ist sicherzustellen das derart Maskierte Textzeilen/Variableninhalte ihrerseits keine "DoubleQuotes" enthalten, diese würden unkontrollierbare Nebeneffekte erzeugen. Sollte sich durch eine Längenbeschränkung der Textzeile eine ungerade Anzahl von "Quotes" ergeben kann dies zum Absturz der Batch führen!
- Findstr kann maximal 1023 Zeichen pro Zeile auswerten
- Find kann keine Begriffe finden, welche hinter der Grenze von 1070 Zechen befinden
- Sort ist auf eine maximale Zeilenlänge von 65535 beschränkt
Generell ist Batch nicht geeignet um komplexe Daten zu verarbeiten.
Input , Speichern , Auswerten und Output von Textzeilen, welche Batch-Steuerzeichen: "%!<>|&^=~* enthalten , kann ohne sehr komplexe Vorkehrungen zu schweren Fehlern oder gar Datenverlusten führen.
Ungeachtet der verworrenen Syntaxregeln von Batch können ASCII-Charaktere 0..31 und größer 126 zu Störungen im Ablauf einer Batch führen.
Ich sage zwar oft "Geht nicht gibt's nicht", aber viele Fallstricke von Batch lassen sich nur extrem kompliziert und trickreich umschiffen. (absoluter Nervenzerfetzer)
Für die Verarbeitung von Daten per Script ist PowerShell wesentlich besser geeignet. Powershell hat nicht die die Beschränkungen von Batch und und hat Vollzugriff auf alle Klassen und Methoden von C#/.Net.
Ich stelle es mal Voran...
Der Kommentar ist lang, weil auch mit viel falschen Prämissen aufgeräumt werden muss.
Du hast Dich da in irgendwelchen Fehlschlüssen verrannt.
Wenn Du extrme Datenmengen effizient verarbeiten möchtest, solltest Du vielleicht mal Fachleuten konkrete Fragen mit Codebeispielen stellen. Leuten wie mir ist es durchaus möglich den Funktionsweise einer Batch in anderen schnelleren Sprachen nachzubilden.
10-20X langsamer läuft als Batch
Ich kenne den Code Deiner "Superbatch" bzw des von Dir verwendeten Powershellscripts nicht. Das Batch schneller sein könnte ist hahnebüchener Unsinn.
Ich programmiere seit 40 Jahren und weiß um die Eigenschaften und Möglichkeiten der einzelnen Sprachen. Batch kennt definitiv keine "schnellen" Datei-Pipelinezugriffe! Batch leitet Daten prinzipiell (innerhalb einer Befehlspipeline erst weiter, wenn der aktive Prozess seine Arbeit abgeschlossen hat. Dabei bedient er sich des Standardin-/output. Das bedeutet sequenzilles lesen/schreiben. Einzelner Zeilen.
In den Kommentaren einer anderen Antwort ...
...habe ich bereits die Möglichkeit erwähnt Dateien als Streams zu behandeln. Dabei wird die Datei automatisch als geschlossener Speicherbereich im RAM abgebildet, was auf heutigen MehrkernCPU bereits eine Paralellisierung darstellt. Der Nutzer arbeitet nicht mehr explizit mit einer physischen Datei die eigentliche "Dateiarbeit" erledigen parallel Betriebssystemprozesse.
Das geht jedoch nur wenn zwischen lesen und schreiben nicht in andere Programme gewechselt werden muss. Damit scheidet Batch komplett aus!
Wenn Powershell 10 mal langsamer als Batch arbeitet, machst Du definitiv etwas falsch (zu viele Variable und umkopiervorgänge zwischen diesen? Weitergabe zu große Objekte für kleine Entscheidungen? Ineffiziente Cmdlets für extreme Datenmengen:
- https://powershell.one/tricks/performance/pipeline
- https://powershell.one/tricks/performance/group-object
- https://powershell.org/2018/05/100887-2/
...und damit komme ich zu Deinem "Energieproblem"
Wie heißt es in einem geflügelten Wort:
Ohne Mampf kein Dampf
Schnellere Befehle brauchen auch mehr Energie. Wenn Dein PowershellScript mehr Leistung beansprucht ist dies völlig normal, das es in der gleichen Zeiteinheit auch mehr Daten verarbeitet. Bei Dir tritt hingegen das Paradoxum auf, dass die Mehrleistung irgendwo in Deinem Powershellscript "verpufft" und der Output langsamer wird.
Das kann durchaus an ineffizienten Cmdlet und falschen Verarbeitungskonzepten liegen, bei denen Datenobjekte in negativen Verzweigungen verworfen werden, statt sie zu "führen"...
Das wird meine CPU bei den Datensätzten, die noch kommen definitiv nicht überleben...
Normale PowershellScripte oder Kommandozeilenprogramme laufen in der Regel Singlethreaded (auf einem Kern) beanspruchen die CPU also nur zu einem Teil.
...und selbst wenn Du es schaffst diese bis zum Anschlag zu belassten, taktet jeder gängige Prozessor seit der letzten 10Jahre automatisch herunter, wenn es ihm zu warm wird. (Außer Overclocked).
Ok ich kann jetzt natürlich nur sagen, wie ich es bisher erlebt habe. Kann natürlich sein, dass ich irgendwas (nur wenige Monate Erfahrung) falsch mache oder ewas in meinem System verlangsamt Powershell extrem...
Also nur um ein einfaches Beispiel zu nennen. Das einfache splitten oder Zusammenfügen von Dateien mit Type und nehmen dafür mal eine meiner Tabellen hier (ca. 900MB groß, 20 Mio Zeilen): Type braucht auf meinem System um die komplette Tabelle zu kopieren etwa 30 Sekunden, wenn ich das mit Powershell z.b mit get-content & select-object versuche: 10-15 Minuten Wartezeit.
Mit Batch-Filtertools wie Awk oder Grep scheint es sogar noch schneller zu gehen: Hier konnte ich in der CMD Schreib und Kopierraten von 80-100MB/sek feststellen -inkl. Schreiben der gefilterten Zeilen-, also etwa so schnell wie wenn ich per USB die Datei auf einen Datenträger kopiere, mit Powershell: bei einigen Zeile für Zeile-Operationen hatte ich Resultate von <1000 oder sogar <500 geschriebenen Zeilen pro Sekunde, bishin zu etwas schnelleren 15-20K wenn z.b der Input in 2.000er Chunks eingelesen wird. Wie gesagt einfache Operationen, ohne Tricks, Parallelisierung oder Ähnl. Oder z.b der einfache Versuch eine etwas größere .txt Datei (sagen wir 5GB groß, mit 90 Mio Zeilen) zu sortieren + Duplikatzeilen eliminieren: Wie würdest du das in Powershell erledigen? Und wie lange würde das mit maximal möglicher Optimierung dauern?
Bereits das Einlesen der kompletten Datei in den RAM (die bislang *schnellste* Powershell Methode bei mir) dauert bei mir (etwa 2MB/s Leserate) zb. fast eine ganze Stunde, wobei bereits vorher der RAM Kill-Out (32GB) droht. Mit Batch -leider klappt aber zumindest bei dieser Dateigröße auch dort nichts ohne Fehler- ist, wenn alles funktioniert, der gesamte Sortier und Schreibvorgang nach ca. 4-5 Minuten erledigt. Also vl. wurde in jüngerer Zeit wirklich etwas an der CMD verbessert oder es gibt halt irgendwas was meine Shell dramatisch verlangsamt... (evtl. Umleitung des Datenstroms durch Malware Defender oder ähnl.?!)
Benutzt dein Script "sort" ? Sind in den "fehlerhaften" Dateien Zeilen, die länger als 4k sind ? - Wenn ja, "sort /rec 65535 ..." setzt die DS-Länge auf 64k, mehr kann der nicht.
Ja es verwendet Sort. OK der Fehler bezieht sich also auf zu große Zeilenlängen?
Keine Ahnung, was sich MS beim Schreiben von sort dabei gedacht hat.... das Programm ist wahrscheinlich so alt, dass da Speicher noch rar war.
Gibt es einen Grund für diese Begrenzungen auf 4/64K?
Batch ist einen Sprache aus den 80er Jahren, mit allen Beschränkungen dieser Zeit. Damals war die maximale Länge eines Datenblocks auf die Größe eines RealMode-Datensegnents von 64kByte beschränkt.
Dieser Grund besteht nicht mehr...
...aber warum sollte an Batch noch etwas ändern? Die Sprache ist so verbugt, das selbst Profis nicht überall durchblicken und alle Fallen kennen, die zu fixen ist nahezu unmöglich. Zudem wurden/werden einige Bugs von Batch gern als "Feature" missbraucht um irgendwelche anderen Beschränkungen auszutricksen. Wenn man die betreffenden Bugs fixen würde, wäre dies das "Aus" für Millionen von tricky-Batchscipten welche vielen Legasy-Systemen ihren Dienst tun
Warum auch?
Batch war und ist eine sehr primitive Sprache für gedacht für einfache administrative Automation. Dafür reicht es
Für komplexere aufgaben gab es schon immer besser geeignete Sprachen.
Das Problem bei Powershell ist halt, dass es bei mir selbst mit Optimierung ca. 10-20X langsamer läuft als Batch und gleichzeitig etwa 2-3x so energie & rechenintensiv = das absolute Gegenteil von hardwareschonend ist. Das wird meine CPU bei den Datensätzten, die noch kommen definitiv nicht überleben...