Um dieses Problem zu beheben, musste ich sicherstellen, dass mehr als 1 Gig Speicher verfügbar war.

Ich hatte auch dieses Problem, aber das Erhöhen des PHP-Speicherlimits löste das Problem.

Hier gilt das gleiche:

PHP Fatal error:  Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:943
Stack trace:
#0 [internal function]: Composer\Util\ErrorHandler::handle(2, 'proc_open(): fo...', 'phar:///usr/loc...', 943, Array)
#1 phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php(943): proc_open('stty -a | grep ...', Array, NULL, NULL, NULL, Array)
#2 phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php(848): Symfony\Component\Console\Application->getSttyColumns()
#3 phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php(771): Symfony\Component\Console\Application->getTerminalWidth()
#4 phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php(113): Symfony\Component\Console\Application->renderException(Object(ErrorException), Object(Symfo in phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php on line 943

Fatal error: Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php on line 943

ErrorException: proc_open(): fork failed - Cannot allocate memory in phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php on line 943

Call Stack:
    0.0001     620632   1. {main}() /usr/local/bin/composer:0
    0.0032     727952   2. require('phar:///usr/local/bin/composer/bin/composer') /usr/local/bin/composer:15
    0.0187    3168240   3. Composer\Console\Application->run() phar:///usr/local/bin/composer/bin/composer:13
    0.0211    3485008   4. Symfony\Component\Console\Application->run() phar:///usr/local/bin/composer/src/Composer/Console/Application.php:66
   13.2099  135622120   5. Symfony\Component\Console\Application->renderException() phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:113
   13.2099  135622968   6. Symfony\Component\Console\Application->getTerminalWidth() phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:771
   13.2099  135623064   7. Symfony\Component\Console\Application->getSttyColumns() phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:848
   13.2099  135625208   8. proc_open() phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:943
   13.2100  135626416   9. Composer\Util\ErrorHandler::handle() phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:943

Weitere Infos zum System:

php -v
PHP 5.3.10 (cli) (built: Feb 20 2012 16:56:36) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
    with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans

Ich habe zweimal den gleichen Fehler erhalten, kann aber sagen: Es funktioniert vor ungefähr einer Stunde (ohne Änderung am Setup) und jetzt im dritten Versuch funktioniert es erneut (ohne Änderung überhaupt).

$ php -v
PHP 5.4.4-4~precise+1 (cli) (built: Aug  6 2012 13:01:46) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

Aktualisieren:

Ok, vergiss es. Ich habe vergessen, den Austausch wieder zu aktivieren ... Die Maschine hat wirklich keinen Speicher mehr ...

Hatte das gleiche Problem beim Versuch, eine Bereitstellung für eine Amazon AWS EC2 Micro-Instanz durchzuführen. Diese Instanzen haben insgesamt nur 613 MB Speicher, sodass Composer nicht genügend Speicher für die Ausführung eines Updates zuweist. Durch das Upgrade auf eine kleine Instanz mit 1,7 GB Gesamtspeicher wurde das Problem behoben.

Ich habe das gleiche Problem ... braucht der Komponist wirklich so viel Speicher? :-Ö

Ich denke, es ist nicht der Komponist selbst, aber trotzdem: Die Mikroinstanzen auf ec2 haben keinen Standardspeicher (standardmäßig) und daher startet das Betriebssystem die Prozesse, wenn der Speicher knapp wird. Die bessere Lösung, anstatt auf klein zu aktualisieren (weil es mehr kostet), besteht darin, einen dateibasierten Austausch zu erstellen (zumindest vorübergehend).

Zum Beispiel.

# /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
# /sbin/mkswap /var/swap.1
# /sbin/swapon /var/swap.1

613M ist sehr viel weniger und denken Sie daran, dass nicht nur PHP es verbraucht. Ich glaube nicht, dass man den Komponisten dafür verantwortlich machen kann. Kann jemand dieses Problem schließen?

