Fatal error: Out of memory

[contaouser1]

Hallo,

ich bekomme folgende Fehlermeldung, wenn ich per Composer eine Erweiterung installieren möchte.

Fatal error: Out of memory (allocated 394526720) (tried to allocate 33554432 bytes) in phar:///kunden/xxxxxxx/xxxxxxx/contao/composer/composer.phar/src/Composer/DependencyResolver/Solver.php on line 220

Konfiguration:
Contao: 3.5.15
composer-client: 0.16.4
Provider: df
Tarif: ManagedHosting Professional
php.ini - memory_limit: 128M
initconfig.php: ini_set('memory_limit', '128M');

Hat jemand eine Idee?

[tab]

Naja... 394526720 >> 128MB. Soviel dürftest du ja schon gar nicht bekommen haben, wenn dein gesetztes Memory Limit greifen würde.

[contaouser1]

Soviel dürftest du ja schon gar nicht bekommen haben, wenn dein gesetztes Memory Limit greifen würde.

Danke für deine Antwort. Wie wird das Limit richtig gesetzt?

[tab]

Sieht eigentlich gut aus, aber es kann ja schlecht wirklich das echte, aktive memory Limit sein, weil der Fehler sonst hätte schon wesentlich früher kommen müssen. Hast du schon mal versucht, mit phpinfo() den Wert auszulesen? Obwohl auch der nicht immer stimmt. (Hallo 1&1 ) Oder setz den Wert mal größer, um zu sehen ob es dann funktioniert, oder ob sich zumindest die Werte in der Fehlermeldung ändern. Also wenigstens mal auf 512M.

[contaouser1]

Habe das memory_limit mal auf 512M und 1024M gesetzt, ändert nichts an der Fehlermeldung. Die Limitangabe scheint ignoriert zu werden.

[Contao-Academy]

Hast du einen SSH Zugang zur Serverconsole?
Dann könntest du den Composer mal darüber ausführen.

Bei Domainfactory dann den Composer über php-Version-cli starten
Verzeichnis /composer

php5.6.22-cli composer.phar update

[contaouser1]

Danke! Das war die Lösung

[Spooky]

Oder in den System Einstellungen den detached mode mit der richtigen PHP executable einstellen.

[andrea$]

wie oder wo kann ich den aktuellen Speicherverbrauch einer Contao Installation ablesen oder anzeigen lassen?
Mir stehen vom Hoster 64MB max. zur Verfügung, die nicht erhöht werden können. Es sei denn, ich buche einen anderen Tarif.

Momentan habe ich 2 Cto. Installationen und eine Wordpress aktiv. In WP habe ich ein Plugin installiert, das mir u.a. die aktuelle Speicherauslastung anzeigt. Auslastung bei 62%!

Im RE habe ich mal gesucht aber nichts gefunden. Der Check zeigt mir das auch nicht an. Ich plane 2 Seiten mit WP zu erstellen. Da wird dann der Speicher nicht ausreichen, es sei denn meine 2 Cto Installationen saugen auch am Speicher?

[Spooky]

wie oder wo kann ich den aktuellen Speicherverbrauch einer Contao Installation ablesen oder anzeigen lassen?

Hier im Thread geht es um Composer. Composer verursacht diesen hohen Speicherverbrauch.

Mir stehen vom Hoster 64MB max. zur Verfügung, die nicht erhöht werden können. Es sei denn, ich buche einen anderen Tarif.

64MiB sind selbst für Contao alleine schon etwas wenig. Wenn du nur eine kleine Website ohne viel Inhalte oder große Ansprüche hast, reicht das.

Im RE habe ich mal gesucht aber nichts gefunden. Der Check zeigt mir das auch nicht an. Ich plane 2 Seiten mit WP zu erstellen. Da wird dann der Speicher nicht ausreichen, es sei denn meine 2 Cto Installationen saugen auch am Speicher?

Die Installationen sind völlig unabhängig. Das Speicher Limit gilt ja pro PHP Prozess.

[andrea$]

Hier im Thread geht es um Composer. Composer verursacht diesen hohen Speicherverbrauch.


