[opensuse-es] Mirando la velocidad de un disco duro
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hola, Pues, siendo fiesta hoy donde trabajo, me he puesto a mirar la velocidad de un disco duro en función de la posición de la cabeza, en un disco en blanco. Para ello he particionado mi nuevo disco (seagate) en multiples particiones de 25 GB, desde la 5 hasta la 23 (la ultima es de +/-16). Luego me he hecho un script que formatea todas esas particiones, y otro que ejecuta primero hdparm en todas ellas, y luego crea un fichero de un giga en todas ellas, tres veces. Finalmente lo he pasado al oocalc, y he hecho un grafiquillo que anexo (Y= MB/s, X= num partición). Las mediciones con hdparm casi se superponen unas a otras. Las de fichero, no: parece que ext4 sale más rápido, y reiser más lento (me ha faltado mirar ext3). El disco resulta más rápido alrededor de la séptima partición, descendiendo considerablemente la velocidad hacia el centro del disco. Hace años hice una medición similar, menos completa, y el resultado era que la velocidad era bastante mayor hacia 1/3 del disco. Por supuesto, nada de esto es concluyente. Es sólo una probatina. Podría también hacer mediciones de escritura o lectura en diversos tamaños o cantidad de ficheros, pero en fin... ya veremos si tengo ganas. Si queréis que ponga los scripts o los datos pues decidlo. - -- Cheers / Saludos, Carlos E. R. (from 11.2 "Emerald" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksXxkQACgkQU92UU+smfQXSVgCdFl4duRFmmMAOGId8vaJz5wBz K30AniUNpkjZlP8FhS+a576n/U3sbc2V =UOl5 -----END PGP SIGNATURE-----
El Thu, 03 Dec 2009 15:08:04 +0100, Carlos E. R. escribió:
Pues, siendo fiesta hoy donde trabajo, me he puesto a mirar la velocidad de un disco duro en función de la posición de la cabeza, en un disco en blanco.
¿Fiesta? Qué morro ;-)
Para ello he particionado mi nuevo disco (seagate) en multiples particiones de 25 GB, desde la 5 hasta la 23 (la ultima es de +/-16). Luego me he hecho un script que formatea todas esas particiones, y otro que ejecuta primero hdparm en todas ellas, y luego crea un fichero de un giga en todas ellas, tres veces. Finalmente lo he pasado al oocalc, y he hecho un grafiquillo que anexo (Y= MB/s, X= num partición).
Las mediciones con hdparm casi se superponen unas a otras. Las de fichero, no: parece que ext4 sale más rápido, y reiser más lento (me ha faltado mirar ext3). El disco resulta más rápido alrededor de la séptima partición, descendiendo considerablemente la velocidad hacia el centro del disco. Hace años hice una medición similar, menos completa, y el resultado era que la velocidad era bastante mayor hacia 1/3 del disco.
Por supuesto, nada de esto es concluyente. Es sólo una probatina.
Podría también hacer mediciones de escritura o lectura en diversos tamaños o cantidad de ficheros, pero en fin... ya veremos si tengo ganas.
Si queréis que ponga los scripts o los datos pues decidlo.
Ahora ya entiendo por qué limitaban a 14-15 particiones los discos scsi
:-P. Hay un descenso en rendimiento de casi el 50% entre las particiones 5-7 y la 16-23.
Tremendo. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.00.0912031553300.3392@nimrodel.valinor> El 2009-12-03 a las 14:36 -0000, Camaleón escribió:
El Thu, 03 Dec 2009 15:08:04 +0100, Carlos E. R. escribió:
Pues, siendo fiesta hoy donde trabajo, me he puesto a mirar la velocidad de un disco duro en función de la posición de la cabeza, en un disco en blanco.
¿Fiesta? Qué morro ;-)
:-) En el pueblo donde trabajo es fiesta; en el pueblo donde vivo, no. Y por poco no me entero y voy a trabajar hoy...
Si queréis que ponga los scripts o los datos pues decidlo.
Ahora ya entiendo por qué limitaban a 14-15 particiones los discos scsi
:-P. Hay un descenso en rendimiento de casi el 50% entre las particiones 5-7 y la 16-23.
Te vi'a dar! :-P Ahora faltaría que alguien se lo creyese que es por eso.
Tremendo.
Desde luego, es un descenso considerable. Ahora que lo pienso... en la escritura a disco con dd no se hace un flush. Puede afectar a mis mediciones bastante. Las hice grabando un fichero de un giga con dd. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAksX0WkACgkQtTMYHG2NR9WgfACeJH/jlzCa7nl/VG31IalxSlav laEAn2FwmPNb7JT4UQINEu7btiaAPmbn =H0D4 -----END PGP SIGNATURE-----
Hola :) On Thursday 03 December 2009 15:55:29 Carlos E. R. wrote:
Content-ID: <alpine.LSU.2.00.0912031553300.3392@nimrodel.valinor>
[...]
Ahora que lo pienso... en la escritura a disco con dd no se hace un flush. Puede afectar a mis mediciones bastante. Las hice grabando un fichero de un giga con dd.
Preguntillas: - ¿con qué opciones creaste los filesystems? Es decir, ¿todos tienen el mismo tamaño de bloque, ...? - el dd, ¿lo has lanzado de un disco a otro? case respuesta in yes) ¿estaban en la misma controladora y/o bus? no) ¿desde el mismo disco? esac x) - dd es monoproceso/thread por lo que no estarás sacando toda la chicha a las CPUs/cores que tengas - si puedes, haz el dd desde un tmpfs en RAM a disco - dd es cpu-bound, por lo que la CPU es factor limitante, comprueba el consumo de CPU Si puedes probar con iozone, mejor. También puedes probar con bonniee++ y otros cuantos que hay por ahí. HTH Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.3 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-12-03 a las 17:56 +0100, Rafa Grimán escribió:
Hola :)
On Thursday 03 December 2009 15:55:29 Carlos E. R. wrote:
[...]
Ahora que lo pienso... en la escritura a disco con dd no se hace un flush. Puede afectar a mis mediciones bastante. Las hice grabando un fichero de un giga con dd.
Preguntillas:
- ¿con qué opciones creaste los filesystems? Es decir, ¿todos tienen el mismo tamaño de bloque, ...?
Opciones por defecto. A ver, mirando en el script: mkfs.ext4 -L test_$X /dev/sdb$X mkfs.reiserfs -l test_$X -q /dev/sdb$X mkfs.xfs -f -L test_$X /dev/sdb$X
- el dd, ¿lo has lanzado de un disco a otro?
Ah, si, por supuesto :-)
case respuesta in
yes) ¿estaban en la misma controladora y/o bus?
Posiblemente. No conozco la arquitectura de esta máquina, pero sospecho que si. Bus sata, distinto cable, controladora de la placa. No se como se lo montan.
no) ¿desde el mismo disco? esac
x)
- dd es monoproceso/thread por lo que no estarás sacando toda la chicha a las CPUs/cores que tengas
- si puedes, haz el dd desde un tmpfs en RAM a disco
- dd es cpu-bound, por lo que la CPU es factor limitante, comprueba el consumo de CPU
Bueno, el dd era este: time dd if=/dev/zero of=/mnt/test/fichero count=5 bs=200M 2>&1 | tee -a $Nombre Por lo que la lectura es en memoria y por tanto mucho más rápida, tiempo despreciable, frente al tiempo del disco.
Si puedes probar con iozone, mejor. También puedes probar con bonniee++ y otros cuantos que hay por ahí.
¡Humm! Tendría que estudiarmelos. Mi intención era simplemente averiguar el efecto de la distancia al borde, o sea, ver si las primeras particiones eran realmente más rápidas, y cuanto. No hacer un estudio serio :-) Ah, el webpin no encuentra iozone para la 11.2. El bonnie, si. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAksYDacACgkQtTMYHG2NR9XeqQCghtGxNf6XRVEc3vuQyCXHcOQ8 zAwAnAv7MJsbqsHngLusEtiPsFbjdo2i =PBgC -----END PGP SIGNATURE-----
Hola :) On Thursday 03 December 2009 20:12:30 Carlos E. R. wrote:
El 2009-12-03 a las 17:56 +0100, Rafa Grimán escribió:
Hola :)
On Thursday 03 December 2009 15:55:29 Carlos E. R. wrote:
[...]
Ahora que lo pienso... en la escritura a disco con dd no se hace un flush. Puede afectar a mis mediciones bastante. Las hice grabando un fichero de un giga con dd.
Preguntillas:
- ¿con qué opciones creaste los filesystems? Es decir, ¿todos tienen el mismo tamaño de bloque, ...?
Opciones por defecto. A ver, mirando en el script:
mkfs.ext4 -L test_$X /dev/sdb$X
Los valores por defecto están (o deberían estar) definidos en el fichero: /etc/mke2fs.conf En el mío, por ejemplo, los valores son: base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr blocksize = 4096 inode_size = 256 inode_ratio = 16384 has_journal,extents,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize man mke2fs.conf para más info.
mkfs.reiserfs -l test_$X -q /dev/sdb$X
No he encontrado los valores por defecto. ¿Alguien los conoce?
mkfs.xfs -f -L test_$X /dev/sdb$X
The default value is 4096 bytes The mininum (and default) value is 256 bytes Parece que los alores son los mismos en ext4 y xfs. Teniendo en cuenta que han sacado muchas ideas de xfs, es de esperar ;)
- el dd, ¿lo has lanzado de un disco a otro?
Ah, si, por supuesto :-)
case respuesta in
yes) ¿estaban en la misma controladora y/o bus?
Posiblemente. No conozco la arquitectura de esta máquina, pero sospecho que si. Bus sata, distinto cable, controladora de la placa. No se como se lo montan.
Por lo qu edices abajo, esto no es relevante. Era por si hacías un dd de un fichero que tenías en disco a otro disco. Si tienes los discos en la misma controladora, puedes tener cuellos de botella.
no) ¿desde el mismo disco? esac
x)
- dd es monoproceso/thread por lo que no estarás sacando toda la chicha a las CPUs/cores que tengas
- si puedes, haz el dd desde un tmpfs en RAM a disco
- dd es cpu-bound, por lo que la CPU es factor limitante, comprueba el consumo de CPU
Bueno, el dd era este:
time dd if=/dev/zero of=/mnt/test/fichero count=5 bs=200M 2>&1 | tee -a $Nombre
Por lo que la lectura es en memoria y por tanto mucho más rápida, tiempo despreciable, frente al tiempo del disco.
Has usado /dev/zero. No se debería usar porque las cahcés (desde la RAM hasta la del disco) no refrescan datos, es decir, estás leyendo valores de caché y no la velocidad real del disco. Usa mejor random o urandom para que se tengan que borrar las cachés (todas las que tengas por en medio).
Si puedes probar con iozone, mejor. También puedes probar con bonniee++ y otros cuantos que hay por ahí.
¡Humm! Tendría que estudiarmelos.
iozone es bastante complejo, aunque puedes hacer un iozone -a que (IIRC) hace todas las pruebas. Bonnie++ tiene menos opciones y es bastante rápido.
Mi intención era simplemente averiguar el efecto de la distancia al borde, o sea, ver si las primeras particiones eran realmente más rápidas, y cuanto. No hacer un estudio serio :-)
No te lo preguntaba por criticar, más que nada era curiosidad 0:)
Ah, el webpin no encuentra iozone para la 11.2. El bonnie, si.
Jarl. Antes sí lo tenía. Bueno, a lo mejor lo han pasado a software.opensuse.org. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.3 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (4)
-
Camaleón -
Carlos E. R. -
Carlos E. R. -
Rafa Grimán