Para resolver esse problema, tive que garantir que havia mais de 1 GB de memória disponível.

Eu também estava tendo esse problema, mas aumentar o limite de memória do PHP resolveu o problema.

O mesmo aqui:

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

Mais informações sobre o 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

Tive o mesmo erro duas vezes, mas posso dizer: Funcionou há cerca de uma hora (sem nenhuma alteração no setup) e agora na terceira tentativa funciona novamente (sem nenhuma alteração).

$ 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

Atualizar:

OK esqueça. Esqueci de habilitar a troca novamente ... A máquina _realmente_ ficou sem memória ...

Tive o mesmo problema ao tentar fazer uma implantação em uma instância do Amazon AWS EC2 Micro. Essas instâncias têm apenas 613 MB de memória no total, portanto, o composer não consegue alocar memória suficiente para que uma atualização seja executada. Atualizar para uma instância pequena com 1,7 GB de memória total eliminou o problema.

Eu tenho o mesmo problema ... o compositor realmente precisa de tanta memória? : -O

Eu acho que não é o próprio composer, mas de qualquer forma: as micro instâncias no ec2 não têm _qualquer_ memória swap (por padrão) e então o sistema operacional chuta os processos, se ficar sem memória. A melhor solução em vez de atualizar para pequeno (porque custa mais) é criar uma troca baseada em arquivo (pelo menos temporária)

Por exemplo.

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

613M é muito menos e lembre-se, que não só o PHP consome. Não acho que se possa culpar o compositor por isso. Alguém pode fechar este problema?

Pessoas que usam microinstâncias não devem ter mais problemas após atualizar o compositor e atualizar seu arquivo de bloqueio para o novo formato, consulte # 1109. Se você tiver problemas de memória com outras coisas além da instalação, consulte # 600.

Estou enfrentando esse problema novamente. Aqui está o meu despejo:

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

Fazer uma simulação com criação de perfil retorna as seguintes informações de uso de mem:

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

Oi,

Só um palpite: você está executando isso em um AWS-micro? Você tem troca
ativado?

Saudações,
Sebastian

20/12/2012 Dan Horrigan [email protected]

Estou enfrentando esse problema novamente. Aqui está o meu despejo:

Erro fatal do PHP: exceção não detectada 'ErrorException' com a mensagem 'proc_open (): fork failed - Não é possível alocar memória' em phar: ///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component /Aplicação de console. php: 969
Rastreamento de pilha:

0 [função 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 ...', 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 na linha 969

Fazer uma simulação com criação de perfil retorna as seguintes informações de uso de mem:

Uso de memória: 25,95 MB (pico: 67,15 MB), tempo: 9,21 s

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/composer/composer/issues/945#issuecomment -11587234.

github.com/KingCrunch

@dhorrigan ouch de acordo com o rastreamento de pilha, parece que o erro fatal foi disparado durante a renderização de uma exceção (uma vez que usa proc_open para verificar a largura do seu terminal). Parece que não é um limite de memória php, mas sim a memória da máquina que acabou, então eu sugiro limpar outras coisas e executá-lo com install em vez de update se você pode executar update em outro lugar que tenha mais memória. a instalação do arquivo de bloqueio usa muito pouca memória.

Estou executando isso em uma caixa do Vagrant, e há um pouco dele rodando, mas esta é a primeira vez que o vejo. Vou tentar reconstruir a caixa com mais memória e ver o que acontece. Eu vou acompanhar.

Para ser honesto, 67 MB não é tão grande. Eu posso ver como isso é um problema se falhar, mas nos dias de hoje, algumas centenas de megs de memória de pico não é muito pedir;)

Sim, encontrei o problema, a VM só tem 6 MB de mem disponíveis (de 512 MB) então, sim. Haha, estou aumentando para ter 1 GB de memória. Deveria ter verificado isso primeiro. Continue.

@Seldaek As micro-instâncias têm 590 MB e por padrão não tem swap. Para brincar, isso funciona bem, mas assim que algum aplicativo precisa de um pouco mais, ele quebra completamente. Como mencionado anteriormente: Criar um swap pega isso :) Leva apenas 10 ou 20 MB a mais.

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

@KingCrung está certo. Acabei de adicionar swap à minha micro instância EC2, conforme descrito aqui .

Agora, atualizar as dependências funciona perfeitamente.

@andremaha Perfeito! Obrigado!! :)

Eu também estou tendo esse problema. Vagrant de 1 GB em um Macbook Air de 4 GB. Acontece mesmo quando estou limitando uma atualização a um fornecedor específico.

Erro fatal do PHP: exceção não detectada 'ErrorException' com a mensagem 'proc_open (): fork failed - Não é possível alocar memória' em phar: /// usr / local / bin / composer / vendor / symfony / console / Symfony / Component / Console / Application . php: 1033
Rastreamento de pilha:

