Para resolver este problema, tuve que asegurarme de que hubiera más de 1 giga de memoria disponible.

También estaba teniendo este problema, pero el aumento del memory_limit de PHP resolvió el problema.

Igual que aquí:

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

Más información sobre el sistema:

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

Recibí el mismo error dos veces, pero puedo decir: Funcionó hace aproximadamente una hora (sin ningún cambio en la configuración) y ahora, en el tercer intento, vuelve a funcionar (sin ningún cambio).

$ 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

Actualizar:

OK olvídalo. Olvidé habilitar el intercambio de nuevo ... La máquina _realmente_ se quedó sin memoria ...

Tuve el mismo problema al intentar realizar una implementación en una instancia de Amazon AWS EC2 Micro. Estas instancias tienen solo 613 MB de memoria en total, por lo que el compositor no puede asignar suficiente memoria para que se ejecute una actualización. La actualización a una instancia pequeña con 1,7 GB de memoria total solucionó el problema.

Tengo el mismo problema ... ¿el compositor realmente necesita tanta memoria? : -O

Supongo que no es el compositor en sí, pero de todos modos: las micro instancias en ec2 no tienen _cualquier_ memoria de intercambio (por defecto) y, por lo tanto, el sistema operativo inicia los procesos, si se queda sin memoria. La mejor solución en lugar de actualizar a un tamaño pequeño (porque cuesta más) es crear un intercambio basado en archivos (al menos temporal)

Por ejemplo.

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

613M es muy inferior y recuerde que no solo PHP lo consume. No creo que se pueda culpar al compositor por ello. ¿Alguien puede cerrar este problema?

Las personas que usan micro instancias ya no deberían tener problemas después de actualizar el compositor y actualizar su archivo de bloqueo al nuevo formato, consulte el n. ° 1109. Si tiene problemas de memoria con otras cosas además de la instalación, consulte el n. ° 600.

Me encuentro con este problema nuevamente. Aquí está mi volcado:

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

Hacer un ensayo con creación de perfiles devuelve la siguiente información de uso de mem:

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

Hola,

Solo una suposición: ¿está ejecutando esto en un AWS-micro? Tienes un intercambio
habilitado?

Saludos,
Sebastián

2012/12/20 Dan Horrigan [email protected]

Me encuentro con este problema nuevamente. Aquí está mi volcado:

Error fatal de PHP: excepción no detectada 'ErrorException' con el mensaje 'proc_open (): la bifurcación falló - No se puede asignar memoria' en phar: ///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component /Aplicación de consola. php: 969
Seguimiento de pila:

0 [función interna]: 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 ...', Matriz, NULL, NULL, NULL, Matriz)

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 en phar: ///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php en la línea 969

Hacer un ensayo con creación de perfiles devuelve la siguiente información de uso de mem:

Uso de memoria: 25,95 MB (pico: 67,15 MB), tiempo: 9,21 s

-
Responda a este correo electrónico directamente o véalo en Gi

github.com/KingCrunch

@dhorrigan ouch de acuerdo con el seguimiento de la pila, parece que el error fatal se desencadenó al generar una excepción (ya que usa proc_open para verificar el ancho de su terminal). Parece que no es un límite de memoria php, sino más bien la memoria de la máquina que se agotó, por lo que sugeriría borrar otras cosas y ejecutarlo con la instalación en lugar de la actualización si puede ejecutar la actualización en otro lugar que tenga más memoria. la instalación desde el archivo de bloqueo utiliza muy poca memoria.

Estoy ejecutando esto en una caja Vagrant, y se está ejecutando bastante, pero esta es la primera vez que lo veo. Intentaré reconstruir la caja con más memoria y veré qué pasa. Yo haré un seguimiento.

Para ser honesto, 67 MB no es tan grande. Puedo ver cómo es un problema si falla, pero en esta época, un par de cientos de megas de memoria máxima no es tanto pedir;)

Ya, encontré el problema, la VM solo tiene 6MB de mem disponibles (de 512MB) entonces, ya. Jaja, lo estoy aumentando para tener 1 GB de memoria. Debería haberlo comprobado primero. Continua.

@Seldaek Las micro instancias tienen 590 MB y, de forma predeterminada, no se intercambian. Para jugar, esto funciona bien, pero tan pronto como alguna aplicación necesita un poco más, se rompe por completo. Entonces, como se mencionó anteriormente: la creación de un intercambio captura esto :) Solo se necesitan 10 o 20 MB más.

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

@KingCrung tiene razón. Acabo de agregar swap a mi microinstancia EC2 como se describe aquí .

Ahora la actualización de dependencias funciona a la perfección.

@andremaha ¡Perfecto! ¡¡Gracias!! :)

También tengo este problema. Vagrant de 1GB en una Macbook Air de 4GB. Sucede incluso cuando estoy limitando una actualización a un proveedor específico.

