Composer möchte 1 GB RAM haben...

[phyton2706]

Hallo zusammen,

ich nutze in einem neuen Projekt den Composer. Soweit so gut...

Allerdings kann ich sein einiger Zeit die installierten Erweiterungen nicht mehr updaten. Ich bekomme folgende Fehlermeldung:

Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 32 bytes) in
phar:///var/www/clients/client6/web9/web/neu/composer/composer.phar/src/Composer/DependencyResolver/Decisions.php on line 76

Wenn ich die Meldung richtig verstehe, dann möchte das Script gerne 1 GB Speicher nutzen...

Das kann doch nicht sein, oder? Welcher Provider stellt den Nutzern denn 1 GB RAM zur Verfügung?
Läuft hier evtl etwas schief?

[tab]

Ich habe bei 1&1 garantierte 2GB, wenn man der Werbung glauben möchte.

[tab]

Wenn es geht, eventuell mal die minimale Stabilität hochsetzen bei den Composer-Einstellungen. Du hast wahrscheinlich viele Erweiterungen mit vielen Versionen und dann auch noch Entwicklerversionen erlaubt. Da kann schon mal ne Menge RAM erforderlich werden.

[Spooky]

composer braucht viel RAM - meiner Meinung kann man komplexe Operationen nur auf einem Root Server oder Lokal machen, wo man ungehindert die Serverparameter verändern kann.

[Samuell]

Aber nur der Werbung nach. Wenn ich das letztens richtig gehört habe, ist das die Gesamtmenge, was aber nicht heißt, dass Du Sie auch komplett für einen Prozess bekommst.
Dort soll es nämlich deutlich, deutlich weniger sein.

[tab]

Muss ich es doch mal testen

[lucina]

See https://github.com/contao-community-...ugin/issues/48

(Du bist nicht allein)

[tab]

Uiuiui. Krass. 134MB gingen noch, 135MB hat er nicht geschafft.

Hatte ich allerdings anfangs schon mal getestet, da gingen 512MB noch. Naja, ich suche schon mal die Kündigungsfrist raus, 134MB sind mir definitiv für den Preis zu wenig. Langsamer ist es zudem auch geworden im Lauf der Zeit.

[lucina]

Ich habe bei 1&1 garantierte 2GB, wenn man der Werbung glauben möchte.

Macht maximal 10% davon je Script.

Quelle: https://twitter.com/1und1hilfe/statu...src=email&s=11

[tab]

Na super, das erfreut doch das Herz.

[lucina]

Wobei dir das in diesem Fall vermutlich auch nichts nützen würde - in dem erwähnten Ticket falle ich zur Zeit mit 1GB RAM ebenfalls und nachhaltig auf die Nase. Im Stagingsystem, auf dem Liveserver sowie auf einem testweise aufgesetzten Reservesystem.

Ist jetzt eigentlich nicht mein Stil, das auch lokal auf meinem Server hier mit 32 GB Ram testen zu wollen ... ;-)

[tab]

Hmmmmm, da steht wohl noch einiges an Arbeit an, sei es beim Composer-Projekt oder auch mit dem Plugin/Client. 1 GB und kein Ende in Sicht. Das kann ich keinem Kunden vermitteln, noch nicht mal mir selbst.

[phyton2706]

Hallo lucina,

vielen Dank. ich habe jetzt die Einstellung auf "Stabil" geändert. Jetzt bekomme ich zumindest die Fehlermeldung nicht mehr.
Allerdings bekomme ich jetzt folgende Meldung, wenn ich den "Test" laufen lasse:

Loading composer repositories with package informationUpdating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - netzmacht/contao-theme-plus 4.4.5 requires ikimea/browser dev-master -> satisfiable by ikimea/browser[dev-master].
    - netzmacht/contao-theme-plus 4.4.5 requires ikimea/browser dev-master -> satisfiable by ikimea/browser[dev-master].
    - Removal request for ikimea/browser == 9999999-dev
    - Installation request for netzmacht/contao-theme-plus >=4.4.5.0,<4.5-dev -> satisfiable by netzmacht/contao-theme-plus[4.4.5].

