SSD cada vez más lento para archivos más grandes, ¿normal?

0

Escribir archivos grandes en mi SSD principal parece lento y estoy tratando de encontrar la razón. Mainboard es un ASUS Maximus VIII Hero y tengo dos SSD conectados:

  1. Samsung SSD 840 EVO 120GB -> sda
  2. Samsung SSD 840 EVO 500 GB -> sdb

Aquí está la salida fdisk -l

Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A3DB9022-5AE0-4BF4-BCA0-E0DAF7BB2106

Device         Start       End   Sectors  Size Type
/dev/sda1       2048   1050623   1048576  512M EFI System
/dev/sda2    1050624 167569407 166518784 79.4G Linux filesystem
/dev/sda3  167569408 234440703  66871296 31.9G Linux swap

Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Entonces el 120GB es el disco de mi sistema y el 500GB es un disco secundario. Si escribo en los SSD con dd, obtengo los siguientes resultados:

sda:

~$ dd if=/dev/zero of=/tmp/dd_performance bs=1G count=1 oflag=direct
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.1183 s, 507 MB/s

~$ dd if=/dev/zero of=/tmp/dd_performance bs=1G count=10 oflag=direct
10737418240 bytes (11 GB, 10 GiB) copied, 296.29 s, 36.2 MB/s

sdb:

~$ dd if=/dev/zero of=/mnt/temp_data/dd_performance bs=1G count=1 oflag=direct
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.13052 s, 504 MB/s

~$ dd if=/dev/zero of=/mnt/temp_data/dd_performance bs=1G count=10 oflag=direct
10737418240 bytes (11 GB, 10 GiB) copied, 21.1424 s, 508 MB/s

Entonces, para un archivo de 1GB, obtengo resultados muy similares. Pero escribir un archivo de 10GB en sda se vuelve dolorosamente lento.

Encontré preguntas similares, pero pensé que oflag = direct debería omitir todos los cachés y escribir directamente. Durante la ejecución, tenía 25 GB de memoria libre.

La única explicación que se me ocurre es que sda ​​tiene muchos más archivos (disco del sistema) y el SSD probablemente tiene más trabajo que hacer para ajustar un archivo de 10GB que en sdb. ¿Es normal este comportamiento? ¿Hay alguna prueba mejor que pueda ejecutar?

linux ssd performance pgruetter
fuente
Creo que su uso incorrecto del parámetro dd's bsestá afectando negativamente el rendimiento. Además, los puntos de referencia muestran que el 840 EVO no tiene nada cerca de ese rendimiento de escritura, lo que insinúa aún más las pruebas defectuosas. // Aparte de todo eso: el modelo de 500 GB tiene el doble de caché "TurboWrite", 6 GB.
Daniel B
¿Puedes explicar qué estoy haciendo mal con el parámetro bs? La sugerencia de caché TurboWrite es interesante, ¡gracias! Como ambos son 840 EVO, no vi ninguna diferencia.
pgruetter
1
Hay un tamaño de bloque óptimo para cualquier transferencia. Por lo general, está en algún lugar alrededor de 256K-1M. Será diferente dependiendo de lo que esté en cada extremo de la transferencia. Verifique esta respuesta sobre ese tema específico.
Daniel B
Intenté la prueba nuevamente con bs = 1M count = 10000 y obtuve 122MB / s. Probablemente probará otras herramientas también.
pgruetter
1
Eso es exactamente lo rápido que debería ser .
Daniel B

Respuestas:

0

Gracias al comentario de Daniel Bs, estoy seguro de que el comportamiento es normal.

Solución

Los dos discos tienen TurboWrites muy diferentes y se espera una caída al escribir archivos grandes. Para el disco más pequeño, la caída solo ocurre antes y es mucho más grande. Además, el tamaño de bloque (1G) que utilicé no es óptimo para las pruebas. Usar un 1M más razonable da mejores resultados.

Conclusión

Todavía usaré el disco más pequeño para las particiones de mi sistema, ya que tienen muchos archivos pequeños y estos funcionan rápidamente. Pero moveré dos máquinas virtuales que también estoy ejecutando en este SSD a una más grande, ya que con frecuencia hago copias de seguridad y las copio.

pgruetter
fuente