Error fatal de PHP: excepción no detectada 'ErrorException' con el mensaje 'proc_open (): la bifurcación falló - No se puede asignar memoria' en phar: /// usr / local / bin / composer / vendor / symfony / console / Symfony / Component / Console / Application . php: 1033
Seguimiento de pila:

0 [función interna]: 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 ()

Puede resolverlo vagrant halt && vagrant up && vagrant ssh, y luego ejecuta de nuevo.

Uso de memoria: 102,39 MB (pico: 427,97 MB), tiempo: 104,79 s

Esto resolvió mi problema http://cloudstory.in/2012/02/adding-swap-space-to-amazon-ec2-linux-micro-instance-to-increase-the-performance/

@adamsmeat gracias! Utilizo tu solución para mi instancia DO

@adamsmeat - Puedo confirmar en una máquina Ubuntu 12.04 512MB Digital Ocean cargada en stock que su solución es lo que se necesitaba. Symfony2 ahora está instalado y funcionando como se desea.

@adamsmeat que me salvó la vida, acaba de agregar 512 MB de espacio de intercambio en mi microinstancia EC2 y el problema está resuelto.

También encontré este problema. Fue en el entorno de uso de vagrant box, la memoria inicial era de 512 MB y el problema se resolvió después de aumentar a 2048 G.

encontré este problema al usar el segmento Digital Ocean de 512 MB ... tuve que https://github.com/composer/composer/issues/945#issuecomment -8552757

lo mismo aquí @ prodev42

Intenté copiar composer.lock en el servidor en vivo y funciona. con el comando

php composer.phar --verbose install

@paparts ¿ Parece que no versionas el composer.lock ? Como regla general: para las aplicaciones, versionícelo, para las bibliotecas, no. No debe ejecutar update en un sistema en vivo, porque es muy probable que, tarde o temprano, llegue un paquete que rompa su aplicación, sin que lo haya probado localmente. Los composer.lock y composer.phar install aseguran que exactamente los paquetes en esas versiones estén instalados, contra los que ha desarrollado su aplicación.

No me di cuenta de que el marco que estaba usando ha incluido el composer.lock en la lista de ignorados. Gracias por señalar eso.

Tuve el problema hoy con la micro instancia EC2. El aumento de memory_limit de PHP a 512M lo solucionó.

¿Sería bueno hacer eso? En el océano digital, la memoria es solo de 512 MB y poner PHP para consumir hasta esa memoria probablemente sería suficiente para su propia VM.

Oh, para nada. No es necesario mencionar que no es un servidor de producción.

Estaba instalando un paquete que requería symfony / event-dispatcher, así que ahora ya no puedo instalar un solo paquete debido al error anterior: S

Conseguí esto cuando habilité opcache.enable_cli en php cli ini

@ younes0 Esa es una descripción bastante vaga. ¿Leíste toda la discusión aquí? Por lo general, se debe a que se quedó sin memoria sin el intercambio habilitado, generalmente dentro de una instancia de nube bastante pequeña o VM.

@KingCrunch en mi caso, no estaba relacionado con memoria insuficiente, recibí el error descrito por @yooper cuando intenté instalar los paquetes del compositor con la opción opcache.enable_cli php configurada en On (VM o no)

Mismo error.

Tengo una gota de océano digital con 1 Gb de RAM.

Cuando comienzo php composer.phar update se come toda la RAM disponible y luego lanza una excepción.

En mi cli/php.ini tengo memory_limit = -1 .

Si la solución es actualizar a una gota con una RAM más grande solo para el compositor, haré php composer.phar update en mi máquina local y luego subiré los archivos a mi vps.

Solo incluye composer.lock

@paparts Gracias, funciona.

Hago php composer.phar update en la máquina local, luego subo composer.lock a VPS y hago php composer.phar install

@moldcraft La otra solución se describe en alguna parte arriba: Simplemente cree una memoria de intercambio, que es bastante lenta, pero al menos le evita errores OOM.

@KingCrunch La otra solución se describe en algún lugar arriba

Sería bueno si @yooper actualizara la descripción del problema con las soluciones encontradas

ProTip: el truco de intercambio también funciona para máquinas virtuales VirtualBox locales que se ejecutan con Vagrant.

Intento insertar usando ajax, pero eso no funciona, el error es: excepción no detectada: memoria insuficiente.
cualquier idea para esto ..

@sivagurupr No sé, de qué estás hablando, pero tengo la sensación de que no está relacionado con este tema. Composer (CLI) no tiene ninguna capacidad ajax: confuso: Sin embargo, al final y después de leer los comentarios, "out of memory" debería ser autoexplicativo: wink:

Cualquier error en este código ...

