Buenos días:
Quería hacer una consulta, puesto que no tengo claro si es normal o tengo algo mal configurado.
Antes de nada, la configuración del entorno:
- Se trata de Windows 7, sobre una máquina virtual VM Ware.
- Como servidor, XAMPP con Apache 2.4.9 y PHP 5.5.11.
La duda en cuestión es referente al comportamiento de Composer al realizar un update, ya que me genera unos ficheros enormes (alrededor de 5GB) en la carpeta tmp/ de XAMPP. Sobre todo en la configuración inicial, que se realizan varios updates, se me queda el disco de la máquina sin espacio en muy poco tiempo. ¿Es normal ésto?
Muchas gracias.
Saludos.
Respuestas
Hay dos cosas que me extrañan mucho en tu pregunta. Primero, es "imposible" que Composer requiera 5 GB para hacer su trabajo (a menos que tengas miles de proyectos complejísimos). Segundo, la caché de Composer no usa por defecto ni el directorio temporal del sistema ni el direcotrio tmp/ de XAMPP.
En este método puedes ver cómo Composer determina el directorio que usar para su caché. En mi caso ese directorio está en ~/.composer/cache/ y "sólo" me ocupa unos 300 MB.
¿Puedes darnos alguna información más sobre los archivos generados en ese directorio tmp/? ¿Son muchos archivos pequeños o pocos grandes? ¿Cómo se llaman? ¿Puedes ver el contenido de alguno de esos archivos?
@javiereguiluz
Buenas tardes:
Acabo de lanzar un update aunque no completo y me ha generado el siguiente fichero sin extensión:
cachegrind.out.1433515890-C__ProgramData_ComposerSetup_bin_composer_phar
El tamaño final ha sido de 4,68 GB
Cuando lanzo un update, genera un fichero enorme y aparentemente uno más pequeño por cada bundle que actualiza.
Otros ficheros tienen nombres (sin extensión) del tipo:
cachegrind.out.1433516605-E__PHP_WF_Proyecto_vendor_sensio_distribution-bundle_Sensio_Bundle_DistributionBundle_Resources_bin_build_bootstrap_php
Los de 5GB soy incapaz de abrirlos, por tamaño, pero otros más pequeños tienen trazas de composer:
version: 1 creator: xdebug 2.2.3 cmd: E:\PHP\WF\Proyecto\web\app_dev.php part: 1 positions: line events: Time fl=php:internal fn=php::in_array 14 0 fl=php:internal fn=php::error_reporting 4 0 fl=php:internal fn=php::error_reporting 4 0 fl=E:\PHP\WF\Proyecto\vendor\composer\autoload_real.php fn=require_once::E:\PHP\WF\Proyecto\vendor\composer\autoload_real.php 1 0 fl=php:internal fn=php::spl_autoload_register 22 0 fl=E:\PHP\WF\Proyecto\vendor\composer\ClassLoader.php fn=require::E:\PHP\WF\Proyecto\vendor\composer\ClassLoader.php 1 0 [...]
No sé si esto aporta algo de claridad. La verdad es que algo bastante molesto, ya no por el tamaño del fichero, que al final he creado una tarea que me lanza un script de limpieza, si no por lo que tarda en hacer un update, que se puede llevar más de 10 minutos.
Muchas gracias.
Saludos.
@jesusjbm
Ya se cuál es el problema: tienes activado el profiler de Xdebug. Este profiler está muy bien para investigar la causa de algún error difícil de depurar. El problema es que si lo dejas activado siempre, te genera archivos gigantescos por cada petición que hagas en una aplicación local o por cada comando PHP que lances en la consola.
La solución consiste en desactivar el profiler de Xdebug. No se si con XAMPP podrás hacer esto visualmente. Si no, busca en el archivo php.ini (o en el propio archivo de configuración de Xdebug si es que lo tiene) la siguiente opción y asegúrate de que su valor sea 0 (en tu caso debe estar puesto a 1):
xdebug.profiler_enable = 0;
Después, reinicia el servidor Apache para que se tengan en cuenta los cambios y ya no deberían generarse esos archivos monstruosos del profiler.
@javiereguiluz
¡Muchas gracias!
Efectivamente era eso.
Un saludo y estoy configurando un par de cosas que me están generando unas dudas, así que dentro de poco lanzaré otra consulta. Muchas gracias de nuevo.
@jesusjbm