Installation über Contao Manager "ManagedHosting Medium"

[albis]

haben auf einem "ManagedHosting Medium" mit Einstellungen wie hier, Contao über den Contao Manager problemos installiert.

Bei "Pakete aktualisieren" bzw. bei "Pakete installieren" kommt der Fehler

Loading composer repositories with package information
Updating dependencies

mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory

Process terminated with exit code 255
Reason: Unknown error

so wie auch hier

[albis]

wir haben das Update nun über SSH vorgenommen:

erst im Webseitenroot über

wget https://getcomposer.org/download/1.4.2/composer.phar

die "composer.phar" geladen und dann über

/usr/local/bin/php7.0.13-cli composer.phar update

die Aktualisierungen vorgenommen. Die composer.json (auch im Webroot) muss natürlich die gewünschten Änderungen (Pakete) enthalten. Der zuvor über den Conato Manager initiierte und abgebrochene Installationsvorgang hatte den Eintrag hier schon vorgenommen.

[Babelfisch]

Hab auf einem ManagedServer von DomainFactory gerade das gleiche Problem. Die Installation von Contao über den Manager ging problemlos aber sowie ich eine Erweiterung installieren will, kommt der Fehler.

Using version ^2.0 for madeyourday/contao-rocksolid-custom-elements
/kunden/…/webseiten/…/contao/composer.json has been updated
Loading composer repositories with package information
Updating dependencies

mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory

Process terminated with exit code 255
Reason: Unknown error

Auf dem Server läuft PHP 7.1.6 und ich habe PHP mal testweise 256 MB RAM gegeben. Das sollte doch eigentlich ausreichen.

Interessanterweise werden die Erweiterungen aber anstandslos installiert, wenn ich Pakete aktualisieren aufrufe.

[Samson1964]

Bei PHP 7 soll der CM ja tatsächlich nicht mehr soviel RAM verbraten. Aber 256 MB ist trotzdem definitiv viel zu wenig.

Gesendet von meinem L52 mit Tapatalk

[Babelfisch]

Bei PHP 7 soll der CM ja tatsächlich nicht mehr soviel RAM verbraten. Aber 256 MB ist trotzdem definitiv viel zu wenig.

Puhh, da gibt es aber noch einiges an Arbeit bei der Entwicklung vom CM. Contao 3.5 betreibe ich mit vielen (auch eigenen und ziemlich umfangreichen) Erweiterungen problemlos mit 128 MB RAM und mehr RAM würde ich ohne absolute Not auch keiner Seite „gönnen“. Auch wenn es sicherlich schwer ist, sollte der Speicherbedarf da schon noch deutlich gesenkt werden, damit der CM auch ohne große Verrenkungen läuft.

[mlweb]

Das hat nichts mit dem Manager zu tun. Der RAM wird beim Auflösen der Abhängigkeiten über Composer benötigt.

Nachtrag: Nutzt Du bei Contao 3.5 den Composer?. Wenn ja müsste Dir das Thema da auch schon mal aufgefallen sein.

[Babelfisch]

Das hat nichts mit dem Manager zu tun. Der RAM wird beim Auflösen der Abhängigkeiten über Composer benötigt.

Da der CM ja zu einem großen Teil eine Oberfläche für den Composer ist, hat es schon damit zu tun. Dass der Speicherbedarf durch den Composer kommt, ist mir auch klar aber du wirst mir sicherlich Recht geben, dass es für die Zukunft kaum sinnvoll sein kann, wenn „nur“ für die Installation oder Aktualisierung einer Erweiterung ein Speicherbedarf von 1 GB RAM vorausgesetzt wird. Das wird bei Shared-Hostern wohl überhaupt nicht funktionieren und auch bei eigenen Servern machen solche Einstellungen keinen Sinn bzw. bremsen das System aus.

Nachtrag: Nutzt Du bei Contao 3.5 den Composer?. Wenn ja müsste Dir das Thema da auch schon mal aufgefallen sein.