[lucina]

Ja, das ist so wenn Du Stable wünschst. Du könntest 'ikimea/browser' in Version [dev-master] ebenfalls hinzufügen, dann wäre das ja trotz Stable da.


Sent from my iPhone using Tapatalk

[phyton2706]

Mir war nicht klar, dass ich trotzdem "höhere" Versionen installieren kann...
Danke erst mal!

Ich werde Dei Ticket bei GitHub mal im Auge behalten...

[Toflar]

Das Problem liegt eindeutig nicht am Plugin. Es liegt an Composer selbst. Wir glauben, dass durch das Release von Symfony 3 die möglichen Kombinationen plötzlich exponential gestiegen sind und deswegen massiv mehr RAM benötigt wird, um die möglichen Kombinationen zu berechnen. Das kann man auch an einem Projekt feststellen, das absolut nichts mit Contao zu tun hat. Update ich hier bei mir eine reine Symfony-Applikation, komme ich locker über 500MB RAM-Verbrauch.
Ich bin überzeugt, dass die PHP-Community auch noch darauf stossen wird (wenn das nicht schon geschehen ist) und dass da gemeinsam nach Lösungen gesucht werden wird.

[Georgi]

Ich bin davon auch betroffen:

alfahosting Multi XXL:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 76 bytes) in phar:///var/www/web428/html/live/composer/composer.phar/src/Composer/Json/JsonFile.php on line 259 

1und1:

Fatal error: Out of memory (allocated 84934656) (tried to allocate 49 bytes) in phar:///homepages/28/d37771296/htdocs/live/composer/composer.phar/src/Composer/Json/JsonFile.php on line 259 

Ich habe beide vor ca. 1 Jahr auf höhere Leistung gehoben, wenn ich jetzt auf die Inhaber wieder zukomme, dass es wieder teuer wird, dann habe ich ein Problem.

Schade, als er lief, war das sehr einfach, aber mit jedem Update, wird er unbrauchbar (nicht ausgereift?).

Ich werde auf die alte Erweiterungsverwaltung zurückgehen müssen, da der Composer nicht brauchbar ist. Gibt es da ein How-to-do, wie man wieder zurück geht?

Gruß Georgi

[doowopy]

Moin Georgi,

- In den Systemeinstellungen die Erweiterung !composer deaktivieren
- In den Systemeinstellungen die Erweiterung repository aktivieren
- Via Install-Tool die Datenbank aktualisieren
- Alle Erweiterungen über die Erweiterungsverwaltung neu installieren
- Via FTP das Verzeichnis TL_ROOT/composer löschen
- Via FTP das Verzeichnis TL_ROOT/system/modules/!composer löschen

Dort gefunden: https://community.contao.org/de/show...l=1#post347266

[lucina]

Ich weiss nicht, ob ich das machen würde. Es scheint ja mit dem letzten Symphony-Release zusammenzuhängen, nach dem Abhängigkeiten sehr umfangreich neu aufgelöst werden müssen.

Für mich, bis das gelöst wird (und sei Dir sicher, es wird gelöst) finde ich es zielführender, eine lokale Installation für Updates zu benutzen. Es *könnte* helfen, die dabei erstellte composer.lock dann dem Livesystem zu verfüttern (da ist es dann nämlich aufgelöst).

[Spooky]

Für mich, bis das gelöst wird (und sei Dir sicher, es wird gelöst)

Das Ticket auf GitHub wurde allerdings schon geschlossen, ohne viel darauf einzugehen.

[lucina]

Geschlossen schaut allerdings anders aus: https://github.com/contao-community-...ugin/issues/48

[Spooky]

Geschlossen schaut allerdings anders aus: https://github.com/contao-community-...ugin/issues/48

Das Problem ist ja kein Problem des composer-plugin, sondern von composer selbst. Das Ticket dazu wurde geschlossen: https://github.com/composer/composer/issues/4928

[lucina]

Es gibt dazu bei Composer selbst eine ganze Reihe von Tickets, und die bieten entweder Lösungsansätze oder sind nicht geschlossen.