Benutzer von Mikroinstanzen sollten nach dem Aktualisieren von Composer und dem Aktualisieren Ihrer Sperrdatei auf das neue Format keine Probleme mehr haben (siehe # 1109). Wenn Sie Speicherprobleme mit anderen Dingen als der Installation haben, lesen Sie # 600.

Ich stoße wieder auf dieses Problem. Hier ist mein Dump:

PHP Fatal error:  Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php:969
Stack trace:
#0 [internal function]: Composer\Util\ErrorHandler::handle(2, 'proc_open(): fo...', 'phar:///vagrant...', 969, Array)
#1 phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php(969): proc_open('stty -a | grep ...', Array, NULL, NULL, NULL, Array)
#2 phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php(874): Symfony\Component\Console\Application->getSttyColumns()
#3 phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php(798): Symfony\Component\Console\Application->getTerminalWidth()
#4 phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php(113): Symfony\Component\Console\Application->re in phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php on line 969

Wenn Sie einen Trockenlauf mit Profiling durchführen, werden die folgenden Informationen zur Verwendung von Mem zurückgegeben:

Memory usage: 25.95MB (peak: 67.15MB), time: 9.21s

Hallo,

Nur eine Vermutung: Führen Sie dies auf einem AWS-Mikro aus? Hast du einen Tausch?
aktiviert?

Grüße,
Sebastian

20.12.2012 Dan Horrigan [email protected]

Ich stoße wieder auf dieses Problem. Hier ist mein Dump:

Schwerwiegender PHP-Fehler: Nicht erfasste Ausnahme 'ErrorException' mit der Meldung 'proc_open (): Fork fehlgeschlagen - Speicher kann nicht zugeordnet werden' in phar: ///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component /Konsolenanwendung. PHP: 969
Stapelspur:

0 [interne Funktion]: Composer \ Util \ ErrorHandler :: handle (2, 'proc_open (): fo ...', 'phar: /// vagrant ...', 969, Array)

1 phar: ///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php (969): proc_open ('stty -a | grep ...', Array, NULL, NULL, NULL, Array)

2 phar: ///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php (874): Symfony \ Component \ Console \ Application-> getSttyColumns ()

3 phar: ///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php (798): Symfony \ Component \ Console \ Application-> getTerminalWidth ()

4 phar: ///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php (113): Symfony \ Component \ Console \ Application-> re in phar: ///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php in Zeile 969

Wenn Sie einen Trockenlauf mit Profiling durchführen, werden die folgenden Informationen zur Verwendung von Mem zurückgegeben:

Speichernutzung: 25,95 MB (Peak: 67,15 MB), Zeit: 9,21 s

- -
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie sich unter Gi tHubhttps an: //github.com/composer/composer/issues/945#issuecomment -11587234.

github.com/KingCrunch

@dhorrigan autsch laut Stack-Trace sieht es so aus, als ob der schwerwiegende Fehler beim Rendern einer Ausnahme ausgelöst wurde (da dies proc_open verwendet, um Ihre Terminalbreite zu überprüfen). Es sieht so aus, als wäre es kein PHP-Speicherlimit, sondern der Speicher des Computers, der aufgebraucht ist. Ich würde daher empfehlen, andere Dinge zu löschen und ihn mit install anstelle von update auszuführen, wenn Sie update irgendwo anders ausführen können, wo mehr Speicher vorhanden ist. Die Installation aus der Sperrdatei benötigt sehr wenig Speicher.

Ich führe dies in einer Vagrant-Box aus, und es läuft ziemlich viel darauf, aber dies ist das erste Mal, dass ich es sehe. Ich werde versuchen, die Box mit mehr Speicher neu aufzubauen und zu sehen, was passiert. Ich werde nachgehen.

Um ehrlich zu sein, sind 67 MB nicht so groß. Ich kann sehen, wie es ein Problem ist, wenn es fehlschlägt, aber heutzutage sind ein paar hundert Megabyte Spitzenspeicher nicht mehr so ​​viel zu verlangen;)

Ja, ich habe das Problem gefunden. Auf der VM sind nur 6 MB Mem verfügbar (von 512 MB). Haha, ich erhöhe es auf 1 GB Speicher. Hätte das zuerst überprüfen sollen. Fortfahren.

@Seldaek Die

https://github.com/composer/composer/issues/945#issuecomment -8552757

@ KingCrung ist richtig. Ich habe gerade einen Swap zu meiner EC2-Mikroinstanz hinzugefügt, wie hier beschrieben.

