# [TIP] velocizzare emerge sync con cdb

## =DvD=

Visto che sul forum italiano pare che non se ne parli posto questo link al forum anglico:

https://forums.gentoo.org/viewtopic-t-261580.html

https://forums.gentoo.org/viewtopic.php?t=202050

----------

## .:deadhead:.

Il sunto del 3d su cdb:

- come far convivere cdb e eix

- perchè una soluzione del genere non diventerà mai la soluzione di default su gentoo

----------

## zolar czakl

Consigliato a chi utilizza il portage compresso con splashfs https://forums.gentoo.org/viewtopic-t-378081-highlight-portage.html

(e' piu' veloce di un sync tradizionale nonostante i rallentamenti introdotti).

ps. sottolineo la raccomandazione di fare il backup prima di fare esperimenti.  :Rolling Eyes: 

----------

## funkoolow

salve,

ho fatto un emerge sync dopo neanche troppo tempo e mi sono ritrovato a far fare un lavoro al mio portatilino di ben 45 minuti, al che ho cercato in giro qualche spiegazione trovando in risposta questo comodo tip che sto testando senza problemi:

http://gentoo-wiki.com/TIP_speed_up_portage_with_cdb

lo segnalo perchè ho visto che tra i tip dei post utilissimi non è elencato, non so se a qualcuno potrà interessare  :Smile: 

ciao a tutti

----------

## Ic3M4n

e funziona?

----------

## ProT-0-TypE

Qua ne avevano già parlato

----------

## randomaze

 *ProT-0-TypE wrote:*   

> Qua ne avevano già parlato

 

Grazie, faccio il merge (e cambio il titolo al posto originario, quello di questo topic chiarisce decisamente meglio la cosa!)

----------

## funkoolow

ops scusate, non avevo visto il post precedente  :Embarassed: 

----------

## gutter

 *Ic3M4n wrote:*   

> e funziona?

 

Ne ho sentito parlare molto bene, ma non l'ho mai provato direttamente.

Sarei curioso di sentire dei commenti da qualcuno che ha fatto delle prove.

----------

## Luca89

Tempo fa avevo notato che l'aggiornamento della cache di portage era diventato veramente molto lento (specialmente quando arrivava alla metà) allora ho provato cdb e devo dire che mi è parso più veloce (a naso però, non so darti numeri precisi), per quanto riguarda gli incrementi della velocità in fase di search non ti so dire perchè uso sempre eix.

----------

## luna80

 *Luca89 wrote:*   

> Tempo fa avevo notato che l'aggiornamento della cache di portage era diventato veramente molto lento (specialmente quando arrivava alla metà) ....

 

quotissimo!! è una cosa che sto riscontrando pure io....mi stavo domandando se non fosse il mio pc che avesse un qualche problema di disorganizzazione o se fosse "normale"

----------

## cloc3

E' molto interessante. E probabilmente è un possibile futuro per portage.

Però, devo confessare che sono molto affezionato al portage attuale, completamente accessibile in chiaro sui file.

Adesso, se hai un problema, se cerchi il nome di un'applicazione che stava nei media-sound, o vuoi verificare un dettaglio di quel particolare ebuild, vai di less e controlli immediatamente. Da ora, suppongo che sarà necessaria una chiamata al database con uno strumento specifico e la relativa sintassi.

Va be. Comunque lo proverò senz'altro.

----------

## makoomba

la struttura resta la stessa, cambia solo il modo in cui portage memorizza la cache.

----------

## mambro

Diventa molto più veloce anche l'update-eix   :Wink: 

----------

## Ic3M4n

però da quello che ho capito leggiucchiando qua e la sono più i difetti che i pregi... proprio per questo non lo implementeranno direttamente in portage ma rimarrà un hack che ogni utente potrà decidere se fare o meno.

----------

## makoomba

 *Luca89 wrote:*   

> Tempo fa avevo notato che l'aggiornamento della cache di portage era diventato veramente molto lento (specialmente quando arrivava alla metà)

 

è su kde che perde tempo, almeno per quanto mi riguarda.

a me piacerebbe che fosse implementata la possibilità di escludere alcuni "rami" di portage, ad esempio su un server ciao xorg-x11, kde, gnome, etc.

----------

## Scen

 *makoomba wrote:*   

> a me piacerebbe che fosse implementata la possibilità di escludere alcuni "rami" di portage, ad esempio su un server ciao xorg-x11, kde, gnome, etc.

 