Das ist doch klar dass man so nicht weitermachen kann ohne es grundständig anzugehen.

[doowopy]

hallo lucina,

... eine lokale Installation für Updates zu benutzen. Es *könnte* helfen, die dabei erstellte composer.lock dann dem Livesystem zu verfüttern (da ist es dann nämlich aufgelöst).

wenn ich das richtig verstehe, kann ich in meiner lokalen Installation Erweiterungen mit dem Composer installieren und die dann auf den Webspace kopieren? Dazu muss ich den Composerclient aber schon auf dem Webspace installiert haben, oder? Welche Dateien/Ordner müssen dazu kopiert werden und was ist mit der Datenbank? Viele doofe Fragen...

VG Olaf

[Spooky]

hallo lucina,



wenn ich das richtig verstehe, kann ich in meiner lokalen Installation Erweiterungen mit dem Composer installieren und die dann auf den Webspace kopieren? Dazu muss ich den Composerclient aber schon auf dem Webspace installiert haben, oder? Welche Dateien/Ordner müssen dazu kopiert werden und was ist mit der Datenbank? Viele doofe Fragen...

VG Olaf

Hier ginge es darum, die komplette Website (oder wenn man weiß, was man tut, nur bestimmte Bereiche, aber das führt jetzt zu weit) auf deinen lokalen Rechner zu spiegeln, dort über die Konsole "composer update" durchführen zu lassen, dann das composer.lock file zurück auf den Server kopieren und am Server über die Konsole dann "composer install" durchführen. Vielleicht wird ja auch noch eine Funktion in den composer-client eingebaut, womit man statt "Pakete aktualisieren" auch "Pakete installieren" sagen kann - wo dann eben "composer install" statt update durchgeführt wird, sodass man nicht selbst Zugriff zur Konsole braucht.

Du könntest aber statt dessen auch danach einfach die gesamte Website wieder auf den Server kopieren.

[lucina]

Das Problem ist ja nicht der Download oder die Installation von Erweiterungen, sondern die initiale Auflösung von Abhängigkeiten.

Der Dreh wäre, lokal und mit viel Speicher die Abhängigkeiten einmal auflösen zu lassen und das der Installation auf dem Server mitzuteilen. Ich würde versuchen, dazu die lokale composer.lock auf den Server zu laden.

Der Contao-Composer sollte dann wissen was er herunterzuladen hat, siehe dazu das Vorposting von Spooky.

Ich kann nicht dafür garantieren dass das in jedem Szenario funktioniert, aber es ist ein brauchbarer Ansatz.

[lucina]

Hier ginge es darum, die komplette Website (oder wenn man weiß, was man tut, nur bestimmte Bereiche, aber das führt jetzt zu weit) auf deinen lokalen Rechner zu spiegeln

Im Grunde täte es wohl reichen, eine lokale [edit]Contao-[/edit]Installation mit Composer (und sonst nichts) zu haben, dort (entweder direkt in der composer.json oder via Paketverwaltung -> Experteneinstellungen) das System mit den Anforderungen des Liveservers bekannt zu machen und es dann durchlaufen zu lassen. Das interessante Ergebnis sollte dann eine brauchbare composer.lock sein, die dann auf den Liverserver gehört.

[Spooky]

Das könnte man ja sogar als Service anbieten. Wenn man im composer-client "Pakete aktualisieren" klickt wird (unter welchen Bedingungen auch immer) vielleicht die composer.json einfach an einen contao-community-alliance Server geschickt (welcher genug Power und RAM hat), wo dort dann das "composer update" durchgeführt und danach das composer.lock file zurück übertragen wird, sodass danach wiederum nur "composer install" ausgeführt werden muss. Eine verrückte, nette Idee

[lucina]

Du wirst lachen, das hatten wir schonmal angedacht. Der Server der Alliance wird das aber vermutlich nicht wegstecken, jedenfalls fand Xtra das irgendwie beängstigend ... ;-)

[Spooky]

Im Grunde täte es wohl reichen, eine lokale Installation mit Composer (und sonst nichts) zu haben

