Conversation
Notices
-
Definitivamente he aprendido hoy que cuando haga los respaldos diarios del nodo !bobinas haré a la vez una pausa de todos sus servicios #gnusocial , debe ser cosa rápida y casi ni se notará en las horas mas bajas de actividad. Al fin y al cabo todo en la vida se reinicia, se duerme o se reestablece de una forma u otra.
- Toni repeated this.
-
Parar el que? No deberia hacer falta hacerlo.
-
Si lo se, te comprendo y comparto misma idea, pero es la segunda (o tercera) vez que sucede lo mismo, se llena toda ram, se llena todo swap y hay que reiniciar manualmente el script de #gnusocial, una vez esto va recuperando la cola pendiente y va enviando por xmpp lo que no hizo horas antes. Debe ser algún detalle (o desajuste) pero no llego a ese nivel para confirmar cual es. /cc @drymer
-
De hecho hay una similitud enorme con #loadaverage, dejas de recibir mensajes xmpp del nodo, pasan unos días y de pronto te llegan todos de golpe y sigue como si nada hubiera pasado. Eso lo sabemos los que nos gusta usar gnusocial por medio del xmpp. /cc @drymer
-
@xikufrancesc creo que @fanta hace un tiempo publicó una forma de no cargar demasiado la bbdd al hacer un volcado de la misma
-
Excelente, preguntaré a @fanta cual es el método, aunque me quedo con la eterna duda de que problema estamos hablando, ¿es la base de datos?, ¿es gnusocial?, ¿es xmpp al interactuar con gnusocial?, ¿es cuando se respalda?, o sea me pregunto cual es "el quid de la cuestión". /cc @imojito
-
@imojito aquí va adjunto. https://linuxinthenight.com/attachment/46569
-
@fanta gracias! cc @xikufrancesc
-
@fanta @imojito y si lo añades al crontab ya ni te cuento , pero para ellos hay que escribir mysql -u debian-sys-maint -plapuñeteracontraseñapegada nombredelabasededatos | gzip.... blblablalblba
-
Ah ya veo, el detalle es --single-transaction y --quick (uno lo había visto, el otro no), lo probaré esta noche a ver que tal. Gracias @fanta /cc @imojito
(Por cierto, mientras el queuedaemon sigue corriendo, por xmpp me sigue llegando mensajes que hace tres horas fueron escritos, a ver cuando termina de sincronizar todo.)
-
@xikufrancesc el script de stopdaemons se recomienda siempre antes de actualizar para que no se corrompa base de datos y no se pierdan datos. Para dumps con el single transaction el load average no se dispara y no hace falta parar. Puedes comprobar peticiones con mytop en tiempo real y también controlar el crecimiento de la base de datos en /var/mysql/ con du -ha en las tablas afectadas. Comprueba no tengas el debug Gnusocial activo. Si no puede con la carga es buena cosa separar mysql a otra máquina o incluso pensar en un cluster con un balanceo round robin. GNUSOCIAL cuando crecen los usuarios empieza a precisar de cachear en ddbb y servidor nginx al menos el directorio avatar y files.
-
@xikufrancesc Como haceis el backup?
-
Con pandilla4gatos.tk siempre se respaldaba con un cron programado a las 23:50pm y con esta orden : "mysqldump -u root --password=holaguapo gnusocial | gzip > /home/pandilla/$archivo"
con algún error inicial pero luego todo bien.
Esta noche trataré de respaldar en mismo cron pero con "mysqldump --single-transaction -quick -u bobinas --password='holaguapo' gnusocial | gzip > /home/pandilla/respaldosclub/$archivo"
El problema real ahora no es el respaldo, sino ver porque "queuedaemon" sigue corriendo y consumiendo procesador y disco duro. /cc @drymer
-
Orale mil gracias @fanta, obvio son excelentes consejos y tengo que ver eso con calma, sin ser pesado me confirmas el beneficio de cerrar registro y poco a poco ir viendo como reacciona no solo la máquina, sino como afecta y como conservar todo, ya que de plano somos humildes y no nos podemos arriesgar a crecer o guardar muchas cosas sin sentido, de ahí la decisión (previamente consultada) de no admitir adjuntos en el nodo para no hacerlo mas complejo. Voy a revisar tal como dices. Saludos.
-
@xikufrancesc En mi caso en mi nodo no tengo abierto registro para poder quitar el nodo cuando quiera y no afectar a terceros pero veo lógico que habilitéis las invitaciones o cerréis registro inicialmente para ir abriendo poco a poco o abrir y cerrar cuando no se quiera más gente. Lo importante supongo es que al final sean quienes sean los usuarios del nodo estos tengan una gnusocialización de calidad.
Por otro lado también existe la opción de aceptar adjuntos pero que estos pasan por 3 fases (2 scripts en cron). Fase 1: 6 meses las imágenes se ven, Fase 2: las imágenes de más de 6 meses sufren una bajada de calidad con imagemagick, Fase 3: al cabo de 6 meses se eliminan. Eso te da un año de permanencia de las imágenes. En cierto modo el timeline es como la memoria, lo de hace un año se va desechando para permitir nuevos recuerdos :).
Xiku Francesc
drymer #en proceso de migrar
Kermit Unchained
fanta ahora en fanta@asocial.56k.es
admin de gnusocial.net
All Bobinas P4G content and data are available under the 