64MiB sind selbst für Contao alleine schon etwas wenig. Wenn du nur eine kleine Website ohne viel Inhalte oder große Ansprüche hast, reicht das.
Die Installationen sind völlig unabhängig. Das Speicher Limit gilt ja pro PHP Prozess.

Danke für deine schnelle Antwort

Im Nachhinein bin ich jetzt auch schlauer. An solche Dinge wie wie memory_limit habe ich nicht gedacht. Die Contao Seite ist sehr klein und davon gibt es eine Kopie. Bei WP hatte ich allerdings schon mehrmals Fatal Error wegen Überschreitung und mußte den Wert auf 64MB setzen.

Also es gibt keine Extention für Cto. die mir das anzeigt?

[Spooky]

Also es gibt keine Extention für Cto. die mir das anzeigt?

Doch: System » Einstellungen » Globale Einstellungen » Debugmodus aktivieren

[andrea$]

cool!

5,9MB für meine aktive Cto. Website

Danke!

[Kahmoon]

Kleiner Tipp bei solchen Meldungen....die Domain kurz auf PHP7 umstellen, update machen, PHP auf 5.6 stellen funzt bei 1und1 bestens. Mit 5.6 laufe ich auch immer in den Speicherfehler wenn ich was am Composer mache.

[bibib]

Ich bin auch gerade wieder in den Fehler reingelaufen.
Eigentlich müsste vom Webspace her alles passen (ähnliche Installationen laufen auf dem gleichen Paket problemlos), aber ich hab möglicherweise Mist gebaut. Es geht um eine Demoinstallation, in der ich Erweiterungen teste. Da heute plötzlich dieser Fehler aufgetaucht ist, habe ich einige Erweiterungen händisch aus /system/modules gelöscht, diese scheinen nun nicht mehr im Composer auf und die Datenbank ist auch aktuell. Allerdings werden immer noch 50 Abhängigkeiten geprüft, eben auch welche von den gelöschten Erweiterungen.

Eckdaten:
Df/Managed Hosting Medium
Contao 3.5.17
Composer wird als eigenständiger Prozess ausgeführt (php5.6.12-cli -d memory_limit=1G -d max_execution_time=900)
Minimale Stabilität: stabil
composer.json:

{
    "name": "local/website",
    "description": "A local website project",
    "type": "project",
    "license": "proprietary",
    "require": {
        "contao-community-alliance/composer-client": "~0.12",
        "contao-legacy/backupdb": ">=3.2.1.9009,<3.3-dev",
        "dklemmt/contao_dk_mmenu": ">=1.5.1.0,<1.6-dev",
        "dma/dma_elementgenerator": "dev-master",
        "felixpfeiffer/subcolumns": ">=3.1.3.0,<3.2-dev",
        "jrgregory/m17-sticky-backend-footer": ">=2.0.4.0,<2.1-dev",
        "madeyourday/contao-rocksolid-antispam": ">=1.0.1.0,<1.1-dev",
        "terminal42/contao-ce-access": ">=2.0.2.0,<2.1-dev",
        "terminal42/contao-easy_themes": ">=2.1.2.0,<2.2-dev"
    },
    "prefer-stable": true,
    "minimum-stability": "stable",
    "config": {
        "preferred-install": "dist",
        "cache-dir": "cache",
        "component-dir": "../assets/components"
    },
    "repositories": [
        {
            "type": "composer",
            "url": "https://legacy-packages-via.contao-community-alliance.org/"
        },
        {
            "type": "artifact",
            "url": "packages"
        }
    ],
    "extra": {
        "contao": {
            "migrated": "done"
        }
    }
}

... also das packt der Webspace im Normalfall ...

Wie werd ich denn diese Abhängigkeiten los?

(Auf PHP7 hab ich auch umgestellt, hat nix geholfen ...)


---------------
Edit: sehe grade, der Thread ist nicht im Composer-Unterforum - sollte man den dorthin verschieben?

[Spooky]

Da heute plötzlich dieser Fehler aufgetaucht ist

Was für ein Fehler genau?

habe ich einige Erweiterungen händisch aus /system/modules gelöscht

Warum hast du das gemacht? Wenn du eine Extension deinstallieren willst, solltest du sie ganz normal deinstallieren - sprich über die Paketverwaltung entfernen (oder direkt in der composer.json) und dann ein Paketupdate machen.

