Prueba de esfuerzo de la memoria RAM

Abre el Terminal, entra:

sudo nvram boot-args="maxmem=8192"

y reiniciar. Esto limitará la RAM a 8 GiB. Ahora comience a utilizar su Mac con la carga de trabajo habitual.

Para volver a habilitar los 16 GiB-RAM completos basta con introducir sudo nvram -d boot-args y reiniciar de nuevo.

Tu comando dd no funcionará como se pretende, porque el número de bloques escritos es 0 (count=0) y el tamaño del bloque sería de 1 Byte (bs=1). Por lo que puedo decir, sólo se crea un "archivo" con el tamaño de 7 GiB en el catálogo del sistema de archivos, pero no se escriben datos en el archivo en sí. Si la cuenta fuera 1 (count=1), se añadiría 1 Byte de datos aleatorios al archivo temp_7gb (seek=7g).

El destino (of=temp_7gb) es dudoso. Crea un archivo en el directorio de trabajo. Tienes que ir a un sistema de archivos en el disco RAM (por ejemplo cd /Volumes/RAM-Disk/ ) primero para crear el archivo allí o escribir directamente en el dispositivo RAM-disco (of=/dev/devX).

dd es una herramienta que mide más la E/S del disco que la carga/velocidad de la CPU o el uso/presión de la memoria.

Con una combinación inteligente de operandos dd todavía se puede utilizar para simular la carga de la CPU / uso de la memoria.

1. if=/dev/urandom or if=/dev/zero están relacionados con la velocidad de la CPU
2. of=/dev/null el disco no estará involucrado.
3. bs=x determina el uso de la memoria (x es casi proporcional al uso de la memoria)
4. count=y te da tiempo a probar cosas

Ejemplos:

dd if=/dev/urandom of=/dev/null bs=1 count=1000 

mide principalmente la sobrecarga de las llamadas al sistema (incluyendo cualquier mitigación de Spectre / Meltdown que su kernel utilice, que hace que las llamadas al sistema sean más lentas de lo que solían ser). Los números aleatorios criptográficamente fuertes también requieren un cálculo significativo, pero 1 llamada al sistema por byte lo dominará. La huella de memoria es baja (en mi sistema unos 400 kB)

dd if=/dev/urandom of=/dev/null bs=1g count=10

mide principalmente la velocidad de la CPU porque tiene que calcular muchos datos aleatorios. La huella de memoria es alta (en mi sistema alrededor de 1 GB). bs=1m sería más o menos lo mismo, pero utilizaría mucha menos memoria.

dd if=/dev/zero of=/dev/null bs=1g count=10

mide principalmente el ancho de banda de la memoria (aquí ~7 GB/s) para el kernel /dev/zero conductor haciendo un memset en el espacio del núcleo en dd del búfer. La huella de memoria ~= tamaño del buffer, que es mucho mayor que cualquier caché. (Algunos sistemas con gráficos Iris Pro tendrán 128MiB o 256MiB de eDRAM; las pruebas con bs=128m vs. bs=512m deberían mostrar esa diferencia).

El núcleo /dev/null El controlador probablemente descarta los datos sin siquiera leerlos, por lo que sólo está midiendo el ancho de banda de escritura en memoria, no la alternancia de escritura + lectura. (Y la sobrecarga de la llamada al sistema debería ser insignificante con sólo una lectura+escritura por cada 1GiB almacenado).

dd if=/dev/zero of=/dev/null bs=32k count=100000

mide principalmente el ancho de banda de escritura de la caché de la CPU (aquí ~13 GB/s) y la sobrecarga de las llamadas al sistema. La CPU no tiene mucho que computar (¡cero!); la huella de memoria es baja (en mi sistema unos 470 kB).

El tamaño de la caché L1d es de 32kiB. Se podría pensar que bs=24k sería más rápido (porque cabe fácilmente en L1d en lugar de tener más desalojos porque el buffer de dd no es lo único que hay en L1d), pero el aumento de la sobrecarga de llamadas al sistema por kB copiado podría hacerlo peor.

La caché L2 es de 256kiB, la L3 es de 3 a 8 MiB. bs=224k debería ver un buen ancho de banda. Puede ejecutar dd en cada núcleo en paralelo y el ancho de banda escalará porque las cachés L2 son privadas por núcleo, a diferencia de las L3 y DRAM compartidas. (En los sistemas Xeon de muchos núcleos, se necesitan varios núcleos para saturar el ancho de banda disponible de la DRAM, pero en un ordenador de sobremesa/portátil un núcleo puede acercarse bastante).