Das Aktualisieren von Abhängigkeiten funktioniert jetzt wie ein Zauber.

@andremaha Perfekt! Vielen Dank!! :) :)

Ich bekomme auch dieses Problem. 1 GB Vagrant auf einem 4 GB Macbook Air. Passiert auch dann, wenn ich ein Update auf einen bestimmten Anbieter beschränke.

Schwerwiegender PHP-Fehler: Nicht erfasste Ausnahme 'ErrorException' mit der Meldung 'proc_open (): Fork fehlgeschlagen - Speicher kann nicht zugeordnet werden' in phar: /// usr / local / bin / composer / vendor / symfony / console / Symfony / Component / Console / Application . PHP: 1033
Stapelspur:

0 [interne Funktion]: Composer \ Util \ ErrorHandler :: handle (2, 'proc_open (): fo ...', 'phar: /// usr / loc ...', 1033, Array)

1 phar: ///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php (1033): proc_open ('stty -a | grep ...', Array, NULL, NULL, NULL, Array)

2 phar: ///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php (911): Symfony \ Component \ Console \ Application-> getSttyColumns ()

3 phar: ///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php (876): Symfony \ Component \ Console \ Application-> getTerminalDimensions ()

4 phar: ///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php (810): Symfony \ Component \ Console \ Application-> getTerminalWidth ()

Kann es lösen, indem Vagabund halt && vagrant up && vagrant ssh, dann wieder laufen.

Speichernutzung: 102,39 MB (Peak: 427,97 MB), Zeit: 104,79 s

Dies löste mein Problem http://cloudstory.in/2012/02/adding-swap-space-to-amazon-ec2-linux-micro-instance-to-increase-the-performance/

@adamsmeat danke! Ich verwende Ihre Lösung für meine DO-Instanz

@adamsmeat - Ich kann auf einem serienmäßig geladenen Ubuntu 12.04 512MB Digital Ocean-Computer bestätigen, dass Ihre Lösung das ist, was benötigt wurde. Symfony2 ist jetzt installiert und funktioniert wie gewünscht.

@adamsmeat , das mein Leben gerettet hat, hat gerade 512 MB Swap-Speicherplatz auf meiner EC2-Mikroinstanz hinzugefügt und das Problem ist gelöst.

Ich bin auch auf dieses Problem gestoßen. In der Umgebung, in der Vagrant Box verwendet wurde, betrug der anfängliche Speicher 512 MB, und das Problem wurde nach einer Erhöhung auf 2048 G behoben.

Bei der Verwendung des Slice Digital Ocean 512MB ist dieses Problem aufgetreten. https://github.com/composer/composer/issues/945#issuecomment -8552757

gleich hier @ prodev42

Ich habe versucht, composer.lock auf den Live-Server zu kopieren und funktioniert. mit dem Befehl

php composer.phar --verbose install

@paparts Klingt so, als würden Sie die composer.lock nicht versionieren? Als Faustregel gilt: Für Anwendungen, die versioniert werden, für Bibliotheken nicht. Sie sollten update auf einem Live-System ausführen, da es sehr wahrscheinlich ist, dass früher oder später ein Paket eingeht, das Ihre Anwendung beschädigt, ohne dass Sie es lokal getestet haben. Die composer.lock und composer.phar install sicher, dass genau die Pakete in diesen Versionen installiert sind, gegen die Sie Ihre Anwendung entwickelt haben.

Ich habe nicht bemerkt, dass das von mir verwendete Framework die composer.lock in der Ignorierliste aufgeführt hat. Vielen Dank für den Hinweis.

Hatte heute das Problem mit der EC2-Mikroinstanz. Durch Erhöhen des PHP-Speicherlimits auf 512 MB wurde das Problem behoben.

Wäre das eine gute Sache? Im digitalen Ozean beträgt der Arbeitsspeicher nur 512 MB, und wenn PHP bis zu einem solchen Speicher verbraucht wird, würde dies wahrscheinlich Ihre eigene VM belasten.

Oh, überhaupt nicht. Es muss nicht erwähnt werden, dass es sich nicht um einen Produktionsserver handelt.

Ich habe ein Paket installiert, für das Symfony / Event-Dispatcher erforderlich ist. Daher kann ich aufgrund des obigen Fehlers kein einziges Paket mehr installieren: S.

