Schwerwiegender Fehler: Erlaubte Speichergröße von 134217728 Bytes erschöpft (CodeIgniter + XML-RPC)

Question

Ich habe eine Reihe von POS-Systemen (Point of Sale), die regelmäßig neue Verkaufsdaten an eine zentrale Datenbank senden, die die Daten zur Berichterstellung in einer großen Datenbank speichert.

Die Client-Kasse basiert auf PHPPOS, und ich habe ein Modul implementiert, das die Standard-XML-RPC-Bibliothek verwendet, um Verkaufsdaten an den Dienst zu senden. Das Serversystem basiert auf CodeIgniter und verwendet die XML-RPC und XML-RPCS Bibliotheken für die Webservice-Komponente. Immer wenn ich viele Verkaufsdaten sende (nur 50 Zeilen aus der Verkaufstabelle und einzelne Zeilen aus sales_items, die sich auf jeden Artikel innerhalb des Verkaufs beziehen), erhalte ich den folgenden Fehler:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 54 bytes)

128M ist der Standardwert in php.ini aber ich gehe davon aus, dass das eine große Zahl ist, die es zu knacken gilt. In der Tat habe ich sogar versucht, diesen Wert auf 1024M, und alles, was es tut, ist eine längere Zeit dauern, um Fehler aus.

Was die Schritte angeht, die ich unternommen habe, so habe ich versucht, alle Verarbeitungen auf der Serverseite zu deaktivieren, und ich habe es so eingerichtet, dass ich unabhängig von der Eingabe eine vorgefertigte Antwort erhalte. Ich glaube jedoch, dass das Problem in der tatsächlichen Übermittlung der Daten liegt. Ich habe sogar versucht, die maximale Skriptausführungszeit für PHP zu deaktivieren, und es tritt immer noch ein Fehler auf.

Answer 1

Für Drupal-Benutzer, diese Chris Lane's Antwort von:

ini_set('memory_limit', '-1');

funktioniert, aber wir müssen es direkt nach der Eröffnung einfügen

<?php

Tag in der Datei index.php im Root-Verzeichnis Ihrer Website.

Answer 2

Ab PHP 5.3 können Sie das Speicherlimit ändern, indem Sie ein .user.ini Datei in der public_html Ordner. Erstellen Sie einfach die oben genannte Datei und geben Sie die folgende Zeile darin ein:

memory_limit = 64M

Einige cPanel-Hosts akzeptieren nur diese Methode.

Answer 3

Absturzseite?

(Das passiert, wenn MySQL große Zeilen abfragen muss. Standardmäßig, memory_limit ist auf klein eingestellt, was für die Hardware sicherer war).

Sie können den vorhandenen Speicherstatus Ihres Systems überprüfen, bevor Sie die php.ini :

# free -m
             total       used       free     shared    buffers     cached
Mem:         64457      63791        666          0       1118      18273
-/+ buffers/cache:      44398      20058
Swap:         1021          0       1021

Hier habe ich es wie im Folgenden erhöht und mache dann service httpd restart um das Problem der Absturzseite zu beheben.

# grep memory_limit /etc/php.ini
memory_limit = 512M

Answer 4

In meinem Fall auf dem Mac (Catalina - Xampp) gab es keine geladene Datei, also musste ich dies zuerst tun.

sudo cp /etc/php.ini.default /etc/php.ini
sudo nano /etc/php.ini

Dann ändern memory_limit = 512M

Starten Sie dann Apache neu und prüfen Sie, ob die Datei geladen wurde

php -i | grep php.ini

Das Ergebnis war

Configuration File (php.ini) Path => /etc
Loaded Configuration File => /etc/php.ini

Endlich prüfen

php -r "echo ini_get('memory_limit').PHP_EOL;"

Answer 5

Für diejenigen, die sich den Kopf zerbrechen, warum um alles in der Welt diese kleine Funktion ein Speicherleck verursachen sollte, sei gesagt, dass manchmal durch einen kleinen Fehler eine Funktion anfängt, sich selbst für immer rekursiv aufzurufen.

Zum Beispiel eine Proxy-Klasse, die den gleichen Namen wie eine Funktion des Objekts hat, das sie proxy stellen wird.

class Proxy {

    private $actualObject;

    public function doSomething() {

        return $this->actualObjec->doSomething();
    }
}

Manchmal vergisst man vielleicht, das kleine actualObjec-Mitglied mitzubringen, und weil der Proxy tatsächlich über das doSomething Methode würde PHP keine Fehlermeldung ausgeben und bei einer großen Klasse könnte man sie für ein paar Minuten ausblenden, um herauszufinden, warum sie Speicher leckt.