[eside-ghost] Lentitud al listar ficheros
Alayn Gortazar
zutoin en gmail.com
Mar Jun 26 01:29:49 CEST 2012
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 a bildua 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 a bildua 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 a bildua 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 a bildua 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 a bildua 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 a bildua 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 a bildua deusto.es>
>>>>>>>
>>>>>>> Aupa!
>>>>>>>
>>>>>>> el Thu, 31 May 2012 10:56:40 +0200 Bruno Gonzalez <stenyak a bildua 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 a bildua listas.deusto.es
>>>>>>> https://listas.deusto.es/mailman/listinfo/eside-ghost
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> eside-ghost mailing list
>>>>>> eside-ghost a bildua 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 a bildua listas.deusto.es
>>>>> https://listas.deusto.es/mailman/listinfo/eside-ghost
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> eside-ghost mailing list
>>>> eside-ghost a bildua 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 a bildua listas.deusto.es
>>> https://listas.deusto.es/mailman/listinfo/eside-ghost
>>
>>
>>
>> _______________________________________________
>> eside-ghost mailing list
>> eside-ghost a bildua 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 a bildua listas.deusto.es
> https://listas.deusto.es/mailman/listinfo/eside-ghost
--
Alayn Gortazar
Más información sobre la lista de distribución eside-ghost