Php array maximum

hatschi1810

Angesehenes Mitglied
Irgendwann gab’s glaube ich mal die Frage von Josh ob es ein Maximum für arrays in PHP gibt. Leider habe ich den Original-Thread dazu nicht mehr gefunden.

Ich kann zwar jetzt nicht wirklich sagen ob es da eine Grenze gibt oder ob die nur vom max. Speicher für das Script abhängt, allerdings habe ich gerade an einem Script festgestellt, das man da manchmal schon aufpassen sollte.

Jedenfalls klappt ein explode das einen String in einen Array mit ~65000 Elementen zerlegen soll auf meinem Testrechner nicht ;-)

Es lohnt es sich eben doch mit Echtdaten beim Entwickeln zu testen, das da solche Datenmengen entstehen hätte ich bei dem Script nicht bedacht und erst am Ende festgestellt.
 
ich weiß nicht, ob das im Zusammenhang steht:
Ein Kollege von mir hat gerade ein Problem damit, Dateien in eine Datenbank zu legen, weil php wohl nur Variablen mit max. 2MB mag (hat nichts mit der Postmax-Größe zu tun).

Weiß jemand, wie man diesen Wert eventuell beeinflussen kann?
 
Sicher das es an PHP nicht an der Datenbank liegt?

Wie sieht denn das Setup aus?

Apache, Windows/Linux, PHP? Bitte mit Versionsnummern.
 
hm, auf das Problem selber wollte ich eigentlich gar nicht unbedingt heraus.
Nun gut:
Es handelt sich um SunOS 5.9 mit php 4.3.3, Apache 1.3.28, MySQL 3.23.49 .
"MYSQL_MODULE_TYPE" ist "builtin" (also php wurde mit '--with-mysql' kompiliert).
Safe Mode ist nicht an, maximale Speicherbelegung von Skripten ist nicht gesetzt, Upload- und Post- Maxsize sind je 32MB.

Die Frage ist, woher die Größenbeschränkung auf 2MB von Variablen kommen könnte.
 
Eigentlich würde ich ja auf ein verwandtes Problem tippen, nämlich einen schlechter Lösungsansatz ;-)

Bei mir lag der Fehler klar in der Annahme, dass ich ein altes Verfahren adaptieren kann. Glücklicherweise habe ich mal eine wichtige Funktion mit echten Daten getestet bevor ich das eigentliche ganze Skript gemacht habe. Hat mir eine Menge Zeit gespart.

Beim 2mb Problem würde ich noch mal Nachdenken ob der Ansatz richtig ist. Klarerweise gibt es auch echte Gründe für solche Probleme, meist lassen sich solche „Extrembeispiele“ umgehen.
 
Der Speicherbedarf von Arrays hängt vom maximalen Speicher für Skripte ab (siehe memory_limit in der php.ini). Hintergrund: Dynamische Arrays sind in verketteten Listen organisiert. Für jedes neue Element des Arrays wird ein bisschen Speicher alloziert und an das Array angehängt. Ein 32bit-System wie PHP4 hat mit Arrays aus 65000 Strings keine Probleme, solange die Umgebung stimmt.

Ein Limit auf 2MB pro Variable gibt es nicht. Habe selbst schon größere Uploads realisiert. Es hängt dabei nicht nur von der maximalen Post-Größe ab, sondern auch von der maximalen Upload-Größe.

Howto optimize your PHP installation to handle large file uploads
 
QUOTE Ich kann zwar jetzt nicht wirklich sagen ob es da eine Grenze gibt oder ob die nur vom max. Speicher für das Script abhängt, allerdings habe ich gerade an einem Script festgestellt, das man da manchmal schon aufpassen sollte.


Nachdem ich mit einem eigens für diese Zwecke programmierten CMS aus schlichter Faulheit ein paar Abkürzungen genommen habe, war ich fast stolz mit meinem Script jeden Server lahm zu legen ;-)
Da ich unglaubliche Mühe habe die Grenzen abzuschätzen bin ich dazu übergegangen Sachen, welche nur schon in die Nähe dieser Grenze kommen sequenziell zu bearbeiten. Allgemein hat mich das zu einem grossen Fan von Funktionen gemacht, die sich auch wieder aufnehmen lassen, wenn der vorherige Rechner explodiert ist ;-)
 
Über den Speicher hatte ich schon kurz nachgedacht. Im Endeffekt ist es so, dass ich einen String fetchen den ich mit explode aufteilen wollte. Vom Speicher würde sich das wohl ausgehen, was für ein Speicher für explode oder Split notwendig ist weiß ich aber nicht.

Jedenfalls werde ich das ganze jetzt anders abarbeiten damit es auch bei wesentlich größerer Datenmenge klappt.
 
QUOTE (Alain Aubert @ Mi 15.12.2004, 8:29) Allgemein hat mich das zu einem grossen Fan von Funktionen gemacht, die sich auch wieder aufnehmen lassen, wenn der vorherige Rechner explodiert ist ;-)

*lach*

Jepp, da wird einem immer warm ums Herz
wink.gif


Wenn man es ernsthaft betrachtet, sollte man schon aufgrund der maximalen Ausführungszeit der Skripte auch bei sequenziellen (also speicherschonenden) Verfahren darauf achten, dass jede Transaktion einen sauberen Datenbestand hinterlässt.
 
Zurück
Oben