Druckbare Version
Also ich denke das mit der PHP-Version ist bei Webgo bei allen Paketen gleich. Man kann sie leider momentan nur global einstellen :(. Das ist das einzige Problem dort, das mich wirklich stört.
Wegen Platin-Paket, das war mal eine Aktion. Ich geb keine Links mehr dazu raus, aber Google findet es problemlos :cool:.
Ich weiß nicht wirklich wo das hingehört. Hier oder in den Thread wo gerade über Problemchen mit dem CM diskutiert wird.
Ich hab wieder Probleme bei Webgo... erst war es sehr wechselhaft, mal lassen sich Erweiterung installieren, mal nicht.
Versuche ich im Moment den CM zu nutzen, gibt es bei der Installation Fehler:
Rufe ich dann die Konsole auf und versuche es da, passiert z.B.:Code:Error: "Out of memory (allocated 1046487040) (tried to allocate 2359296 bytes)" in phar:///home/www/die-zettelfee.de/web/contao-manager.phar.php/vendor/composer/composer/src/Composer/DependencyResolver/Transaction.php on 123
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
In Transaction.php line 123:
[Symfony\Component\Debug\Exception\OutOfMemoryException]
Error: Out of memory (allocated 1046487040) (tried to allocate 2359296 byte
s)
Exception trace:
tenside:runtask [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [--disable-events] [--] <command> <taskId>
Process terminated with exit code 255
Reason: Unknown error
Jetzt versuche ich auf der Konsole das Update, läuft es durch...Code:php71 contao-manager.phar.php composer require glumanda99/contao-rellax
Using version ^1.0 for glumanda99/contao-rellax
/home/www/die-zettelfee.de/composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
Der Support kann mir im Moment auch nicht wirklich weiter helfen, weils mal geht, mal nicht.Code:php71 contao-manager.phar.php composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
- Installing glumanda99/contao-rellax (1.0): Loading from cache
Writing lock file
Generating autoload files
> ComponentInstaller\Installer::postAutoloadDump
Compiling component files
> Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication
Added/updated the web/app_dev.php file.
Added/updated the web/app.php file.
Wie gesagt, es ging auch schon problemlos mit dem Paket und dem CM.
Was kann ich tun?
Ich bin da auch gerade dran an diesem Problem. Bei mir betrifft es seit etwa Mitte Januar ein Platin-Paket auf dem Server s86. Ist in dem Fall mein eigenes.
Ich habe noch weitere Kundenpakete bei denen das nicht der Fall ist. Alles andere Server.
Magst Du Deinen Server bekannt geben, bei dem es bei Dir passiert?
Ich arbeite auf dem Server im Moment für meine Liveinstallation über composer install.
Ah, okay... das "beruhigt" mich etwas. Hin und hergerissen zwischen Manager Problemen und Hoster, war ich jetzt wirklich ratlos wonach man suchen soll. Der Supporter bei Webgo denkt mittlerweile auch, was soll das.
Mein Server ist s136 - ebenfalls ein Platin-Paket.
Ganz blöde Frage. Wenn ich alles bisher mit dem Manager gemacht habe bzw. den per Konsole angeschubst habe... wie bediene ich dann per Konsole den Composer direkt? Oder würde das keinen Unterschied machen...? :o
edit: Wie gezeigt: "php71 contao-manager.phar.php composer require paket/paketname" funktioniert nicht. Allerdings, wenn ich danach das Update anschiebe via "php71 contao-manager.phar.php composer update" -> dann wird das Paket installiert.
Gruß
Thomas
Was meinst du mit "per Konsole angeschubst"? Hast du den in der contao-manager.phar enthaltenenen Composer über die Konsole aufgerufen? Du kannst dir von getcomposer.org jederzeit eine composer.phar runterladen und entweder ins Installationsverzeichnis (nicht /web/) schieben und von dort aufrufen. Oder, wenn es dir bei deinem Hoster möglich ist, composer global zu installieren, so dass du ihn aus jedem Verzeichnis heraus einfach als "composer" aufrufen kannst. Bei Webgo sollte eigentlich Composer global installiert sein, ob der mittlerweile auch aktuell ist bzw sich aktualisieren lässt weiss ich allerdings nicht.
Also ich versuche ein Paket zu installieren, egal ob über den Manager oder über den Konsolenaufruf "php71 contao-manager.phar.php composer require paket/paketname"
Hier bekomme ich Fehler (siehe oben).
Wenn ich danach aber "php71 contao-manager.phar.php composer update" aufrufe, wird das Paket installiert.
Ich kann so arbeiten, kein Ding, aber gedacht ist das dann doch anders, oder?
Wenn der Composer dort global installiert sein sollte, wo fände ich den? Und dann rufe ich den dort einfach via "composer require paket/paketname" auf, wenn ich was installieren will?
Sorry, aber ich bin ja bereit alles zu lernen und erstmal überall zu lesen, aber intuitiv und userfriendly ist nach modernen Gesichtspunkten m.M. nach echt anders...
Gruß
Thomas
/usr/bin/php7.2 /usr/bin/composer ...Zitat:
Zitat von tblumrich
PHP-Version ggf. anpassen.
Was ich meinte war dann composer install
Composer Update funktioniert in meinem Problem-Paket grundsätzlich auch nicht.
Nach meinem etwas ärgerlichen Hinweis diesbezüglich ist er auf allen Paketen nach Aussage des Supports aktualisiert. Ich habs auf allen Paketen, deren ich habhaft werden konnte kontrolliert.Zitat:
Zitat von tab
Nur composer aufrufen ist allerdings schlecht. Dann wird er nach Aussagen des Supports mit PHP 5.6 aufgerufen und das wollen wir ja in den meisten Fällen nicht.
Auch so bekomme ich Out of Memory, wenn ich direkt den Composer direkt nutze.
Wenn ich danach composer update aufrufe wird das Paket installiert.
composer install läuft auch durch, es wird aber gemeldet:
Code:Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them.
Vermutlich bist du hart an der Grenze des verfügbaren RAMs und das require verbraucht noch ein paar Extrabytes beim Runterladen des Pakets. Danach ist das Paket schon da und in die json eingetragen und es reicht deshalb gerade so.
Was ich mich frage ist, ob es Sinn macht, im Manager bzw in der json nicht überall einfach "neueste" zu benutzen. Kann man eventuell irgendwie ältere Versionen ausschliessen und würde das eventuell RAM einsparen? Also z.B. Composer "mitteilen", dass man von keinem Paket eine ältere Version haben will als aktuell installiert? Das würde dann allerdings bedeuten, dass man beim Update eine neuere Contao-Version nicht installiert bekommt, die z.B. ein aktuell installiertes Paket, von dem es keine neuere Version gibt, als conflict eingetragen hat. Sowas gabs ja auch schon mal, damals wurde die Verwendung einer älteren Version des Pakets damit erzwungen, was dann hier nicht klappen würde.
Wie Du den Composer aufrufst (ob über Manager oder Konsole) ändert ja nichts am tatsächlichen Speicherbedarf.Zitat:
Zitat von tblumrich
Umgekehrt kann es ein Unterschied zwischen dem Speicher geben der Deinem Prozess über den Manager zugebilligt wird und dem der Dir über die Konsole zur Verfügung steht.
Ich habe nun das gleiche Problem, wie genau machst du das Update?Zitat:
Zitat von mlweb
Du überträgst deine lokale composer.lock Datei auf den Server - und dann?
ausführen. Oder wenn du die composer.phar nicht heruntergeladen hast, dafür aber den Contao Manager verwendest:Code:php7.1 composer.phar install -o
Oder direkt im Contao Manager unter Maintenance » Composer Dependencies » Run Installer.Code:php7.1 web/contao-manager.phar.php composer install -o
Großartig!
Danke!
Nun habe ich meine Installation wieder retten können :-)
Dort habe ich nach einem mißglückten Update nur noch einen Error beim Aufruf des Managers bekommen...
Leider ist der Contao Manager immer noch zu abhängig von der eigentlichen Contao Installation - obwohl er das nicht sein müsste. Ich hoffe das wird noch geändert.
Ich hatte gestern und heute 3x Kontakt mit dem webgo Support, weil ich auf dem Server s136 mit einem Platin-Paket bei einer Contao 4.4.13 Installation keine Erweiterung installieren konnte.
Die eigentliche Installation und das hinzufügen von Erweiterungen hat vor wenigen Wochen aber problemlos geklappt...Code:Using version ^1.4 for codefog/contao-cookiebar
/home/www/xxx/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
mmap() failed: [12] Cannot allocate memory
Process terminated with exit code 255
Reason: Unknown error
Als erstes habe ich die Empfehlung bekommen in der php.ini das Speicherlimit von 256M auf 512M zu setzen.
Das hat aber keinen Unterschied gemacht.
Also habe ich noch mal angerufen. Da habe ich erfahren, das es ein bekannter Bug mit Contao 4.4 und den aktuellen Versionen von MySQL(?) ist und das ich mal nach "Contao 4.4 Cannot allocate memory mysql fix" suchen soll - da würde ich verschiedene Einträge dazu finden. Die Einträge habe ich aber nicht gefunden.
Das Problem soll wohl auch in der Contao 4.5 behoben sein... - warum dann nicht in der 4.4?
Weiß da jemand was dazu?
Habe ich nur falsch gesucht?
Also habe ich heute Morgen noch mal angerufen um das Problem zu klären und hatte Herr Da Silva dran - ich glaube das ist einer der besten Leute dort, der hat mir bisher immer sofort helfen können.
Leider nicht bei diesem Problem...
Er hat aber festgestellt, das bei der Fehlermeldung immer die exakt gleiche Zahl an fehlendem Speicher steht - sehr unwahrscheinlich das dies wirklich so der Fall ist wenn ich mehrfach versuche die gleiche oder auch andere Erweiterungen zu installieren. Er hat auch kurzfristig das Speicher-Limit auf 1GB hoch gesetzt - gleiche Fehlermeldung.
Danach habe ich entdeckt das ich noch einen andern Kunden auf dem gleichen Server s136 habe - allerdings ein Power-Paket.
Dort gibt es keine Problem! Updaten oder Erweiterungen installieren geht beides problemlos.
Das hilft zwar alles nicht, weil das Problem noch immer besteht, aber vielleicht kann irgendjemand damit mehr anfangen und das Problem dadurch einkreisen?
Ach ja: Nachdem ich Dank @Spooky meine Installation retten konnte und ein Update auf die aktuelle Contao 4.4.16 gemacht habe, bestand das Problem leider immer noch - die Installation von Erweiterungen ist nicht möglich. Ich denke auch ein Update über den Manager wird mir die Installation wieder zerschiessen - nun weiß ich aber zumindest wie ich diese wieder retten kann...
Das kann auch keine Auswirkung haben. Laut der Fehlermeldung wird der maximale Speicherverbrauch jedes Prozesses, zumindest für deinen SSH User, generell limitiert.Zitat:
Zitat von Cranker
Diese Aussage ist nicht richtig.Zitat:
Zitat von Cranker
Dir bleibt momentan wohl nichts anderes über als alle Erweiterungen zuerst immer lokal installieren und dann auf dem Server ein composer install zu machen (über den Contao Manager oder über SSH).Zitat:
Zitat von Cranker
Das war noch der Versuch normal über den Manager - aber das ist wahrscheinlich das gleiche!?Zitat:
Zitat von Spooky
Davon gehe ich auch aus, aber darum frage ich was es damit auf sich hat...Zitat:
Zitat von Spooky
Der Support Mitarbeiter "Da Silva" wusste davon auch nix.
Ja das denke ich auch.Zitat:
Zitat von Spooky
Ich habe gerade noch mal ein paar Tests gemacht:
Server s122 - CMS Pro Paket => OK Update & Installation von Erweiterungen möglich
Server s129 - CMS Pro Paket => OK Update & Installation von Erweiterungen möglich
Server s133 - CMS Pro Paket => OK Update & Installation von Erweiterungen möglich
Server s136 - CMS Pro Paket => OK Update & Installation von Erweiterungen möglich
Server s136 - CMS Power Paket => OK Update & Installation von Erweiterungen möglich
Server s143 - CMS Power Paket => OK Update & Installation von Erweiterungen möglich
Server s124 - CMS Platin Paket => ERROR Installation von Erweiterungen nicht möglich
Server s136 - CMS Platin Paket => ERROR Installation von Erweiterungen nicht möglich
Scheint wohl am Platin-Paket zu liegen!?
Wie gesagt, auf dem Server (bei welchem Paket auch immer), scheint der maximale Speicherverbrauch für alle Prozesse deines Users (SSH, Webserver, …) hart eingeschränkt zu sein.
Aber genau das scheint doch nicht zu stimmen!?Zitat:
Zitat von Spooky
Ich habe das Problem bei zwei verschiednen Servern (s124, s136) mit dem Platin Paket, aber auf dem einen Server (s136) eben nicht mit zwei anderen Paketen (Pro & Power).
Demnach ist es eben nicht Server- sondern Paket-Abhängig.
Ah ok, ja kann schon sein :). Mit der Information kannst du ja nun wieder zum WebGo Support gehen.
Da wäre vielleicht mal ein klärendes Wort seitens Webgo hilfreich, damit jeder weiß, woran er mit welchem Paket ist.
Also einfach eine kleine Tabelle, in der für die verschiedenen Pakete aufgelistet wird, wie das maximale RAM aussieht für
- Normaler Websitezugriff (Seitenaufrufe)
- Composer-Aufruf aus der Konsole
- Composer-Aufruf über Contao-Manager
Dass es Beschränkungen gibt, ist ja per se nichts Böses. Geht halt nicht ohne, der Gesamtspeicher des Servers ist nun mal limitiert und andere User auf dem Server möchten vielleicht auch mal ein paar KB RAM nutzen ;). Kann ja auch nicht sein, dass alle anderen Fehlermeldungen bekommen, bloss weil ich gerade ein "composer update" ausführen will. Wahrscheinlich werden manche Limits auch nicht fix sein, sondern von der Anzahl der User auf dem Server sowie deren Paketen, der Anzahl aktiver Prozesse oder wovon auch immer abhängen. Das darf dann gern mit angegeben werden, ebenso eventuelle feste Minimal- und Maximalwerte, also wieviel RAM bekomme ich jeweils garantiert und wieviel kann ich maximal bekommen. Dann eventuell noch eine Aussage, wie die Zahlen zu verstehen sind, pro Prozess oder pro User oder ...?
Dann kann man auch besser abschätzen, welches Paket man braucht für ein Projekt. Oder, wie in meinem Fall, welches Paket ich mir leisten muss, um notfalls Updates für Kundeninstallationen in anderen Paketen bei Webgo durchführen zu können Ok, das geht natürlich notfalls immer lokal, ist aber bequemer "von Webgo zu Webgo". Ich will meinen Kunden keine "falschen" Pakete "verkaufen" (ich verkaufe kein Hosting, den Vertrag mit dem Hoster schliesst bei mir letztlich immer der Kunde selbst ab, aus vielerlei Gründen. Ich spreche also lediglich eine Empfehlung aus). "Falsche" Pakete wären dann aus meiner Sicht solche, die unter- oder deutlich überdimensioniert sind für den "Normalbetrieb" der Website. Ich will also niemandem einen Power-Paket empfehlen, nur weil er für das Update die 2GB RAM braucht, wenn seine Seite eh nur recht moderate Zugriffszahlen haben wird und im Normalbetrieb mit 32MB pro Zugriff auskommt. Da reicht dann auch ein kleineres Paket mit 256 oder 512MB RAM und das Update macht man halt woanders. Umgekehrt will ich auch niemandem ein Starter-Paket empfehlen, wenn ihm das dann bei zwei gleichzeitigen Zugriffen um die Ohren fliegt.
Es sieht nicht so aus als ob das ein Speicher-Problem ist, eher ein Konfigurationsproblem bei dem Platin-Paket.
Der Speicher bei dem Platin- und bei dem Pro-Paket sind gleich: 512 MB (memory_limit steht aber auf 256 MB).
Nur das Power Paket hat 1024 MB RAM zur Verfügung.
Bei der Installation von Contao über den Manager und anschließendem installieren von Erweiterungen hatte ich auch keine Problem - egal auf welchem Paket.
Die Probleme tauchten erst später auf...
Habe ich gerade gemacht und meine Erfahrungen an die per E-Mail geschickt.Zitat:
Zitat von Spooky
Vielleicht finden die das Problem damit.
Das Problem ist ja eh schon gefunden ;). Die haben den für Prozesse deines Users zur Verfügung stehenden Speicher limitiert. Diese Limitation müsste WebGo entfernen oder erhöhen (bspw. auf 1536M).
Poste mal deine composer.json.
Zitat:
Zitat von Spooky
Das ist nun von dem Projekt das ich lokal aktualisiert habe und dann über das Terminal upgedatet habe.Code:{
"name": "contao/managed-edition",
"type": "project",
"description": "Contao Open Source CMS",
"license": "LGPL-3.0+",
"authors": [
{
"name": "Leo Feyer",
"homepage": "https://github.com/leofeyer"
}
],
"require": {
"php": "^5.6|^7.0",
"codefog/contao-cookiebar": "^1.4",
"codefog/contao-mobile_menu": "^2.7",
"contao/calendar-bundle": "^4.4",
"contao/comments-bundle": "^4.4",
"contao/faq-bundle": "^4.4",
"contao/listing-bundle": "^4.4",
"contao/manager-bundle": "4.4.*",
"contao/news-bundle": "^4.4",
"contao/newsletter-bundle": "^4.4",
"erdmannfreunde/onepage-navigation": "^1.0",
"madeyourday/contao-rocksolid-columns": "^2.0",
"roave/security-advisories": "dev-master",
"terminal42/contao-easy_themes": "^2.2",
"trilobit-gmbh/contao-cookiebar-bundle": "^1.0"
},
"config": {
"component-dir": "assets"
},
"scripts": {
"post-install-cmd": [
"Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
],
"post-update-cmd": [
"Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
]
}
}
Was hoffst du darin zu finden? Welche Erweiterungen installiert sind?
Wie kommst du darauf?Zitat:
Zitat von Spooky
Verwende diese composer.json und versuche es nochmal:Zitat:
Zitat von Cranker
Im wesentlichen habe ich "roave/security-advisories": "dev-master", entfernt - denn diese Abhängigkeit verbraucht bei der Abhängigkeitsauflösung viel mehr Speicher. Siehe https://community.contao.org/de/show...l=1#post466415Code:{
"name": "contao/managed-edition",
"type": "project",
"description": "Contao Open Source CMS",
"license": "LGPL-3.0-or-later",
"authors": [
{
"name": "Leo Feyer",
"homepage": "https://github.com/leofeyer"
}
],
"require": {
"php": "^5.6|^7.0",
"codefog/contao-cookiebar": "^1.4",
"codefog/contao-mobile_menu": "^2.7",
"contao/calendar-bundle": "^4.4",
"contao/comments-bundle": "^4.4",
"contao/faq-bundle": "^4.4",
"contao/listing-bundle": "^4.4",
"contao/manager-bundle": "4.4.*",
"contao/news-bundle": "^4.4",
"contao/newsletter-bundle": "^4.4",
"erdmannfreunde/onepage-navigation": "^1.0",
"madeyourday/contao-rocksolid-columns": "^2.0",
"terminal42/contao-easy_themes": "^2.2",
"trilobit-gmbh/contao-cookiebar-bundle": "^1.0"
},
"conflict": {
"contao/core-bundle": "<4.4.8"
},
"config": {
"component-dir": "assets"
},
"extra": {
"branch-alias": {
"dev-4.4": "4.4.x-dev"
}
},
"scripts": {
"post-install-cmd": [
"Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
],
"post-update-cmd": [
"Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
]
}
}
Das geht aus dieser Fehlermeldung hervor.Zitat:
Zitat von Cranker
Man muss beim RAM unterscheiden zwischen Konsolenprozessen (Composer Konsolenaufruf), Apache-Prozessen und eventuell noch vom Apache-Prozess erzeugten Konsolenprozessen (Contao-Manager). Das kann alles unterschiedlich konfiguriert sein.
Das Platin-Paket ist auch kein CMS-Paket wie CMS Pro und CMS Power. Kann durchaus sein, dass hier für die CMS-Pakete eben andere Regeln gelten als für die "Go-Pakete" und vielleicht nochmal andere für die aktuellen Webhosting-Pakete (Starter, Profi, Business, Power). Es könnte also dem GoPaket Platin ohne Weiteres auf der Konsole oder über den Manager nur z.B. 512MB zugestanden werden und dem CMS Pro 1GB, obwohl bei beiden steht 512MB.
Das hat leider nicht geklappt:Zitat:
Zitat von Spooky
Code:Using version ^1.0 for trilobit-gmbh/contao-cookiebar-bundle
/home/www/xxx/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
mmap() failed: [12] Cannot allocate memory
Process terminated with exit code 255
Reason: Unknown error
Ah. Das hatte ich noch nicht gesehen.Zitat:
Zitat von Spooky
O.K.Zitat:
Zitat von Spooky
Irgendwas geht hier furchtbar schief. Ich teste gerade auf einem Platin-Paket, natürlich nur im ureigensten Interesse des entsprechenden Kunden, der ja auch mal Contao 4 bekommen soll. ;)
Ausgangslage: Alte Testinstallation 4.4.4 mit Manager Beta 10, nur Core installiert. Update mit dem alten Manager auf 4.4.16 problemlos.
Ich starte dann den Manager neu und er macht ein Update auf Beta 16. Ich wähle Webgo, alles ok.
Dann kommt der Teil, den ich nicht wirklich verstehe ...
1) Ich versuche die erste Erweiterung zu installieren (codefog/contao-cookiebar). Es kommt der obenstehende mmap-Fehler.
2) Ich klicke auf "Bestätigen und Schliessen", der Manager initialisiert sich offenbar neu und prüft das System und die Installation, danach erscheint die Suchmaske für die Erweiterungen und kreiselt endlos mit dem zuvor eingegebenen Suchstring.
6) Ich breche das ab durch Klick auf das Kreuz hinter dem Eingabefeld.
7) Es erscheint wieder die Liste der installierten Bundles, ich klicke auf "Pakete aktualisieren".
8) Nanu?!? Die zuvor nicht installierte Erweiterung wird problemlos installiert!
9) Installtool aufgerufen, danach im Manager "Bestätigen ud Schliessen".
10) Nächste Erweiterung, das selbe Spiel wieder, bei jeder Erweiterung.
Ich habe jetzt alles installiert aus der Liste von Cranker, bis auf das roave/security-advisories, das wird irgendwie nicht gefunden bei der Suche über den Manager. Dazu habe ich dann noch BackupDB installiert, auch hier das selbe Spiel, zuerst die mmap-Fehler Geschichte. Aber jetzt sind die Erweiterungen jedenfalls alle drin in der Installation. Ein oder zwei Mal wurde gemeckert, dass was mit der Installation nicht stimmt, irgendwelche Dateien gefunden wurden. Aktuelle Seite neu laden im Firefox hat jedes Mal zuverlässig geholfen, danach gings dann wieder weiter. Jetzt muss mir das nur noch jemand erklären...
Edit: Ich habe eben noch versucht, roave/security advisories zu installieren mit
Das ging dann schief:Code:php71 composer.phar require --dev roave/security-advisories:dev-master
Man sieht aber zumindest, dass tatsächlich 1GB RAM verfügbar zu sein scheint im Platin-Paket.Code:Loading composer repositories with package information
Updating dependencies (including require-dev)
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
PHP Fatal error: Out of memory (allocated 1046487040) (tried to allocate 4096 bytes) in phar:///home/www/kundendomain.de/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52
Fatal error: Out of memory (allocated 1046487040) (tried to allocate 4096 bytes) in phar:///home/www/kundendomain.de/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52
Etwas änlich Seltsames habe ich auch gerade erlebt, als ich mit nem goPlatin von 4.4.14 auf 4.4.16 updaten wollte. Zuerst wollte sich der Manager auf 16 beta aktualisieren. In der Konsole erschien nichts, die Sanduhr lief ewig. Irgendwann habe ich einfach die contao-manager.phar.php neu aufgerufen, und siehe da, das Update auf die beta 16 schien erfolgreich funktioniert zu haben, obwohl keine Ausgabe im console DIV zu sehen war und die Sanduhr ewig lief.
Dann die Pakete aktualisiert, wollte ja von 4.4.14 auf 4.4.16, und dort gleiches Spiel mit Consolen-DIV und Sanduhr erlebt. Irgendwann dann wieder contao-manager.phar.php aufgerufen und dann die Ausgabe in der Konsole gesehen. Alles schien erfolgreich verlaufen zu sein.
Aber dass da keine Ausgabe in der Konsole kommt und die Sanduhr ewig läuft, kann ja eigentlich nicht am Server liegen, sondern an dem Manager denke ich.
Ich verknüpfe das hier mal mit den Meldungen zum Hoster WebHostOne. Auch dort scheinen sich Hinweise zu verdichten, dass es was mit der neuen Version des Managers zu tun haben könnte: https://community.contao.org/de/showthread.php?70192-Contao-Manager-Webhostone-Cannot-allocate-memory
Ich will nur kurz bestätigen, dass ich mit meinem Platin Paket genau die gleichen Probleme habe, die hier beschrieben wurden.
Mein Vorgehen ist auch immer die Zwei-Schritte Taktik: Erweiterung über Manager installieren bis zur genannten Fehlermeldung, dann install oder update über die Konsole.
Gesendet von iPad mit Tapatalk
habe die Probleme mal an Andi (CM-Hauptentwickler) weitergeleitet.
Was ich halt gar nicht verstehen kann ist, dass beim ersten Aufruf des Composer Update durch den Manager regelmäßig zu 100% der mmap-Fehler kommt und beim zweiten Versuch dann aber das Memory reicht. Jedenfalls etwa bis zu der Anzahl und Größe von Erweiterungen, wie ich es auch anfangs bei älteren Managerversionen gewohnt war. Dass das mit roave/security-advisories in Entwicklerversion nicht mehr klappt finde ich absolut nachvollziehbar. Das scheint also real zu sein. Aber was passiert da beim ersten Aufruf? Was ist da anders? Wird da mehr RAM allokiert, ist da vor dem Aufruf bereits mehr RAM allokiert oder ist es vielleicht gar nicht die Menge des angeforderten RAM was die Probleme macht, sondern irgendetwas Anderes? Jedenfalls behauptet das Konsolenfenster auch beim zweiten Versuch "Updating dependencies" und es klappt.
Ich kann mich hier anschließen.
Ich bin schon seit Januar mit Webgo (Herrn da Silva) im Kontakt. Leider bin ich von den Antworten nicht ganz so begeistert.
Die letzte Antwort kam heute und zwar nicht zum ersten Mal mit der Auskunft, dass bei ihnen angeblich der Konsolenbefehl fürs Update beim Testen funktioniert hat.
Mir ist das seit dem ersten Auftreten der Probleme noch nie gelungen. Ich kann mir irgenwie keinen Reim drauf machen was das soll.
Ich kann nicht bestätigen, dass es grundsätzlich die Platinpakete betrifft.
Platinpakete bei folgenden Servern laufen problemlos:
s139
s133
s93
Paket cms Pro auf folgendem Serverläuft ebenfalls problemlos:
s143
Probleme macht das Platin-Paket auf Server:
s86
Die Installationen sind alle vergleichbar - kleine Websites mit nur sehr wenig Erweiterungen.
Bei mir ist das Problem zum ersten Mal im Januar auf der Konsole aufgetreten.
Zuvor war sowohl Installation über den Manager als auch Installation über die Konsole immer problemlos möglich.
Ich kann nicht mal eine blanke Contao Core Testversion aktualisieren (weder über Konsole noch über Contao Manager).
Ich frag mich auch langsam was da los ist.
Vielleicht noch zur Ergänzung: Verwendet wir entweder PHP 7.1 oder 7.2.
Ich hatte mir in den funktionierenden Paketen auch mal den Speicherbedarf angeschaut:
Der durchschnittlichen Speicherbedarf lag bei ca. 270MB (peak: zwischen 800MB und 900MB), time: zwischen 60s und 75s. Aber wie gesagt waren das Installationen mit teilweise mehrere Erweiterungen, während die nicht funktionierende Testversion völlig „nackt“ ist und damit sicher nicht mehr Speicher benötigt.
Moin,
wir haben Eure Posts aufmerksam durch gelesen und sind dabei einige Neuerungen durchzuführen. So konnten wir das SSL Problem mittlerweile beheben.
Das hier erwähnte Problem bei Platin Tarifen konnten wir bisher jedoch mittels interner Tests nicht nachstellen, da diese Problematik nur sporadisch vorzukommen scheint. Wir bitten Euch uns bei Problemen an unsere E-Mailadresse support@webgo.de eine Nachricht zu schicken. Im ersten Satz der Mail schreibt bitte "z. Hd. Herrn Möhring - Contao Platinpaket". Wir werden uns dann mit Euch schnellst möglich in Verbindung setzen um das Problem langfristig zu beseitigen.
Beste Grüße
Euer webgo Team
Hallo in die Runde,
nachdem ich in den letzten Wochen wirklich nur noch genervt war, weil meine Tickets meist sehr unzureichend beantwortet worden sind, habe ich kurzer Hand das Paket gewechselt (steht nicht auf der "normalen" Paketseite: https://www.webgo.de/cms/pakete/ Hier das Power-Paket).
Jetzt flutscht alles (nachdem es noch Probleme mit dem Zertifikat gab, die aber mittlerweile auch behoben wurden.)
Viele Grüße
Hella