Ha tornat a caure. Hi ha quelcom que ho fa petar…
Avui cap vespre mos podam quedar. Sobre les 20h et va be?
Opps. no puc. Dimecres cap vespre?
Dimecres no puc, ho sento. Demà?
Igualment, em ficaré a dins a revisar logs avui.
Ahir vaig estar revisant i tot i que com diu en @tuttle sembla de la base de dades, no sé com continuar.
Hem de fer alguna cosa.
Hem de estudiar be el assumpte (grrr). Aquests dies no crec que trob ni els temps ni s’energia. Pot ser que algun altre que coneixem pot donar-mos un cop de mà?
1 'M'agrada'
En algun lloc vaig llegir que amb el temps, la base de dades de Pleroma es va omplint més i més de brossa, no sé si podria ser el cas. Alguns dels desenvolupadors deien que era molt difícil sol·lucionar-ho, que caldria refer tot el concepte de dalt a baix.
Jo provaria fer-li un repack a la base de dades sencera, tinc una guia de com es fa aquí: pg_repack, com reduir l'espai en disc que ocupa una base de dades Postgresql — spla però cal canviar les taules per les de pleroma, és clar.
Tot i així no hi ha garanties de que s’arregli per el que deien els desenvolupadors, no és la típica brossa de qualsevol base de dades Postgresql sinó que Pleroma desa en la base de dades coses que no hauria de desar.
1 'M'agrada'
Estic provant el que proposa l’spa, @tuttle . A veure si ho soluciona una mica. De moment la base de dades ocupa 17 Gb abans de fer res.
Per cert, @spla, m’ha costat una mica pillar que pg_repack -x -d <base de dades> --table <taula> era ja fora de postgres (tot i que ho podria haver deduït per l’absència de “;” al final i per l’script).
Ja ha acabat.
S’ha reduit de 17 Gb a 13 Gb. No sé si serà suficient…
Vaig a reiniciar el servei de pleroma.
Res, no ha tardat ni un minut a tornar a petar. 
bé, s’havia de provar. Quin error dona?
1 'M'agrada'
Doncs des de pleroma, això que posava més amunt:
Des de la base de dades, no hi puc accedir ara que sóc a la feina. Ho reviso quan arribi a casa.
Segons diuen aquí podeu provar diversos valors de la variable pool_size fins a trobar un que li agradi.
Cal afegir la variable a config/prod.secrets.exs (no deu ser-hi), per exemple:
config :pleroma, Pleroma.Repo,
adapter: Ecto.Adapters.Postgres,
pool_size: 10,
…
Si amb 10 segueix donant l’error provar 15 i així anar pujant fins que ja li agradi. Hi ha un altre variable que també pot ajudar segons diu l’error. En la pàgina que he enllaçat la tenen posada:
queue_target: 5000
També es pot afegir sota de pool_size si és que provant diferents valors de pool_size no es sol·luciona.
1 'M'agrada'
Gràcies!
El tuttle va estar provant alguna costa, no sé si alguna d’aquestes.
1 'M'agrada'
A veure si hi ha sort!
1 'M'agrada'
Encara pots avui? M’han anul·lat l’assaig…
He provat algunes coses (com la que proposava l’spla), però crec que ja les havia provat el tuttle.
No se m’acut molt més… No sé si tornar a instal·lar i utilitzar la mateixa bbdd serviria, si el problema és la bbdd…
Podeu provar de pujar el valor max_connections del propi servidor de base de dades Postgresql. Aquest paràmetre és 100 per defecte però el podeu provar de pujar a 150 o 200 si cal. El trobareu en el fitxer de configuració de Postgresql. Per exemple, a Ubuntu Server 22.04 el fitxer és a:
/etc/postgresql/14/main/postgresql.conf
Si canvieu el valor, cal reiniciar Postgresql.
Per a mastodont.cat el vaig haver de pujar a 350:
max_connections = 350
1 'M'agrada'
Ho podem provar. D’aquí hem tret:
shared_buffers = 512MB
effective_cache_size = 1536MB
maintenance_work_mem = 128MB
work_mem = 26214kB
max_worker_processes = 2
max_parallel_workers_per_gather = 1
max_parallel_workers = 2
Alguns valors els hem pujat més encara.
Hi ha una pàgina genial per a afinar un servidor Postgresql:
1 'M'agrada'