Nein, nutze ich nicht. Contao 3.5 war nur ein Beispiel, wie viel RAM man normalerweise auch bei einer umfangreichen Seite benötigt. Davon abgesehen würde ich Composer dort ja dann auf der Kommandozeile nutzen und da sind die Speicherlimits komplett anders.

[mlweb]

Da der CM ja zu einem großen Teil eine Oberfläche für den Composer ist, hat es schon damit zu tun.

Inwieweit an der Minimierung des Speicherbedarfs von Composer gearbeitet wird weiss ich nicht. Ich meine aber dass der Manager nur dann weniger Speicher benötigen wird, wenn es auch der Composer tut.

... aber du wirst mir sicherlich Recht geben, dass es für die Zukunft kaum sinnvoll sein kann, wenn „nur“ für die Installation oder Aktualisierung einer Erweiterung ein Speicherbedarf von 1 GB RAM vorausgesetzt wird. Das wird bei Shared-Hostern wohl überhaupt nicht funktionieren und auch bei eigenen Servern machen solche Einstellungen keinen Sinn bzw. bremsen das System aus.

Zu dem Thema gab es ja schon viele ausführliche und kontroverse Diskussionen. Ich glaub die brauchen wir hier nicht noch einmal aufzuwärmen.

Davon abgesehen würde ich Composer dort ja dann auf der Kommandozeile nutzen und da sind die Speicherlimits komplett anders.

Bei Contao 3 hattest Du die Auswahl zwischen Paketverwaltung mit Composer und Composer über die Konsole. Bei Contao 4 ist es der Contao Manager mit Composer oder Composer über die Konsole. Insofern sehe ich da nicht wirklich einen Unterschied.

[lucina]

Da der CM ja zu einem großen Teil eine Oberfläche für den Composer ist, hat es schon damit zu tun. Dass der Speicherbedarf durch den Composer kommt, ist mir auch klar aber du wirst mir sicherlich Recht geben, dass es für die Zukunft kaum sinnvoll sein kann, wenn „nur“ für die Installation oder Aktualisierung einer Erweiterung ein Speicherbedarf von 1 GB RAM vorausgesetzt wird. Das wird bei Shared-Hostern wohl überhaupt nicht funktionieren und auch bei eigenen Servern machen solche Einstellungen keinen Sinn bzw. bremsen das System aus.

Nein, dass hat nichts mit Composer an sich zu tun, sondern damit, dass es Speicher braucht, um umfangreiche Abhängigkeiten aufzulösen. Man kann das eingrenzen, indem man die Zahl der zu berücksichtigenden Pakete limitiert.

Man kann das tun, indem man Einstellungen bezgl der Stabilität der zu nutzenden Extensions (=Bundles) macht. Contao 4 ist an sich so konfiguriert, dass nur solche Pakete berücksichtigt werden, die mit 'Stable' getaggt sind. Das ist auch das, was man für eine Liveseite möchte. Da will man keine Betas, Alphas oder gar Entwicklungssnapshots. Und unter diesen Bedingungen benötigt die Aktualisierung einer Erweiterung kein Gigabyte. Ich habe hier einige Systeme, bei denen im Produktivbetrieb 256 MB vollkommen ausreicht. Das ist im Übrigen eine Verdoppelung des empfohlenen RAMs für Contao 3, was ich - immerhin fünf Jahre später -
jetzt nicht so schlimm finde.

Ein Beispiel: Eine Webseite bei mir mit den Rocksolid-Erweiterungen, dem Notification-Center, NewsCategories, Shariff, Changelanguage, einer Mailchimp-Bridge, BackupDB und drei weiteren eigenen kleineren Extensions benötigt bei der Aktualisierung via Contao-Manager bei mir maximal 237 MB. Das finde ich kommod, vor allem, wenn ich berücksichtige, dass damit die Frage der Contao-Updates auch gleich mit abgehandelt wird.

