8 votos

¿Cuál es la relación entre el tamaño de bloque y IO?

He estado leyendo sobre el disco recientemente que me llevó a 3 diferentes dudas. Y yo no soy capaz de vincular a ellos. Tres términos diferentes que estoy confundido con se block size, IO y Performance.

Estaba leyendo acerca de superbloque en slashroot cuando me encontré con la declaración de

Menos IOPS se realizará si usted tiene más grande el tamaño de bloque para su sistema de archivos.

De esto entiendo que Si quiero leer 1024 KB de datos, un disco(por decir Una) con un tamaño de bloque de 4 kb/4096B tomaría más de IO que un disco(Digamos B) con un tamaño de bloque de 64 kb.

Ahora mi pregunta es: ¿cuánto más IO iba a disco Una necesidad ?.

Medida de lo que estoy entendiendo el número de solicitud de e / s necesario para leer los datos dependerá también del tamaño de cada solicitud de e / s.

  • So who is deciding what is the size of the IO request? Is it equal to the block size? Algunas personas dicen que su aplicación decide el tamaño de solicitud de e / s que parece bastante justo, pero entonces, ¿cómo OS divide la solicitud única en múltiples IO. There must be a limit after which the request splits in more then one IO. How to find that limit ?
  • Is it possible that in both disk (A and B) the data can be read in same number of IO?
  • Does reading each block means a single IO ? If not how many blocks can be maximum read in a single IO?
  • If the data is sequential or random spread, does CPU provides all block address to read once?

También

num de IOPS posible = 1 /(promedio de demora de rotación + avg tiempo de búsqueda)

Rendimiento = IOPS * IO tamaño

Desde arriba de los IOPS de un disco, sería fijar siempre, pero IO tamaño puede ser variable. Por lo que para calcular el máximo posible de rendimiento necesitamos el máximo IO tamaño. Y a partir de esto lo que yo entiendo es que Si quiero aumentar el rendimiento de un disco me gustaría hacer un pedido con la máxima de datos que se puede enviar en una solicitud. Es esta suposición correcta ?

Me disculpo por demasiadas preguntas, pero he estado leyendo acerca de esto por un tiempo y no puede llegar a una respuesta satisfactoria. He encontrado diferentes puntos de vista sobre el mismo.

5voto

HBruijn Puntos 16577

Creo que el artículo de la Wikipedia lo explica bastante bien:

Ausencia simultánea de las especificaciones de tiempo de respuesta y carga de trabajo, los IOPS son esencialmente sin sentido.
...
Como puntos de referencia, IOPS números publicados por el dispositivo de almacenamiento de los fabricantes no se relacionan directamente con el mundo real el rendimiento de la aplicación. ...

Ahora a tus preguntas:

Así que es decidir cuál es el tamaño de la solicitud de e / s?

Que es un tanto fácil y una pregunta difícil de responder para un no-programador como yo.

Como de costumbre, la respuesta es un no satisfactorio "depende"...

Operaciones de e/S con respecto a un disco de almacenamiento de una aplicación son generalmente llamadas al sistema para el sistema operativo y su tamaño depende de que sistema se realiza una llamada de...

Estoy más familiarizado con Linux que otros sistemas operativos, así que voy a utilizar como referencia.

El tamaño de las operaciones de e/S como open() , stat() , chmod() y similar es casi insignificante.
En un disco giratorio el rendimiento de las llamadas depende principalmente de lo mucho que el disco actuador necesita para mover el brazo y la cabeza de lectura a la posición correcta en la bandeja de disco.

Por otro lado el tamaño de un read() y write() llamadas es un principio establecido por la aplicación y puede variar entre 0 y 0x7ffff000 (2,147,479,552) bytes en una única solicitud de e/S...

Por supuesto, una vez que la llamada de sistema ha sido realizada por la aplicación y es recibido por el sistema operativo, la llamada se consigue programada y en la cola (dependiendo de si o no la opción O_DIRECT se utiliza para pasar por la página y la caché de buffers y de e/S directa de la selección).

El sistema abstracto de la llamada deberá ser asignada a/de las operaciones en el subyacente del sistema de archivos que se ordena en diferentes bloques (el tamaño de la que normalmente se establece cuando el archivo se crea el sistema) y, finalmente, el controlador de disco de opera en cualquiera de los sectores del disco duro de 512 o 4096 bytes o SSD de páginas de memoria de 2K, 4K, 8K, o 16K.

(Para puntos de referencia normalmente a la lectura y escritura de llamadas generalmente se establecen a 512B o 4 kb que se alinean muy bien con el disco subyacente que resulta en un rendimiento óptimo.)

Debe haber un límite, después de que la solicitud se divide en más de una IO. Cómo encontrar el límite ?

Sí, hay un límite, en Linux como se documenta en el manual de un solo read() o write() llamada de sistema devolverá un máximo de 0x7ffff000 (2,147,479,552) bytes. Para leer archivos de mayor tamaño más grande necesitará más llamadas al sistema.

La lectura de cada bloque de una sola IO ?

Como tengo entendido normalmente cada ocurrencia de una llamada al sistema es lo que cuenta como IO evento.

Una sola read() llamada al sistema de cuenta como 1/0 evento y ni X ni Y de IO, independientemente de cómo el sistema de llamada traducido/implementado para acceder a X bloques de un sistema de ficheros o de lectura Y sectores de un giro de disco duro.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: