¿Debería deshabilitar el archivo de página con SSD?

He estado leyendo esta pregunta y tiene mucha información excelente.

Pero suponiendo que tenga más que suficiente RAM, creo que el archivo de página debería estar desactivado en SSD para extender la vida útil. Sé que perderías el volcado del núcleo en caso de bloqueo, pero no mucha gente necesita esa información.

Según tengo entendido, sin un archivo de página, a medida que alcanza el límite de su RAM, eso podría desencadenar una paliza en el disco. Pero para los SSD no existe el concepto de golear, las lecturas son rápidas.

¿Qué piensan ustedes?

Pero suponiendo que tenga más que suficiente RAM, creo que el archivo de página debería deshabilitarse en SSD para extender la vida útil. Sé que perderías el volcado del núcleo en caso de bloqueo, pero no mucha gente necesita esa información

Esto suena más bien como una optimización prematura. No ha discutido qué SSD planea usar, y sin mirar realmente la carga de trabajo de su servidor y su hoja de datos SSD planificada, no puede tener idea de qué efecto tendrá un archivo de página en la vida útil de su SSD.

También hay un gran volumen de información errónea, tanto en Internet como en la falla del servidor, acerca de los SSD que sufren de poca vida útil. Los SSD de los primeros modelos pueden haber tenido problemas, y las unidades flash USB definitivamente comienzan a degradarse, pero los SSD de clase empresarial tienen algoritmos de nivelación de desgaste mucho mejores y algunos utilizan flash de repuesto para mejorar el rendimiento y el desgaste.

Las unidades Intel X25-E , por ejemplo, reclaman una duración de escritura de 1 petabyte de escrituras aleatorias para la unidad de 32 GB. Si está saturando la interfaz de escritura (200 MB / seg) sin parar, con sobrescritura, mi estimación es que durará unos 58 días. Pero eso está escribiendo algo así como 17 TB de datos por día en esa unidad.

La carga de trabajo típica del servidor en la unidad del sistema operativo será mucho, mucho menos, incluso si tiene un archivo de página. Llámalo 50 GB por día. Si la cifra de 1 PB es precisa (y sé que puede considerarse una cifra promedio, más discusión más adelante), todavía está en algún lugar al norte de 50 años.

Esas cifras parecen ridículamente altas, por supuesto, así que echemos un vistazo a las cifras reales citadas por Intel para la longevidad esperada de las unidades . Intel estaba feliz de calificar las unidades MLC (no empresariales) para escribir 100 GB de datos, todos los días, durante cinco años. La comprensión estándar del flash SLC vs. MLC dice que el flash SLC dura aproximadamente 10 veces más que el MLC (el enlace anterior también muestra esto en un gráfico).

La verdad se confirmará con el tiempo, por supuesto: comenzaremos a ver que las unidades fallan temprano o no lo haremos. Pero los números detrás de las unidades se suman a la longevidad unidad no ser un problema con los SSD de calidad decente en absoluto .

Si está utilizando un SSD MLC, quizás tenga razón en preocuparse. Pero tenga en cuenta que si Intel está feliz de calificar la unidad a 100 GB / día durante cinco años, eso sigue siendo básicamente lo mismo que 50 GB / día durante 10 años. Y, volviendo a mi punto original, aún necesita saber qué tipo de carga de trabajo real va a hacer en el disco.

Personalmente, diría firmemente que no use un SSD MLC en un entorno de servidor de producción. Si un SSD SLC decente es demasiado costoso, quédese con discos giratorios por ahora.