Wenn Du entwickelst, dann wird das anders sein. Dazu musst Du allerdings entweder lokal arbeiten oder auf Deinem Entwicklungsserver mit mehr Ressourcen. Aber kein Livesystem sollte je zum entwickeln benutzt werden.

Man muss sich allerdings mal klar machen, woher der Speicherbedarf dann kommt. Bei Stable kann man recht genau eingrenzen, welche Versionen einer Erweiterung überhaupt für die Auflösung der Abhängigkeiten herangezogen werden. Da lege ich eine Version fest, und damit ist das klar. Auch bei Beta und Alpha (wo getaggte Versionen bestehen) kann ich das festlegen. Auch das ist übersichtlich, wenngleich bei jeder Stufe mehr.

Stelle ich allerdings 'Dev' ein, dann potentieren sich die Möglichkeiten (von, sagen wir mal, 30 bis 50 auf ein paar tausend Versionen). Es liegt auf der Hand, dass dann exponentiell mehr Speicher benötigt wird, und genauso liegt auf der Hand, dass sich das nicht ändern kann.

Letztlich ist so ein Szenario auch gar nicht für ein kleines Shared-Hosting-Paket gedacht, sondern für einen Workflow, bei dem Du mit ausreichenden Ressourcen entwickelst (wozu denn sonst 'Dev'-Versionen?) und dann, wenn alles auf der Entwicklungsmaschine gut und sicher und stabil ist, auf den Liveserver deployen kannst, der all das ja gar nicht auflösen muss.

So in etwa ... :-)

[Babelfisch]

Also nur noch mal zur Info: Ich habe testweise ein komplett neues Contao 4.4 mit dem Contao Manager installiert und wollte danach eine einzige Erweiterung (rocksolid-custom-elements) mit dem Contao Manager installieren. Wie man an der Fehlermeldung sieht, reichen dazu 256 MB RAM offenbar nicht aus. Es geht hier (noch) nicht um ein Dev-System oder eins mit ’zig Erweiterungen und Abhängigkeiten.

[mlweb]

Ich habe gerade mal auf einem schwacher Shared-Hosting getestet.

Hetzner Level 4
Memory-Limit: 192 MB
Max-Execution-Time: 90s
kein ssh-Zugang

Neuinstallation Contao 4.4.3 über den Manager ok
Installation Erweiterungen:

contao-rocksolid-custom-elements ok

contao-rocksolid-slider ok

contao-easy_themes ok
m17-sticky-backend-footer ok

Erst als ich noch isotope hinterherschieben wollte ist das Paket mit

Process terminated with exit code 137 
Reason: Kill (terminate immediately)

ausgestiegen.

Ich nutze Hetzner mit Contao 4 nur zum Testen für die Community, weil die Eckdaten m.E. für Contao 4 nicht geeignet sind (u.a. kein ssh-Zugang).
Beim Update der Installation reicht das Memory Limit meist auch nicht. Auch bei der Installation habe ich manchmal schon zwei Anläufe gebraucht, weil ein Script abgebrochen wurde.

Ich kann Dir als Nicht-Entwickler leider nicht genau erklären warum es bei einigen Hostern mit einem vergleichsweise geringen Memory-Limit funktioniert (zumindestens die Installation) und bei anderen nicht.
Der Contao Manager versucht soweit ich weiss automatisch das Memory Limit auf 1.5 GB anzuheben und führt Composer als eigenständigen Prozess aus. Ich habe mal hier im Forum (im Zusammenhang Contao 3 und Paketverwaltung) gelesen, dass der Speicher den der Hoster in dem Fall zur Verfügung stellt meist höher ist als das angegebene Memory Limit.

[tab]

Auch die PHP-Version scheint einen erheblichen Unterschied auszumachen. PHP 7.x benötigt für den selben Vorgang wesentlich weniger RAM als PHP 5.6

[Babelfisch]

