この問題を解決するには、1ギガバイトを超えるメモリが使用可能であることを確認する必要がありました。

私もこの問題を抱えていましたが、PHPのmemory_limitを増やすと問題が解決しました。

こっちも一緒：

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

システムに関する詳細情報：

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

同じエラーが2回発生しましたが、次のように言うことができます。約1時間前（セットアップを変更せずに）動作し、3回目に（まったく変更せずに）再試行します。

$ 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

更新：

わかった、忘れてくれ。 スワップを再度有効にするのを忘れました...マシンが_本当に_メモリ不足になりました...

Amazon AWS EC2Microインスタンスにデプロイしようとしたときに同じ問題が発生しました。 これらのインスタンスには合計で613MBのメモリしかないため、composerは更新を実行するのに十分なメモリを割り当てることができません。 合計メモリが1.7GBのスモールインスタンスにアップグレードすると、問題が解消されました。

私は同じ問題を抱えています....作曲家は本当にたくさんのメモリを必要としますか？ ：-O

コンポーザー自体ではないと思いますが、とにかく：ec2のマイクロインスタンスには（デフォルトで）スワップメモリ​​がないため、メモリが不足するとOSがプロセスを開始します。 小規模にアップグレードする代わりに（コストがかかるため）より良い解決策は、ファイルベースのスワップを作成することです（少なくとも一時的）

例えば。

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

613Mは非常に少なく、PHPだけが消費するわけではないことを覚えておいてください。 作曲家のせいにすることはできないと思います。 誰かがこの問題を解決できますか？

マイクロインスタンスを使用している人は、composerを更新し、ロックファイルを新しい形式に更新した後、問題が発生することはありません。＃1109を参照してください。 インストール以外でメモリの問題が発生した場合は、＃600を参照してください。

私は再びこの問題に遭遇しています。 これが私のダンプです：

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

プロファイリングを使用してドライランを実行すると、次のmem使用情報が返されます。

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

こんにちは、

推測：これをAWS-microで実行していますか？ スワップはありますか
有効ですか？

よろしく、
セバスチャン

2012/12/20ダン・ホリガン[email protected]

私は再びこの問題に遭遇しています。 これが私のダンプです：

PHPの致命的なエラー：キャッチされない例外「ErrorException」とメッセージ「proc_open（）：フォークに失敗しました-メモリを割り当てることができません」phar：/// vagrant / www / api-v3 / composer.phar / vendor / symfony / console / Symfony / Component /コンソール/アプリケーション。 php：969
スタックトレース：

0 [内部関数]：Composer \ Util \ ErrorHandler :: handle（2、 'proc_open（）：fo ...'、 'phar：/// vagrant ...'、969、配列）

1 phar：///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php（969）：proc_open（ 'stty -a | grep ...'、アレイ、NULL、NULL、NULL、アレイ）

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（969行目）

プロファイリングを使用してドライランを実行すると、次のmem使用情報が返されます。

メモリ使用量：25.95MB（ピーク：67.15MB）、時間：9.21秒

—
このメールに直接返信するか、Gi tHubhttps：//github.com/composer/composer/issues/945#issuecomment-11587234で表示してください。

github.com/KingCrunch

スタックトレースによると、 @ dhorrigan ouchは、例外のレンダリング中に致命的なエラーがトリガーされたようです（proc_openを使用して端末の幅をチェックしているため）。 これはphpのメモリ制限ではなく、マシンのメモリが不足しているように見えるので、他のものをクリアして、より多くのメモリがある別の場所でupdateを実行できる場合は、updateではなくinstallで実行することをお勧めします。 ロックファイルからのインストールは、メモリをほとんど使用しません。

私はこれをVagrantボックスで実行していて、かなり実行されていますが、これは私が初めて見たものです。 より多くのメモリを使用してボックスを再構築し、何が起こるかを確認します。 私がフォローアップします。

正直なところ、67MBはそれほど大きくありません。 失敗した場合にどのように問題になるかはわかりますが、この時代では、数百メガのピークメモリを求めることはそれほど多くありません;）

ええ、問題を見つけました。VMには6MBのmemしかありません（512MBのうち）ので、そうです。 ははは、1GBのメモリを搭載するように拡張しています。 最初にそれをチェックする必要がありました。 続ける。

@Seldaekマイクロインスタンスの容量は590MBで、デフォルトではスワップはありません。 これをいじってみるとうまくいきますが、アプリケーションがもう少し必要になるとすぐに完全に壊れます。 したがって、前述のように、スワップを作成するとこれがキャッチされます:)必要なのは10 MB、つまり20MBだけです。

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

@KingCrungは正しいです。 ここで説明するように、EC2マイクロインスタンスにスワップを追加しまし

現在、依存関係の更新は魅力のように機能します。

