Blog

Using Composer in AWS OpsWorks + micro instances

I have a very simple recipe that downloads composer.phar and installs all the dependencies for the package. While testing this recipe I ran into an a memory issue.


$sudo php composer.phar install
Loading composer repositories with package information
Installing dependencies
- Installing symfony/event-dispatcher (dev-master 4b34aad)
PHP Fatal error:  Uncaught exception 'ErrorException' with 	message 'proc_open(): fork failed - Cannot allocate memory' in phar:///srv/www/my_application_name/releases/20130603234158/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php:975
Stack trace:
#0 [internal function]: Composer\Util\ErrorHandler::handle(2, 'proc_open(): fo...', 'phar:///srv/www...', 975, Array)
...

A quick online search will revealed that composer memory issues while running small VMs is a common problem. I even had this issue in a local VM.

The simplest fix is to add more memory, but this could be a costly solution.

In my case I addressed the problem by doing the following two things:

  • Ensure that the composer.lock file is part of the repository and/or it uses a new format
  • Add Memory Swap to the EC2 Instance

Articles [1] and [2] in the references below describe how to add Memory Swap to address this issue. But memory swap all by itself will not help if the lock file is not present or has an outdated format. See here for more info.

It is also likely that new instances added to the OpsWorks layer will fail starting up because of the same issue. In this case you can create a new recipe to add swap on startup. This may be important if you have time based or load based instances.

References

  1. Adding Swap to any EC2 Instance
  2. Symfony2, Composer, Capifony and an EC2 Micro instance
  3. ErrorException: proc_open(): fork failed - Cannot allocate memory in phar