0 [função 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 ()

Pode resolvê-lo por vagrant halt && vagrant up && vagrant ssh, e então executando novamente.

Uso de memória: 102,39 MB (pico: 427,97 MB), tempo: 104,79 s

Isso resolveu meu problema http://cloudstory.in/2012/02/adding-swap-space-to-amazon-ec2-linux-micro-instance-to-increase-the-performance/

@adamsmeat obrigado! Eu uso sua solução para minha instância DO

@adamsmeat - Posso confirmar em uma máquina Ubuntu 12.04 512 MB Digital Ocean carregada que sua solução é o que era necessário. Symfony2 agora está instalado e funcionando como desejado.

@adamsmeat que salvou minha vida, acabou de adicionar 512 MB de espaço de troca na minha micro instância EC2 e o problema está resolvido.

Eu também encontrei esse problema. Estava no ambiente de uso do vagrant box. A memória inicial era de 512 M. O problema foi resolvido após aumentar para 2048G.

encontrou este problema ao usar a fatia de 512 MB do Digital Ocean ... precisava https://github.com/composer/composer/issues/945#issuecomment -8552757

mesmo aqui @ prodev42

Tentei copiar composer.lock para o servidor live e funciona. com o comando

php composer.phar --verbose install

@paparts Parece que você não composer.lock ? Como regra geral: para aplicativos, crie versão; para bibliotecas, não. Você não deve executar update em um sistema ativo, porque é bem provável que, mais cedo ou mais tarde, chegue um pacote que interrompa seu aplicativo, sem que você o tenha testado localmente. Os composer.lock e composer.phar install garantem que exatamente aqueles pacotes nessas versões estão instalados, contra os quais você desenvolveu seu aplicativo.

Não percebi que a estrutura que estava usando listou composer.lock na lista de ignorados. Obrigado por apontar isso.

Tive o problema hoje com micro instância EC2. Aumentar o limite de memória do PHP para 512M corrigiu isso.

isso seria uma coisa boa a fazer? No oceano digital, a memória é de apenas 512 MB e colocar o PHP para consumir essa memória provavelmente seria o seu próprio VM.

oh, não mesmo. Não há necessidade de mencionar que não é um servidor de produção.

Eu estava instalando um pacote que exigia symfony / event-dispatcher, então agora não posso instalar um único pacote devido ao erro acima: S

Peguei isso quando habilitei opcache.enable_cli no php cli ini

@ younes0 Essa é uma descrição muito vaga. Você leu toda a discussão aqui? Normalmente é porque você ficou sem memória sem a troca habilitada, geralmente em uma pequena instância de nuvem, ou VM.

@KingCrunch no meu caso, não estava relacionado à memória insuficiente, recebi o erro descrito por @yooper quando tentei instalar pacotes composer com a opção opcache.enable_cli php definida como On (VM ou não)

Mesmo erro.

Eu tenho uma gota digitalocean com 1 Gb de RAM.

Quando eu inicio php composer.phar update ele consome toda a RAM disponível e em seguida lança uma exceção.

No meu cli/php.ini tenho memory_limit = -1 .

Se a solução for atualizar para um droplet com uma RAM maior apenas para o compositor, farei php composer.phar update em minha máquina local e, em seguida, carregarei os arquivos em meu vps.

Basta incluir composer.lock

@paparts Obrigado, funciona.

Eu faço php composer.phar update na máquina local, em seguida, envio composer.lock para o VPS e faço php composer.phar install

@moldcraft A outra solução é descrita em algum lugar acima: Basta criar uma memória swap, que é bem lenta, mas pelo menos evita erros de OOM.

@KingCrunch A outra solução é descrita em algum lugar acima

Será bom se @yooper atualizar a descrição do problema com as soluções encontradas

ProTip: o truque de troca também funciona para VMs VirtualBox locais rodando com Vagrant.

Tento inserir usando ajax, mas não está funcionando, o erro é: exceção não capturada: sem memória ..
qualquer ideia para isso ..

@sivagurupr Não sei do que você está falando, mas tenho a sensação de que não tem a ver com esse assunto. O Composer (CLI) não tem nenhum recurso de ajax: confused: No entanto, no final e depois de ler os comentários "sem memória" deve ser autoexplicativo: wink:

Qualquer erro neste código ....

Na quinta-feira, 12 de março de 2015 às 16h08, Sebastian Krebs [email protected]
escrevi:

@sivagurupr https://github.com/sivagurupr Não sei, o que você é
falando, mas tenho a sensação de que não tem a ver com esse assunto.
O Composer (CLI) não tem nenhum recurso de ajax [imagem:: confused:]
No entanto, no final e depois de ler os comentários "fora da memória" deve
seja autoexplicativo [imagem:: wink:]

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/composer/composer/issues/945#issuecomment -78456750.

Corri para este problema ao instalar http://github.com/sabre/xml em uma máquina Vagrant. Porém, consegui consertar habilitando a troca usando o exemplo acima.

Eu tenho o mesmo erro, mas com uma grande instância: 4 gb RAM e 4 gb swap. A RAM livre nunca se esgota, muito menos a RAM disponível / em cache, e a troca não é tocada!

É a primeira vez que executa a atualização do composer nesta nova máquina, CentOS / CloudLinux 7.1.

Alguma ideia? Por favor?

Eu tive o mesmo erro ao correr na minha Vagrant Box. Eu tinha 2 GB de RAM quando recebi o erro. Eu estendi a RAM para 4 GB e funcionou. Mas, ainda assim, é estranho que precise de tanto RAM.

Corri para este problema novamente e adicionar o composer.lock não funcionou. Mas, em vez disso, tentei usar o espaço de troca em vez de estender muita memória. Um artigo sobre digitalocean é bastante bacana https://www.digitalocean.com/community/tutorials/how-to-configure-virtual-memory-swap-file-on-a-vps

Eu também encontrei o 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

Meu limite de memória é definido como -1

minha saída free :

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

Eu também estava tendo esse problema, mas aumentar o limite de memória do PHP resolveu o problema.

eu também

Estava tendo o mesmo problema com memory_limit definido como -1. A única coisa que funcionou para mim foi recarregar minha máquina.

Como adicionar swap no Ubuntu 14.04
https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04

Este artigo me ajudou para uma instância de 512M RAM.

[Resolvido] Se você estiver executando isso na máquina virtual, pare a máquina virtual pelo comando vagrant halt ou pela parada normal.

Altere o tamanho da RAM de acordo com seu aplicativo. No meu caso, atualizei a memória para 1024 MB.
o padrão era 256 MB;

ou seja, funcionou

Pare o serviço mysql httpd ou nginx e execute novamente

Executar compositor

E reinicie os serviços

HI @sergiohermes

Isso só funciona, quando o nginx e / ou mysql coincidentemente consome tanta memória que o compositor perde. Além disso, interromper os serviços essenciais provavelmente não é uma opção na maioria dos casos. Você realmente deve investir em memória, fisicamente ou na forma de uma partição / arquivo de swap. Já está tudo documentado neste tópico.

Eu entendo, mesmo assim era um jeito sem ter que trocar.
O mais apropriado, mas é criar uma troca. Sem dúvida.
Olhando para "centos", encontrou uma referência interessante.

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

Eu acredito que adicionarei este tópico.

Oh, eu uso swap resolvê-lo, obrigado

Você pode evitar isso aumentando o tamanho da memória do arquivo php.ini , o que é uma opção errada. Melhor deletar o cache e reconstruir os pacotes.

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

Ou posso ser feito por:

/ bin / dd se = / dev / zero de = / var / swap.1 bs = 1M contagem = 1024
/ sbin / mkswap /var/swap.1
/ sbin / swapon /var/swap.1

@ mohitg-bs acho que você confundiu alguma coisa

• Remover arquivos não libera RAM
• Não se trata de PHPs memory_limit , mas da memória (virtual) de todo o sistema. Não há nenhuma configuração ini, que pode criar sua RAM.

Resolvi o mesmo problema no Vagrant.

Aumentei facilmente a http://www.josheaton.org/increase-memory-vagrant-virtual-machine/
então, eu aumentei o valor de memory_limit
e exclua o cache do compositor: sudo rm -R ~ / .composer
e, finalmente, vagrant reload .

Eu tive o mesmo problema em uma caixa virtual rodando através do Vagrant.
Corrigido pelo aumento da RAM do VBox.

Mudança de configuração de vb.memory = 512 para vb.memory = 1024

Eu adicionei memória swap e isso resolveu meu problema.

Você ficou sem memória swap, tente isto

/ bin / dd se = / dev / zero de = / var / swap.1 bs = 1M contagem = 1024
/ sbin / mkswap /var/swap.1
/ sbin / swapon /var/swap.1

Para adicionar um arquivo de troca:

Determine o tamanho do novo arquivo de permuta em megabytes e multiplique por 1024 para determinar o número de blocos. Por exemplo, o tamanho do bloco de um arquivo de permuta de 64 MB é 65536.
Em um prompt de shell como root, digite o seguinte comando com count sendo igual ao tamanho de bloco desejado:
dd if = / dev / zero de = / swapfile bs = 1024 contagem = 65536
Configure o arquivo de troca com o comando:
mkswap / swapfile
Para ativar o arquivo de troca imediatamente, mas não automaticamente no momento da inicialização:
swapon / swapfile
Para habilitá-lo no momento da inicialização, edite / etc / fstab para incluir a seguinte entrada:
/ swapfile swap swap padrões 0 0
Na próxima vez que o sistema for inicializado, ele habilitará o novo arquivo de troca.

Após adicionar o novo arquivo de troca e ativá-lo, verifique se ele está ativado visualizando a saída do comando cat / proc / swaps ou free.

obrigado!

Dicas - se adicionar swap não resolver o erro de memória do compositor / não conseguir alocar:

• Reinicie sua máquina após adicionar a troca. Eu descobri que o erro do compositor não desapareceu após adicionar 8G de swap. Mas depois de reiniciar funcionou.
• Eu também desliguei outra VM que estava executando e fechei o Chrome com muitas guias

(Estou usando o composer em um ambiente de desenvolvimento no macOS X Sierra 10.12.4 com 16 Gb de RAM).

Isso foi resolvido? Eu atualizei o Composer globalmente. Além disso, criei um espaço de troca de 1 GB por sugestão de @ gillera235 . Ainda obtenho o mesmo erro. O que posso fazer para solucionar isso?

Se ajudar, estou usando uma micro instância EC2 de nível gratuito.

empurre o arquivo composer.lock em seu servidor e faça

composer --verbose install

desta forma, não consumia muita memória e era super rápido instalar os pacotes atualizados de acordo com as versões do arquivo composer.lock.

acontece quando você tem menos memória
tente estes passos
1) parada do serviço mysql
2) execute seu comentário
3) serviço mysql start