Ich hab ja PHP 7.1.6 und das sollte da schon passen. Ich werde mal eine neue Installation machen und es dann noch mal testen. Mich wundert ja auch, dass die Erweiterungen dann beim Aktualisieren anstandslos installiert wurden und der RAM dort gereicht.

[Sitting Bull]

Ich klinke mich hier mal ein, obwohl es ja eigentlich um die DomainFactory geht. Ich bin bei Hetzner und habe das gleiche Problem. Auch unter Level 19 384MB memory_limit funktioniert der Contao-Manager für das Aktualisieren nicht. Es scheint also einige viel genutzte Provider zu geben, bei denen Contao mit dem Manager nicht funktioniert. DF und Hetzner sind ja nun auch keine Krauter.

Außerdem kann man den Kunden, die einen Account bei Hetzner haben ja nicht mal eben einen Providerwechsel vorschlagen, weil Contao nicht mehr klarkommt?! Mich würde daher schon mal interessieren, wie das mit dem Manager weitergehen soll? Da wünscht man sich doch das alt Repository zurück!

Was ich echt nicht verstehe: Warum funktioniert es denn per SSH? Wird da weniger Memory benötigt?

[Spooky]

Über SSH gibt es (meist) kein künstliches memory limit.

[Spooky]

Außerdem kann man den Kunden, die einen Account bei Hetzner haben ja nicht mal eben einen Providerwechsel vorschlagen, weil Contao nicht mehr klarkommt?!

Doch, natürlich? Du bist doch der Web Entwickler und hast dementsprechend die Expertise die Entscheidung zu treffen, wie du eine Web Applikation programmierst und welche Anforderungen diese Web Applikation hat. Dein Kunde hat diese Expertise wahrscheinlich nicht. Du wirst dem Kunden doch wohl hoffentlich auch nicht nachgeben wenn er meint, ein 5€ Hosting bietet genug Performance für seinen Webshop mit 50.000 Produkten oder ähnliches.

[Babelfisch]

Ein Webshop mit 50.000 Produkten kommt wahrscheinlich sehr gut mit einem Memory Limit von 256 MB RAM aus. Ein größeres Limit würde das System auch insgesamt eher verschlechtern, da das die Anzahl gleichzeitiger Zugriffe blockiert (davon gehe ich zumindest aus).

Ich will jetzt nicht auf die Entwickler vom CM meckern, insbesondere, da sie ja für den großen Speicherverbrauch nicht verantwortlich sind. Allerdings ist es auch nicht ok, das einfach so als gegeben hinzustellen und den Nutzern zu sagen, dass sie halt damit klar kommen müssen. Damit ist keinem gedient und irgendwie sollte schon daran gearbeitet werden, hier noch einiges zu verbessern.

[Spooky]

Ein Webshop mit 50.000 Produkten kommt wahrscheinlich sehr gut mit einem Memory Limit von 256 MB RAM aus.

Das memory_limit ist nur ein Faktor der entscheidet, ob die Website überhaupt läuft oder nicht. Das sagt nichts über die Performance aus.

Ein größeres Limit würde das System auch insgesamt eher verschlechtern, da das die Anzahl gleichzeitiger Zugriffe blockiert (davon gehe ich zumindest aus).

Wie kommst du darauf?

[Babelfisch]

Das memory_limit ist nur ein Faktor der entscheidet, ob die Website überhaupt läuft oder nicht. Das sagt nichts über die Performance aus.

Ja, aber ein wichtiger und die Anforderungen wurde mit dem Contao Manager vervielfacht.

Ich verstehe auch nicht, warum das hier so sehr verteidigt wird. Mag sein, dass es momentan keine andere Lösung dafür gibt aber es tut Contao sicherlich nicht gut, wenn Contao jetzt auf einen Schlag und ohne ersichtlichen Grund viel höhere Systemanforderungen hat und bei vielen Hostern nicht mehr läuft oder zumindest eine Konfiguration des Memory Limits notwendig ist.

