# O que leva ao "Updating Portage cache"  demorar cada vez ma?

## domus-br

Pois é pessoal

a medida que vou fazendo o emerge sync, tem se tornado muito demorada no momento que o "Updating Portage cache" passa a "atualizar"

não entendo com isso vem sendo possivel, uma vez que nao permito que os "intervalos" entre um "emerge sync" e outro, fiquem muito distantes, pra ocasionalmente nao ter tanto trafego de informação, mas basta chegar no Updating Portage cache, que a situação fica feia, demora o mesmo tempo ou mais com se nao tivesse nenhuma ebuild no portage e tivesse baixando

----------

## RoadRunner

A cache do portage cria uma mini portage tree onde as ebuilds contêm apenas as informações necessárias às pesquisas e cálculo de dependências. Como o portage tem cada vez mais ebuilds, cada vez demora mais a criar e actualizar esta cache.

Como é um processo que depende na sua maioria do acesso a disco, se este estiver muito fragmentado o processo demora mais.

----------

## domus-br

 *RoadRunner wrote:*   

> A cache do portage cria uma mini portage tree onde as ebuilds contêm apenas as informações necessárias às pesquisas e cálculo de dependências. Como o portage tem cada vez mais ebuilds, cada vez demora mais a criar e actualizar esta cache.
> 
> Como é um processo que depende na sua maioria do acesso a disco, se este estiver muito fragmentado o processo demora mais.

 

Entendo,

existe uma maneira de melhorar isso? pergunto... pois tem ficado insuportavel esperar tanto tempo um simples emerge sync, nao por conta do trafego, mas sim do cache quando vai atualizar

meu FS está em reiser

Grato

----------

## MetalGod

podes usar as versoes instaveis do portage que de certa maneira estao a receber patches para optimizar esse problema

enquanto isso podes instalar o app-portage/esearch para minimizar o tempo de procura   :Question: 

----------

## domus-br

 *MetalGod wrote:*   

> podes usar as versoes instaveis do portage que de certa maneira estao a receber patches para optimizar esse problema
> 
> enquanto isso podes instalar o app-portage/esearch para minimizar o tempo de procura  

 

partindo do principio do "esearch"  ele teria que ser executado? ou eu basta apenas instalar que amenizarei a lentidao do ermege sync?

detalhe: o esearch já foi instalado

----------

## thiagonunes

Existe um método que as vezes pode fazer uma diferença impressionante na velocidade da atualização do cache do portage. Baixando um snapshot do portage dinovo.

Vcê quer testar o quanto melhorou? Faça o seguinte:

# emerge sync

# time emerge metadata

Anote o resultado do campo "real".

Então, usuários brasileiros podem fazer o seguinte:

# wget www.las.ic.unicamp.br/pub/gentoo/snapshots/portage-latest.tar.bz2

Então faça um backup do seu portage atual:

# mv /usr/portage /usr/portage.bkp

Descompacte o portage mais novo:

# tar xjf portage-latest.tar.bz2 -C /usr

Recupere seus distfiles:

# mv /usr/portage.bkp/distfiles /usr/portage

Agora temos uma árvore do portage limpinha. Vamos testar de quanto foi a melhora:

# time emerge metadata

Agora compare o tempo do campo real com a atualização na versão antiga. No meu gentoo o emerge metadata da árvore antiga levava 3m49s, agora leva 2m12s.

Apesar do meu caso não parecer muito impressionante eu não sei porque eu levava bem mais tempo pra fazer essa atualização, só dessa vez não levou, mas era algo em torno de 10 minutos. E também já vi casos parecidos com o meu passarem a fazer a atualização do cache em menos de 1 minuto.

A árvore do portage é grande, ocupa muito espaço, então não esqueça de apagar a antiga.

# rm -rf /usr/portage.bkp

Pessoal, por favor digam como funcionou para vocês e qual foi o ganho.

----------

## Operador Nabla

Eu apliquei este método sugerido no Gentoo Wiki. Com isso, a atualização dos metadados ficou sensivelmente mais rápida.

O método envolve a utilização de um módulo Python cujo código está disponível no link acima. Aos que quiserem experimentá-lo, mas não têm conhecimento sobre Python, deixo um conselho: cuidado ao "copiar e colar" o texto do código, pois a indentação das linhas que aparecem no texto da página deve ser respeitada.