[bibib]

Was für ein Fehler genau?

Sorry, dieser hier:
Fatal error: Out of memory (allocated 401604608) (tried to allocate 12 bytes) in phar:///.../composer/composer.phar/src/Composer/DependencyResolver/Solver.php on line 220

Warum hast du das gemacht? Wenn du eine Extension deinstallieren willst, solltest du sie ganz normal deinstallieren - sprich über die Paketverwaltung entfernen (oder direkt in der composer.json) und dann ein Paketupdate machen.

Weil ich sie eben nicht mehr über den Composer deinstallieren konnte weil dann die Out of Memory-Fehlermeldung gekommen ist -> da beißt sich die Katze wieder in den Schwanz. Installieren konnte ich alles, aber deinstallieren nicht mehr. Das versteh ich ja auch nicht, wie das immer passieren kann. Installation war irgendwann im Sommer, Deinstallationsversuch heute ... zwischendurch hab ich die Seite nicht angerührt.

[Spooky]

Sorry, dieser hier:
Fatal error: Out of memory (allocated 401604608) (tried to allocate 12 bytes) in phar:///.../composer/composer.phar/src/Composer/DependencyResolver/Solver.php on line 220

Und composer läuft tatsächlich im detached mode mit

php5.6.12-cli -d memory_limit=1G -d max_execution_time=900

?

[bibib]

Ja, siehe Screenshot:

detached_mode.JPG

[Spooky]

Dann hast du bei deinem Hoster leider auch über das CLI nicht genügend Speicher. Das Speicher Limit sieht jedoch dynamisch aus, evt. hast du zu anderen Zeiten mehr zur Verfügung.

[bibib]

Dann hast du bei deinem Hoster leider auch über das CLI nicht genügend Speicher. Das Speicher Limit sieht jedoch dynamisch aus, evt. hast du zu anderen Zeiten mehr zur Verfügung.

Danke für deine geduldigen Infos, aber nur zu meinem Verständnis noch: Das würde auch erklären, warum die Installation ohne Speicherfehlermeldung möglich war? Weil ich einfach den richtigen Zeitpunkt erwischt habe?
Und jetzt am besten um drei in der Nacht mal probieren oder ansonsten alles in die Tonne kippen und Seite einfach neu machen?

[Spooky]

Seit du installiert hast haben sich ja evt. auch deine Abhängigkeiten geändert.

[MacKP]

Machs bei df.eu einfach über SSH. Damit läuft das alles wie am Schnürchen. Zumindest ziehe ich mir immer die Installationen von anderen Hostern auf meinen Account bei df um dort dann per Konsole alles zu updaten etc. ;-)

Viele Grüße

[Spooky]

Theoretisch sollte dann aber auch direkt über SSH der Speicher nicht reichen.

[bibib]

Machs bei df.eu einfach über SSH. Damit läuft das alles wie am Schnürchen. Zumindest ziehe ich mir immer die Installationen von anderen Hostern auf meinen Account bei df um dort dann per Konsole alles zu updaten etc. ;-)

Okay, das probier ich. Bin allerdings noch nicht so ganz trittsicher bei SSH. Bis jetzt kann ich nur Installationen ver- und entpacken.
Ich wechsle also ins Root-Verzeichnis der Contao-Installation und dann gebe ich das hier ein?

php5.6.22-cli composer.phar update

[Spooky]

Nein, nicht ins Root Verzeichnis, sondern ins das /composer Verzeichnis deiner Contao Installation. Dort führst du dann das Kommando aus, ja. Versuche es aber vorher nochmal im detached mode im Backend mit folgender Einstellung:

php5.6.12-cli

, also ohne

 -d memory_limit=1G -d max_execution_time=900

[bibib]

Detached Mode nur mit php5.6.12-cli hat die gleiche Fehlermeldung ergeben, aber über SSH hat es funktioniert!
Yeah DANKE euch!!

[MacKP]

Theoretisch sollte dann aber auch direkt über SSH der Speicher nicht reichen.

Praktisch ist das direkt über die Konsole eben doch möglich mit mehr Speicher ;-)