@andremahaパーフェクト！ ありがとうございました！！ :)

私もこの問題を抱えています。 4GB MacbookAirで1GBVagrant。 更新を特定のベンダーに制限している場合でも発生します。

PHPの致命的なエラー：キャッチされない例外「ErrorException」とメッセージ「proc_open（）：フォークに失敗しました-メモリを割り当てることができません」phar：/// usr / local / bin / composer / vendor / symfony / console / Symfony / Component / Console / Application 。 php：1033
スタックトレース：

0 [内部関数]：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、配列）

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（）

vagrant hold && vagrant up && vagrant sshを実行してから、再度実行することで解決できます。

メモリ使用量：102.39MB（ピーク：427.97MB）、時間：104.79秒

これで私の問題は解決しましたhttp://cloudstory.in/2012/02/adding-swap-space-to-amazon-ec2-linux-micro-instance-to-increase-the-performance/

@adamsmeatありがとう！ 私はあなたのソリューションを私のDOインスタンスに使用します

@ adamsmeat-ストックロードされた

@adamsmeatは私の命を救い、EC2マイクロインスタンスに512MBのスワップスペースを追加しただけで、問題は解決しました。

私もこの問題に遭遇しました。それはvagrantboxを使用している環境で、初期メモリは512Mでしたが、2048Gに増やした後に問題は解決しました。

Digital Ocean512MBスライスを使用してこの問題が発生しました... https：//github.com/composer/composer/issues/945#issuecomment-8552757にアクセスする必要がありました

ここも同じ@ prodev42

composer.lockをライブサーバーにコピーしてみましたが、動作します。 コマンドで

php composer.phar --verbose install

@paparts composer.lockバージョン管理していないようですね。 経験則として：アプリケーションの場合はバージョン管理し、ライブラリの場合はバージョン管理しないでください。 ライブシステムでupdateを実行しないでください。遅かれ早かれパッケージが届き、ローカルでテストしていなければ、アプリケーションが破損する可能性があります。 composer.lockとcomposer.phar installは、そのバージョンのパッケージが正確にインストールされ、アプリケーションを開発したことを保証します。

使用しているフレームワークが無視リストにcomposer.lockをリストしていることに気づきません

今日、EC2マイクロインスタンスで問題が発生しました。 PHPのmemory_limitを512Mに増やすと、修正されました。

それは良いことでしょうか？ デジタルオーシャンメモリでは512MBしかなく、PHPをそのようなメモリまで消費するようにすると、おそらく独自のVMが実行されます。

ああ、全然。 実稼働サーバーではないことは言うまでもありません。

symfony / event-dispatcherが必要なパッケージをインストールしていたので、上記のエラーのために単一のパッケージをインストールできなくなりました：S

php cli iniでopcache.enable_cliを有効にしたときにこれを取得しました

@ younes0それはかなり漠然とした説明です。 ここで議論全体を読みましたか？ 通常は、かなり小さなクラウドインスタンス（VM）内でスワップを有効にせずにメモリが不足したためです。

私の場合、 @ KingCrunchはメモリ不足とは関係ありませんopcache.enable_cli phpオプションをOn （VM）に設定してcomposerパッケージをインストールしようとすると、 @ yooperによって説明されたエラーが発生し

同じエラー。

私は1GbRAMを搭載したデジタルオーシャンドロップレットを持っています。

php composer.phar updateを開始すると、使用可能なすべてのRAMが消費され、例外がスローされます。

私のcli/php.iniにはmemory_limit = -1ます。

解決策がコンポーザー専用のより大きなRAMを備えたドロップレットにアップグレードすることである場合、ローカルマシンでphp composer.phar updateしてから、ファイルをvpsにアップロードします。

composer.lock含めるだけです

@papartsありがとう、それは動作します。

ローカルマシンでphp composer.phar updateを実行してから、 composer.lockをVPSにアップロードし、 php composer.phar install

@moldcraftもう1つの解決策は、上記のどこかで説明されています。スワップメモリ​​を作成するだけです。これはかなり低速ですが、少なくともOOMエラーを防ぐことができます。

@KingCrunch他の解決策は上記のどこかで説明されています

@yooperが問題の説明を見つけた解決策で更新するといい

ProTip：スワップトリックは、Vagrantで実行されているローカルVirtualBoxVMでも機能します。

ajaxを使用して挿入しようとしましたが、機能しません。エラーは次のとおりです。キャッチされない例外：メモリ不足。
これについては何でも考えます。

@sivagurupr何を言っているのかわかりませんが、この問題とは関係がないと感じています。 Composer（CLI）にはajax機能がありません：confused：ただし、最後とコメントを読んだ後、「メモリ不足」は自明であるはずです：wink：

このコードの間違い...

4時08分PMの木、2015年3月12日には、セバスチャン・クレブス[email protected]
書きました：

