Afin de résoudre ce problème, je devais m'assurer qu'il y avait plus de 1 Go de mémoire disponible.

J'avais également ce problème, mais l'augmentation de la limite de mémoire PHP a résolu le problème.

Pareil ici:

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

Plus d'informations sur le système:

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

J'ai eu la même erreur deux fois, mais je peux dire: cela fonctionne il y a environ une heure (sans aucun changement sur la configuration) et maintenant, dans le troisième essai, cela fonctionne à nouveau (sans aucun changement du tout).

$ 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

Mettre à jour:

OK oublie ça. J'ai oublié de réactiver le swap ... La machine a vraiment manqué de mémoire ...

J'ai eu le même problème lors de la tentative de déploiement sur une instance Amazon AWS EC2 Micro. Ces instances ne disposent que de 613 Mo de mémoire au total, le compositeur ne parvient donc pas à allouer suffisamment de mémoire pour qu'une mise à jour s'exécute. La mise à niveau vers une petite instance avec 1,7 Go de mémoire totale a résolu le problème.

J'ai le même problème ... le compositeur a-t-il vraiment besoin de tant de mémoire? : -O

Je suppose que ce n'est pas le compositeur lui-même, mais de toute façon: les micro-instances sur ec2 n'ont pas de mémoire de swap _any_ (par défaut) et donc le système d'exploitation lance les processus, s'il manque de mémoire. La meilleure solution au lieu de passer à une version petite (car cela coûte plus cher) est de créer un swap basé sur un fichier (au moins temporaire)

Par exemple.

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

613M est bien moins et rappelez-vous que non seulement PHP le consomme. Je ne pense pas qu'on puisse en blâmer le compositeur. Quelqu'un peut-il résoudre ce problème?

Les personnes utilisant des micro-instances ne devraient plus avoir de problèmes après la mise à jour du compositeur et la mise à jour de votre fichier de verrouillage au nouveau format, voir # 1109. Si vous avez des problèmes de mémoire avec d'autres choses que l'installation, voir # 600.

Je rencontre à nouveau ce problème. Voici mon 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

Faire une analyse à sec avec profilage renvoie les informations suivantes sur l'utilisation de la mémoire:

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

Salut,

Juste une supposition: exécutez-vous cela sur un AWS-micro? Avez-vous un échange
activée?

Cordialement,
Sébastien

20/12/2012 Dan Horrigan [email protected]

Je rencontre à nouveau ce problème. Voici mon Dump:

Erreur fatale PHP: exception non interceptée 'ErrorException' avec le message 'proc_open (): fork failed - Cannot allocate memory' in phar: ///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component /Application de la console. php: 969
Trace de la pile:

0 [fonction interne]: 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 en ligne 969

Faire une analyse à sec avec profilage renvoie les informations suivantes sur l'utilisation de la mémoire:

Utilisation de la mémoire: 25,95 Mo (pic: 67,15 Mo), durée: 9,21 s

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps: //github.com/composer/composer/issues/945#issuecomment -11587234.

github.com/KingCrunch

@dhorrigan aïe selon la trace de la pile, il semble que l'erreur fatale a été déclenchée lors du rendu d'une exception (puisque cela utilise proc_open pour vérifier la largeur de votre terminal). On dirait que ce n'est pas une limite de mémoire php mais plutôt la mémoire de la machine qui est épuisée, donc je suggérerais d'effacer d'autres choses et de l'exécuter avec install au lieu de update si vous pouvez exécuter update ailleurs qui a plus de mémoire. l'installation à partir du fichier de verrouillage utilise très peu de mémoire.

Je l'exécute dans une boîte Vagrant, et il y a pas mal de fonctionnement dessus, mais c'est la première fois que je le vois. Je vais essayer de reconstruire la boîte avec plus de mémoire et voir ce qui se passe. Je vais suivre.

Pour être honnête, 67 Mo n'est pas si grand. Je peux voir à quel point c'est un problème s'il échoue, mais à l'heure actuelle, quelques centaines de Mo de mémoire de pointe ne sont pas tellement à demander;)