El jueves 12 de marzo de 2015 a las 4:08 p.m., Sebastian Krebs [email protected]
escribió:

@sivagurupr https://github.com/sivagurupr No se, que eres
hablando, pero tengo la sensación, de que no está relacionado con este tema.
Composer (CLI) no tiene ninguna capacidad ajax [imagen:: confusa:]
Sin embargo, al final y después de leer los comentarios "sin memoria" debería
ser autoexplicativo [imagen:: guiño:]

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/composer/composer/issues/945#issuecomment -78456750.

Me encontré con este problema al instalar http://github.com/sabre/xml en una máquina Vagrant. Sin embargo, logré solucionarlo habilitando el intercambio usando el ejemplo anterior.

Tengo el mismo error pero con una instancia grande: 4 gb de RAM y 4 gb de intercambio. La RAM libre nunca se agota, y mucho menos la RAM disponible / en caché, ¡y el intercambio no se toca!

Es la primera vez que se ejecuta la actualización del compositor en esta nueva máquina, CentOS / CloudLinux 7.1.

¿Algunas ideas? ¿Por favor?

Tuve el mismo error ejecutándose en mi Vagrant Box. Tenía 2 gb de ram cuando recibí el error. Extendí la memoria RAM a 4 GB y funcionó. Pero, todavía es extraño que necesite tanto ram.

Me encontré con este problema nuevamente y agregar composer.lock no funcionó. Pero en su lugar, intenté usar el espacio de intercambio en lugar de extender mucha memoria. Un artículo sobre digitalocean es bastante ingenioso https://www.digitalocean.com/community/tutorials/how-to-configure-virtual-memory-swap-file-on-a-vps

También encontré el problema:

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

Mi memory_limit está establecido en -1

mi free salida:

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

También estaba teniendo este problema, pero el aumento del memory_limit de PHP resolvió el problema.

yo también

Se estaba encontrando con el mismo problema con memory_limit establecido en -1. Lo único que funcionó para mí fue recargar mi máquina.

Cómo agregar Swap en Ubuntu 14.04
https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04

Este artículo me ayudó para una instancia de 512M RAM.

[Resuelto] Si está ejecutando esto en una máquina virtual, detenga la máquina virtual ya sea mediante el comando vagrant halt o mediante una parada elegante.

Cambie el tamaño de la RAM según su aplicación, en mi caso actualicé la memoria a 1024 MB.
predeterminado era 256 MB;

es decir, funcionó

Detenga el servicio mysql httpd o nginx y vuelva a ejecutarlo

Ejecutar compositor

Y reiniciar los servicios

Hola @sergiohermes

Esto solo funciona, cuando nginx y / o mysql casualmente consumen tanta memoria, ese compositor pierde. Además, detener los servicios esenciales probablemente no sea una opción en la mayoría de los casos. Realmente debería invertir en memoria, ya sea físicamente o en forma de partición / archivo de intercambio. Todo está ya documentado en este hilo.

Entiendo, de todos modos fue una forma sin tener que intercambiar.
Lo más adecuado pero es crear un swap. Sin duda.
Echando un vistazo, encontramos "centos" una referencia interesante.

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

Creo que agregaré este hilo.

Oh, uso swap resolverlo, gracias

Puede evitar esto aumentando el tamaño de la memoria de php.ini file, que es una opción incorrecta. Mejor borre la caché y reconstruya los paquetes.

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

O, puedo hacerlo por:

/ 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 supongo que confundiste algo

• Eliminar archivos no libera RAM
• No se trata de PHP memory_limit , sino de la memoria (virtual) de todo el sistema. No hay una configuración ini que pueda crear su RAM.

Resolví el mismo problema en Vagrant.

Aumenté fácilmente la memoria en la máquina virtual Vagrant http://www.josheaton.org/increase-memory-vagrant-virtual-machine/
luego, aumenté el valor de
y eliminar la caché del compositor: sudo rm -R ~ / .composer
y finalmente recarga vagabunda .

Tuve el mismo problema en una caja virtual que se ejecuta a través de Vagrant.
Se corrigió aumentando la memoria RAM de VBox.

Cambio de configuración de vb.memory = 512 a vb.memory = 1024

Agregué memoria de intercambio y resolvió mi problema.

Te quedaste sin memoria de intercambio, prueba esto

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

Para agregar un archivo de intercambio:

Determine el tamaño del nuevo archivo de intercambio en megabytes y multiplíquelo por 1024 para determinar el número de bloques. Por ejemplo, el tamaño de bloque de un archivo de intercambio de 64 MB es 65536.
En un indicador de shell como root, escriba el siguiente comando con un recuento igual al tamaño de bloque deseado:
dd if = / dev / zero of = / swapfile bs = 1024 count = 65536
Configure el archivo de intercambio con el comando:
mkswap / swapfile
Para habilitar el archivo de intercambio inmediatamente pero no automáticamente en el momento del arranque:
swapon / swapfile
Para habilitarlo en el momento del arranque, edite / etc / fstab para incluir la siguiente entrada:
/ swapfile swap swap valores predeterminados 0 0
La próxima vez que se inicie el sistema, habilita el nuevo archivo de intercambio.