Ich habe das bekommen, als ich opcache.enable_cli in PHP CLI INI aktiviert habe

@ younes0 Das ist eine ziemlich vage Beschreibung. Hast du die ganze Diskussion hier gelesen? Normalerweise liegt es daran, dass Ihnen der Speicherplatz ausgeht, ohne dass der Swap aktiviert ist, normalerweise innerhalb einer ziemlich kleinen Cloud-Instanz oder VM.

@KingCrunch in meinem Fall, es war nicht auf unzureichenden Speicher zurückzuführen. Ich habe den von @yooper beschriebenen Fehler opcache.enable_cli php zu installieren, die auf On (VM) gesetzt war oder nicht)

Gleicher Fehler.

Ich habe ein Digitalocean-Tröpfchen mit 1 GB RAM.

Wenn ich php composer.phar update starte, frisst es den gesamten verfügbaren RAM und löst dann eine Ausnahme aus.

In meinem cli/php.ini ich memory_limit = -1 .

Wenn die Lösung darin besteht, nur für Komponisten auf ein Droplet mit einem größeren RAM zu aktualisieren, werde ich auf meinem lokalen Computer php composer.phar update ausführen und dann die Dateien auf meinen vps hochladen.

Fügen Sie einfach composer.lock

@paparts Danke, es funktioniert.

Ich mache php composer.phar update auf dem lokalen Computer, lade dann composer.lock auf VPS hoch und mache php composer.phar install

@moldcraft Die andere Lösung ist oben beschrieben: Erstellen Sie einfach einen Swap-Speicher, der ziemlich langsam ist, aber zumindest OOM-Fehler verhindert.

@KingCrunch Die andere Lösung ist oben beschrieben

Es ist schön, wenn @yooper die

ProTip: Der Swap-Trick funktioniert auch für lokale VirtualBox-VMs, die mit Vagrant ausgeführt werden.

Ich versuche, mit Ajax einzufügen, aber das funktioniert nicht. Der Fehler ist: Nicht erfasste Ausnahme: Nicht genügend Speicher.
Irgendwelche Ideen dafür ..

@sivagurupr Ich weiß nicht, wovon Sie sprechen, aber ich habe das Gefühl, dass es nicht mit diesem Problem zusammenhängt. Composer (CLI) hat keine Ajax-Funktionen: verwirrt: Am Ende und nach dem Lesen der Kommentare sollte "out of memory" jedoch selbsterklärend sein: wink:

Irgendwelche Fehler in diesem Code ....

Am Do, 12. März 2015 um 16:08 Uhr, Sebastian Krebs [email protected]
schrieb:

@sivagurupr https://github.com/sivagurupr Ich weiß nicht, was Sie sind
Ich spreche darüber, aber ich habe das Gefühl, dass es nicht mit diesem Problem zusammenhängt.
Composer (CLI) hat keine Ajax-Funktionen [Bild :: verwirrt:]
Am Ende und nach dem Lesen der Kommentare sollte jedoch "out of memory" sein
selbsterklärend sein [Bild :: zwinker ::]

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/composer/composer/issues/945#issuecomment -78456750.

Bei der Installation von http://github.com/sabre/xml auf einem Vagrant-Computer ist dieses Problem aufgetreten. Ich habe es jedoch geschafft, das Problem zu beheben, indem ich das Austauschen anhand des obigen Beispiels aktiviert habe.

Ich habe den gleichen Fehler, aber mit einer großen Instanz: 4 GB RAM und 4 GB Swap. Der freie RAM ist nie erschöpft, geschweige denn der verfügbare / zwischengespeicherte RAM, und der Swap wird nicht berührt!

Es ist das erste Mal, dass ein Composer-Update auf diesem neuen Computer, CentOS / CloudLinux 7.1, ausgeführt wird.

Irgendwelche Ideen? Bitte?

Ich hatte den gleichen Fehler in meiner Vagrant Box. Ich hatte 2 GB RAM, als ich den Fehler bekam. Ich habe den RAM auf 4 GB erweitert und es hat funktioniert. Trotzdem ist es komisch, dass es so viel RAM braucht.