Ich bin mir nicht sicher ob das funktioniert, denn in dem Fall könnte es sein, dass die contao/core dependencies auch hinzugefügt werden, weil das composer-plugin keine Contao Installation finden kann.

Du wirst lachen, das hatten wir schonmal angedacht. Der Server der Alliance wird das aber vermutlich nicht wegstecken, jedenfalls fand Xtra das irgendwie beängstigend ... ;-)

Hehe ok

[Toflar]

Es gibt mehrere Probleme mit dem Cloud-Ansatz. Erstens würde er eine unheimliche Last tragen müssen, das ist ja klar :-)
Dann aber gibt es Tasks, die lokal ausgeführt werden müssen. Z.B. die ganzen post-update Scripts, die dann Symlinks anlegen oder bei Symfony z.B. direkt nach DB-Zugangsdaten fragen etc. Komplett ohne Composer wird also sowieso nicht gehen.

Was aber gehen könnte, nur müsste das natürlich Composer selbst unterstützen, wäre wenn das Resolving in die Cloud verschoben wird. Das Auflösen der Abhängigkeiten ist ja das Problem. Bei einer normalen Symfony-Installation - und da handelt es sich um wirklich nichts sonderlich Komplexes bei mir - analysiert er bereits über 700 000 (!) Regeln um feststellen zu können, ob die gewünschten Pakete kompatibel zueinander sind und welche davon die neusten sind.
Nur mal so um einen Eindruck davon zu geben, weshalb es besser ist, auf einen existierenden Abhängigkeitsmanager zu setzen, als selber einen zu erfinden ;-)

Die Abhängigkeiten sind aber wiederum auch von der Plattform abhängig (z.B. PHP-Version oder PHP-Extensions).

Kurzfassung: Das "composer update" müsste in der Cloud stattfinden und eine "composer.lock" als Antwort liefern (da drin steht quasi was installiert werden soll). Lokal müsste dann ein "composer install" ausgeführt werden (der prüft keine Abhängigkeiten mehr, sondern installiert nur noch was in der "composer.lock" steht). So benötigt er entsprechend viel weniger RAM und die lokalen Skripte und Composer Plugins werden trotzdem alle ausgeführt und berücksichtigt.

[mlweb]

Ich bin überzeugt, dass die PHP-Community auch noch darauf stossen wird (wenn das nicht schon geschehen ist) und dass da gemeinsam nach Lösungen gesucht werden wird.

Ich denke da muß definitiv etwas passieren. Ich bin ein absoluter Freund von Composer, aber es gibt auch gewisse Grenzen.

composer braucht viel RAM - meiner Meinung kann man komplexe Operationen nur auf einem Root Server oder Lokal machen, wo man ungehindert die Serverparameter verändern kann.

Wenn die Gefahr besteht, dass der Composer auf einem gut ausgebauten Webhostingpaket nicht läuft, dann finde ich das problematisch. Wo fängt die Komplexität an? Bei Isotope, bei Metamodels oder schon dann wenn ein Kunde viele verschiedene kleine Erweiterungen einsetzt?
Inzwischen sind auch manch kleine Erweiterungen im ER2 nicht mehr in der aktuellen Version verfügbar und ich bin mehr und mehr dazu übergegangen standardmäßig den Composer zu verwenden. Bisher auch weitestgehend ohne Probleme bzw. zumindestens ohne Probleme mit dem RAM.
Wenn der Composer die Zukunft bei Contao sein soll, dann muss er prinzipiell auch auf einem Webhostingpaket laufen - sicher nicht auf jedem Billigangebot und vielleicht auch nicht in jeder beliebigen Kombination von großen mächtigen Erweiterungen.

Die hier beschriebene Alternative mit dem Umweg über den eigenen leistungsfähigen Server bzw. lokalen Server ist sicher eine Interimslösung, aber auf Dauer ... Ganz klares NEIN

[tab]

Nennt mich altmodisch (da habt ihr sogar Recht), aber irgendwie scheint mir da bei Composer lieber der (relativ!) einfache Weg beschritten zu werden, anstatt sich mit der Realität auseinander zu setzen und nach realistischen Lösungen zu suchen.