Viele Grüße

[Spooky]

Frage mich nur warum, also wo der technische Unterschied besteht.

[tblumrich]

Hallo.

Entschuldigt das ich den Thread raushole, aber ich komme leider (mal wieder) auch nicht weiter, ähnlich bibib.
Ich hab hier eine Kundeninstallation, die bisher (lag jetzt ca. 2 Monate ohne was dran zu machen) mit 128MB keine Probleme machte. Gestern nun geht keine Paketaktualisierung mehr. Hatte dann den Kunden gebeten, das Memory_limit auf 512 MB hochzusetzen, leider bleibts dabei:

Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 32 bytes) in phar:///opt/users/www/***/html/httpdocs/neu2016/composer/composer.phar/src/Composer/DependencyResolver/RuleSetGenerator.php on line 261

Auf Alpha setzen bringt auch nichts etc...
Das mit den Detached Mode hab ich auch schon probiert... da meldet mir der Composer direkt:

$ /usr/bin/env php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction
/usr/bin/env: php: No such file or directory

Wie geht das eigentlich, das plötzlich selbst mit hochgesetztem Speicher Fehler kommen, obwohl ich mit viel niedrigeren Voraussetzungen vor 1 Monat keine Probleme hatte, ohne das irgendwas geändert wurde?

Achso, hier noch die composer.json, falls wichtig:

{
    "name": "local/website",
    "description": "A local website project",
    "type": "project",
    "license": "proprietary",
    "require": {
        "contao-community-alliance/composer-client": "~0.12",
        "contao-legacy/ajaxform": ">=1.0.3.9005,<1.1-dev",
        "contao-legacy/font-awesome-inserttag": ">=1.0.0.9003,<1.1-dev",
        "contao-legacy/m17pagefolders": ">=1.3.0.9010,<1.4-dev",
        "delahaye/dlh_googlemaps": ">=2.2.0.0,<2.3-dev",
        "dklemmt/contao_dk_caroufredsel": ">=1.3.2.0,<1.4-dev",
        "dklemmt/contao_dk_masonry": ">=1.2.1.0,<1.3-dev",
        "jrgregory/m17-sticky-backend-footer": ">=2.0.6.0,<2.1-dev",
        "madeyourday/contao-rocksolid-columns": ">=1.0.7.0,<1.1-dev",
        "madeyourday/contao-rocksolid-slider": ">=1.5.8.0,<1.6-dev",
        "terminal42/contao-mailusername": ">=1.0.5.0,<1.1-dev"
    },
    "prefer-stable": true,
    "minimum-stability": "alpha",
    "config": {
        "preferred-install": "dist",
        "cache-dir": "cache",
        "component-dir": "../assets/components"
    },
    "repositories": [
        {
            "type": "composer",
            "url": "https://legacy-packages-via.contao-community-alliance.org/"
        },
        {
            "type": "composer",
            "url": "https?://legacy-packages-via.contao-community-alliance.org",
            "allow_ssl_downgrade": false
        },
        {
            "type": "artifact",
            "url": "packages"
        }
    ],
    "extra": {
        "contao": {
            "migrated": "done"
        }
    }
}

Da Kundeninstallation... hab ich keine Möglichkeit auf SSH... was kann ich tun? Außer alles manuell zu installieren...

Danke und beste Grüße
Thomas

[Spooky]

Auf Alpha setzen bringt auch nichts etc...

Wenn dann solltest du "stable" verwenden.

Das mit den Detached Mode hab ich auch schon probiert... da meldet mir der Composer direkt:

$ /usr/bin/env php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction
/usr/bin/env: php: No such file or directory

Der PHP Pfad ist falsch, den musst du anpassen (falls du auf dem Server überhaupt eine passende PHP cli executable zur Verfügung hast). Siehe dazu die Informationen zum detached mode.

Wie geht das eigentlich, das plötzlich selbst mit hochgesetztem Speicher Fehler kommen, obwohl ich mit viel niedrigeren Voraussetzungen vor 1 Monat keine Probleme hatte, ohne das irgendwas geändert wurde?