Ya, trouvé le problème, la VM n'a que 6 Mo de mémoire disponible (sur 512 Mo) donc, oui. Haha, je l'augmente pour avoir 1 Go de mémoire. J'aurais dû vérifier cela en premier. Continuer.

@Seldaek Les micro-instances ont 590 Mo et par défaut pas de swap. Pour jouer, cela fonctionne bien, mais dès qu'une application a besoin d'un peu plus, elle se brise complètement. Donc, comme mentionné précédemment: la création d'un swap attrape ceci :) Cela ne prend que 10 ou 20 Mo de plus.

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

@KingCrung a raison. Je viens d'ajouter le swap à ma micro-instance EC2 comme décrit ici .

Maintenant, la mise à jour des dépendances fonctionne comme un charme.

@andremaha Parfait! Je vous remercie!! :)

Je reçois également ce problème. 1 Go de Vagrant sur un Macbook Air de 4 Go. Cela se produit même lorsque je limite une mise à jour à un fournisseur spécifique.

Erreur fatale PHP: exception non interceptée 'ErrorException' avec le message 'proc_open (): fork failed - Cannot allocate memory' in phar: /// usr / local / bin / composer / vendor / symfony / console / Symfony / Component / Console / Application . php: 1033
Trace de la pile:

0 [fonction interne]: 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, tableau)

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 ()

Peut le résoudre en arrêtant le vagabond et en vagabondant et en ssh vagrant, puis en courant à nouveau

Utilisation de la mémoire: 102,39 Mo (pic: 427,97 Mo), durée: 104,79 s

Cela a résolu mon problème http://cloudstory.in/2012/02/adding-swap-space-to-amazon-ec2-linux-micro-instance-to-increase-the-performance/

@adamsmeat merci! J'utilise votre solution pour mon instance DO

@adamsmeat - Je peux confirmer sur une machine Ubuntu 12.04 512 Mo Digital Ocean chargée en stock que votre solution est ce qu'il fallait. Symfony2 est maintenant installé et fonctionne comme vous le souhaitez.

@adamsmeat qui m'a sauvé la vie, vient d'ajouter 512 Mo d'espace de swap sur ma micro-instance EC2 et le problème est résolu.

J'ai également rencontré ce problème: c'était dans l'environnement d'utilisation de vagrant box, la mémoire initiale était de 512 Mo et le problème a été résolu après avoir augmenté à 2048G.

rencontré ce problème en utilisant une tranche de 512 Mo de Digital Ocean ... dû https://github.com/composer/composer/issues/945#issuecomment -8552757

même ici @ prodev42

J'ai essayé de copier composer.lock sur le serveur en direct et fonctionne. avec la commande

php composer.phar --verbose install

@paparts On dirait que vous ne versionize le composer.lock ? En règle générale: pour les applications, effectuez une version, pour les bibliothèques, ne le faites pas. Vous ne devriez pas exécuter update sur un système en direct, car il est fort probable que tôt ou tard un paquet arrive, qui brise votre application, sans que vous l'ayez testé localement. Les composer.lock et composer.phar install garantissent exactement que les packages de ces versions sont installés, contre lesquels vous avez développé votre application.

Je n'ai pas remarqué que le framework que j'utilisais a répertorié le composer.lock sur la liste des ignorés. Merci d'avoir fait remarquer cela.

Eu le problème aujourd'hui avec la micro-instance EC2. L'augmentation de la limite de mémoire PHP à 512M l'a corrigé.

serait-ce une bonne chose à faire? Dans l'océan numérique, la mémoire n'est que de 512 Mo et mettre PHP à consommer une telle mémoire serait probablement votre propre VM.

oh, pas du tout. Inutile de mentionner que ce n'est pas un serveur de production.

J'étais en train d'installer un paquet qui nécessitait symfony / event-dispatcher, donc maintenant je ne peux plus installer un seul paquet à cause de l'erreur ci-dessus: S

J'ai obtenu ceci quand j'ai activé opcache.enable_cli dans php cli ini

@ younes0 C'est une description assez vague. Avez-vous lu toute la discussion ici? Habituellement, c'est parce que vous avez manqué de mémoire sans permutation activée, généralement dans une assez petite instance de cloud ou VM.