Ich bin erneut auf dieses Problem gestoßen und das Hinzufügen von composer.lock hat nicht funktioniert. Stattdessen habe ich versucht, Swap Space zu verwenden, anstatt viel Speicher zu erweitern. Ein Artikel über Digitalocean ist ziemlich geschickt https://www.digitalocean.com/community/tutorials/how-to-configure-virtual-memory-swap-file-on-a-vps

Ich bin auch auf das Problem gestoßen:

PHP Warning:  proc_open(): fork failed - Cannot allocate memory in phar:///home/...../sculpin.phar/vendor/symfony/console/Symfony/Component/Console/Application.php on line 974

Mein memory_limit ist auf -1 gesetzt

meine free Ausgabe:

             total       used       free     shared    buffers     cached
Mem:          1992       1331        660        122          8        217
-/+ buffers/cache:       1105        886
Swap:          255        237         18

Ich hatte auch dieses Problem, aber das Erhöhen des PHP-Speicherlimits löste das Problem.

ich auch

Stieß auf dasselbe Problem mit memory_limit auf -1 gesetzt. Das einzige, was für mich funktioniert hat, war das Nachladen meiner Maschine.

So fügen Sie Swap unter Ubuntu 14.04 hinzu
https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04

Dieser Artikel hat mir bei der 512M RAM-Instanz geholfen.

[Gelöst] Wenn Sie dies in einer virtuellen Maschine ausführen, stoppen Sie die virtuelle Maschine entweder durch einen vagabundierenden Stoppbefehl oder durch einen ordnungsgemäßen Stopp.

Ändern Sie die RAM-Größe gemäß Ihrer Anwendung. In meinem Fall habe ich den Speicher auf 1024 MB aktualisiert.
Standard war es 256 MB;

dh es hat funktioniert

Beenden Sie den mysql httpd- oder nginx-Dienst und führen Sie ihn erneut aus

Führen Sie den Composer aus

Und starten Sie die Dienste neu

HI @sergiohermes

Dies funktioniert nur, wenn Nginx und / oder MySQL zufällig so viel Speicher verbrauchen, den der Komponist vermisst. In den meisten Fällen ist es wahrscheinlich auch keine Option, wichtige Dienste zu stoppen. Sie sollten wirklich in Speicher investieren, entweder physisch oder in Form einer Auslagerungspartition / -datei. Es ist alles bereits in diesem Thread dokumentiert.

Ich verstehe, jedenfalls war es ein Weg, ohne tauschen zu müssen.
Am besten ist es jedoch, einen Swap zu erstellen. Ohne Zweifel.
Ein Blick auf "Centos" fand eine interessante Referenz.

https://www.digitalocean.com/community/tutorials/additional-recommended-steps-for-new-centos-7-servers

Ich glaube, ich werde diesen Thread hinzufügen.

Oh, ich benutze Swap, um es zu lösen, danke

Sie können dies vermeiden, indem Sie die Speichergröße von php.ini erhöhen, was eine falsche Option ist. Löschen Sie besser den Cache und erstellen Sie die Pakete neu.

Delete composer cache: `sudo rm -R ~/.composer`
Delete vendor folder: `sudo rm -R vendor`
Rebuild the vendor packages: `composer update`

Oder ich kann gemacht werden durch:

/ bin / dd if = / dev / zero von = / var / swap.1 bs = 1M count = 1024
/ sbin / mkswap /var/swap.1
/ sbin / swapon /var/swap.1

@ mohitg-bs Ich denke du hast etwas durcheinander gebracht

• Durch das Entfernen von Dateien wird kein RAM freigegeben
• Es geht nicht um PHPs memory_limit , sondern um den (virtuellen) Speicher des gesamten Systems. Es gibt keine INI-Einstellung, mit der Sie RAM erstellen können.

Ich habe das gleiche Problem in Vagrant gelöst.

Ich habe den Speicher auf der Vagrant Virtual Machine leicht Http://www.josheaton.org/increase-memory-vagrant-virtual-machine/
dann habe ich den Wert von memory_limit erhöht
und löschen Sie den Composer-Cache: sudo rm -R ~ / .composer
und schließlich vagabundierendes Nachladen .