Dazu kommt, dass diese Systemanforderungen soweit ich das sehe nirgendwo außerhalb des Forums kommuniziert werden und die auftretenden Fehlermeldung im CM auch nicht aussagekräftig sind. Das wird wohl für viel Frust sorgen und kann kaum förderlich für die weitere Verbreitung von Contao sein.

Wie kommst du darauf?

Weil ich davon ausgehe, dass der Prozess dann auch soviel Speicher fest zugewiesen bekommt. Ansonsten könnte ja nicht garantiert werden, dass der Speicher genutzt werden kann. Daraus folgere ich, dass es eben nur maximal (verfügbarer Speicher / Memory Limit) Prozesse geben kann. Ein größeres Memory Limit schränkt also die gleichzeitig verarbeitbaren Anfragen auf dem Webserver ein.

Korrigiere mich, wenn ich mich irre.

[Spooky]

Nein, das memory_limit bezieht sich nur auf einen einzelnen PHP Prozess. Wieviele Worker der Webserver spawned hängt nicht direkt von dieser Einstellung ab (zumal der Webserver ja nicht nur PHP Anfragen abwickelt), sondern von der verfügbaren Verarbeitungsleistung (= Prozessorleistung, vereinfacht gesagt).

[Babelfisch]

Dann verstehe ich aber nicht, wie dann aber das Memory Limit garantiert werden kann? Der Speicherbedarf steht ja beim Start des Prozess noch nicht fest und dann kann ja ohne weiteres mal mehr Speicher als vorhanden gebraucht werden. Ok, da kann dann geswapt werden aber das will man ja nicht.

Aber egal, am eigentlichen Problem ändert das erst mal nichts. Wäre es aber nicht möglich, den zusätzlichen Speicher einfach nur im Contao Manager zu reservieren?

ini_set('memory_limit','1024M'); 

Ich weiß nicht, wie das bei Shared Hostern ist aber bei Domain Factory funktioniert das problemlos und damit könnte der wenig benötigte Contao Manager sich den benötigten Speicher sichern, während Contao selber locker mit 128MB auskommt.

[Spooky]

Der Speicherbedarf steht ja beim Start des Prozess noch nicht fest und dann kann ja ohne weiteres mal mehr Speicher als vorhanden gebraucht werden. Ok, da kann dann geswapt werden aber das will man ja nicht.

Genau. Dann braucht der Prozess länger zum verarbeiten und es dauert länger, bis dass der Client den Response bekommt. Ist das Hosting für die Anforderungen also nicht ausreichend dimensioniert, kann es zu solchen Flaschenhälsen kommen.

Aber egal, am eigentlichen Problem ändert das erst mal nichts. Wäre es aber nicht möglich, den zusätzlichen Speicher einfach nur im Contao Manager zu reservieren?

ini_set('memory_limit','1024M'); 

Das ist bereits der Fall: https://github.com/contao/contao-man...onsole#L51-L55
Macht auch Composer so. Funktioniert aber nicht bei jedem Hosting.

[Babelfisch]

Das ist bereits der Fall: https://github.com/contao/contao-man...onsole#L51-L55
Macht auch Composer so. Funktioniert aber nicht bei jedem Hosting.

Dann war das wohl bei der von mir am 18. August getesteten Version noch nicht freigegeben. Denn da hat es ja nicht funktioniert und bei df funktioniert es.

[Spooky]

Der Code ist schon von Anfang an drin in dieser oder einer anderen Form. Und in dieser Form schon seit der ersten Alpha Version.

[Babelfisch]

Der Code ist schon von Anfang an drin in dieser oder einer anderen Form. Und in dieser Form schon seit der ersten Alpha Version.

Na dann haut da noch was nicht hin. Möglicherweise wird das Speicherlimit beim Installiere nicht hochgesetzt und nur beim Aktualisieren. Das würde zumindest erklären, warum ich erst den Fehler bekam, es sich dann aber über die Aktualisierung installieren lies.

[Spooky]

Könnte natürlich sein. Dazu weiß ich leider zu wenig über den Contao Manager.