@KingCrunch dans mon cas, ce n'était pas lié à une mémoire insuffisante, j'ai eu l'erreur décrite par @yooper lorsque j'ai essayé d'installer des packages de compositeur avec l'option opcache.enable_cli php définie sur On (VM ou pas)

Même erreur.

J'ai une gouttelette digitalocean avec 1 Go de RAM.

Quand je démarre php composer.phar update il mange toute la RAM disponible puis lève une exception.

Dans mon cli/php.ini j'ai memory_limit = -1 .

Si la solution est de passer à une gouttelette avec une plus grande RAM juste pour composer, je ferai php composer.phar update sur ma machine locale, puis téléchargerai les fichiers sur mon vps.

Incluez simplement composer.lock

@paparts Merci, ça marche.

Je fais php composer.phar update sur la machine locale puis télécharge composer.lock vers VPS et fais php composer.phar install

@moldcraft L'autre solution est décrite quelque part ci-dessus: il suffit de créer une mémoire d'échange, qui est assez lente, mais au moins elle vous évite les erreurs OOM.

@KingCrunch L'autre solution est décrite quelque part ci-dessus

Ce sera bien si @yooper mettra à jour la description du problème avec les solutions trouvées

ProTip: l'astuce de swap fonctionne également pour les machines virtuelles VirtualBox locales exécutées avec Vagrant.

J'essaie d'insérer en utilisant ajax, mais cela ne fonctionne pas, l'erreur est: exception non interceptée: mémoire insuffisante.
toute idée pour ça ..

@sivagurupr Je ne sais pas de quoi vous parlez, mais j'ai le sentiment que ce n'est pas lié à ce problème. Composer (CLI) n'a pas de capacités ajax: confused: Cependant, à la fin et après avoir lu les commentaires "out of memory" devrait s'expliquer d'eux-mêmes: wink:

Toute erreur dans ce code ...

Le jeu.12 mars 2015 à 16:08, Sebastian Krebs [email protected]
a écrit:

@sivagurupr https://github.com/sivagurupr Je ne sais pas ce que tu es
parler, mais j'ai le sentiment, que ce n'est pas lié à ce problème.
Composer (CLI) n'a pas de capacités ajax [image:: confused:]
Cependant, à la fin et après avoir lu les commentaires "out of memory" devrait
être auto-explicatif [image:: wink:]

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/composer/composer/issues/945#issuecomment -78456750.

J'ai rencontré ce problème lors de l'installation de http://github.com/sabre/xml sur une machine Vagrant. Cependant, j'ai réussi à résoudre ce problème en activant l'échange en utilisant l'exemple ci-dessus.

J'ai la même erreur mais avec une grande instance: 4 Go de RAM et 4 Go de swap. La RAM libre n'est jamais épuisée, encore moins la RAM disponible / mise en cache, et le swap n'est pas touché!

C'est la première fois que la mise à jour du compositeur est exécutée sur cette nouvelle machine, CentOS / CloudLinux 7.1.

Des idées? S'il vous plaît?

J'ai eu la même erreur en cours d'exécution dans ma Vagrant Box. J'avais 2 Go de RAM quand j'ai eu l'erreur. J'ai étendu la RAM à 4 Go et cela a fonctionné. Mais, c'est toujours étrange qu'il ait besoin de tant de bélier.

J'ai rencontré à nouveau ce problème et l'ajout du composer.lock n'a pas fonctionné. Mais au lieu de cela, j'ai essayé d'utiliser l'espace d'échange au lieu d'étendre beaucoup de mémoire. Un article sur digitalocean est assez chouette https://www.digitalocean.com/community/tutorials/how-to-configure-virtual-memory-swap-file-on-a-vps

J'ai également rencontré le problème:

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

Ma limite de mémoire est définie sur -1

ma sortie free :

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

J'avais également ce problème, mais l'augmentation de la limite de mémoire PHP a résolu le problème.

moi aussi

Rencontrait le même problème avec memory_limit défini sur -1. La seule chose qui a fonctionné pour moi a été de recharger ma machine.

Comment ajouter Swap sur Ubuntu 14.04
https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04

Cet article m'a aidé pour l'instance de 512 Mo de RAM.