Intendi questo? (Da http://www.gentoo.org/doc/it/handbook/handbook-x86.xml?part=3&chap=5)

 *Quote:*   

> 
> 
> Usare un Portage Tree Subset
> 
> Escludere pacchetti e/o categorie
> ...

 

P.S. io utilizzo il CDB backend per Portage ed Eix, e devo dire che è tutto molto + veloce!  :Very Happy:  A me funziona da DIo  :Cool: 

----------

## makoomba

l'avevo visto, ma quello è solo un "trucchetto" che ti espone a tutta una serie di potenziali problemi.

la feature andrebbe implementata in portage, non certo come cheat di rsync

----------

## FonderiaDigitale

questo e' quello che faccio io:

- creo un ramdisk.

- monto portage e il db di eix in un file di loop, dentro il ramdisk.

----------

## Ic3M4n

 *FonderiaDigitale wrote:*   

> questo e' quello che faccio io:
> 
> - creo un ramdisk.
> 
> - monto portage e il db di eix in un file di loop, dentro il ramdisk.

 

si però devi utilizzare 300 mega di ram per portage... o una 20ina se utilizzi un qualche tipo di compressione... però io ho solo 512M di ram... credo sia improponibile come cosa... che ne pensi?

----------

## FonderiaDigitale

in linea di massima hai ragione, tuttavia il file di loop serve a ridurre il numero di inode occupati dal singolo file, per cui dovresti vedere gia una riduzione di spazio senza compressione.

fai delle prove, e' la cosa migliore.

----------

## makoomba

sbaglio o c'era un tip squashfs+uniofs a riguardo ?

----------

## Ic3M4n

 *FonderiaDigitale wrote:*   

> in linea di massima hai ragione, tuttavia il file di loop serve a ridurre il numero di inode occupati dal singolo file, per cui dovresti vedere gia una riduzione di spazio senza compressione.
> 
> fai delle prove, e' la cosa migliore.

 

si, al max provo a vedere di fare qualcosina... la cosa che mi lasciava perplesso era l'utilizzo della ram per portage. ho solo 512M ed utilizzarne "un bel po?" (da quantificare) per portage mi sembra uno spreco di risorse... però mi piacerebbe provarlo... al max se riesci a quantificarmi la dimensione del tuo ramdis k mi faccio già una mezza idea senza star qui a provare soluzioni varie. nel caso sarebbe possibile (dico una vaccata) comprimere il ramdisk con squashfs? o è una cosa impossibilie da fare?

----------

## FonderiaDigitale

c'e' un tip per unionfs.

in ogni caso il portage lo monteresti solo quando ti serve, e lo smonti quando non.

per come fare, ti rimando a qualche tempo addietro in cui ho scritto un howto su come compilare portage in ram.. il principio e' lo stesso.

----------

## makoomba

union+squash sembra avere problemi con le ultime versioni

@Fonderia

di tanto in tanto, nei miei log compare:

```
mail smartd[10415]: Device: /dev/hda ringrazia FonderiaDigitale per il tip sulla compilazione in ram

```

----------

## Ic3M4n

si quello lo uso ed è magnifico... a prop.... grazie!   :Laughing: 

per montarlo e smontarlo non saprei... beh ci penso su e faccio qualche prova... al max posso sempre tornare indietro.

----------

## Sasdo

 *gutter wrote:*   

>  *Ic3M4n wrote:*   e funziona? 
> 
> Ne ho sentito parlare molto bene, ma non l'ho mai provato direttamente.
> 
> Sarei curioso di sentire dei commenti da qualcuno che ha fatto delle prove.

 

Guarda non ho dati misurati accuratamente ma sulla mia macchina:

emerge -ave gnome

senza cdb: taaaanto tempo (ordine del minuto)

con cdb:   pochi secondi

emerge --sync

senza cdb: stoppavo al 51% perchè mi stufavo di aspettare

con cdb: liscio come l'olio in un paio di minuti

voto a cdb:

10/10!!!

----------

## Ic3M4n

beh... potrebbe anche essere che il taanto tempo sia proprio dovuto al fatto che non fai finire l'aggiornamento del sync.

----------

## Sasdo

 *Ic3M4n wrote:*   

> beh... potrebbe anche essere che il taanto tempo sia proprio dovuto al fatto che non fai finire l'aggiornamento del sync.

 

sì l'ho pensato anche io ...ma cosa vuoi... do più spesso un emerge sync piuttosto che un emerge -ave gnome =)

----------

## Ic3M4n

beh... se ti può essere utile ti do la mia soluzione... almeno quella che ho sul fisso... faccio il sync la mattina alle 7 con cron. così quando mi sveglio ha già finito.   :Laughing: 

----------

## gutter

 *Ic3M4n wrote:*   

> beh... se ti può essere utile ti do la mia soluzione... almeno quella che ho sul fisso... faccio il sync la mattina alle 7 con cron. così quando mi sveglio ha già finito.  

 

"Un cron job al giorno toglie il medico di torno"

Vecchio proverbio cinese

----------

## Danilo

Non ho letto le controindicazioni ma ...

Ho appena fatto un esync e mi viene solo da dire 

M I R A C O L O 

```

time esync 

<smenamenti vari>

real    12m0.482s

user    2m31.277s

sys     0m35.666s

```

  :Shocked:   :Shocked:   :Shocked:   :Shocked:   :Shocked: 

Il tutto sull'instancabile athlon 700   :Cool: 

In passato si parlava di circa 50 minuti

---------------- EDIT --------------

```

time emerge metadata

psyco started...

skipping sync

>>> Updating Portage cache:  100%

real    2m57.736s

user    0m34.638s

sys     0m6.932s

```

Psyco era stato inserito in passato...

----------

## Ic3M4n

mi sembrano davvero molti 50 minuti... sei sicuro?

domani riprovo un sync al lavoro sul mio 450MHz... ma mi sembrano molti meno...

----------

## Danilo

 *Ic3M4n wrote:*   

> mi sembrano davvero molti 50 minuti... sei sicuro?
> 
> domani riprovo un sync al lavoro sul mio 450MHz... ma mi sembrano molti meno...

 

Si a me tanto era ormai. C'e' qualche cosa sopra che ciuccia risorse.

Inoltre 12 minuti non li trovo neanche in ufficio (P4 1400 mi sembra)

Comunque qualcuno riassume quali sono i dubbi all'uso? Non  mi va di leggere il thread in inglese.

----------

## X-Drum

da un paio di giorni dopo un sync ho notato che il processo 

di aggiornamento della cache di portage si è notevolmente

velocizzato (io non fatto assolutamente nulla) che abbiano

ottimizzato qualcosa? o soggettivo?

----------

## bandreabis

Infatti.. facendo un sync al giorno praticamente, non ho mai pensato di cercare alternative a "emerge sync", infatti da qualche giorno il sync è velocissimo anche dopo il 50 %. Io cmq ci metto sempre due o tre minuti massimo massimo.

Mi sa che abbiamo fatto molto rumore per nulla, o forse molto rumore per far sì che chi di dovere abbia risolto il problema.  :Wink: 

Saludos

Andrea

----------

## funkoolow

personalmente confermo che dopo aver fatto passare qualche giorno, il sync ha preso un paio di minuti massimo, contro i minimo 10 del pre integrazione cdb. mi è pure capitato di scontrarmi col problema dell'update del phtyon che spacca il portage ed ho risolto in mezzo minuto come indicato nel wiki stesso. al momento non resta nessun problema, solo gioia per la velocità di syncing  :Wink: 

----------

## Dece

Personalmente non ho notato questo miglioramento del sync negli ultimi giorni: anzi, proprio per la continua ed esasperante lentezza mi sono deciso a provare questa modifica, e devo dire che a prima vista la velocità del sync è aumentata non di poco  :Smile: 

----------

## X-Drum

come non detto: adesso si è riabbassata nooootevolemente...

omg bisogna fare qualcosa per ottimizzare portage, questi tempi

sono troppo alti...

----------

## makoomba

sulla gwn se ne parlava.

ci stanno lavorando.

----------

## bandreabis

 *X-Drum wrote:*   

> come non detto: adesso si è riabbassata nooootevolemente...
> 
> omg bisogna fare qualcosa per ottimizzare portage, questi tempi
> 
> sono troppo alti...

 

Quoto!  :Sad: 

----------

## neon

Chiedo venia, ieri ho aperto un thread sullo stesso argomento...

 *GWN wrote:*   

> 
> 
> Is a patch available now?
> 
> Yes, http://dev.gentoo.org/~ferringb/portage/2.0/3.0-cache-backport-experimental-7.patch is the relevant patch.
> ...

 

Qualcuno ha provato questa patch?

----------