É por exemplos como esse que eu me convenço, cada vez mais, que o Portage [ainda] explora mal a plataforma Python. Mas tenho fé que isso vai ser resolvido com as futuras versões...

----------

## MetalGod

esses problemas estao a ser resolvidos as versoes instaveis.

----------

## Vanquirius

 *domus-br wrote:*   

> partindo do principio do "esearch"  ele teria que ser executado? ou eu basta apenas instalar que amenizarei a lentidao do ermege sync?

 

Rode eupdatedb e depois use "esearch" aos invés de  "emerge -s".

----------

## errado

 *Vanquirius wrote:*   

>  *domus-br wrote:*   partindo do principio do "esearch"  ele teria que ser executado? ou eu basta apenas instalar que amenizarei a lentidao do ermege sync? 
> 
> Rode eupdatedb e depois use "esearch" aos invés de  "emerge -s".

 

Queria entender a preferência que vocês têm pelo esearch já que o eix é infinitamente superior   :Rolling Eyes: 

http://dev.croup.de/proj/eix/

----------

## thiagonunes

Concordo plenamente com a idéia de usar o eix. Muito melhor.

Mas outro dia eu falei sobre um método para se diminuir o tempo de busca e atualização do cache da árvore do portage. Esqueçam aquilo, é muito burro.

Agora acho que eu entendo o porque daquilo funcionar. Fragmentação do sistema de arquivos.

Eis um método mais inteligente de fazer a mesma coisa:

# cd /usr

# mv portage/distfiles .

# tar cf portage.tar portage (precisa de 500 MB livres na partição do /usr)

# rm -rf portage

# tar xf portage.tar

# mv distfiles portage

Depois rodem um 'emerge metadata' e comparem a melhora.

Outra idéia que vou colocar em prática em breve é criar uma partição separada pra árvore do portage. Alguém ja pensou nisso antes? Valeu a pena?

----------

## Operador Nabla

 *thiagonunes wrote:*   

> Outra idéia que vou colocar em prática em breve é criar uma partição separada pra árvore do portage. Alguém ja pensou nisso antes? Valeu a pena?

 

Eu fiz isso. Criei uma partição de mais ou menos 300 MB só para hospedar a minha Portage Tree e as minhas Portage Overlays (também criei partições separadas para o meus diretórios DISTDIR e PKGDIR). Na época, fiz isso mais para preservar a minha Portage Tree em possíveis reinstalações do sistema (e formatação das partições) do que para qualquer outra finalidade. Talvez isso tenha melhorado um pouco o desempenho do Portage, mas nada perceptível se comparado à adoção do módulo CDB que eu citei no meu post anterior.

----------

## thiagonunes

Fazendo o 'emerge sync' novamente outro dia eu percebi que a melhora só é perceptível quando se faz a atualização do cache do portage num momento em que ela já está atualizada, ou seja, não serve pra nada. Mesmo com a partição separada a lentidão permaneceu ao se fazer essa atualização do cache logo após uma sincronização nova. Portanto, se a melhora foi de 1 min em 10 ou 15 essa melhora é irrelevante.

Testarei outro dia esse módulo CDB, depois eu digo de quanto foi a melhora.

----------

## MetalGod

aqui esta o que voces querem

http://dev.gentoo.org/~ferringb/portage/2.0

----------

## thiagonunes

Desculpe mas eu não entendi.

----------

## MetalGod

esse ebuild contem patches para incrementar a performance do portage e corrige o bug da metadata aos 51%

----------

## SbrubblesMan

Interessante, eu estava com esse problema a até uns 3 dias atrás.  Não sei porque, nem como, ele foi sanado esses últimos dias...

----------

## MetalGod

provavelmente fizeste o upgrade para o portage 2.0.53  :Wink: 

----------

## alexandre_parente

o que eu posso dizer sobre o 2.0.53 eh que nada mudou... continua lento e irritante.

quanto ao bug aos 51%, foi resolvido... agora o bug eh aos 50% ... 

o emerge usa 98% do cpu durante o metadata e dura aproximadamente 30 hora.

----------

## MetalGod

e' normal fazer isso tudo porque provavelmente nem imaginas a quantidade de coisas que se faz nessas operaçoes... a nova versao 2.1_pre1 esta notoriamente mais rapida como era de esperar... e ja esta disponivel para usar.