[Résolu] Si vous exécutez ceci dans une machine virtuelle, arrêtez la machine virtuelle soit par la commande vagrant halt, soit par l'arrêt progressif.

Changez la taille de la RAM selon votre application, dans mon cas, j'ai mis à jour la mémoire à 1024 Mo.
par défaut, il était de 256 Mo;

c'est à dire cela a fonctionné

Arrêtez le service mysql httpd ou nginx et réexécutez

Exécutez le compositeur

Et redémarrez les services

HI @sergiohermes

Cela ne fonctionne que lorsque nginx et / ou mysql consomme par hasard autant de mémoire que le compositeur manque. L'arrêt des services essentiels n'est probablement pas non plus une option dans la plupart des cas. Vous devriez vraiment investir dans la mémoire, soit physiquement, soit sous la forme d'une partition / d'un fichier d'échange. Tout est déjà documenté dans ce fil.

Je comprends, de toute façon c'était un moyen sans avoir à échanger.
Le plus approprié est de créer un swap. Sans aucun doute.
Jetant un oeil trouvé pour "centos" une référence intéressante.

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

Je crois que va ajouter ce fil.

Oh, j'utilise swap pour le résoudre, merci

Vous pouvez éviter cela en augmentant la taille de la mémoire à partir du fichier php.ini , ce qui est une mauvaise option. Mieux vaut supprimer le cache et reconstruire les packages.

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

Ou, je peux être fait par:

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

@ mohitg-bs je suppose que vous avez mélangé quelque chose

• La suppression de fichiers ne libère pas de RAM
• Il ne s'agit pas de PHP memory_limit , mais de la mémoire (virtuelle) de tout le système. Il n'y a pas de paramètre ini qui peut créer de la RAM.

J'ai résolu le même problème dans Vagrant.

J'ai facilement augmenté la mémoire sur la machine virtuelle Vagrant http://www.josheaton.org/increase-memory-vagrant-virtual-machine/
puis, j'ai augmenté la valeur de memory_limit
et supprimez le cache du compositeur: sudo rm -R ~ / .composer
et enfin rechargement vagabond .

J'ai eu le même problème sur une Virtual Box passant par Vagrant.
Corrigé en augmentant la RAM VBox.

Changement de configuration de vb.memory = 512 à vb.memory = 1024

J'ai ajouté de la mémoire d'échange et cela a résolu mon problème.

Vous n'avez plus de mémoire d'échange, essayez ceci

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

Pour ajouter un fichier d'échange:

Déterminez la taille du nouveau fichier d'échange en mégaoctets et multipliez par 1024 pour déterminer le nombre de blocs. Par exemple, la taille de bloc d'un fichier d'échange de 64 Mo est de 65536.
À l'invite du shell en tant que root, tapez la commande suivante avec count égal à la taille de bloc souhaitée:
jj si = / dev / zéro de = / swapfile bs = 1024 count = 65536
Configurez le fichier d'échange avec la commande:
mkswap / swapfile
Pour activer le fichier d'échange immédiatement mais pas automatiquement au démarrage:
swapon / swapfile
Pour l'activer au moment du démarrage, modifiez / etc / fstab pour inclure l'entrée suivante:
/ swapfile swap swap par défaut 0 0
La prochaine fois que le système démarre, il active le nouveau fichier d'échange.

Après avoir ajouté le nouveau fichier d'échange et l'avoir activé, vérifiez qu'il est activé en affichant la sortie de la commande cat / proc / swaps ou free.

Je vous remercie!

Conseils - si l'ajout de swap ne résout pas le compositeur à court de mémoire / n'a pas pu allouer d'erreur:

• Redémarrez votre machine après avoir ajouté le swap. J'ai trouvé que l'erreur du compositeur n'a pas disparu après avoir ajouté 8G de swap. Mais après le redémarrage, cela a fonctionné.
• J'ai également arrêté une autre VM que j'exécutais et j'ai fermé Chrome avec trop d'onglets