Klar, die denkbaren Kombinationen von Versionen von Paketen explodieren kombinatorisch sehr schnell, wenn man die Anzahl der Pakete und die durchschnittliche Anzahl der betrachteten Versionen erhöht. Insofern würde es sicher schon mal helfen, wenn bei Erweiterungen mehr stabile Versionen angestrebt werden, so dass man seinen Composer-Client auf stabile Versionen einstellen kann und nicht auf Entwicklerversionen gehen muss, von denen es naturgemäß eine Unmenge gibt.

Aber eben weil die Kombinationen sehr schnell explodieren, kann es eben nicht der richtige Weg sein, die alle gleichzeitig im Memory halten zu wollen. Das ist in der Regel der programmiertechnisch einfachste Weg und oft auch die Lösung, die am schnellsten läuft - solang der Server nicht explodiert bzw genug RAM hat. Da solche Server aber eher dünn gesät sind, müssen andere Lösungen gefunden werden, mit denen auch ein handelsüblicher Shared Hosting Webspace klarkommen kann. Ansonsten muss man halt auf Contao einen Aufkleber draufpappen mit der Aufschrift "Vorsicht, läuft nur auf high end Rootservern mit RAM > 64GB". Und das nur deshalb, weil man ihn für die Paketverwaltung braucht, während die eigentliche Website später auch im Shared Hosting Webspace laufen würde.

Wie so eine andere Lösung aussieht bzw aussehen kann, da gibt es sicher verschiedene Ansätze. Die billigste wäre wahrscheinlich, die ganze Kompatibilitätsproblematik wieder auf dem User abzuladen und ihn manuell installieren zu lassen was immer er will, er wird dann schon sehen was funktioniert und was nicht. Oder er löst die Abhängigkeiten im Kopf oder auf Papier selbst auf. Durchaus möglich, obwohl weder im Kopf noch auf dem Papier so ohne weiteres 1 GB RAM verfügbar ist. Das geht ja jetzt schon, manuelle Installation ist ja zum Glück noch möglich. Unglaublich, wie man das als User hinbekommen kann, ohne 800.000 Kombinationen von Versionen im Kopf zu behalten und zu bewerten oder aufs Papier zu schreiben.

Wie geht das eigentlich? Intelligente Algorithmen nehme ich mal an . Jetzt müsste man die nur noch programmtechnisch realisieren. Da könnte man sich Anregungen z.B. aus dem Bereich der Schachprogramme holen. Da sind 800.000 Kombinationen (von Zügen) heutzutage eine eher lächerliche Menge, die einen durchschnittlichen PC zum Gähnen bringt. Anfangs wurden da auch "brute force" Algorithmen benutzt. Mittlerweile benutzt man Dinge wie Hash-Tabellen, MiniMax Strategien und anderes mehr. Und die Erfolge sind beeindruckend.

Das wird man hier nicht 1 zu 1 übertragen können, aber man muss doch z.B Überlegungen anstellen können, wie Softwareentwicklung mit Versionierung in der Regel "funktioniert". Es wird kaum vorkommen, dass Version 1 von Paket A die Version > 3 von Paket B benötigt, während die Version 2 von Paket A jetzt plötzlich nur Version > 0 von Paket B voraussetzt. Theoretisch denkbar, praktisch eher selten. Könnte man benutzen, um einen großen Teil der theoretisch denkbaren Kombinationen erst gar nicht in Betracht ziehen zu müssen. Zumindest als Option, weil es ja theoretisch auch mal nicht die optimale Kombination von Versionen liefern könnte oder eine mögliche Lösung gar nicht finden könnte.

Aber vielleicht wird das ja alles und viel mehr bereits gemacht und genutzt, dann entschuldigt bitte dieses Pamphlet . Zumindest geht es mir jetzt danach etwas besser Würde mich allerdings schon mal interessieren, wie Composer prinzipiell funktioniert bzw wie die Algorithmen zur Suche nach der optimalen Kombination von Versionen aussehen. Gibt es dazu irgendwas an Informationen, ohne sich durch den kompletten Code kämpfen zu müssen? Oder wenigstens einen Tipp, welcher Teil des Codes da relevant ist?

