La semana pasada noté que mi computadora se había ralentizado seriamente. Mis tareas habituales parecen tardar una eternidad, e incluso mis demos JMP estándar tardaban un poco más de lo que estaba acostumbrado. Intenté las tareas normales, como reparar permisos, verificar la memoria, ver si había alguna extensión dañada del kernel e incluso instalar una versión limpia de Mac OS Mavericks para ver si eso solucionaría el comportamiento que estaba viendo.
Entonces me di cuenta de que podría estar pasando algo con mi unidad de estado sólido (SSD). Como todavía tenía el disco duro original (un disco giratorio estándar) que venía con mi MacBook Pro, lo instalé e intenté arrancar desde el disco original.
Un programa que uso para ver cómo está funcionando tu computadora es Geekbench. Realiza una gran cantidad de tareas de procesador, gráficos y de uso intensivo de disco y luego reporta un número de rendimiento de núcleo único y múltiple que luego puede comparar con una base de datos de computadoras que están especificadas de manera similar a la suya. Entonces puedes ver si estás logrando un rendimiento comparable.
Bueno, como resultado, el rendimiento de mi computadora debería ser de aproximadamente 2,000 para un solo núcleo y 10,000 para varios núcleos. Obtuve 700 para un solo núcleo y 3000 para varios núcleos con el SSD. Cuando puse el HDD original en mi computadora portátil, el rendimiento aumentó a unos 2,000 y 8,500, mucho más cerca de lo que debería ser.
Así que, obviamente, algo estaba pasando con mi unidad. Sin darme por vencido, decidí ver si podía reacondicionarlo. También pensé que esta era una gran oportunidad para recopilar y visualizar algunos datos utilizando JMP. Utilicé un programa llamado DiskTester, de la suite de herramientas Digiloyd. Una de las funciones en DiskTester es una función SSD de reacondicionamiento. Esto escribe una gran cantidad de datos en todo el espacio libre de una unidad y le permite iterar varias veces. El programa informa el desplazamiento del fragmento en MB, la velocidad de escritura promedio, la velocidad de escritura actual, así como la velocidad de escritura mínima y máxima.
El disco, según el desarrollador de Digiloyd Tools, "responde a este tratamiento limpiando y desfragmentando". Si este proceso funciona en mi disco, debería ver un rendimiento bastante malo para la primera iteración que mejora drásticamente después de unas pocas iteraciones.
Así que borré mi unidad, arranqué desde mi otra unidad interna y comencé el proceso de reacondicionamiento, dejé que funcionara durante la noche y recogí ocho iteraciones de datos en bruto.
DiskTester me dio la opción de copiar los datos sin procesar en el portapapeles, lo que hice, y luego creé un archivo .txt que ahora importaré a JMP.
Usaré Archivo> Abrir para obtener el archivo .txt, y luego, cuando se me dé la opción, elegiré Abrir como: Datos (usando vista previa), lo que me da la opción de inspeccionar los datos antes de ingresar a JMP.
Estoy contento con el aspecto de las columnas, y veo por el ícono 123 que todos mis datos entrarán como continuos, que es lo que quiero. En esta ventana, tengo la opción de dar nombres a las columnas, lo que haré.
Y ahora tengo mis datos sin procesar en JMP, pero hay un paso más que tendré que hacer antes de poder visualizar los resultados. Puedes ver que me falta una columna importante, que es el número de iteración. Necesitaré esto para usarlo como una fase o variable de agrupación. Afortunadamente, puedo generar esto bastante fácilmente en JMP. Crearé una nueva columna y luego haré clic derecho para acceder a la información de la columna. Cuando crea una nueva columna, tiene la opción de inicializar los datos. Elegiré los datos de secuencia y luego ingresaré 1 para De, 8 para A (como quiero datos de iteración de 1 a 8) y 1 para el Paso.
Sé que mi último bloque es de 482,176 MB y el programa está escribiendo fragmentos de 128 MB, lo que significa que cada iteración tendrá 3,767 medidas únicas. Así que pondré 3767 en el campo Repetir cada valor N veces.
Puedo revisar mi trabajo mirando las filas 3.767 y 3.768. Por supuesto, 3.767 está etiquetado como iteración 1 y 3.768 está etiquetado como iteración 2. Ahora estoy listo para irme.
Usaré Graph Builder para ver qué está pasando en los datos. Tener el Offset en GB en lugar de MB puede ser una mejor manera de mostrar las etiquetas en el eje X para todos mis gráficos, así que antes de continuar, voy a transformar MB en GB haciendo clic derecho en el botón Compensar MB, hacer clic en Fórmula y luego tomar Desplazar MB y dividir por 1000. Esto crea una columna de transformación personalizada sin tener que volver a la tabla de datos. Querré usar esto más tarde, así que lo renombraré Offset GB, haga clic derecho y luego seleccione: Agregar a la tabla de datos. La gráfica a continuación muestra el patrón de las lecturas de rendimiento en el disco para cada iteración. He reducido la transparencia de los puntos a 0.1 para que podamos verlos mejor y también agregué un límite de especificaciones más bajo de 110 MB / s al gráfico.
Como puede ver en el gráfico, el rendimiento en la primera iteración está en todas partes. Si bien el rendimiento promedio de escritura es decente (91 MB / s), hay muchos fragmentos de 128 MB que se escriben mucho más lentamente en el disco. Por la iteración 2, sin embargo, las cosas están empezando a mejorar drásticamente. El rendimiento promedio de escritura ha aumentado a 115 MB / seg. En la iteración 5, las cosas empiezan a asentarse y, en ese momento, parece que observo un comportamiento asintótico en el rendimiento de escritura.
Sin embargo, lo que queda de todas las iteraciones es una banda de bloques que se encuentran en los 40 altos para el rendimiento de escritura. Incluso al final de la prueba, 130 bloques se encuentran en el sector de menor rendimiento. Esto se ha mejorado enormemente desde la primera iteración, donde 2,294 bloques están por debajo del límite de especificación. Si agrego un filtro de datos locales a Graph Builder, puedo concentrarme solo en la primera y última iteración y comparar el rendimiento. Si bien el rendimiento de escritura parece ser muy variable en la iteración 1, en la iteración 8, hay tres bandas rectas que indican un rendimiento constante en todos los sectores probados de la unidad. La causa de los sectores de menor rendimiento es todavía un misterio para mí, pero sospecho que puede ser algo en el sistema operativo, donde el programa está siendo interrumpido por alguna otra tarea del sistema que causa una caída en el rendimiento medido. (Si alguien tiene una mejor hipótesis, déjala en los comentarios).
Entonces, esta gran pregunta es: "¿Funcionó?" Bueno, me complace informar que sí lo hizo. Después de ejecutar el procedimiento de reacondicionamiento y reinstalar la unidad en mi computadora portátil, mi puntaje Geekbench regresó a 2,900 / 9,500, que es lo que debería esperar dadas las especificaciones de mi hardware. Y la drástica caída en la velocidad que noté en mi computadora ya no existe.