@ sagarshah16 O que acontece se eu não tiver um serviço mysql?

tente descobrir qual de seus serviços em execução ocupa mais espaço de memória. se não for mysql.

sim, o ig update composer deve resolver o problema, infelizmente eu atualizo via git bash. Sempre lança o mesmo erro para atualizar. Portanto, para usuários do Windows, certifique-se de usar cmd.exe .

Acerte o erro antes. Estava no Ubuntu 16.04 em uma microinstância EC2.
Resolvido adicionando um arquivo de troca de 1G.

Basta seguir este link e resolver o 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

Referência:
http://manpages.ubuntu.com/manpages/xenial/man8/swapspace.8.html

Obrigado Jeroen T. Vermeulen

Enthusiasm is the light of knowledge. Unknown author.

O estusiasmo é luz do conhecimento. Autor desconhecido.

Esse problema pode ser agravado por não ter habilitado o over-commit de memória. A bifurcação é extremamente ineficiente sem superalocação de memória. Essencialmente, quando você bifurca, você dobra o uso de memória comprometido de seu processo atual, criando outro processo idêntico. Grande parte dessa memória é compartilhada entre os processos pai e filho, mas é cópia na gravação, portanto, qualquer gravação fará com que a memória compartilhada seja copiada. Quando o over-commit está habilitado, seu sistema permite essa memória compartilhada duplicada, mas se você gravar na memória compartilhada, pode não ter RAM física suficiente para lidar com a cópia. Com o over-commit desabilitado, seu sistema não permitirá que você aloque a memória em primeiro lugar.

