[eside-ghost] Lentitud al listar ficheros

Bruno Gonzalez stenyak en gmail.com
Mar Jun 26 07:42:17 CEST 2012 

Joder, muchas gracias! Lo había dado por perdido (ahora suelo tener
abiertos chrome, firefox y opera, complementándose entre sí cuando alguno
hace mal alguna cosa concreta).

Pues lo cierto es que, en los momentos puntuales en que chromium se
arrastra, oigo interferencias en la tarjeta de sonido integrada, lo cual
lleva a pensar que hay un movimiento excesivo de datos por buses, o cpu, o
algún bridge o lo que sea (a tanto no me llega el oído :-D). Concuerda con
lo que dices (CPU emulando cosas que la gráfica se pasaría por el forro de
la GPU).

Probaré a compilar la version parcheada a ver qué tal, gracias de nuevo! :-)


2012/6/26 Alayn Gortazar <zutoin en gmail.com>

> Aupa Bruno,
>
> ya ha pasado algo de tiempo desde que escribiste esto, pero respecto
> al tema de Chromium, probablemente tenga que ver con la combinación
> explosiva de libcairo2 y drivers nVidia.
>
> Parece que libcairo intenta usar "server side gradients" (no me atrevo
> a traducir eso, queda muy raro en cualquiera de las traducciones que
> se me ocurren), los drivers de nvidia no lo implementan, y se va todo
> al garete.
>
> Si usas Debian, a mi con downgradear el paquete a la versión .1.10.2-7
> me ha bastado, aunque luego es un engorro mantener el sistema
> actualizado porque los paquetes que dependen de libcario se chinan un
> poco, hay que actualizar a la ultima version (con un apt-get -f
> install), upgradear y volver a poner el paquete en su versión antigua.
>
> Si prefieres el proceso de parchear manualmente la librería para que
> no use los gradientes esos, échale un vistazo a este thread:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616308
> juraría que por ahí dicen algo al respecto, yo últimamente ando algo
> vago para ponerme a parchear y tal, pero seguro que eso me evitaría
> algún que otro dolor de cabeza con las actualizaciones... O:-)
>
> Suerte!
>
>
> 2012/5/31 Bruno Gonzalez <stenyak en gmail.com>:
> > Sip, el problema son los metadatos del inodo. El problema es que la
> solución
> > propuesta en serverfault, y que probé al mediodía (el fsck -D) no era la
> > correcta. Por la simple razón de que fsck pasa de tu culo si no le pones
> el
> > flag -f. Por eso no había tardado ni 1 segundo en ejecutarse:
> efectivamente
> > *no* había hecho nada. Mea culpa, supongo. O_o'
> >
> > Total que acabo de pasarle un fsck -fD, y ahora *sí* que ha tardao media
> > hora. Y tras reiniciar, compruebo que ambos directorios tardan menos de
> una
> > décima en listar los ficheros. Oh yeah!
> >
> > Conclusión: visto lo visto, voy a pasarle un fsck -fD a todos mis
> equipos en
> > cuanto pueda, y un par de veces al año. Tengo a chromium en casa que
> tarda 5
> > segundos en cambiar de pestaña o crear una vacía, mientras firefox va
> todo
> > fresco; igual es el mismo problema y todo (algún directorio de caché o
> > temporales o yoquésé).
> >
> > Gracias a todos por la ayuda!
> >
> >
> >
> > 2012/5/31 Jon Ander Ortiz <jonbaine en gmail.com>
> >>
> >> Me parece super interesante el tema. Aquí:
> >>
> >> http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-05/msg07079.html
> >>
> >> Comentan los siguiente:
> >>
> >> "The problem is that unless the user is deleting a *huge* number of
> >> files, it's rare that the directory entry block goes completely empty.
> >> If you shrink from 15,000 messages to 12,000 messages, say, because of
> >> the fact that we use a hashed b-tree as our data structure, the leaf
> >> blocks in the btree generally still contain some directory entries.
> >> So to fix this we need to actually coalesce directory leaf blocks on
> >> the fly, on top of everything else that I had mentioned. It's
> >> certianly doable, but again, someone would have to submit a patch. We
> >> might get around to it one of these days, but plates of those of us
> >> who are doing ext4 are pretty full with higher priority items at
> >> present.
> >> "
> >>
> >> Por lo que parece que no encojen la estrucutra B-tree que se monta para
> >> acceder a los inodos, por lo que, aunque tengas dos ficheros si estaba
> ahí
> >> metido todo el demonio, la estructura del Btree, se la tiene que
> recorrer
> >> entera.
> >>
> >>  Ya dicen, que ala, que algún valiente mande algún parche (jajaja) que
> >> ellos están con ext4 (esto es del 2009) :P.
> >>
> >> 2012/5/31 Bruno Gonzalez <stenyak en gmail.com>
> >>>
> >>> Bueno, he avanzado algo. Si alguien controla un poco de sistemas de
> >>> ficheros, fijo que sabe decirme cuál es el problema.
> >>>
> >>> Primera prueba:
> >>>  - Reinicio
> >>>  - Me explota la fuente de alimentación según pasaba el POST (Murphy
> >>> haciendo horas extra...). Cambio la fuente.
> >>>  - Le paso un fsck (todo impoluto, no se queja de nada), y de seguido
> un
> >>> fsck -D para arreglar sus historias esas. No tarda ni 1 segundo en
> terminar
> >>> (no sé yo si hace algo realmente xD).
> >>>  - Reinicio again, hago un ls, y...
> >>> $ time ls directorio
> >>> real 0m23.316s
> >>> user 0m0.000s
> >>> sys 0m0.180s
> >>>
> >>> Nada, sigue yendo igual de lento la primera vez, 23 segundos.
> >>>
> >>>
> >>> Segunda prueba:
> >>> Duplico el directorio que da problemas y reinicio:
> >>> $ cp -a directorio_viejo directorio_nuevo
> >>> $ sudo reboot
> >>> Compruebo que el directorio viejo sigue tardando 23 segundos, pero el
> >>> nuevo no tarda ni 1 décima de segundo!
> >>>
> >>> Más interesante aún:
> >>> $ diff -r directorio_viejo directorio_nuevo
> >>> Ambos son clavados, dice.
> >>>
> >>> $ du -sh directorio_*
> >>> 848K directorio_nuevo
> >>> 12M directorio_viejo
> >>> La copia idéntica ocupa 15 veces menos *en disco*.
> >>>
> >>> Vamos a desconfiar del diff recursivo, comprobemos los contenidos byte
> a
> >>> byte:
> >>> $ find directorio_viejo  -exec cat {} \; | wc -c
> >>> 696432
> >>> $ find directorio_nuevo  -exec cat {} \; | wc -c
> >>> 696432
> >>> Y si le paso vimdiff, todos esos 696432 bytes son idénticos. Así q
> >>> definitivamente es la misma información.
> >>>
> >>>
> >>> Conclusión: toca desechar el mito de que en linux no hay que pasar
> >>> defrag, o qué? =D
> >>> Alguna otra idea?
> >>>
> >>> Con usar la copia nueva se me soluciona el problema, pero quiero saber
> la
> >>> solución real, por pura curiosidad científica.
> >>>
> >>>
> >>> 2012/5/31 Jon Ander Ortiz <jonbaine en gmail.com>
> >>>>
> >>>> Aupa!!!
> >>>>
> >>>> Como curiosidad te puedes implementar un "ls" o algo parecido
> >>>> bypasseando las cachés de disco.
> >>>> Con hacer un open con el flag O_DIRECT, bypasseas todas las cachés y
> >>>> demás morrallas así que puedes tener un resultado de referencia para
> >>>> comparar ya que te quitas las cachés de enmedio, y ver el rendimiento
> de tu
> >>>> sistema de ficheros / disco sin las cachés.
> >>>>
> >>>> De esta manera, puedes ver si es que tu sistema de ficheros va así (yo
> >>>> que se.. movidas chungas de ext), e incluso compararlo con otro disco
> de
> >>>> características parecidas a ver si está crujido.
> >>>>
> >>>> Un saludo!!
> >>>> Jonan
> >>>>
> >>>>
> >>>> 2012/5/31 Bruno Gonzalez <stenyak en gmail.com>
> >>>>>
> >>>>> Si, la caché juega su papel, pero el problema no es que linux consiga
> >>>>> acelerar el proceso, sino que el proceso pueda ir tan lento en
> primer lugar.
> >>>>>
> >>>>> Según leo en serverfault, si el directorio ha tenido en el pasado
> >>>>> muchos ficheros (en mi caso he tenido varios miles), incluso si
> ahora no
> >>>>> tiene más que 2 archivos, puede ser necesario optimizar los índices
> de la
> >>>>> trócola derecha de ext2/3/4 con:
> >>>>> # e2fsck -D /dev/<particion>
> >>>>>
> >>>>> No lo he probado aún, más tarde reiniciaré con una live y os comento
> >>>>> los resultados.
> >>>>> Mientras tanto, si a alguien se le ocurre alguna posible solución que
> >>>>> no implique reiniciar, bienvenida será :-)
> >>>>>
> >>>>>
> >>>>> 2012/5/31 ALi <osatien en gmail.com>
> >>>>>>
> >>>>>> yo creo que se trata de alguna cache
> >>>>>> porque me pasa a mi parecido con find .... la primera vez que busca
> la
> >>>>>> leche, pero las siguientes van muy rapido, supongo que sera
> parecido. eso
> >>>>>> si, desconozco de donde almacena la cache
> >>>>>>
> >>>>>>
> >>>>>> 2012/5/31 Pablo Garaizar Sagarminaga <garaizar en deusto.es>
> >>>>>>>
> >>>>>>> Aupa!
> >>>>>>>
> >>>>>>> el Thu, 31 May 2012 10:56:40 +0200 Bruno Gonzalez <
> stenyak en gmail.com>
> >>>>>>> decía:
> >>>>>>>
> >>>>>>> > $ dmesg no dice nada raro... Alguien tiene idea de qué podría
> ser?
> >>>>>>> > Sectores muertos del disco duro tal vez?
> >>>>>>> > Es el único directorio en el que me ha pasado.
> >>>>>>>
> >>>>>>> Ni idea, pero yo le tiraría un ltrace al ls cuando sepas que va a
> >>>>>>> pasar, para ver si ves dónde puede estar quedándose atascado. Si no
> >>>>>>> ves
> >>>>>>> nada, strace.
> >>>>>>>
> >>>>>>> --
> >>>>>>>  Pablo Garaizar Sagarminaga
> >>>>>>>  Universidad de Deusto
> >>>>>>>  Avda. de las Universidades 24
> >>>>>>>  48007 Bilbao - Spain
> >>>>>>>
> >>>>>>>  Phone:       +34-94-4139000 Ext 2512
> >>>>>>>  Fax:                  +34-94-4139101
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> eside-ghost mailing list
> >>>>>>> eside-ghost en listas.deusto.es
> >>>>>>> https://listas.deusto.es/mailman/listinfo/eside-ghost
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> eside-ghost mailing list
> >>>>>> eside-ghost en listas.deusto.es
> >>>>>> https://listas.deusto.es/mailman/listinfo/eside-ghost
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Saludos,
> >>>>>      Bruno González
> >>>>>
> >>>>> _______________________________________________
> >>>>> Jabber: stenyak AT gmail.com
> >>>>> http://www.stenyak.com
> >>>>>
> >>>>> _______________________________________________
> >>>>> eside-ghost mailing list
> >>>>> eside-ghost en listas.deusto.es
> >>>>> https://listas.deusto.es/mailman/listinfo/eside-ghost
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> eside-ghost mailing list
> >>>> eside-ghost en listas.deusto.es
> >>>> https://listas.deusto.es/mailman/listinfo/eside-ghost
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Saludos,
> >>>      Bruno González
> >>>
> >>> _______________________________________________
> >>> Jabber: stenyak AT gmail.com
> >>> http://www.stenyak.com
> >>>
> >>> _______________________________________________
> >>> eside-ghost mailing list
> >>> eside-ghost en listas.deusto.es
> >>> https://listas.deusto.es/mailman/listinfo/eside-ghost
> >>
> >>
> >>
> >> _______________________________________________
> >> eside-ghost mailing list
> >> eside-ghost en listas.deusto.es
> >> https://listas.deusto.es/mailman/listinfo/eside-ghost
> >
> >
> >
> >
> > --
> > Saludos,
> >      Bruno González
> >
> > _______________________________________________
> > Jabber: stenyak AT gmail.com
> > http://www.stenyak.com
> >
> > _______________________________________________
> > eside-ghost mailing list
> > eside-ghost en listas.deusto.es
> > https://listas.deusto.es/mailman/listinfo/eside-ghost
>
>
>
> --
> Alayn Gortazar
> _______________________________________________
> eside-ghost mailing list
> eside-ghost en listas.deusto.es
> https://listas.deusto.es/mailman/listinfo/eside-ghost
>



-- 
Saludos,
     Bruno González

_______________________________________________
Jabber: stenyak AT gmail.com
http://www.stenyak.com
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://listas.deusto.es/mailman/private/eside-ghost/attachments/20120626/afa81075/attachment-0001.html>

Más información sobre la lista de distribución eside-ghost