[Georgi]

@lucina

Ich weiss nicht, ob ich das machen würde.

Sollte ich also noch warten mit der Rücksetzung auf die Erweiterungsverwaltung? Ich bin dann im Backend erstmal handlungsunfähig. Hoffentlich wirkt sich das im Frontend nicht aus.

Composer braucht nach meiner Meldung 135 MB, ich habe aber nur 120 bzw. 128 MB zur Verfügung.

Ich hatte dem Composer immer wieder eine Chance gegeben. Aber ich kann doch nicht ständig mit der Problematik auf die Inhaber der Homepage zukommen, es muss wieder etwas zugekauft werden.

Gruß Georgi

[tab]

Wenn der Composer die Zukunft bei Contao sein soll, dann muss er prinzipiell auch auf einem Webhostingpaket laufen - sicher nicht auf jedem Billigangebot und vielleicht auch nicht in jeder beliebigen Kombination von großen mächtigen Erweiterungen.

Ich würde es mal so ausdrücken: Es sollte nicht sein, dass der Paketmanager die Anforderungen ans Hosting definiert und dabei weit höhere Anforderungen herauskommen, als die Website selbst im Betrieb eigentlich erfordert. Das wäre ziemlich unglücklich und den Kunden gegenüber sehr schwer vermittelbar.

[tab]

Composer braucht nach meiner Meldung 135 MB, ich habe aber nur 120 bzw. 128 MB zur Verfügung.

Das Dumme ist, dass man das so gar nicht sagen kann. Du siehst nur, dass dein gegenwärtig verfügbares RAM nicht reicht. Wieviel dir fehlt weisst du nicht, kann ein KB oder genauso gut ein GB sein. Vielleicht hätte er danach ja noch 1 GB allokieren wollen, wenn er die 76 Bytes bekommen hätte.

[do_while]

Da muss natürlich auch mal die Frage erlaubt sein, ob wir mit dem Composer überhaupt auf dem richtigen Weg sind?
Suche ich mir ein Hosting, auf dem der Composer gut läuft oder suche ich ein Hosting für Contao?

[mlweb]

Da muss natürlich auch mal die Frage erlaubt sein, ob wir mit dem Composer überhaupt auf dem richtigen Weg sind?

Soweit möchte ich im Moment gar nicht gehen. Die Webhostingpakete werden bezüglich RAM ja auch immer besser.
Wenn ich es richtig verstanden habe, ist es ja im Moment ein Problem, was erst mit dem neuesten Release von Symfony aufgetaucht ist.
Für mich - und ich bin kein PHP-Programmierer - stellt sich eher die Frage brauchen wir das gesamte Framework innerhalb von Contao oder könnten wir auf einen bestimmten Teil der neuen Abhängigkeiten verzichten ohne Einbußen in der Funktionalität zu haben?

Kurzfassung: Das "composer update" müsste in der Cloud stattfinden und eine "composer.lock" als Antwort liefern (da drin steht quasi was installiert werden soll). Lokal müsste dann ein "composer install" ausgeführt werden (der prüft keine Abhängigkeiten mehr, sondern installiert nur noch was in der "composer.lock" steht). So benötigt er entsprechend viel weniger RAM und die lokalen Skripte und Composer Plugins werden trotzdem alle ausgeführt und berücksichtigt.

Das wäre ja etwas fast in der Richtung.

[mlweb]

Noch ein kleiner Nachtrag vielleicht.
Wir sind nicht das einzige CMS, welches mit Composer arbeitet.
Auch TYPO3 arbeitet damit und hat mehr oder weniger Probleme mit dem RAM insbesondere bei 1&1, wie ich gerade gelesen habe.
Insofern denke ich, dass der Composer der richtige Weg ist, weil sich viele Leute um eine Problemlösung bemühen.

[tab]

Ja, das klingt nicht schlecht. Das würde die Anforderungen auf den "Cloud Server" verlagern. Allerdings bleibt das erwähnte Problem, dass diese(r) Server eben eine gigantische Last zu tragen hätte(n).