Obtendo este erro com 1.4GIG disponível ...

$ 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

Uma correção para esse problema é adicionar espaço de troca (isto é, paginação) à instância.

O paging funciona criando uma área em seu disco rígido e usando-a para memória extra. Essa memória é muito mais lenta do que a memória normal, por mais que esteja disponível.

Para adicionar este espaço extra à sua instância, você digita:

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

Se você precisar de mais de 1024, mude para algo mais alto.

Para habilitá-lo por padrão após a reinicialização, adicione esta linha a / etc / fstab:

/var/swap.1 swap swap padrões 0 0

@dhorrigan ouch de acordo com o rastreamento de pilha, parece que o erro fatal foi disparado durante a renderização de uma exceção (uma vez que usa proc_open para verificar a largura do seu terminal). Parece que não é um limite de memória php, mas sim a memória da máquina que acabou, então eu sugiro limpar outras coisas e executá-lo com install em vez de update se você pode executar update em outro lugar que tenha mais memória. a instalação do arquivo de bloqueio usa muito pouca memória.

Muito obrigado, em vez de executar composer update eu fiz composer install . Que consertou!

É melhor do que ter que aumentar o tamanho da memória no php.ini ou aumentar a própria memória da instância.

Ligar a troca resolveu meu problema.

/ bin / dd se = / dev / zero de = / var / swap.1 bs = 1M contagem = 1024
/ sbin / mkswap /var/swap.1
/ sbin / swapon /var/swap.1

Quantos de vocês postarão algo que foi escrito neste tópico? @jemerocay , você leu o tópico? O mesmo é postado cerca de 10 mensagens acima.

Colaboradores: fechem isso, por favor.