Reducir el espacio de almacenamiento eliminando la caché de Mastodon y una conversación sobre MinIO y LocalStack
Hola, soy Incompetente.
Un problema que inevitablemente surge al construir una instancia de Mastodon es el problema del almacenamiento.
Dado que se obtiene toda la información de otros servidores, su crecimiento es incontrolable.
Así que encontré un script que parece bueno.
Scripting en Bash
Al parecer, se puede eliminar todo de una vez con tootctl, que está disponible desde Mastodon v4.1 en adelante.
Improving Mastodon’s disk usage
Así que lo cambié a 1 día y lo copié tal cual a continuación.
#!/bin/bash
# Podar cuentas remotas que nunca interactuaron con un usuario local
RAILS_ENV=production /home/sns/mastodon/bin/tootctl accounts prune;
# Eliminar estados remotos con los que los usuarios locales nunca interactuaron, con más de 1 día de antigüedad
RAILS_ENV=production /home/sns/mastodon/bin/tootctl statuses remove --days 1;
# Eliminar archivos adjuntos de medios con más de 1 día de antigüedad
RAILS_ENV=production /home/sns/mastodon/bin/tootctl media remove --days 1;
# Eliminar todos los encabezados (incluidas las personas que sigo)
RAILS_ENV=production /home/sns/mastodon/bin/tootctl media remove --remove-headers --include-follows --days 0;
# Eliminar vistas previas de enlaces con más de 1 día de antigüedad
RAILS_ENV=production /home/sns/mastodon/bin/tootctl preview_cards remove --days 1;
# Eliminar archivos no vinculados a ninguna publicación
RAILS_ENV=production /home/sns/mastodon/bin/tootctl media remove-orphans;
Tarda demasiado, así que todavía no puedo determinar cuánto espacio de almacenamiento se liberará ^^;
Almacenamiento de objetos doméstico ideal
Recientemente, he estado pensando en tener un servidor de almacenamiento separado del servidor de producción.
Las razones son las siguientes:
- Cuando se almacenan archivos grandes en un disco separado, el kernel de Linux se bloquea con errores de E/S de disco cuando el disco falla.
- Independencia del sistema de archivos
- Es más claro separarlo de los binarios ejecutables.
Hay otras razones, pero en resumen, son las mencionadas anteriormente.
En particular, he aprendido que los errores de E/S del primer punto pueden bloquear el sistema incluso al reiniciar, lo que a veces requiere la extracción directa del disco (aunque es posible evitarlo modificando y compilando los parámetros del kernel), por lo que parece necesario hacerlo.
En cuanto a la independencia del sistema de archivos, me gustaría usar el robusto ZFS, pero el ZFS disponible en entornos Linux es una copia pseudo, por lo que no es un ZFS completo.
Si se desea usar ZFS, es necesario configurar y usar un entorno FreeBSD.
En cuanto a RAID, es aún más complejo y no lo haré porque existe la posibilidad de que no se pueda recuperar si la tarjeta RAID falla.
Por lo tanto, quiero usar FreeBSD como servidor de almacenamiento de objetos.
En cuanto a que es más claro separarlo de los binarios ejecutables, es simplemente que, al considerar la distribución, quiero construir un entorno separado como un área de almacenamiento de uso general, similar a Plan9 en el pasado.
Si solo se trata de ejecutar programas, no se necesitan cientos de GB ni varios TB.
MinIO y LocalStack
LocalStack parece poder emular AWS S3, pero la versión gratuita no es persistente y tiene limitaciones.
Como almacenamiento de objetos más OSS, MinIO parece ser una buena opción si se va a implementar en un servidor real.
LocalStack: Para usar un entorno simulado de AWS S3 temporalmente, como en entornos de desarrollo.
MinIO: Para construir un servidor como almacenamiento de objetos.
Parece que deben usarse de forma diferente.
Por lo tanto, construiré un servidor MinIO.
Hasta la próxima. Saludos.