Ich hatte das gleiche Problem mit einer virtuellen Box, die durch Vagrant lief.
Behoben durch Erhöhen des VBox-RAM.

Konfigurationsänderung von vb.memory = 512 zu vb.memory = 1024

Ich habe Swap Memory hinzugefügt und es hat mein Problem gelöst.

Sie haben keinen Swap-Speicher mehr. Versuchen Sie dies

/ bin / dd if = / dev / zero von = / var / swap.1 bs = 1M count = 1024
/ sbin / mkswap /var/swap.1
/ sbin / swapon /var/swap.1

So fügen Sie eine Auslagerungsdatei hinzu:

Bestimmen Sie die Größe der neuen Auslagerungsdatei in Megabyte und multiplizieren Sie sie mit 1024, um die Anzahl der Blöcke zu bestimmen. Die Blockgröße einer 64-MB-Auslagerungsdatei beträgt beispielsweise 65536.
Geben Sie an einer Shell-Eingabeaufforderung als root den folgenden Befehl ein, wobei count der gewünschten Blockgröße entspricht:
dd if = / dev / zero von = / swapfile bs = 1024 count = 65536
Richten Sie die Auslagerungsdatei mit dem folgenden Befehl ein:
mkswap / swapfile
So aktivieren Sie die Auslagerungsdatei sofort, jedoch nicht automatisch beim Booten:
Swapon / Swapfile
Um es beim Booten zu aktivieren, bearbeiten Sie / etc / fstab mit dem folgenden Eintrag:
/ swapfile swap swap default 0 0
Beim nächsten Systemstart wird die neue Auslagerungsdatei aktiviert.

Überprüfen Sie nach dem Hinzufügen und Aktivieren der neuen Auslagerungsdatei, ob sie aktiviert ist, indem Sie die Ausgabe des Befehls cat / proc / swaps oder free anzeigen.

Dankeschön!

Tipps - Wenn das Hinzufügen von Swap den Komponisten nicht aus dem Speicher bringt / Fehler nicht zuordnen konnte:

• Starten Sie Ihren Computer neu, nachdem Sie Swap hinzugefügt haben. Ich habe festgestellt, dass der Composer-Fehler nach dem Hinzufügen von 8G Swap nicht behoben wurde. Aber nach dem Neustart hat es funktioniert.
• Ich habe auch eine andere VM heruntergefahren, die ich ausgeführt habe, und Chrome mit zu vielen Registerkarten geschlossen

(Ich verwende Composer in einer Entwicklungsumgebung unter macOS X Sierra 10.12.4 mit 16 GB RAM.)

Wurde dies behoben? Ich habe den Composer global aktualisiert. Außerdem habe ich pro @ gillera235- Vorschlag einen Swap-Speicherplatz von 1 GB

Wenn es hilft, verwende ich eine kostenlose Micro-EC2-Instanz.

Schieben Sie die Datei composer.lock auf Ihren Server und tun Sie dies

Komponist --verbose installieren

Auf diese Weise wurde nicht viel Speicher benötigt und es war superschnell, die aktualisierten Pakete gemäß den Versionen in der Datei composer.lock zu installieren.

Es passiert, wenn Sie weniger Speicher haben
Versuchen Sie diese Schritte
1) Service MySQL Stop
2) Führen Sie Ihren Kommentar aus
3) Service MySQL starten

@ sagarshah16 Was passiert, wenn ich keinen

Versuchen Sie herauszufinden, welcher Ihrer laufenden Dienste mehr Speicherplatz benötigt. wenn es nicht mysql ist.

yeah ig update composer sollte das problem lösen, leider aktualisiere ich via git bash. Beim Aktualisieren wird immer der gleiche Fehler ausgegeben. Stellen Sie für Windows-Benutzer einfach sicher, dass Sie cmd.exe .

Treffen Sie den Fehler früher. War unter Ubuntu 16.04 auf einer EC2-Mikroinstanz.
Gelöst durch Hinzufügen einer 1G-Auslagerungsdatei.

Folgen Sie einfach diesem Link und beheben Sie das Problem.

https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-16-04

$ apt install swapspace 

$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="16.04.3 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.3 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

Referenz:
http://manpages.ubuntu.com/manpages/xenial/man8/swapspace.8.html