----------

## domus-br

eu sinceramente perdi a vontade de atualizar o gentoo em razao desses problemas, so atualizo em ultimo caso ainda sim, se for muito importante e necessario, pois comigo tb nao senti nenehuma diferença chega no cache acabou a paciencia

----------

## MetalGod

python nao e' uma linguagem mt rapida ate' porque e' altamente orientada a objectos... o codigo do portage e' bom na minha opiniao os devs cada vez estao a adicionar melhorias nas performances em vez de novas features basta esperar e ver o resultado.

----------

## alexandre_parente

procurando mais uma vez por solucao para esse caso. A unica coisa que realmente funciona eh o uso do modulo cdb, com todas as resalvas e advertencia que encontrei quanto ao seu uso, recomento.

uso o cdb e o eix. o emerge metadata esta bem mais rapido e o uso do cpu pelo emerge nao passa do 15%.

o problema agora eh o tamanho da arvore que tem ate revista "app-doc/phrack" !!! isso eh um sistema de pacotes ou uma biblioteca?

----------

## alexandre_parente

Outro aplicativo que estou usando e que gostei muito foi o "emerge-delta-webrsync" que reduz muito o uso da net durante o sync e com isso o tempo necessario.

O portage bem que poderia explorar mais o xdelta... e nao se limitar aos pacotes do kde.

----------

## domus-br

pessoal,

acho que agora percebi que nao ouve demoras no cache, aparentimente a nova versao tem surtido efeito positivo, vou permanecer em observação

abraço

----------

## pilla

 *alexandre_parente wrote:*   

> 
> 
> o problema agora eh o tamanho da arvore que tem ate revista "app-doc/phrack" !!! isso eh um sistema de pacotes ou uma biblioteca?

 

Tem um arquivo para colocar os excludes do rsync (ou seja, quais partes da árvore não devem ser sincronizadas). 

Use com parcimônia para evitar que partes importantes da árvore não sejam atualizadas.

----------

## tetrix

 *Quote:*   

> ... parcimônia ...

 

Acho que você ta assistindo de mais os comerciais de cerveja hehe

----------

## pilla

 *tetrix wrote:*   

>  *Quote:*   ... parcimônia ... 
> 
> Acho que você ta assistindo de mais os comerciais de cerveja hehe

 

Pelo que lembro, esse parcimônia veio de uma propaganda de bohemia  :Very Happy: 

----------

## domus-br

esqueçam o que disse, fui fazer um sync aqui, quando chegou em 51% ja era!! que raiva!   :Evil or Very Mad: 

voltou tudo que era antes

----------

## MetalGod

versao de portage ?

----------

## domus-br

 *MetalGod wrote:*   

> versao de portage ?

 

Olá

2.0.53

grato

----------

## pilla

portage-2.1_pre3_r1 funciona bem pra mim (mas é beta ainda -- cuidado com o bug do emaint ou algo assim).

----------

## rafwas

Puxa, mas o seguinte pessoal...estou com um erro ainda na instalação...  :Confused: 

Quando coloco "emerge --sync" para atualizar a árvore do portage, dá esse erro...  :Mad: 

>>>Updating Portage cache: 88%!!! Cannot resolve virtual package name to an ebuild

!!!This is a bug, please repot it! (virtual/libintl.0)

Alguma sugestão?!

----------

## MetalGod

ya... ou actualizar o portage (podes correr o rescue) ou sim sem duvida reportar o bug   :Laughing: 

----------

## rafwas

Atualizar o portage com o "portage-20060129.tar.bz2" ou com o "portage-latest.tar.bz2"...qual a diferença?!?!?!  :Rolling Eyes: 

E mais uma...  :Very Happy:  ...eu não preciso do emerge --sync se já tiver a última versão do portage?!?!?  :Question: 

 :Question:   :Question: 

----------

## xef

Muito provavelmente um ficheiro é um linik para o outro

----------

## rafwas

Bom pessoal...  :Very Happy: 

Estava tentando instalar o Gentoo com uma iso do 2005.0 e pelo jeito não estava muito boa...assim que baixei e tentei com a o 2005.1 tudo se resolveu...ainda não entendi, mas valeu pela força...  :Laughing: 

----------

## Kobal

up para ter no meus posts.   :Cool: 

----------

