Composer: Composer muy lento para leer y escribir archivos de caché
cuando corro
composer update --profile --vvv
Obtengo el siguiente resultado:
https://gist.github.com/tnorthcutt/770ba18a3f3f182354d85b7c80a91fe1
La resolución de dependencia en sí es muy rápida y (en este caso) no se instalan, actualizan ni eliminan paquetes (porque anteriormente ejecuté composer update ). Sin embargo, leer y escribir los archivos de caché parece _extremadamente_ lento.
¿Hay algo que pueda hacer para acelerar esto o para depurar más?
Mi composer.json :
{
"name": "laravel/laravel",
"description": "The Laravel Framework.",
"keywords": [
"framework",
"laravel"
],
"license": "MIT",
"type": "project",
"require": {
"php": ">=5.6.4",
"laravel/framework": "5.3.*",
"laravel/cashier": "~7.0",
"laravel/spark": "*@dev",
"yab/laracogs": "^1.9",
"hashids/hashids": "^1.0",
"barryvdh/laravel-cors": "^0.8.0",
"barryvdh/laravel-debugbar": "^2.2",
"barryvdh/laravel-ide-helper": "^2.1",
"doctrine/dbal": "^2.5",
"spatie/laravel-collection-macros": "^1.4",
"league/csv": "^8.1",
"guzzlehttp/guzzle": "^6.2"
},
"require-dev": {
"fzaninotto/faker": "~1.4",
"mockery/mockery": "0.9.*",
"phpunit/phpunit": "~5.0",
"symfony/css-selector": "3.1.*",
"symfony/dom-crawler": "3.1.*",
"phpmd/phpmd": "@stable",
"spatie/laravel-migrate-fresh": "^1.3"
},
"autoload": {
"classmap": [
"database"
],
"psr-4": {
"App\\": "app/"
}
},
"autoload-dev": {
"classmap": [
"tests/TestCase.php"
]
},
"scripts": {
"post-root-package-install": [
"php -r \"copy('.env.example', '.env');\""
],
"post-create-project-cmd": [
"php artisan key:generate"
],
"post-install-cmd": [
"Illuminate\\Foundation\\ComposerScripts::postInstall",
"php artisan optimize"
],
"post-update-cmd": [
"Illuminate\\Foundation\\ComposerScripts::postUpdate",
"php artisan ide-helper:generate",
"php artisan optimize"
]
},
"config": {
"preferred-install": "dist"
},
"repositories": [
{
"type": "path",
"url": "./spark"
}
]
}
Salida de composer diagnose :
Checking composer.json: WARNING
require.laravel/spark : unbound version constraints (*@dev) should be avoided
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com oauth access: OK
Checking disk free space: OK
Checking pubkeys: FAIL
Missing pubkey for tags verification
Missing pubkey for dev verification
Run composer self-update --update-keys to set them up
Checking composer version: OK
tnorthcutt
Todos 49 comentarios
Parece un problema del entorno, no relacionado con Composer. Nada más que pueda agregar a esto sin saber más sobre la configuración de su sistema (sistema operativo, particiones, uso de VM sí/no, cualquier enlace simbólico en su ruta o no, directorio de inicio cifrado o no, etc.).
alcohol
en 15 mar. 2017
Para que conste, acabo de probar su composer.json en un servidor virtual respaldado por Westmere Xeon con SSD:
[269.9MB/5.05s] Resolving dependencies through SAT
[271.3MB/5.35s] Dependency resolution completed in 0.297 seconds
Tenga en cuenta los 5 segundos, mientras que eso es rápido en el otro extremo de la escala, sus 270 segundos son definitivamente un problema local.
Además: ¿está ejecutando la última versión de Composer, en PHP 7.x? Debe tener en cuenta que PHP 5.6 con Xdebug en una versión antigua de Composer puede ser por sí solo 5 veces más lento que una compilación reciente que deshabilita Xdebug, en PHP 7.1, que suele ser 2 o 3 veces más rápido que PHP 5.6 en el tipo de operaciones. que suceden durante la deserialización de caché.
curry684
en 15 mar. 2017
@ curry684 gracias por la comparación. Estoy ejecutando la versión de Composer 1.4.1 y la versión de PHP 7.0.15 .
@alcohol lo siento, debería haber pensado en agregar más información. Esto está en:
- Barra táctil rMBP 2016 de 13", procesador de 3,1 ghz
- macOS Sierra
10.12.3 - SSD de 512 gb, partición única
- Sin máquina virtual
- Enlaces simbólicos en la ruta: _tal vez_, ver más abajo
- Sin directorio de inicio cifrado (aunque tengo FileVault activado)
Mis $PATH :
/Users/travis/.phpbrew/bin:/Users/travis/go/bin:/usr/local/opt/php70/bin:/usr/local/opt/coreutils/libexec/gnubin:/Users/travis/.yarn/bin:/Users/travis/bin:/Users/travis/.composer/vendor/bin:/Users/travis/dotfiles/bin:/usr/local:/usr/local/sbin:/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Tengo enlaces simbólicos en mi directorio de inicio, pero apuntan _a_ un directorio en mi ruta. El (¿quizás?) relevante:
bin -> /Users/travis/dotfiles/bin
Intenté una instalación separada/nueva de Composer desde la fuente siguiendo las instrucciones en CONTRIBUTING.md , pero eso produjo tiempos sustancialmente idénticos.
¿Alguna otra sugerencia sobre cómo depurar más?
tnorthcutt
en 15 mar. 2017
¿FileVault no cifra su directorio de inicio de forma predeterminada?
alcohol
en 15 mar. 2017
Creo que sí, pero tenía la impresión de que mientras estaba conectado, no afectaba el rendimiento. Ahora lo apago para probar.
_Editar: una búsqueda rápida revela que FileVault probablemente no sea el culpable , pero lo probaré de todos modos._
tnorthcutt
en 15 mar. 2017
También puede intentar mover el repositorio a un directorio que esté fuera de cualquier ruta existente, por ejemplo, /code .
alcohol
en 15 mar. 2017
¿Te refieres al proyecto en el que estoy trabajando o a la instalación de Composer?
tnorthcutt
en 15 mar. 2017
El proyecto en el que estás trabajando. También puede intentar crear /composer y luego asegurarse de que su variable de entorno COMPOSER_HOME esté configurada para apuntar a /composer .
alcohol
en 15 mar. 2017
@tnorthcutt ¿Hay alguna posibilidad de que esté ejecutando la aplicación de ejemplo en un servicio de contenedor?
davidjeddy
en 15 mar. 2017
@davidjeddy ¿Te refieres a algo como Docker? Si es así, no.
tnorthcutt
en 15 mar. 2017
Ok, nueva información para informar. I:
- FileVault desactivado
- Composer instalado desde la fuente en
/composer - Establezca
COMPOSER_HOMEen/composer - Corrió
/composer/composer global require franzl/studio -vvv --profilemientras estaba en/composer - Ejecuté '/composer/composer update -vvv --profile
while in/composer (este paquete simplemente porque lo había estado mirando recientemente)
Salida de 4: https://gist.github.com/tnorthcutt/6b88fb29713baf9d425b626afafb73aa (528,28 segundos)
Salida de 5: https://gist.github.com/tnorthcutt/1db9a4cbdeac8edfb2183b3ebb17a953 (196,55 segundos)
¿Tengo razón en que esto parece _muy_ lento?
tnorthcutt
en 15 mar. 2017
Ahora parece que gran parte de la lentitud está en la descarga de archivos de packagist; otros también están reportando problemas .
Anécdata:
Si wget https://packagist.org/p/provider-latest%242f333ec502b004ca61c6fb3bc4bc1190d623c76fe2ff036e7bd89effb214ca25.json , mi velocidad es de 19,3 KB/s
Si wget https://gist.github.com/tnorthcutt/9cd436dda5a607cd994aaeff3d1ab318/raw/862e2ba6eb3e5fba571e4b7112929b2d12643a74/provider.json (el mismo archivo), mi velocidad es de 604 KB/s.
He confirmado proporciones similares con personas en otras ubicaciones geográficas. Lo que me parece extraño es que mi conexión con Packagist es un orden de magnitud más lenta que con Github, y es el mismo caso para otros, pero la suya es del orden de ~ 900 KB/s de Packagist y ~ 3 MB/s de Github. Así que no es como si estuviera maximizando la posible velocidad de conexión a Packagist en este momento.
tnorthcutt
en 15 mar. 2017
Sí, parece que tenemos un poco de contracción del ancho de banda en la hora pico cuando EE. UU. comienza a funcionar. Trabajando en mejorar las cosas. Te responderé más tarde.
Seldaek
en 16 mar. 2017
Está bien, veremos cómo progresan las cosas, pero ahora tenemos un espejo en vivo en América del Norte. La propagación de DNS debería comenzar lentamente, por lo que supongo que en unas pocas horas, una vez que EE. UU. esté en funcionamiento, podremos evaluar la situación con un poco más de detalle. Por favor reportar cualquier rareza.
Seldaek
en 16 mar. 2017
No estoy seguro de por qué, pero a veces /composer/composer update -vvv --profile da como resultado la descarga de nuevos archivos a la memoria caché y otras veces no. De todos modos, ejecuté ese comando hace un momento y tardó 558,14 segundos en ejecutarse, sin descargar nada: https://gist.github.com/tnorthcutt/a9553be31e79af9e1cadeb59bc1e573e
Estoy completamente desconcertado en cuanto a por qué las lecturas y escrituras de archivos tardan tanto. Me encantaría poder depurar esto más, pero no estoy seguro de cómo en este momento. Cualquier sugerencia sería muy apreciada.
tnorthcutt
en 16 mar. 2017
@tnorthcutt Veo que está usando el complemento de carga Hirak\Prestissimo\Plugin allí, ¿puede perfilar lo mismo sin el complemento? ¿También puede decirnos a qué IP resuelve su DNS packagist.org y dónde se encuentra?
naderman
en 16 mar. 2017
Una pregunta es si va mejor hoy que ayer, pero dado que parece que estás en Australia, supongo que no ayudará tanto como a la gente en los EE. UU. y alrededor.
Seldaek
en 16 mar. 2017
Estoy en Oklahoma, en los Estados Unidos.
traceroute packagist.org :
traceroute to packagist.org (87.98.253.214), 64 hops max, 52 byte packets
1 dsldevice (192.168.1.254) 7.653 ms 11.825 ms 12.931 ms
2 108-220-130-1.lightspeed.okcbok.sbcglobal.net (108.220.130.1) 49.499 ms 29.246 ms 30.032 ms
3 71.147.108.64 (71.147.108.64) 30.002 ms 53.982 ms 32.427 ms
4 * * *
5 12.83.71.73 (12.83.71.73) 400.389 ms
12.83.71.77 (12.83.71.77) 409.175 ms
12.83.71.73 (12.83.71.73) 436.222 ms
6 gar26.dlstx.ip.att.net (12.123.16.85) 431.853 ms 462.154 ms 474.891 ms
7 * * *
8 * * *
9 be100-155.nwk-5-a9.nj.us (198.27.73.29) 98.558 ms 67.636 ms 99.753 ms
10 be100-1298.ldn-5-a9.uk.eu (192.99.146.132) 177.426 ms 204.570 ms
be100-1295.ldn-1-a9.uk.eu (192.99.146.126) 204.755 ms
11 be10-1194.gra-g2-a9.fr.eu (91.121.128.92) 248.548 ms
be10-1193.gra-g1-a9.fr.eu (91.121.128.90) 237.393 ms
be10-1194.gra-g2-a9.fr.eu (91.121.128.92) 205.076 ms
12 vl21.gra-g1-a75.fr.eu (213.251.128.43) 204.071 ms 143.825 ms *
13 be50-7.gra-3a-a9.fr.eu (37.187.231.88) 181.233 ms 248.780 ms
be50-7.gra-3b-a9.fr.eu (37.187.231.92) 201.475 ms
14 eu.packagist.org (87.98.253.214) 244.092 ms * 230.853 ms
@tnorthcutt ok, es de esperar que obtenga mejores resultados una vez que se vuelva a cargar su caché de dns, ese es el packagist.org francés al que se está conectando.
naderman
en 16 mar. 2017
Puede intentar codificar packagist.org a 144.217.203.53 en su archivo de hosts para probarlo ahora, pero asegúrese de eliminarlo nuevamente más tarde, ya que la IP puede cambiar sin previo aviso.
Seldaek
en 16 mar. 2017
Lo tengo, le daré una oportunidad codificada.
Sin embargo, ¿alguna idea sobre las lecturas y escrituras de archivos súper lentas? Una actualización tarda casi 10 minutos sin descargas 😕
tnorthcutt
en 16 mar. 2017
@tnorthcutt como dije, intente sin el complemento, ya que no estoy seguro de que esté informando con precisión lo que está demorando con las descargas en paralelo.
naderman
en 16 mar. 2017
@naderman oh, lo siento, quise mencionar que lo estoy intentando sin eso, solo está tomando un tiempo 😬
tnorthcutt
en 16 mar. 2017
Las lecturas/escrituras de caché lentas, lo más probable es que sea solo una impresión que tiene de la salida, porque no sale cuando la CPU está procesando cosas.
Seldaek
en 16 mar. 2017
@Seldaek Lo tengo. ¿Te parece una cantidad de tiempo normal?
tnorthcutt
en 16 mar. 2017
No hay 10 minutos definitivamente en el lado largo de las cosas. Estoy investigando otros factores además de la red (que definitivamente fue un problema y espero que las cosas mejoren, pero puede que no sea la única causa para ti).
Seldaek
en 16 mar. 2017
@naderman aquí hay una repetición sin Prestissimo: https://gist.github.com/tnorthcutt/2f41f421198b88329c64a52d0730a8b1
Tiempo total 138,15 s, por lo que es una gran mejora. También volví a ejecutar un traceroute justo después y sigo presionando 87.98.253.214 .
tnorthcutt
en 16 mar. 2017
@tnorthcutt TTL en ese registro DNS fue un día, por lo que puede demorar algunas horas
naderman
en 16 mar. 2017
Acabo de vaciar mi dns y ahora obtengo 144.217.203.53 .
Sin embargo, no parece estar mejorando drásticamente las velocidades de descarga (actualmente se está ejecutando composer udpate ). Por ejemplo, wget http://packagist.org/p/provider-2015%2419f785235d2cb13e2b2aa2a23244e050b64cf79d7387d678b20088406c571053.json todavía me da ~13 KB/s, mientras que wget a un archivo de tamaño similar en Github obtiene ~1 MB/s.
Además de las bajas velocidades de la red, ¿hay alguna forma de que pueda diagnosticar mejor mis problemas solo locales? No estoy seguro de cómo proceder ya que tengo una instalación nueva de Composer, un nuevo conjunto COMPOSER_HOME , etc.
tnorthcutt
en 16 mar. 2017
@tnorthcutt ¿Ya no veo ningún problema local per se en ese archivo de registro? ¿Puedes enviar otra ruta de rastreo?
naderman
en 16 mar. 2017
traceroute to packagist.org (144.217.203.53), 64 hops max, 52 byte packets
1 dsldevice (192.168.1.254) 8.286 ms 8.449 ms 4.865 ms
2 108-220-130-1.lightspeed.okcbok.sbcglobal.net (108.220.130.1) 89.297 ms 28.015 ms 28.277 ms
3 71.147.108.64 (71.147.108.64) 34.490 ms 32.461 ms 33.858 ms
4 * * *
5 12.83.71.77 (12.83.71.77) 28.156 ms
12.83.71.73 (12.83.71.73) 32.521 ms
12.83.71.77 (12.83.71.77) 31.109 ms
6 gar26.dlstx.ip.att.net (12.123.16.85) 37.299 ms 41.726 ms 38.924 ms
7 * * *
8 * * *
9 be100-104.nwk-1-a9.nj.us (192.99.146.253) 567.632 ms
be100-155.nwk-5-a9.nj.us (198.27.73.29) 542.429 ms 555.572 ms
10 be10-1037.bhs-g1-a9.qc.ca (192.99.146.99) 515.780 ms 569.876 ms 547.976 ms
11 * vl21.bhs-g1-a75.qc.ca (198.27.73.63) 137.918 ms
vl21.bhs-g2-a75-lo2.qc.ca (198.27.73.91) 189.143 ms
12 be50-5.bhs-3a-a9.qc.ca (198.27.73.92) 464.066 ms 418.524 ms
be50-7.bhs-3b-a9.qc.ca (198.27.73.98) 98.177 ms
13 ca.packagist.org (144.217.203.53) 86.854 ms 129.686 ms 183.286 ms
Tiene razón, no hay problemas solo locales en la última ejecución: https://gist.github.com/tnorthcutt/538b77aa8bde471114686f074762a012
Puede que me falte una comprensión fundamental de cómo funciona Composer, pero a veces descarga muchos archivos (como en esa ejecución) y otras veces no descarga casi nada. Creo que el patrón es que en las ejecuciones cuando no se descarga mucho, las lecturas/escrituras locales son muy lentas. Aunque no puedo decir eso con seguridad.
tnorthcutt
en 16 mar. 2017
@tnorthcutt hizo un poco de limpieza en las cosas iluminadas... no entraré demasiado en detalles aquí, pero de todos modos eso debería acelerar las cosas aún más.
Seldaek
en 16 mar. 2017
Parece que todo va bien hasta ahora, así que cierro esto https://twitter.com/packagist/status/842441015839608833
Seldaek
en 16 mar. 2017
@Seldaek gracias! Mirror es mucho, mucho más rápido.
tnorthcutt
en 16 mar. 2017
A mi siempre me va muy lento, intenté buscar por todos lados sin mucho éxito. No puedo identificar cuál es el culpable, la descarga es lenta la mayor parte del tiempo, pero a veces no parece haber ninguna actividad de red o CPU para ese asunto y el compositor simplemente permanece allí.
Normalmente es lento, hoy es súper súper lento... tal vez sea algo temporal.
-v cuelga de Writing /Users/ariel/.composer/cache/repo/https---packagist.org/packages.json into cache pero eso no debe llevar tanto tiempo.
Estoy ejecutando 1.4.2 y PHP 7.0.18, sin contenedor, OSX 10.12.5, unidad SSD, FileVault habilitado. ¿Alguna ayuda aquí?
hanoii
en 23 may. 2017
@hanoii ver https://github.com/composer/composer/issues/6342
stof
en 23 may. 2017
Este problema todavía existe para mí, y ninguno de los problemas planteados en este problema no resuelve mi problema.
NabiKAZ
en 16 dic. 2017
Sí, el compositor ha sido súper súper lento hoy en día :( ¿qué sucedió realmente aquí? Aquí hay un registro cuando intenté instalar un solo paquete:
[6.5MB/394.61s] Downloading https://packagist.org/p/provider-2013%241e6878bf2b5d94a5e3cb2e852c378b6e41db311b4a339875ab02c22dedf4a221.json
[ErrorException]
zlib_decode(): data error
EDITAR: no importa, esto fue un problema de conexión. Cambié mi conexión y funciona bien aunque todavía un poco lento.
angganegara
en 19 dic. 2017
mismo problema en la arquitectura docker (contenedor php 1GB ram y 4 cores)
juanantoniomosquera
en 1 ago. 2018
@juanantoniomosq ¿estás en OSX? Si es así, el rendimiento de lectura/escritura del archivo es un problema de Docker.
https://blog.docker.com/2017/05/user-guided-caching-in-docker-for-mac/ por ejemplo.
davidjeddy
en 2 ago. 2018
@davidjeddy no, env de linux.
juanantoniomosquera
en 3 ago. 2018
Ah, interesante; ¿Cuál es la salida de un traceroute?
davidjeddy
en 3 ago. 2018
He estado luchando con la velocidad de Composer desde hace un par de semanas. Primero pensé que tenía algo que ver con mi entorno, pero hoy también he tenido problemas de velocidad en un entorno completamente diferente. Ejecutar Composer usando Docker o ejecutarlo en un host Linux no hace ninguna diferencia en términos de velocidad. Si ejecuto composer update , lee una tonelada de archivos del caché. A veces lo descarga y luego lo escribe en la carpeta de caché. Procesar cada 10 archivos tarda aproximadamente 1 o 2 segundos. Sumando al menos un minuto. He proporcionado un registro de composer update si eso podría ser de alguna ayuda.
https://gist.github.com/pascal08/c9cdfc476b09a468989e9b95f4831671
pascal08
en 21 ago. 2018
Mi problema se resolvió usando el último kernel de CentOS (antes de usar el kernel de elrepo).
juanantoniomosquera
en 3 sept. 2018
Lentitud para mí en la ventana acoplable
````
el compositor requiere zendframework/zend-inputfilter -vvv --profile
[7.7MB/0.00s] Cargando repositorios de compositores con información del paquete
[7.9MB/0.01s] Descargando https://repo.packagist.org/packages.json
[7.9MB/0.20s] Escribiendo /root/.composer/cache/repo/https---repo.packagist.org/packages.json en caché
[8,0 MB/0,21 s] Actualización de dependencias (incluido require-dev)
[8.1MB/0.21s] Leyendo /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2013.json desde caché
[12.1MB/1.01s] Leyendo /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2014.json desde caché
[20.3MB/4.37s] Leyendo /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2015.json desde caché
[33.3MB/12.09s] Leyendo /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2016.json desde caché
[52.6MB/25.94s] Leyendo /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2017.json desde caché
[69.9MB/35.49s] Leyendo /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2017-10.json desde caché
[76.4MB/40.08s] Leyendo /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2018-01.json desde caché
[91.4MB/47.77s] Leyendo /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2018-04.json desde caché
[102.3MB/56.47s] Descargando http://repo.packagist.org/p/provider-2018-07%24bd48a4a312894b4b8c944cab441fe479f3ce547c949cf6e4c22546ff6a399f90.json
[119.5MB/62.95s] Escribiendo /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2018-07.json en caché
[115,8 MB/63,43 s] Leyendo /root/.composer/cache/repo/https---repo.packagist.org/p-provider-archived.json desde la memoria caché
[115.6MB/63.70s] Descargando http://repo.packagist.org/p/provider-latest%2486b0f858d808d6a10b6f375c1e3842bfce12a7b84ca118737c1bf77bbcd42d4f.json
[122,7 MB/65,42 s] Escritura de /root/.composer/cache/repo/https---repo.packagist.org/p-provider-latest.json en caché
.....
[448,1 MB/271,58 s] Uso de memoria: 448,11 MB (pico: 498,2 MB), tiempo: 271,58 s
````
Tampoco estoy seguro de cuánta memoria debe comer el compositor, pero 500 MB suena demasiado para instalar una dependencia.
svycka
en 20 sept. 2018
Lentitud para mí en la ventana acoplable
composer require zendframework/zend-inputfilter -vvv --profile [7.7MB/0.00s] Loading composer repositories with package information [7.9MB/0.01s] Downloading https://repo.packagist.org/packages.json [7.9MB/0.20s] Writing /root/.composer/cache/repo/https---repo.packagist.org/packages.json into cache [8.0MB/0.21s] Updating dependencies (including require-dev) [8.1MB/0.21s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2013.json from cache [12.1MB/1.01s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2014.json from cache [20.3MB/4.37s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2015.json from cache [33.3MB/12.09s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2016.json from cache [52.6MB/25.94s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2017.json from cache [69.9MB/35.49s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2017-10.json from cache [76.4MB/40.08s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2018-01.json from cache [91.4MB/47.77s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2018-04.json from cache [102.3MB/56.47s] Downloading http://repo.packagist.org/p/provider-2018-07%24bd48a4a312894b4b8c944cab441fe479f3ce547c949cf6e4c22546ff6a399f90.json [119.5MB/62.95s] Writing /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2018-07.json into cache [115.8MB/63.43s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-archived.json from cache [115.6MB/63.70s] Downloading http://repo.packagist.org/p/provider-latest%2486b0f858d808d6a10b6f375c1e3842bfce12a7b84ca118737c1bf77bbcd42d4f.json [122.7MB/65.42s] Writing /root/.composer/cache/repo/https---repo.packagist.org/p-provider-latest.json into cache ..... [448.1MB/271.58s] Memory usage: 448.11MB (peak: 498.2MB), time: 271.58sTampoco estoy seguro de cuánta memoria debe comer el compositor, pero 500 MB suena demasiado para instalar una dependencia.
problema de host del kernel probablemente ...
juanantoniomosquera
en 20 sept. 2018
PC reiniciada y reconstrucción de la imagen de la ventana acoplable ahora
[330.7MB/6.22s] Memory usage: 330.71MB (peak: 383.52MB), time: 6.22s
así que tal vez tenías razón
svycka
en 20 sept. 2018
@juanantoniomosquera @svycka gracias! me salvas el dia!
mismo problema, reinicie la PC y funciona bien de nuevo.
rvitaliy
en 20 may. 2020
Temas relacionados
indomtrading
·
3Comentarios
finwe
·
3Comentarios
bkrukowski
·
3Comentarios
ghost
·
3Comentarios
francoispluchino
·
3Comentarios
Comentario más útil
Este problema todavía existe para mí, y ninguno de los problemas planteados en este problema no resuelve mi problema.