(J'utilise composer dans un environnement de développement sur macOS X Sierra 10.12.4 avec 16 Go de RAM).

Cela a-t-il été résolu? J'ai mis à jour globalement le Composer. De plus, j'ai créé un espace d'échange de 1 Go par suggestion @ gillera235 . Je reçois toujours la même erreur. Que puis-je faire pour le dépanner?

Si cela vous aide, j'utilise une instance micro EC2 gratuite.

pousser le fichier composer.lock sur votre serveur et faire

composer --verbose installer

de cette façon, il n'a pas fallu beaucoup de mémoire et a été très rapide pour installer les paquets mis à jour selon les versions du fichier composer.lock.

ça arrive quand tu as moins de mémoire
essayez ces étapes
1) arrêt du service mysql
2) Exécutez votre commentaire
3) démarrage du service mysql

@ sagarshah16 Que se passe-t-il si je n'ai pas de service mysql?

essayez de trouver lequel de vos services en cours d'exécution prend plus d'espace mémoire. si ce n'est pas mysql.

ouais ig update composer devrait résoudre le problème, malheureusement je mets à jour via git bash. Il jette toujours la même erreur pour mettre à jour. Donc, pour les utilisateurs Windows, assurez-vous d'utiliser cmd.exe .

Frappez l'erreur plus tôt. Était sur Ubuntu 16.04 sur une micro-instance EC2.
Résolu en ajoutant un fichier d'échange 1G.

Juste suivi ce lien et résolu le problème.

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

Référence:
http://manpages.ubuntu.com/manpages/xenial/man8/swapspace.8.html

Merci Jeroen T. Vermeulen

Enthusiasm is the light of knowledge. Unknown author.

O estusiasmo é luz do conhecimento. Autor desconhecido.

Ce problème peut être exacerbé par le fait de ne pas activer la surcharge de mémoire. Le fork est massivement inefficace sans sur-commit de mémoire. Essentiellement, lorsque vous forkez, vous doublez l'utilisation de la mémoire engagée de votre processus actuel en créant un autre processus identique. Une grande partie de cette mémoire est partagée entre les processus parent et enfant, mais est une copie sur écriture, donc toute écriture entraînera la copie de la mémoire partagée. Lorsque la sur-validation est activée, votre système autorise cette mémoire partagée dupliquée, mais si vous écrivez dans la mémoire partagée, vous n'aurez peut-être pas assez de RAM physique pour gérer la copie. Avec le sur-commit désactivé, votre système ne vous permettra pas d'allouer de la mémoire en premier lieu.

Obtenir cette erreur avec 1.4GIG disponible ...

$ 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

Une solution à ce problème consiste à ajouter de l'espace d'échange (c'est-à-dire de pagination) à l'instance.

La pagination fonctionne en créant une zone sur votre disque dur et en l'utilisant pour de la mémoire supplémentaire, cette mémoire est beaucoup plus lente que la mémoire normale, mais il en reste beaucoup plus.

Pour ajouter cet espace supplémentaire à votre instance, saisissez:

sudo / bin / dd if = / dev / zero of = / 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

Si vous avez besoin de plus de 1024, remplacez-le par quelque chose de plus élevé.

Pour l'activer par défaut après le redémarrage, ajoutez cette ligne à / etc / fstab:

/var/swap.1 swap swap par défaut 0 0

@dhorrigan aïe selon la trace de la pile, il semble que l'erreur fatale a été déclenchée lors du rendu d'une exception (puisque cela utilise proc_open pour vérifier la largeur de votre terminal). On dirait que ce n'est pas une limite de mémoire php mais plutôt la mémoire de la machine qui est épuisée, donc je suggérerais d'effacer d'autres choses et de l'exécuter avec install au lieu de update si vous pouvez exécuter update ailleurs qui a plus de mémoire. l'installation à partir du fichier de verrouillage utilise très peu de mémoire.

Merci beaucoup, au lieu d'exécuter composer update j'ai fait composer install . Ce qui l'a réparé!

C'est mieux que d'avoir à augmenter la taille de la mémoire dans php.ini ou à augmenter la mémoire de l'instance elle-même.

L'activation du swap a résolu mon problème.

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

Combien d'entre vous publieront quelque chose qui a été écrit dans ce fil? @jemerocay , avez-vous lu le sujet? La même chose est postée ~ 10 messages ci-dessus.

Contributeurs: fermez ceci, s'il vous plaît.