(Por otro lado, si hace los números, digamos 100 GB por día durante 50 años, que es la calificación "SLC dura 10 veces más que MLC", parece que Intel dice que su unidad de 32 GB tiene una vida útil total de escritura de más cerca de 2 PB de datos, no el 1 PB citado en la especificación del producto. Incluso si solo confío en el menor de esos dos valores para estar feliz de que mis unidades X25-E duren más de 10 años.

Además de que la longevidad probablemente no sea un problema, como menciona Daniel Lawson, y los comentarios del propio equipo de EM (a continuación), considere

1. El archivo de paginación solo se usará cuando sea necesario de todos modos
2. Si se utiliza el archivo de paginación , tenerlo en el SSD frente a un disco duro giratorio hará una gran diferencia

¿Se debe colocar el archivo de paginación en SSD?

Sí. La mayoría de las operaciones de archivos de paginación son lecturas aleatorias pequeñas o escrituras secuenciales más grandes, que son tipos de operaciones que los SSD manejan bien.

Al observar los datos de telemetría de miles de trazas y centrarnos en las lecturas y escrituras de archivos de paginación, encontramos que

• Pagefile.sys lee más de 40 Pagefile.sys escribe alrededor de 40 a 1
• Los tamaños de lectura de Pagefile.sys suelen ser bastante pequeños, con un 67% inferior o igual a 4 KB y un 88% inferior a 16 KB.
• Las escrituras de Pagefile.sys son relativamente grandes, con un 62% mayor o igual a 128 KB y un 45% con un tamaño exacto de 1 MB. De hecho, dados los patrones de referencia de archivos de paginación típicos y las características de rendimiento favorables que tienen los SSD en esos patrones, hay pocos archivos mejores que el archivo de paginación para colocar en un SSD.

Soporte y preguntas y respuestas para unidades de estado sólido (MSDN)

En lugar de deshabilitar el archivo de paginación por completo, puede ser útil decirle al sistema operativo que no lo use (por ejemplo sysctl vm.swappiness=0).

El sistema operativo evitará usarlo a menos que sea necesario, guardando las escrituras innecesarias del SSD.

Dejaría el archivo de página habilitado siempre; ciertas partes de su sistema operativo o aplicaciones pueden estar escritas para esperar que haya una allí, y como tal pueden comportarse mal si no hay una.

Habiendo dicho eso, he ejecutado Windows (XP) sin un archivo de página en el pasado, y ha sido perfectamente feliz con todo lo que le lancé. Sin embargo, siempre existía la duda de que surgiría algo que no le gustaría.

Una opción podría ser configurarlo realmente pequeño.

Esto no responde directamente al OP, pero quería corregir una impresión errónea en la respuesta / comentarios anteriores de Ronald y Daniel. (Soy nuevo, así que no tengo suficientes puntos para comentar).

TRIM es, de hecho, lo más importante que puede hacer para extender la vida útil de un SSD. He aquí por qué: las SSD periódicamente "recolectan basura": copie los datos (fragmentados) de bloques de borrado parcialmente vacíos y escríbalos de forma contigua en un bloque recién borrado.

Las direcciones se reasignan para que el host no tenga que darse cuenta de esto. Esta actividad de escritura adicional, no directamente asociada con las escrituras del host, se denomina "amplificación de escritura". En el peor de los casos de un SSD completamente lleno con una pequeña cantidad de espacio sobreaprovisionado (espacio oculto), la amplificación de escritura puede estar fácilmente en el rango de 500% - 700% de la velocidad de escritura del host.

Durante la recolección de basura, el SSD no se molesta en copiar y reescribir páginas que han sido invalidadas (sobrescritas o recortadas), ahorrando una gran cantidad de trabajo y actividad de escritura. Si el sistema de archivos borra un archivo grande, pero no informa a la unidad a través de TRIM, la unidad continuará copiando esos datos borrados, desperdiciando escrituras, indefinidamente (o hasta que esas direcciones de bloque se asignen a algún otro archivo, que podría ser mucho tiempo)

En resumen, TRIM es realmente importante tanto para la longevidad como para el rendimiento.

Lo dije en la otra publicación que vinculaste, pero ejecutamos un servidor de línea principal sin un archivo de paginación y todo aquí parece estar bien. De hecho, parece más rápido sin él. Tenemos 8 GB de RAM y diría que debe tomar una decisión en función de si tiene mucha RAM, no de si su disco duro es un SSD o no. Aunque puedo entender el deseo de salvarle la vida al no hacer escrituras innecesarias.

Simplemente use un segundo disco duro para la memoria virtual.

He estado ejecutando una computadora portátil con 8 GB de RAM, unidad SSD única y sin archivo de página, durante más de un año, sin problemas. Me encontré con un juego que requería el archivo de la página, fui al sitio web del software y obtuve el comando de ejecución para deshabilitarlo, problema resuelto.

Mi laptop tiene cuatro años. Antiguo, pero funciona más rápido que algunos escritorios que son más nuevos. La pérdida de memoria, también conocido como archivo SWAP, ha sido el problema con el sistema operativo Windows desde la creación de la técnica. Desafortunadamente, los desarrolladores de Linux siguieron sus pasos. Cuanto menos software esté ejecutando en segundo plano, mejor (especialmente si es de Microsoft).

Yo diría que no use el intercambio, si puede salirse con la suya. O tal vez reducir el intercambio hacia abajo. Si bien es difícil usar uno (¿cuánto tiempo tomaría escribir en la unidad completa 100,000 veces, con el ancho de banda máximo que tiene?), Si no lo necesita.

Por otra parte, hibernar (suspender en disco) no funciona sin algún tipo de intercambio.

Solía ​​haber algún comportamiento extraño sin intercambio (como en un disco RAM de 50 MB para intercambiar sería una victoria), pero eso fue parcheado el verano pasado (¿o fue 2007?), Por lo que un sistema operativo actual debería estar bien.

Ahora todo lo que necesitamos es hardware que admita el comando de borrado (Linux lo ha admitido durante meses), y la vida en SSD será excelente.

Me han quemado dos SSD de clase empresarial muy prematuramente (es decir, dentro del período de garantía). Creo que la razón fue un fuerte intercambio debido a la paliza. A menudo me di cuenta de que tenía procesos innecesarios en ejecución / daemons con errores con pérdidas de memoria, de modo que había una gran actividad de intercambio casi continuamente. Ejecuto iostat -n9 -w 10en segundo plano de vez en cuando y noto que a menudo hay una actividad continua de disco pesado. Además, la actividad del proceso del kernel (intercambio) se registró como la fuente de la mayoría de las E / S. Recuerdo un demonio que tuvo una pérdida de memoria durante meses y que necesitaba matar periódicamente. A menudo no soluciono los problemas a menos que el sistema sea molestamente lento, por lo que la agitación continuó durante mucho tiempo antes de que me tomara el tiempo de reiniciar el demonio. Y más tiempo para que se repare la fuga.

Si bien deshabilitar el intercambio llamaría mi atención sobre la paliza, por lo que el problema se abordaría antes de que ocurriera un desgaste importante en el SSD, está lejos de ser la mejor manera de evitar dicho daño; cualquier herramienta de monitoreo / alerta decente sería mejor.

Una advertencia que muchas de las respuestas no reconocen es que si un servidor está agitando un SSD de forma continua, se quemará bastante rápido: el agotamiento dentro de un año en esta situación es común. La agitación clásica generalmente ocurre cuando el intercambio de memoria virtual es lo suficientemente pesado como para mantener la unidad (intercambio) ocupada principalmente, dentro de un orden de magnitud de su ancho de banda de E / S máximo, y hay al menos un proceso esperando una E / S relacionada con el intercambio O para completar la mayor parte del tiempo que el sistema está en ese estado. Las otras respuestas suponen que el sistema no espaliza, al menos no de la manera clásica; o confiar en un malentendido de lo que es la paliza. Y esa suposición falsa, a pesar de otros datos precisos, conduce a respuestas incorrectas en cuanto a por qué la paginación, incluso cuando un SSD es la única ubicación posible para el archivo de intercambio, es mejor dejarlo habilitado.

Deshabilite el archivo de paginación en el disco cuando tenga mucha memoria sin usar. Algunos programas antiguos exigen una funcionalidad de archivo de paginación y para esos Windows crearán una pequeña funcionalidad de archivo de paginación en la memoria.