@sivagurupr https://github.com/sivaguruprわかりません、あなたは何ですか
話しているのですが、この問題とは関係がないと感じています。
Composer（CLI）にはajax機能がありません[画像::混乱：]
ただし、最後に「メモリ不足」のコメントを読んだ後は、
自明であること[画像::ウィンク：]

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/composer/composer/issues/945#issuecomment-78456750 。

Vagrantマシンにhttp://github.com/sabre/xmlをインストールするときに、この問題が発生しました。 しかし、上記の例を使用してスワッピングを有効にすることで、なんとか修正できました。

同じエラーが発生しますが、インスタンスが大きくなります：4GBのRAMと4GBのスワップ。 使用可能な/キャッシュされたRAMは言うまでもなく、空きRAMが使い果たされることはなく、スワップに影響はありません。

この新しいマシン、CentOS / CloudLinux7.1でcomposerupdateを実行するのは初めてです。

何か案は？ お願いします？

VagrantBoxで同じエラーが発生しました。 エラーが発生したとき、2GBのRAMがありました。 RAMを4GBに拡張すると、機能しました。 しかし、それでもそれがそれほど多くのラムを必要とするのは奇妙です。

この問題が再び発生し、composer.lockの追加が機能しませんでした。 しかし、代わりに、多くのメモリを拡張する代わりに、スワップスペースを使用しようとしました。 digitaloceanに関する記事はかなり気の利いたものですhttps://www.digitalocean.com/community/tutorials/how-to-configure-virtual-memory-swap-file-on-a-vps

私も問題に遭遇しました：

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

memory_limitが-1に設定されています

私のfree出力：

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

私もこの問題を抱えていましたが、PHPのmemory_limitを増やすと問題が解決しました。

私も

memory_limitを-1に設定して同じ問題が発生していました。 私のために働いた唯一のことは私のマシンをリロードすることでした。

Ubuntu14.04でスワップを追加する方法
https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04

この記事は、512MのRAMインスタンスに役立ちました。

[解決済み]これを仮想マシンで実行している場合は、vagranthaltコマンドまたはgracefulstopのいずれかで仮想マシンを停止します。

アプリケーションに応じてRAMサイズを変更します。私の場合、メモリを1024MBに更新しました。
デフォルトは256MBでした。

すなわちそれは働いた

mysql httpdまたはnginxサービスを停止して、再実行してください

Composerを実行する

そしてサービスを再開する

こんにちは@sergiohermes

これは、nginxやmysqlが偶然にその量のメモリを消費した場合にのみ機能し、そのコンポーザーは見逃します。 また、ほとんどの場合、重要なサービスを停止することはおそらく選択肢ではありません。 物理的に、またはスワップパーティション/ファイルの形式で、実際にメモリに投資する必要があります。 それはすべてこのスレッドですでに文書化されています。

とにかく、それは交換する必要のない方法だったと私は理解しています。
最も適切ですが、スワップを作成することです。 間違いなく。
「centos」を見てみると、興味深いリファレンスです。

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

このスレッドを追加すると思います。

ああ、私はスワップを使ってそれを解決します、ありがとう

php.iniファイルからメモリサイズを増やすことでこれを回避できますが、これは間違ったオプションです。 キャッシュを削除してパッケージを再構築することをお勧めします。

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

または、次の方法で実行できます。

/ 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何かを混ぜたと思います

• ファイルを削除してもRAMは解放されません
• これは、PHPのmemory_limitではなく、システム全体の（仮想）メモリに関するものです。 RAMを作成できるini設定はありません。

Vagrantでも同じ問題を解決しました。

Vagrant仮想マシンのメモリを簡単にhttp://www.josheaton.org/increase-memory-vagrant-virtual-machine/
次に、 memory_limitの値を
コンポーザーキャッシュを削除します： sudo rm -R〜 / .composer
そして最後にvagrantreload 。

Vagrantを介して実行されているVirtualBoxでも同じ問題が発生しました。
VBoxRAMを増やすことで修正されました。

構成をvb.memory = 512からvb.memory = 1024

スワップメモリ​​を追加しましたが、問題は解決しました。

スワップメモリ​​が不足しました。これを試してください

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

スワップファイルを追加するには：

新しいスワップファイルのサイズをメガバイト単位で決定し、1024を掛けてブロック数を決定します。 たとえば、64MBのスワップファイルのブロックサイズは65536です。
rootとしてシェルプロンプトで、次のコマンドを入力します。countは目的のブロックサイズと同じです。
dd if = / dev / zero of = / swapfile bs = 1024 count = 65536
次のコマンドを使用してスワップファイルを設定します。
mkswap / swapfile
スワップファイルをすぐに有効にしますが、起動時に自動的には有効にしません。
swapon / swapfile
起動時に有効にするには、/ etc / fstabを編集して次のエントリを含めます。
/ swapfileスワップスワップのデフォルト00
次回システムを起動すると、新しいスワップファイルが有効になります。