Vor 1 Monat war ja auch alles anders . Die Welt dreht sich weiter, neue Versionen von hunderten oder tausenden Paketen kommen hinzu, dadurch steigt auch die Komplexität der Abhängigkeitsauflösung und damit auch der Speicherverbrauch.

[tblumrich]

Vielen Dank spooky für die schnelle Rückmeldung.

Das heißt dann leider in übersetzt für mich in diesem Fall: Frickellösung.
Denn selbst wenn ich den korrekten Pfad irgendwie erfahre, befürchte ich wird das nichts nützen (siehe bibib).

Beim letzten Satz stimme ich dir grundsätzlich zu, aber wenn des so weitergeht, das innerhalb von 1 Monat der 4fache Speicher nicht ausreicht... wo soll das hinführen? Ich hab mich ja schon damit abgefunden, dass man mittlerweile für Contao mit Composer auch halber Systemadmin sein muss... aber irgendwann... wird das echt zu viel des Guten und eine gute Usability für den NonDev bzw. NonSysAdmin kann Contao nicht mehr bescheinigt werden. Leider.

Jut. Nochmals Dankeschön!

[Spooky]

Das heißt dann leider in übersetzt für mich in diesem Fall: Frickellösung.

Warum?

Denn selbst wenn ich den korrekten Pfad irgendwie erfahre, befürchte ich wird das nichts nützen (siehe bibib).

Warum? Bei welchem Hoster bist du?

wo soll das hinführen?

In die Bredouille .

Momentan befindet sich die Composer Cloud in der Testphase. Damit gehören dann Speicherprobleme der Vergangenheit an (mehr oder weniger...). Darüberhinaus wird sich beim composer selbst vielleicht auch etwas ändern, sodass bei der Abhängigkeitsauflösung nicht mehr so viel Speicher verbraucht wird.

[tblumrich]

Warum?
Warum? Bei welchem Hoster bist du?

Ich fasse das mal zusammen. Kundenserver... und ich hab da nur einen mehr oder weniger erfahrenen Ansprechpartner (der mir zumindest 512MB zur Verfügung gestellt hat), der mir das eben bisher alles so zur Verfügung stellen konnte, wie ich es (bisher) für Contao benötige. Hat ja auch alles hingehauen.
Und ich bin eben auch nur Frontendler... wenn ich da auch noch mit meinem Halbwissen von PHP Pfaden, PHP cli executable etc. anfange, gucken wir uns beide blöde an. Ich weiß, das scheinen keine guten Voraussetzungen mehr zu sein für ein Projekt.
Deswegen und wegen fehlendem SSH: Frickellösung... und weil ich dann eben wahrscheinlich manuell installiere... ist ja nicht sooo schlimm, wenn die Abhängigkeiten nicht wären bei manchen Extensions...

In die Bredouille .

Momentan befindet sich die Composer Cloud in der Testphase. Damit gehören dann Speicherprobleme der Vergangenheit an (mehr oder weniger...). Darüberhinaus wird sich beim composer selbst vielleicht auch etwas ändern, sodass bei der Abhängigkeitsauflösung nicht mehr so viel Speicher verbraucht wird.

Hehe, das baut ja direkt wieder etwas auf!
Ich könnte mir vorstellen, das das noch mehr Leute interessiert. Les ich an den falschen Stellen oder wo läuft da die Informationspolitik für sowas?

[Spooky]

Deswegen und wegen fehlendem SSH: Frickellösung...

Wenn der detached mode funktioniert, ist es keine Frickellösung.

Und bzgl. dem richtigen PHP Pfad: entferne einfach mal /usr/bin/env.

[tblumrich]

Leider brauche ich wohl doch den richtigen Pfad:

$ php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction
sh: 1: php: not found

Ganz blöde Frage... Frage ich den Serverkumpel einfach ob er mir den richtigen Pfad für PHP auf dem Server nennen kann? Sehe ich das auf dem FTP irgendwie, dessen Zugang ich habe... ich komme dort eine Ebene tiefer wie das httpdocs Verzeichnis ( da gibts sowas wie etc, bin usw...)? Oder aus der phpinfo?

[Spooky]

Im einfachsten Fall einfach den Server Admin fragen. Über die phpinfo() kann man das unter Umständen auch ableiten.