Estoy especificando una nueva MacBook Pro y quiero saber cuánta memoria requiere mi carga de trabajo. Estoy haciendo mi trabajo de desarrollo en un iMac 2011 con 16 GB de RAM y quiero saber si necesito tanta memoria para mi nuevo MBP ya que la RAM no se puede actualizar.
Creé un disco RAM de 8 GB y un archivo aleatorio de 7 GB para ver la presión de la memoria en mi Mac:
diskutil erasevolume HFS+ 'RAM Disk' `hdiutil attach -nomount ram://16777216`
dd if=/dev/urandom of=temp_7gb bs=1 count=0 seek=7g
Para mi sorpresa, ¡casi no tuvo impacto en el gráfico de presión de memoria en el Monitor de actividad! ¿Lo estoy haciendo bien? ¿Cómo puedo simular que mi Mac actual solo tiene 8 GB de memoria?
Abra Terminal, ingrese:
sudo nvram boot-args="maxmem=8192"
y reiniciar Esto limitará la RAM a 8 GiB. Ahora empieza a usar tu Mac con la carga de trabajo habitual.
Para volver a habilitar los 16 GiB-RAM completos, simplemente ingrese sudo nvram -d boot-argsy reinicie nuevamente.
Su comando dd no funcionará según lo previsto, porque la cantidad de bloques escritos es 0 (recuento = 0) y el tamaño del bloque sería 1 byte (bs = 1). Por lo que puedo decir, solo se crea un "archivo" con un tamaño de 7 GiB en el catálogo del sistema de archivos, pero no se escribe ningún dato en el archivo en sí. Si el recuento fuera 1 (recuento=1), se agregaría 1 byte de datos aleatorios al archivo temp_7gb (búsqueda=7g).
El destino (of=temp_7gb) es dudoso. Crea un archivo en el directorio de trabajo. Primero debe hacer un cd en un sistema de archivos en el disco RAM (por ejemplo, cd /Volumes/RAM-Disk/) para crear el archivo allí o escribir directamente en el dispositivo de disco RAM (of=/dev/devX).
dd es una herramienta que mide más bien 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, aún puede usarlo para simular el uso de memoria/carga de CPU.
if=/dev/urandom or if=/dev/zeroestán relacionados con la velocidad de la CPUof=/dev/nullel disco no estará involucrado.bs=xdetermina el uso de la memoria (x es casi proporcional al uso de la memoria)count=yte da tiempo para probar cosasEjemplos:
dd if=/dev/urandom of=/dev/null bs=1 count=1000
mide principalmente la sobrecarga de llamadas al sistema (incluidas las mitigaciones de Spectre / Meltdown que usa su kernel, que hacen 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 dominará eso. La huella de memoria es baja (en mi sistema alrededor de 400 kB)
dd if=/dev/urandom of=/dev/null bs=1g count=10
mide principalmente la velocidad de la CPU porque tiene que calcular una gran cantidad de datos aleatorios. La huella de memoria es alta (en mi sistema alrededor de 1 GB). bs=1msería más o menos lo mismo pero usaría mucha menos memoria.
dd if=/dev/zero of=/dev/null bs=1g count=10
/dev/zeromide principalmente el ancho de banda de la memoria (aquí ~7 GB/s) para el controlador del kernel haciendo un memsetespacio en el kernel en ddel búfer. La huella de memoria ~= tamaño del búfer, que es mucho más grande 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 /dev/nullcontrolador del kernel probablemente descarta los datos sin siquiera leerlos, por lo que solo está midiendo el ancho de banda de escritura de la memoria, no alternando escritura + lectura. (Y la sobrecarga de llamadas al sistema debería ser insignificante con solo una lectura + escritura por 1 GiB almacenado).
dd if=/dev/zero of=/dev/null bs=32k count=100000
mide principalmente el ancho de banda de escritura de caché de la CPU (aquí ~13 GB/s) y la sobrecarga de llamadas al sistema. La CPU no tiene mucho que calcular (¡ceros!); la huella de memoria es baja (en mi sistema alrededor de 470 kB).
El tamaño de caché L1d es de 32 kiB. Uno pensaría bs=24kque sería más rápido (porque encaja fácilmente en L1d en lugar de tener más desalojos porque el búfer de dd no es lo único en L1d), pero el aumento de la sobrecarga de llamadas al sistema por kB copiado podría empeorar las cosas.
El caché L2 es de 256 kiB, L3 es de 3 a 8 MiB. bs=224kdebería ver un ancho de banda bastante bueno. Puede ejecutar dden cada núcleo en paralelo y el ancho de banda se escalará porque las cachés L2 son privadas por núcleo, a diferencia de L3 y DRAM compartidos. (En los sistemas Xeon de muchos núcleos, se necesitan varios núcleos para saturar el ancho de banda DRAM disponible, pero en una computadora de escritorio o portátil, un núcleo puede acercarse bastante).
/dev/zerofragmentos de 1 GB solo hace que el kernel haga un gran conjunto de memorias. (Y descartar el resultado). en.wikipedia.org/wiki/Intel_QuickPath_Interconnect tiene un diagrama que muestra que QPI es para sistema <-> DRAM o CPU, no para CPU <-> DRAM.bs=32kcuellos de botella en la sobrecarga de llamadas al sistema tanto como el costo mínimo de un conjunto de memoria de 32kB. Con la mitigación de Spectre + Meltdown, la sobrecarga de llamadas al sistema es significativamente mayor. 13 GB/s es ridículamente bajo para la escritura de caché en blanco y negro en un núcleo. Aunque el tamaño de L1d = 32 kiB, es probable que vea ddque el rendimiento se reduce si lo reduce a 24 000, por lo que es más probable que obtenga todas las coincidencias de L1d, sin desalojos. O sube si lo creces bs=224k(justo por debajo del tamaño L2 de 256kB). Estos son los tamaños de caché de Intel desde Nehalem.ddpara crear un archivo de tamaño conocido en un ramdisk, sin esperar que dd en sí ocupara la memoria. (Los datos no comprimibles de urandom derrotan a zswap o lo que sea, si MacOS hace eso; no conozco bien MacOS en absoluto) Oh, excepto que estaban tratando de hacer un archivo disperso. /facepalm. (Aparentemente, MacOS admite el almacenamiento de archivos dispersos sobre HFS+, aunque HFS+ en sí no lo hace)dd if=/dev/urandom of=temp_7gb bs=1 count=0 seek=7g) es inútil. No se escribe nada (recuento=0) y falta el destino correcto (ya sea cd a disco RAM o un válido de (of=/dev*X*/)).count=1hacer un archivo disperso para que ni siquiera esté haciendo lo que probablemente sea inútil. No necesita buscar en absoluto para llenar cero, comobs=1m count=$((7*1024))
Alejandro
mike henderson
Jörg W. Mittag
seek=7g) y luego escribe 0 bloques (count=0) de tamaño 1 octeto (size=1). En otras palabras: no escribirá nada en absoluto. Todo lo que hace es crear un archivo disperso con un agujero 7G al principio y sin contenido de lo contrario. El tamaño total del archivo será insignificante (básicamente solo los metadatos para describir el "agujero").darren h
radarbob