新しいスワップファイルを追加して有効にした後、コマンドcat / proc / swapsまたはfreeの出力を表示して有効になっていることを確認します。

ありがとうございました！

ヒント-スワップを追加してもコンポーザーのメモリ不足が解決されない場合/エラーを割り当てることができなかった場合：

• スワップを追加した後、マシンを再起動します。 8Gのスワップを追加した後、composerエラーが消えなかったことがわかりました。 しかし、再起動した後、それは機能しました。
• また、実行中の別のVMをシャットダウンし、タブが多すぎるChromeを閉じました

（16GbRAMを搭載したmacOSX Sierra 10.12.4の開発環境でcomposerを使用しています）。

これは解決されましたか？ Composerをグローバルに更新しました。 さらに、 @ gillera235の提案ごとに1GBのスワップスペースを作成しました。 それでも同じエラーが発生します。 トラブルシューティングするにはどうすればよいですか？

それが役立つ場合は、無料利用枠のマイクロEC2インスタンスを使用しています。

サーバーにcomposer.lockファイルをプッシュして実行します

Composer --verbose install

このように、それは多くのメモリを必要とせず、composer.lockファイルのバージョンに従って更新されたパッケージをインストールするのに超高速でした。

メモリが少ないときに発生します
これらの手順を試してください
1）サービスmysql停止
2）コメントを実行します
3）サービスmysqlの開始

@ sagarshah16 mysqlサービスがない場合はどうなりますか？

実行中のサービスのどれがより多くのメモリスペースを必要とするかを見つけてください。 mysqlでない場合。

ええ、ig updatecomposerは問題を解決するはずです。悲しいことに私はgitbashを介して更新します。 更新すると常に同じエラーがスローされます。 したがって、Windowsユーザーには、必ずcmd.exe 。

先にエラーをヒットします。 EC2マイクロインスタンスのUbuntu16.04にありました。
1Gスワップファイルを追加することで解決しました。

このリンクをたどって問題を解決しました。

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

参照：
http://manpages.ubuntu.com/manpages/xenial/man8/swapspace.8.html

ありがとうJeroenT。Vermeulen

Enthusiasm is the light of knowledge. Unknown author.

O estusiasmo é luz do conhecimento. Autor desconhecido.

この問題は、メモリのオーバーコミットを有効にしないことで悪化する可能性があります。 フォークは、メモリのオーバーコミットなしでは非常に非効率的です。 基本的に、フォークするときは、別の同一のプロセスを作成することにより、現在のプロセスのコミットされたメモリ使用量を2倍にします。 このメモリの多くは親プロセスと子プロセスの間で共有されますが、コピーオンライトであるため、書き込みを行うと共有メモリがコピーされます。 オーバーコミットが有効になっている場合、システムはこの複製された共有メモリを許可しますが、共有メモリに書き込む場合、コピーを処理するのに十分な物理RAMがない可能性があります。 オーバーコミットを無効にすると、システムはそもそもメモリを割り当てることができなくなります。

利用可能な1.4GIGでこのエラーを取得しています...

$ 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

この問題の修正は、インスタンスにスワップ（つまりページング）スペースを追加することです。

ページングは​​、ハードドライブに領域を作成し、それを追加のメモリに使用することで機能します。このメモリは通常のメモリよりもはるかに低速ですが、使用できるメモリははるかに多くなります。

この余分なスペースをインスタンスに追加するには、次のように入力します。

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

1024を超える必要がある場合は、それをより高い値に変更してください。

再起動後にデフォルトで有効にするには、次の行を/ etc / fstabに追加します。

/var/swap.1スワップスワップのデフォルト00

スタックトレースによると、 @ dhorrigan ouchは、例外のレンダリング中に致命的なエラーがトリガーされたようです（proc_openを使用して端末の幅をチェックしているため）。 これはphpのメモリ制限ではなく、マシンのメモリが不足しているように見えるので、他のものをクリアして、より多くのメモリがある別の場所でupdateを実行できる場合は、updateではなくinstallで実行することをお勧めします。 ロックファイルからのインストールは、メモリをほとんど使用しません。

どうもありがとう、 composer updateを実行する代わりに、 composer install 。 それを修正しました！

php.iniのメモリサイズを増やしたり、インスタンスメモリ自体を増やしたりするよりも優れています。

スワップをオンにすると、問題が解決しました。

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

このスレッドに書かれたものを投稿する人は何人いますか？ @jemerocay 、トピックを読んだことがありますか？ 同じことが上記の約10通のメッセージに投稿されています。

寄稿者：これを閉じてください。