Después de agregar el nuevo archivo de intercambio y habilitarlo, verifique que esté habilitado viendo la salida del comando cat / proc / swaps o free.

¡gracias!

Consejos: si agregar swap no resuelve que el compositor se quede sin memoria / no pudo asignar el error:

• Reinicie su máquina después de agregar swap. Encontré que el error del compositor no desapareció después de agregar 8G de intercambio. Pero después de reiniciar funcionó.
• También apagué otra VM que estaba ejecutando y cerré Chrome con demasiadas pestañas

(Estoy usando Composer en un entorno de desarrollo en macOS X Sierra 10.12.4 con 16 Gb de RAM).

¿Se ha resuelto esto? He actualizado Composer a nivel mundial. Además, creé un espacio de intercambio de 1GB por sugerencia de @ gillera235 . Sigo recibiendo el mismo error. ¿Qué puedo hacer para solucionarlo?

Si ayuda, estoy usando una instancia micro EC2 de nivel gratuito.

empuje el archivo composer.lock en su servidor y haga

compositor --verbose install

de esta manera no tomó mucha memoria y fue superrápido instalar los paquetes actualizados según las versiones en el archivo composer.lock.

pasa cuando tienes menos memoria
prueba estos pasos
1) servicio de parada de mysql
2) ejecuta tu comentario
3) inicio del servicio mysql

@ sagarshah16 ¿Qué sucede si no tengo un servicio mysql?

intente encontrar cuál de sus servicios en ejecución ocupa más espacio en la memoria. si no es mysql.

sí, ig update composer debería resolver el problema, lamentablemente actualizo a través de git bash. Siempre arroja el mismo error para actualizar. Entonces, para los usuarios de Windows, asegúrese de usar cmd.exe .

Golpea el error antes. Estaba en Ubuntu 16.04 en una micro instancia EC2.
Resuelto agregando un archivo de intercambio 1G.

Simplemente siguió este enlace y resolvió el problema.

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

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

Gracias Jeroen T. Vermeulen

Enthusiasm is the light of knowledge. Unknown author.

O estusiasmo é luz do conhecimento. Autor desconhecido.

Este problema puede agravarse si no se habilita la sobreafirmación de memoria. La bifurcación es enormemente ineficaz sin un exceso de memoria. Básicamente, cuando bifurca, duplica el uso de memoria comprometido de su proceso actual creando otro proceso idéntico. Gran parte de esta memoria se comparte entre los procesos padre e hijo, pero es copia en escritura, por lo que cualquier escritura hará que se copie la memoria compartida. Cuando la sobre-confirmación está habilitada, su sistema permite esta memoria compartida duplicada, pero si escribe en la memoria compartida, es posible que no tenga suficiente RAM física para manejar la copia. Con el over-commit deshabilitado, su sistema no le permitirá asignar la memoria en primer lugar.

Obteniendo este error con 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

Una solución para este problema es agregar espacio de intercambio (es decir, paginación) a la instancia.

La paginación funciona creando un área en su disco duro y usándola para memoria adicional, esta memoria es mucho más lenta que la memoria normal, sin embargo, hay mucha más disponible.

Para agregar este espacio adicional a su instancia, escriba:

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 necesita más de 1024, cámbielo por algo más alto.

Para habilitarlo de forma predeterminada después del reinicio, agregue esta línea a / etc / fstab:

/var/swap.1 swap swap valores predeterminados 0 0

@dhorrigan ouch de acuerdo con el seguimiento de la pila, parece que el error fatal se desencadenó al generar una excepción (ya que usa proc_open para verificar el ancho de su terminal). Parece que no es un límite de memoria php, sino más bien la memoria de la máquina que se agotó, por lo que sugeriría borrar otras cosas y ejecutarlo con la instalación en lugar de la actualización si puede ejecutar la actualización en otro lugar que tenga más memoria. la instalación desde el archivo de bloqueo utiliza muy poca memoria.

Muchas gracias, en lugar de ejecutar composer update hice composer install . ¡Que lo arregló!

Es mejor que tener que aumentar el tamaño de la memoria en php.ini o aumentar la memoria de la instancia.

Activar el intercambio resolvió mi problema.

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

¿Cuántos de ustedes publicarán algo de lo que se escribió en este hilo? @jemerocay , ¿has leído el tema? Lo mismo se publica en ~ 10 mensajes arriba.

Colaboradores: cierre esto, por favor.