昨日、Composerを使用してLaravel 4プロジェクトの1つに_aws/aws-sdk-php
_をインストールしようとしましたが、イベントのチェーンを正確に思い出せませんが、正常にインストールされませんでした。それ以来、Composerのメモリが不足しているというエラーが表示されています--Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 32 bytes) in phar:///usr/local/bin/composer/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52
。
Php.ini _memory_limit
_を-1に増やしましたが、これは開発環境と実稼働環境の両方で引き続き発生します(実稼働はCent OS 6です)。 _memory_limit
_を実行するときにCLIを介して_composer_update
_を増やすと、インストールは正常に完了しますが、それは永遠にかかります。
メモリ不足のためにComposerを防ぐためにクリアする必要があるある種のキャッシュはありますか? composer updateを実行するたびに、AWSSDKをインストールしようとしているように感じます。
コンポーザーファイル
_{
"name": "laravel/laravel",
"description": "The Laravel Framework.",
"keywords": ["framework", "laravel"],
"license": "MIT",
"require": {
"laravel/framework": "4.0.*",
"rtablada/package-installer": "dev-master",
"mogreet/mogreet-php": "dev-master",
"twilio/laratwilio": "dev-master",
"balloon/elephant.io": "dev-master",
"facebook/php-sdk": "dev-master",
"way/generators": "dev-master",
"codesleeve/asset-pipeline": "dev-master",
"natxet/CssMin": "dev-master"
},
"autoload": {
"classmap": [
"app/commands",
"app/controllers",
"app/models",
"app/database/migrations",
"app/database/seeds",
"app/tests/TestCase.php",
"app/libraries"
]
},
"scripts": {
"post-install-cmd": [
"php artisan optimize"
],
"pre-update-cmd": [
"php artisan clear-compiled"
],
"post-update-cmd": [
"php artisan optimize"
],
"post-create-project-cmd": [
"php artisan key:generate"
]
},
"config": {
"preferred-install": "dist"
},
"minimum-stability": "dev"
}
_
編集:先に進む前に、常に最新バージョンのコンポーザーを実行していることを確認してから、composer self-update
を介して更新できます。
composer update
を実行すると、各ライブラリ(または最新リリース)の最新のgitrefが計算され、そのバージョンのライブラリがインストールされます。次に、これらのバージョンをcomposer.lock
ファイルに保存します。
composer install
を実行すると、composer.lock
ファイルで定義されているバージョンがインストールされるだけです。
composer update
に非常に時間がかかり、大量のメモリを使用する理由は、すべてのライブラリのバージョンをトレースし、composer.json
で定義したバージョンと比較して、そのライブラリのすべての依存関係を確認する必要があるためです。これは非常に集中的なプロセスです。
composer hhvm
を使用して(インストールできます ここ ))実行すると、composer update
プロセスが大幅に高速化されます。
それを除けば、メモリ使用量が多い状態で生活し、php.ini
ファイルでそれを増やす必要があります。 CLIに関連するものを必ず更新してください。
編集:実稼働環境でcomposer update
を実行しないでください。開発中のみ依存関係を更新し、composer install
を使用して、本番環境にいるときに最後に使用したcomposer依存関係のセットをインストールする必要があります。
現時点では、Composerにバグがあり、メモリが使い果たされています。
もしあなたがそうするなら
composer install
次に、ベンダー内のフォルダーを削除します
rm -rf vendor/laravel
そして、やります
composer update
このエラーが発生します。これはバグであり、メモリが不足することは想定されていません。
今のところ、次のようにして自分で修正できます。
php -d memory_limit=-1 /usr/local/bin/composer update
また、チェックしてください このスレッド 、彼らはこれを修正しようとしています。
これを試して。それは私の問題を修正しました。私はメモリを更新するよりもそれを修正するためのより良い方法を推測します。
Sudo composer self-update
簡単です。次のコマンドを入力します。
rm -rf vendor/
rm -rf composer.lock
php composer install --prefer-dist
低メモリマシンまたは他のメモリの問題で動作するはずです
これほど多くのメモリを消費していた理由は、パッケージとreplaceキーワードを処理するときのComposerの動作によるものです。
Replaceの背後にある考え方は、2つのことを実行できるようにすることでした。
標準ライブラリバージョンを独自のバージョンに置き換えます。例えば'symfony/yaml'に例が見つかった場合は、フォークしてバグを修正し、「nightmicu/yaml」というパッケージとしてリリースできます。次に、composer "nightmicu/yaml"が "symfony/yaml"を置き換えることを伝えることができます。その後、 "symfony/yaml"に依存する他のパッケージをインストールすると、 "nightmicu/yaml」。
これにより、パッケージを単一のコンポーネントとしてだけでなく、完全なライブラリとしてリリースすることもできます。 symfonyフレームワークパッケージは、その各コンポーネントパッケージを置き換えます。
問題は、最大約1時間前のreplaceキーワードが、Packagist全体でグローバルに機能していたことです。
これは、フォークされて名前が変更された人気のあるライブラリの場合、インストールできるバージョンが大量にあることを意味します。これが大量のメモリ使用量を引き起こし、処理に長い時間がかかっていた原因です。
最新バージョンのcomposer.pharを入手した場合は、ルートcomposer.jsonで指定されたパッケージのみを操作することで、「replace」の動作が異なるため、より良いはずです。つまり、composer.jsonでパッケージを明示的に使用する必要があります。自分でテストすることはできませんでしたが、交換可能にするか、交換品として機能させることです。
私もこれに遭遇しましたが、brew
を使用しています。
composer --version
brew info composer
brew upgrade composer
...
==> Upgrading 1 outdated package:
composer 1.9.0 -> 1.9.2
==> Upgrading composer
...
それでも私のcomposer require drupal/environment_indicator
は修正されませんでした
他の人が言及したphpメモリ制限を使用して、これを最終的に修正しました。
php -d memory_limit=-1 `which composer` require drupal/environment_indicator
Windowsでこれを修正する最も簡単な方法は次のとおりです。
Goto:C:\ ProgramData\ComposerSetup\bin
編集composer.bat
次のように変更します。
@ECHO OFF
php -d memory_limit=-1 "%~dp0composer.phar" %*
ファイルを保存して実行します。
作曲家の自己更新