Sto cercando di utilizzare la finestra mobile beta su OSX, principalmente per lo sviluppo di Symfony ma i volumi montati sono incredibilmente lenti. Anche per un progetto Symfony vanill ho tempo di caricamento della pagina 6s. È insopportabile! Qualcuno ha trovato una soluzione a questo problema? Cercando di allontanarmi dal vagabondo ma non riesco proprio a trovare un modo ragionevole di lavorare con la finestra mobile.finestra mobile su volumi lenti OSX
risposta
a quanto pare c'è una soluzione in questo momento:
https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/48 https://forums.docker.com/t/how-to-speed-up-shared-folders/9322/15
I volumi normali devono essere veloci. Ma non è possibile modificare nulla per renderli più veloci se non si desidera modificare il formato del disco.
Ma forse il collo di bottiglia è la CPU o la RAM. È possibile verificarlo con il comando docker stats
. Questi sono di default impostati su 2 core e 2 GB di RAM. Puoi cambiarlo in Docker per Mac GUI.
There's a long thread with explanation from Docker Team e varie soluzioni alternative.
Attualmente, the issue is being tracked on GitHub.
Mentre alcuni workaround potrebbero essere migliori di altri, temo che l'opzione ideale per il momento sia passare a Linux.
Ho avuto esattamente la stessa cosa. Per me l'uso di docker-bg-sync (see on GitHub) ha apportato un notevole miglioramento in termini di velocità e utilizzo della CPU.
Non è bello quanto basta montare il volume poiché è necessario avviare un nuovo contenitore per ogni sincronizzazione, ma fa il lavoro.
Ho trascorso molto del mio tempo a cercare soluzioni valide. E ho trovato. d4m-nfs consentono di utilizzare i volumi della finestra mobile tramite nfs. Nel mio caso ha dato un aumento delle prestazioni 16 volte! (1.8sec vs ~ 30sec)
anche d4m-NFS ha un manuale piuttosto complicato, ecco un altro link con esempio dettagliato: https://github.com/laradock/laradock/issues/353#issuecomment-262897619
Ho appena lascio questo qui per altri Googler.
Questo sembra promettente. Mi chiedo se c'è qualche TL, DR che dice se è possibile ottenere un semplice 'docker run --rm -v' oneliner ie per gli usi' mvn install'/'grunt build' – ciekawy
Ricevo un errore cercando di seguire le istruzioni puoi spiegare passo dopo passo cosa hai fatto per risolvere questi problemi? –
Il mio errore era il seguente, ERRORE: per dbdev Impossibile avviare il servizio dbdev: Supporti negati:/docker-per-mac/osxfs/# namespace per maggiori informazioni. . /distribution/db_data_dev non è condiviso da OS X e non è noto a Docker. È possibile configurare percorsi condivisi da Docker -> Preferenze ... -> Condivisione file. Vedere https://docs.docker.com ERRORE: si sono verificati errori durante l'avvio del progetto. –
Ok, l'utente Spiil ha dato una soluzione, ma volevo elaborare i passaggi esatti da prendere da quando ho passato 12 ore cercando di capirlo, ma una volta che sai come è super facile e risolve tutti i problemi di rallentamento!
La chiave qui è capire che questa soluzione crea unità NFS (Network File System) come mezzo di comunicazione dai Docker Containers al Mac invece del file system OSX standard che al momento è molto lento a causa di bug o come funziona *
Seguire esattamente questi passaggi.
1.) Clona questo repository qui (https://github.com/IFSight/d4m-nfs) nella tua home directory. Per fare questo aprire terminale e digitare cd ~
quindi digitare git clone https://github.com/IFSight/d4m-nfs
alternativa si può anche fare questo in un unico rivestimento git clone https://github.com/IFSight/d4m-nfs ~/d4m-nfs
2.Successivamente, andare nella cartella d4m-nfs e creare un nuovo file nella cartella/etc e denominarlo d4m-nfs-mounts.txt
3.) Aggiungere le seguenti righe di codice a questo.
/Users/yourusername:/Users/yourusername:0:0
Che quanto sopra non fa altro che consente di utilizzare ancora le cartelle relativi con finestra mobile-composizione e permette tutte le porte per la connessione su di esso da qui il 0: 0.
EDIT Non mettere/volumi qui !!
4.) Vai le preferenze della finestra mobile e procedere come segue
Assicuratevi solo/tmp sta mostrando e nient'altro. Voglio dire nient'altro non funzionerà se c'è qualcos'altro dato che creerà conflitti con i sistemi NFS che lo script farà per te in seguito. Riavvia la finestra mobile e la finestra mobile: componi anche tutti i contenitori.
5.) Infine spostarsi nella directory d4m-nfs creata nel passaggio 1 e digitare il seguente comando, /bin/bash d4m-nfs.sh
modifica Il modo corretto per digitare il comando precedente è presente come un altro utente dal github (if-kenn) ha sottolineato, ./d4m-nfs.sh
che usa lo Shebang per quale shell deve eseguirlo.
Se eseguito correttamente, non dovrebbero esserci errori e questo dovrebbe funzionare. Nota: NON ESEGUIRE come sh d4m-nfs.sh questo creerà degli errori e dovrai cancellare il file delle esportazioni per ricominciare. Infatti ogni volta che apporti delle modifiche, dovrai cancellare il tuo file di esportazione.
Questo è il mio aspetto.
EDIT :: IMPORTANTE - Rimuovere il/privato e volumi! Questo dovrebbe essere solo utenti/nome utente ora!
Se vedete qualcosa di diverso da questo non stavate correndo con bash. È possibile accedere rapidamente al file delle esportazioni come questo in Mac se si commettono errori e basta cancellarlo per ricominciare.
Basta selezionare Vai alla cartella
e quindi digitare /etc/exports
Questo è un bel scorciatoia per ottenere rapidamente ad esso e cancellarlo nel vostro editor di testo preferito.
Assicurarsi inoltre che nessun contenitore sia in esecuzione o si otterrà il ciclo ........ di morte. Se questo ciclo di morte continua, assicurati di aggiornare la finestra mobile e quindi riavvia il computer. Si ricomincia ... sembrava essere l'unico modo per farlo funzionare sul mio computer degli amici. Fare riferimento a questo (https://github.com/IFSight/d4m-nfs/issues/3)
Nota per .... ciclo. Di recente ho trovato un'altra soluzione. Assicurati di NON essere registrato come root e assicurati di aver estratto il repository git nella cartella ~ degli utenti, non nella cartella root ~.In altre parole, dovrebbe essere in Utenti/nome utente.
Inoltre, assicurarsi che la cartella/tmp disponga di autorizzazioni di scrittura complete poiché lo script deve scrivere qui altrimenti non funzionerà. chmod 777 -R /tmp
6.) Se lo si è fatto correttamente durante l'esecuzione dello script, sarà simile a questo.
Poi basta eseguire il finestra mobile-up comporre -d come al solito nella cartella del progetto symfony (o qualunque progetto che si sta utilizzando con finestra mobile) e tutto dovrebbe funzionare ... tranne bassi NO MORE lenti !
È necessario eseguire questa operazione ogni volta che si riavvia il computer o la finestra mobile.
Inoltre, se si verificano errori di montaggio, probabilmente non si ha il progetto archiviato nella directory Utenti/nome utente. Ricorda che è dove l'abbiamo montato. Se il tuo progetto è diverso da lì, dovrai modificare di conseguenza il file d4m-nfs-mounts.txt.
Altro Info:
Solo una domanda veloce, questa soluzione è più veloce della soluzione qui? Https: //forums.docker.com/t/how-to-speed-up-shared-folders/9322/15 Pensavo di poter usare il migliore :) Qualsiasi suggerimento sarebbe utile – AshwinKumarS
Sì, perché in pratica si sta utilizzando l'approccio alla cartella condivisa –
Salvato la mia vita, grazie mille @JosephAstrahan – thiagotonon
Per le persone la lettura di questo ora, forse è meglio aspettare Docker per risolvere questo problema. Una richiesta pull è già stata accettata per migliorare le prestazioni (https://github.com/docker/docker/pull/31047). Questo sarà pubblicato da qualche parte ad aprile 2017 e dovrebbe essere un grande miglioramento.
Ho provato alcuni rimedi per Docker per Mac, ma tutti avevano alcuni svantaggi piuttosto grandi, per lo più in usabilità. Una buona fonte per le alternative di OSXFS può essere trovata a: https://github.com/EugenMayer/docker-sync/wiki/Alternatives-to-docker-sync. Crediti per Eugen Mayer per averlo impostato.
EDIT: Il primo miglioramento è implementato nella release edge. https://github.com/docker/for-mac/issues/77 ha più informazioni su questo.
Nella più recente finestra mobile 17.06.0-ce-mac18 volumi montati con: cache sembra funzionare abbastanza bene.
Non penso. Utilizzo la finestra mobile 17.06.0-ce-mac18 (18433) per un'applicazione Ruby on Rails. Ma la velocità fa ancora schifo. –
ma hai montato i volumi con: cache? Devi modificare il file docker-composer.yml o passare cli. Ho provato con vanilla Symfony3 e la velocità della pagina è di circa 200ms che è molto meglio di 6s :) – Viorel
Ho i volumi 'cache 'di' volumi: -.:/Nome_progetto: cache' ma sembra non funzionare. Comunque la velocità è lenta. Una pagina web richiede molto tempo per essere caricata. –
Ho scoperto che la creazione di una macchina virtuale CoreOS sotto Parallels, quindi l'uso della Docker che si trova all'interno di CoreOS è molto più veloce di Docker per Mac (attualmente con la versione 17.12.0-ce-mac49 (21995)).
Sto facendo build di codice Linux utilizzando CMAKE/Ninja/GCC ed è quasi due volte più veloce della stessa build di Docker per Mac.
Nel mio caso, ho un sacco di fonti di libreria che fanno parte del contenitore (ad esempio Boost, OpenSSL) e una quantità decente di codice C++ che tengo locale al mio Mac.
Questo sembra essere uno sviluppo recente. Docker/Mac è diventato molto più lento di quanto mi ricordi di essere un mese o due fa. Forse sono solo io ...
Beh, non è nemmeno vicino alla velocità nativa. Eseguendo un semplice benchmark i volumi montati sono circa 15 più lenti dei nativi. Non penso che CPU o RAM siano il collo della bottiglia, poiché questo accade solo quando utilizzo volumi montati. Se inserisco l'intera base di codice nel contenitore, ottengo la velocità del metallo. L'utilizzo della CPU o della RAM è molto più basso rispetto a quando utilizzo una VM. – Viorel
Sì, che con la velocità nativa è con linux, con lo stesso formato e senza hypervisor. Ma i volumi di Docker per Mac sono più veloci di VM – Julian
Più veloce di VM con nfs?Con i volumi NFS montati per una pagina di app symfony di vanilla, il tempo di caricamento in una VM è di circa 60 ms anziché di 6 con docker beta. – Viorel