Deshabilitar el intercambio es una buena idea si
- su software puede lidiar con condiciones de falta de memoria con gracia o se limita a evitar situaciones OOM
- tener un rendimiento constante es fundamental (cuando su sistema está cambiando, la latencia aumentará, lo que puede ser lo suficientemente malo como para que sea inútil para muchas aplicaciones)
Este tipo de cosas sucede a menudo con las bases de datos. Lo veo más con bases de datos noSQL, pero las bases de datos relacionales pueden sufrir el mismo desafío.
No hay nada en el sistema operativo que requiera intercambio para estar allí. Linux se ocupa de esto con bastante gracia al eliminar el último proceso que solicitó memoria. No desea llegar a ese punto, así que asegúrese de ajustar Oracle para usar solo ~ 90% de la memoria, de modo que quede algo para los demonios del sistema y el margen de error. La memoria "libre" también se usa para el almacenamiento en búfer de E/S de disco, lo que es una gran ganancia de rendimiento, por lo que tratar de consumir más memoria por parte de la propia base de datos eventualmente ralentizará el rendimiento general del sistema lo suficiente como para ser contraproducente.
Incluso con los sistemas que tienen una fracción de la memoria de la pregunta si la aplicación es una base de datos o un caché o un sistema similar, por defecto no cambiaría en este momento.
Autoridades
Para que no solo confíes en mi palabra:
Casandra
Datastax explica a Cassandra:
Debe deshabilitar el intercambio por completo. El no hacerlo puede disminuir severamente el rendimiento. Debido a que Cassandra tiene varias réplicas y una conmutación por error transparente, es preferible que una réplica se elimine inmediatamente cuando la memoria esté baja en lugar de entrar en intercambio. Esto permite que el tráfico se redirija inmediatamente a una réplica en funcionamiento en lugar de continuar llegando a la réplica que tiene una latencia alta debido al intercambio. Si su sistema tiene mucha DRAM, el intercambio aún reduce significativamente el rendimiento porque el sistema operativo intercambia el código ejecutable para que haya más DRAM disponible para almacenar en caché los discos.
riak
Basho le explica a Riak que debes:
Idealmente, debe deshabilitar el intercambio para asegurarse de que las páginas de proceso de Riak no se intercambien. Deshabilitar el intercambio permitirá que Riak se bloquee en situaciones en las que se quede sin memoria. Esto dejará un archivo de volcado de memoria, llamado erl_crash.dump , en el /var/log/riak directorio que se puede utilizar para determinar la causa del uso de la memoria.
mysql
Percona está sentado en la cerca y proporciona advertencias útiles para ambos lados de la pregunta. MariaDB no está de acuerdo con deshabilitar el intercambio:
Si bien algunos deshabilitan el intercambio por completo, y ciertamente desea evitar que los procesos de la base de datos lo usen, puede ser prudente dejar algo de espacio de intercambio para al menos permitir que el kernel se caiga con gracia en caso de que ocurra un pico. Tener un intercambio de emergencia disponible al menos le permite cierto margen para eliminar cualquier proceso fuera de control.
Error del servidor
Una respuesta bien recibida aquí incluye:
Personalmente, encuentro un sistema intercambiable peor que un sistema bloqueado. Un sistema colapsado activaría un servidor de respaldo en espera para tomar el control mucho antes. Y en una configuración activa-activa (o de equilibrio de carga), un sistema bloqueado se retiraría de la rotación mucho antes. Una victoria para el sistema de no intercambio nuevamente.
Esa respuesta tiene 22 votos a favor hoy y tiene 4 años. También puede ver algunas otras respuestas que exaltan el valor del intercambio, pero no hay indicios de que estén ejecutando bases de datos. Tampoco tienen tantos votos a favor. :)
calamar
Si bien no recomiendan abiertamente deshabilitar el intercambio, los chicos del calamar dicen:
Squid tiende a ser un poco acaparador de memoria. Utiliza la memoria para muchas cosas diferentes, algunas de las cuales son más fáciles de controlar que otras. El uso de la memoria es importante porque si el tamaño del proceso de Squid excede la capacidad de RAM de su sistema, algunas partes del proceso deben intercambiarse temporalmente en el disco. El intercambio también puede ocurrir si tiene otras aplicaciones que consumen mucha memoria ejecutándose en el mismo sistema. El intercambio hace que el rendimiento de Squid se degrade muy rápidamente.
Eso es lo que no quiere que le suceda a su base de datos.
redis
Si bien redis recomienda oficialmente el intercambio, los usuarios no lo compran:
Primero deshabilite el intercambio:Redis y el intercambio no se mezclan fácilmente y esto ciertamente puede causar lentitud.
hadoop
Como se ve en esta respuesta con más votos en la comunidad de hortonworks:
Para hosts esclavos/trabajadores/datos que solo tienen servicios distribuidos, es probable que pueda deshabilitar el intercambio. Con los servicios distribuidos, es preferible dejar que el proceso/host se elimine en lugar de intercambiar. La eliminación de ese proceso o host no debería afectar la disponibilidad del clúster. Dicho de otra manera:quieres "fracasar rápido" y no "degradarte lentamente".
[....]
Para maestros , el intercambio también suele estar deshabilitado, aunque no es una regla establecida de Hortonworks y supongo que habrá alguna discusión/desacuerdo. Los maestros se pueden tratar de la misma manera que se trataría a los maestros en otros entornos que no sean de Hadoop.
El temor de deshabilitar el intercambio en maestros es que un evento OOM (memoria insuficiente) podría afectar la disponibilidad del clúster. Pero eso aún sucederá incluso con el intercambio configurado, solo que tomará un poco más de tiempo. Las buenas prácticas del administrador/operador serían monitorear la disponibilidad de RAM y luego solucionar cualquier problema antes de quedarse sin memoria. Manteniendo así la disponibilidad sin afectar el rendimiento. Entonces no se necesita intercambio.
Me gusta esto porque habla de una aplicación Java, pero llega a muchas de las mismas conclusiones mencionadas anteriormente sobre las bases de datos. Además, menciona monitoreo lo cual es muy útil para ajustar aplicaciones de alto rendimiento. Si no tienes números para comparar, todo se basa en sentimientos que son más difíciles de comparar. Cree gráficos para cada métrica medible:latencia a nivel de aplicación y rendimiento hasta gráficos de CPU, disco, memoria y red. Esos proporcionan la mayor parte de los datos reales sobre los que tiene que tomar decisiones.