Vielen Dank, dass Sie Jeroen T. Vermeulen

Enthusiasm is the light of knowledge. Unknown author.

O estusiasmo é luz do conhecimento. Autor desconhecido.

Dieses Problem kann noch verschärft werden, wenn die Speicherüberschreibung nicht aktiviert ist. Das Forking ist massiv ineffizient, ohne dass der Speicher überlastet wird. Im Wesentlichen verdoppeln Sie beim Verzweigen die festgeschriebene Speichernutzung Ihres aktuellen Prozesses, indem Sie einen anderen identischen Prozess erstellen. Ein Großteil dieses Speichers wird von den übergeordneten und untergeordneten Prozessen gemeinsam genutzt, wird jedoch beim Schreiben kopiert, sodass beim Schreiben der gemeinsam genutzte Speicher kopiert wird. Wenn Over-Commit aktiviert ist, lässt Ihr System diesen duplizierten gemeinsam genutzten Speicher zu. Wenn Sie jedoch in den gemeinsam genutzten Speicher schreiben, verfügen Sie möglicherweise nicht über genügend physischen RAM, um die Kopie zu verarbeiten. Wenn Over-Commit deaktiviert ist, können Sie auf Ihrem System den Speicher überhaupt nicht zuweisen.

Diesen Fehler mit 1.4GIG erhalten ...

$ free -m; composer require --dev phpro/grumphp
              total        used        free      shared  buff/cache   available
Mem:           2000         416        1277          21         305        1405
Swap:             0           0           0
Using version ^0.14.1 for phpro/grumphp
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 12 installs, 0 updates, 0 removals
  - Installing symfony/dependency-injection (v3.4.11): The following exception is caused by a lack of memory or swap, or not having swap configured
Check https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors for details


  [ErrorException]                                   
  proc_open(): fork failed - Cannot allocate memory

Eine Lösung für dieses Problem besteht darin, der Instanz Swap-Speicher (dh Paging-Speicherplatz) hinzuzufügen.

Beim Paging wird ein Bereich auf Ihrer Festplatte erstellt und für zusätzlichen Speicher verwendet. Dieser Speicher ist viel langsamer als der normale Speicher, es ist jedoch viel mehr verfügbar.

Um diesen zusätzlichen Speicherplatz zu Ihrer Instanz hinzuzufügen, geben Sie Folgendes ein:

sudo / bin / dd if = / dev / zero von = / var / swap.1 bs = 1M count = 1024
sudo / sbin / mkswap /var/swap.1
sudo chmod 600 /var/swap.1
sudo / sbin / swapon /var/swap.1

Wenn Sie mehr als 1024 benötigen, ändern Sie dies in etwas Höheres.

Fügen Sie diese Zeile zu / etc / fstab hinzu, um sie nach dem Neustart standardmäßig zu aktivieren:

/var/swap.1 Swap Swap Standard 0 0

@dhorrigan autsch laut Stack-Trace sieht es so aus, als ob der schwerwiegende Fehler beim Rendern einer Ausnahme ausgelöst wurde (da dies proc_open verwendet, um Ihre Terminalbreite zu überprüfen). Es sieht so aus, als wäre es kein PHP-Speicherlimit, sondern der Speicher des Computers, der aufgebraucht ist. Ich würde daher empfehlen, andere Dinge zu löschen und ihn mit install anstelle von update auszuführen, wenn Sie update irgendwo anders ausführen können, wo mehr Speicher vorhanden ist. Die Installation aus der Sperrdatei benötigt sehr wenig Speicher.

Vielen Dank, anstatt composer update auszuführen, habe ich composer install . Welches hat es behoben!

Es ist besser, als die Speichergröße in der php.ini oder den Instanzspeicher selbst zu erhöhen.

Durch Einschalten des Swaps wurde mein Problem behoben.

/ bin / dd if = / dev / zero von = / var / swap.1 bs = 1M count = 1024
/ sbin / mkswap /var/swap.1
/ sbin / swapon /var/swap.1

Wie viele von euch werden etwas posten, was in diesem Thread geschrieben wurde? @jemerocay , hast du das Thema gelesen? Das gleiche wird ~ 10 Nachrichten oben gepostet.

Mitwirkende: Schließen Sie dies bitte.