[07:19:47]
<Maranda> @resync
[07:30:51]
<Maranda [A]> > <@mzan:matrix.org> Ai tempi del telegrafo c'era forse meno banda, ma anche meno latenza!
Il problema sono gli aggiornamenti che stanno facendo, l'aumento delle utenze sul server e lo storage del server che forse è troppo lento.
[07:35:24]
<Maranda [A]> Per ogni transazione dal DB l'IOWAIT progressivamente sta aumentando, ma di sicuro non vado a sostituire lo storage con degli SSD server-grade, che mi costerebbero un rene e mezzo, perché qualcuno non sa scrivere codice.
[07:43:31]
<ermanno> adesso c'è il nuovo HS di libera.chat e migliaia di nuovi utenti che migrano ma non penso che c'entri ....... In pratica libera.chat è completamenta bridged in matrix, basta aggiungere libera.chat nella lista dei server per vedere tutti i canali
[07:55:31]
<Maranda [A]> No non c'entra nulla
[07:56:12]
<Maranda [A]> Hanno fatto delle modifiche al codice al quanto deleterie
[07:59:23]
<Maranda [A]> Che stanno avendo un effetto a catena, e visto che interessano tutti i server configurati per utilizzare i worker direi che è un problema perché parliamo di quasi tutti i server pubblici
[08:35:46]
<ermanno> > <@maranda:aria-net.org> Che stanno avendo un effetto a catena, e visto che interessano tutti i server configurati per utilizzare i worker direi che è un problema perché parliamo di quasi tutti i server pubblici
Ma in effetti tutto quel casino con redis per aggirare le limitazioni di python sui multiprocessori non mi ha mai convinto. Per fortuna basta monolitico per me da solo....
[08:43:21]
<Maranda [A]> > <@ermanno:erm67.dynu.net> Ma in effetti tutto quel casino con redis per aggirare le limitazioni di python sui multiprocessori non mi ha mai convinto. Per fortuna basta monolitico per me da solo....
Il problema in realtà non è neanche Python ma Twisted se vogliamo dirla tutta, e utilizzare Redis per le replica e lo scambio IPC va benissimo... se solo non fosse tutto ciò che sta a latere è un mezzo disastro.
[08:43:27]
<ermanno> Comunque ieri ho trovato la room synapse-announcements con più di 10 miliardi di state changes, dopo 2 ore ho cancellato compress-state e eliminato la stanza. 6GB liberati sul server postgres ... Va molto più veloce adesso.
[08:43:52]
<Maranda [A]> > <@ermanno:erm67.dynu.net> Ma in effetti tutto quel casino con redis per aggirare le limitazioni di python sui multiprocessori non mi ha mai convinto. Per fortuna basta monolitico per me da solo....
Il problema in realtà non è neanche Python ma Twisted se vogliamo dirla tutta, e utilizzare Redis per le replica e lo scambio IPC va benissimo... se solo non fosse tutto che tutto ciò che sta a latere è un mezzo disastro.
[08:44:06]
<ermanno> SELECT room_id, count(*) AS count
FROM state_groups_state
GROUP BY room_id
ORDER BY count DESC;
[08:44:13]
<ermanno> prova questa query
[08:47:14]
<Maranda [A]> Non è necessario ho pulito gli stati non referenziati ieri
[08:48:29]
<ermanno> Si ma comunque non è normale che arrivi a 10 miliardi in una settimana
[08:49:15]
<Maranda [A]> E non posso comprimere lo stato, il DB inizia ad avere una discreta dimensione ci impiegherei una vita
[08:49:40]
<Maranda [A]> A 10 miliardi ci sono arrivato dopo mesi
[08:50:04]
<Maranda [A]> !ping
[08:51:38]
<Maranda [A]> !ping
[08:54:35]
<Maranda [A]> Finché sta assestato su questo livello è una merda quasi accettabile a dir il vero
[08:55:01]
<Maranda [A]> Vediamo come progredisce la situazione
[08:55:33]
<katyusha (IRC)> pong
[09:09:09]
<ermanno> > <@maranda:aria-net.org> E non posso comprimere lo stato, il DB inizia ad avere una discreta dimensione ci impiegherei una vita
Cancella la stanza e ricreala :-) funziona
[09:10:11]
<ermanno> Da synapse admin, con delete content
[11:36:14]
<Maranda [A]> ermanno: non è un ragionamento che si può fare. Se cancello le stanze butterei fuori le persone che stanno dentro
[11:38:48]
<Maranda [A]> Le uniche operazioni accettabili sono pulire gli stati dereferenziati e le copie delle stanze inutilizzate, cose già tutte fatte
[11:41:08]
<Maranda [A]> L'unica cosa da fare al momento è attendere la prossima release che dovrebbe avere i fix per i problemi di replicazione e send_join
[13:05:06]
<tech_exorcist (IRC)> [2021-05-29T00:27:17+0200] <mzan{m}> Ai tempi del telegrafo c'era forse meno banda, ma anche meno latenza! | sono d'accordo
[13:05:54]
<mzan> Maranda > Per ogni transazione dal DB l'IOWAIT progressivamente sta aumentando, ma di sicuro non vado a sostituire lo storage con degli SSD server-grade, che mi costerebbero un rene e mezzo, perché qualcuno non sa scrivere codice.
[13:06:29]
<mzan> Lo scrivo solo perchè l'ho fatto in questa settimana. Mi sono divertito a configurare nel mio computer desktop di lavoro bcache. Ho quindi un HDD + un SSD che fa da cache.
[13:06:43]
<tech_exorcist (IRC)> che ne direste di spostarvi ad IRC invece di usare Matrix, che sembra essere un sistema eccessivamente complesso per un canale testuale con poco meno di 200 utenti, tra persone e bot? 🙂
[13:07:04]
<tech_exorcist (IRC)> potreste usare il bridge OFTC←→Matrix se preferite i client Matrix
[13:07:12]
<tech_exorcist (IRC)> #_oftc_#ita:matrix.org
[13:07:59]
<mzan> tech_exorcist io sono entrato qui solo per vedere come funziona Matrix. Ma per il resto la tua proposta avrebbe senso, dato che uso IRC e mi trovo benissimo.
[13:09:20]
<Maranda> mzan: le parole chiavi sono, per l'appunto, il tuo computer.
[13:09:32]
<mzan> Matrix comunque è un brutto esempio per l'IT: ci hanno buttato dentro milioni di euro, grants vinti a livello EU, e se ne escono con qualcosa di mastodontico e lento. :-/
[13:09:40]
<tech_exorcist (IRC)> mzan: a quali reti sei collegato, e quale nickname usi?
[13:10:02]
<mzan> tech_exorcist irc.libera.chat e mzan come utente
[13:10:09]
<mzan> se fai un ping sono online anche adesso
[13:10:10]
<tech_exorcist (IRC)> ok
[13:10:13]
<tech_exorcist (IRC)> un attimo
[13:10:16]
<mzan> Uso quassel e sono reperibile sempre
[13:10:42]
<tech_exorcist (IRC)> ho dei problemi con l'autenticazione
[13:10:49]
<tech_exorcist (IRC)> e sembra che tu abbia +R
[13:10:56]
<tech_exorcist (IRC)> quindi non posso inviarti messaggi diretti
[13:11:20]
<mzan> tech_exorcist +R mi evita dello SPAM vero?
[13:11:30]
<tech_exorcist (IRC)> assolutamente
[13:11:36]
<mzan> ok allora lo tengo
[13:12:08]
<tech_exorcist (IRC)> ora provo a risolvere quei problemi, tra qualche minuto dovrei aver risolto
[13:12:17]
<mzan> tech_exorcist se vuoi mi ricconneto a freenode, ma alla fine tutti i canali che seguivo si sono trasferiti us irc.libera.chat
[13:12:27]
<tech_exorcist (IRC)> non sono più su freenode
[13:12:53]
<Maranda> Sarebbe un costo in più non giustificabile, poi è un server di produzione dove posso mettere i miei "giocattoli da laboratorio", ma il margine di manovra è limitato fino a che "il giocattolo" non rompe i coglioni alla roba seria.
[13:13:06]
<tech_exorcist (IRC)> a proposito, hanno spostato il bridge Matrix da freenode a libera?
[13:13:56]
<mzan> Maranda no no, ho solo detto la cosa perchè per coincidenza ho fatto l'operazione questa settimana. Tra l'altro entro un mese esce bcachefs sul kernel in stable. Dovrebbe essere ancora migliore di bcache.
[13:14:24]
<mzan> bcache è ottimo dato che memorizza nel SSD tutte le operazioni di scrittuare e poi le replica in modo sicuro sul HDD ma facendo accessi sequenziali. Quindi ottimo se uno ha HDD SMR anche.
[13:15:21]
<tech_exorcist (IRC)> ProtonMail non vuole funzionare ora, prverò dopo a risolvere
[13:15:24]
<mzan> bcachefs lo danno con le features di btrfs e ZFS (più o meno), ma con le prestazioni di XFS.
[13:16:03]
<mzan> Inoltre dovrebbe usare bene i devices moderni.
[13:20:28]
<Maranda [A]> Non lo metto in dubbio ma alla fin della fiera il server in questione ha due processori, 144GB di RAM, 32MB di cache L3 totale, la VM di Synapse ha 32GB allocati e utilizzati forse a meta per una dozzina di utenti simultanei in croce. Deve bastare e pochi cazzi.
[13:24:02]
<Maranda [A]> Se poi fosse in resource starvation posso capire, ma qua è solo perché Synapse e Postgres son due robe fatte col culo e allora no.
[13:26:57]
<mzan> 32GB di RAM solo per Synapse vorrebbe dire che tutte le informazioni più importanti dovrebbero stare in RAM e non su disco
[13:27:08]
<mzan> (in un mondo ideale)
[13:33:36]
<Maranda [A]> > <@mzan:matrix.org> 32GB di RAM solo per Synapse vorrebbe dire che tutte le informazioni più importanti dovrebbero stare in RAM e non su disco
Bravo, e Postgresql è anche lui impostato di conseguenza. E non vanno lo stesso un cazzo ne l'uno ne l'altro, tradotto una mmmerda con tre m.. Alché il mio lavoro è bello che finito tu-tu e adios.
[13:39:49]
<mzan> Boh non so cosa dire. Davanti a questi numeri, mi verrebbe anche da sospettare una qualche configurazione non ottimale: che so dei fsync di troppo, ecc.. Ma non me ne intendo, non ho mai configurato una cosa del genere e quindi me ne sto zitto.
[13:40:52]
<mzan> Cioè preciso: sono numeri talmente incredibilmente schifosi, che non me la sento di sparare a zero contro Synapse, e mi tengo il beneficio del dubbio che forse qualcosa non è configurato bene o c'è una interazione strana nella configurazione della macchina e Synapse.
[13:41:49]
<mzan> Di sicuro Synapse non ne uscirebbe bene ugualmente, ma qua siamo davvero ad una farse. O forse è anche il protocollo Matrix a essere disegnato male. Ma come detto non so.
[13:44:06]
<mzan> Io a volte ho fatto dei lavori che richiedevano delle ottimizzazioni un po' spinte, e a volte rifacendo il codice nel modo giusto, è un attimo migliorare anche di un 100x.
[13:45:20]
<mzan> Se invece fai le cose male, non c'è limite su quanto il codice possa andare lento :-)
[13:48:10]
<mzan> Alcuni settaggi che potrebbero causare errori: uno setta il TRIM/DISCARD del file-system, quando invece è un comando da lanciare da "cron-job" tipo una volta a settimana.
[13:48:27]
<mzan> Il TRIM blocca tutte le altre operazioni, e se fatto in maniera eccessiva deteriora anche la vita dei SSD.
[13:48:38]
<mzan> Se è un HDD invece non centra nulla.
[13:48:42]
<mzan> Ma ne ho detto una tanto per dire.
[13:48:49]
<mzan> Un buffer configurato male di PG.
[13:49:21]
<Maranda [A]> Allora il problema che Postgresql è l'unico dbms in cui la configurazione lato server è quasi del tutto indeterministica, le ottimizzazioni le fai per la maggiore lato client, io di sicuro non mi metto a trafficare con il codice dello storage di Synapse
[13:50:51]
<Maranda [A]> Oltretutto Synapse apre un botto di sessioni e non supporta i bouncer quindi già abbiamo la risposta
[13:51:37]
<mzan> Non ho mai usato PG (e mi dispiace, ne parlano benissimo) ma se ricordo bene, ogni sessione/connessione in PG è un processo a parte.
[13:52:34]
<Maranda [A]> > <@mzan:matrix.org> Non ho mai usato PG (e mi dispiace, ne parlano benissimo) ma se ricordo bene, ogni sessione/connessione in PG è un processo a parte.
Continua a non usarlo con buona pace dei fanboy che ne parlano così bene, ne guadagnerai solamente.
[13:53:49]
<mzan> Beh dai PG ne parlano tutti benissimo, quindi vuol dire che se uno lo usa bene (parlo di Synapse), poi va bene.
[13:54:00]
<mzan> Ovvio che se lo usi male, o non è il tool giusto per quel lavoro, allora tutto degenera.
[13:54:06]
<Maranda [A]> Si è per l'appunto per risparmiare risorse si dovrebbe utilizzare un bouncer che funge da connection manager e riutilizzare le risorse
[13:55:03]
<Maranda [A]> Si è per l'appunto per risparmiare risorse si dovrebbe utilizzare un bouncer che funge da connection manager e riutilizzare le sessioni
[13:55:48]
<mzan> Tipo per un lavoro ho usato MySQL + un engine column-store (TokuDB ora semi dismesso) e le prestazioni sono aumentate a dismisura, perchè per quel tipo di lavoro era l'engine giusto. Ma per select singoli e inserimenti non bulk, TokuDB farebbe schifo. Se usi le librerie e i tools giusti e li usi bene, uno ottiene miracoli.
[13:55:55]
<mzan> Ma se li usi male, le prestazioni crollano.
[13:57:42]
<mzan> Tra l'altro le CPU moderne vanno velocissime, ma se fai troppi context-switch di processi, per loro è come fare il trasloco di una casa, prima di passare ad un nuovo task, e rallentano a dismisura.
[13:57:49]
<mzan> L'hardware moderno va velocissimo fin quando lo usi bene.
[13:57:59]
<mzan> Se lo usi male, regredisce in fretta.
[13:59:12]
<mzan> Per non parlare dei grandi misteri IT. Non ho mai capito a cosa serva lo SWAP in Linux. Tutte le volte che lo SWAP mi è entrato in funzione, il computer si è praticamente bloccato :-)
[13:59:28]
<mzan> Manco ce la metto più la partizione di SWAP.
[13:59:44]
<mzan> Penso che in BSD facciano prima: scelgono un processo che usa troppa RAM o non ritengono utile e fanno kill.
[14:00:08]
<mzan> Meglio buttare giù un processo dalla torre, che crollare tutti insieme!
[14:02:01]
<mzan> Morale della storia: abbiamo dell'hardware che se usato bene, potrebbe rendere 1000, ma per vari motivi lo facciamo rendere 10 o 100. Ed è un serpente che si mangia la coda: un device hardware che potrebbe rendere 1000 se usato bene, implementa un modo compatibile con il passato in cui rende 500 fin quando lo usi in un certo modo ragionevole, ma se esageri rende "10" perchè saltano i trucchi.
[14:03:53]
<mzan> Le stesse CPU di oggi, hanno tanto hardware per farle andare bene con il vecchio codice C, ma loro oramai vorrebbero essere usate in un modo completamente diverso. Ma perpetuano loro stesse la farsa in cui a loro i processi piacciono! :-)
[14:03:58]
<mzan> ok fine del pezzone
[14:04:11]
<mzan> Mi piace a volte ottimizzare il codice, e mi sono fatto prendere la mano :-)
[14:16:52]
<Maranda [A]> > <@mzan:matrix.org> Penso che in BSD facciano prima: scelgono un processo che usa troppa RAM o non ritengono utile e fanno kill.
In Linux il concetto è più o meno simile va a memoria utilizzata e "peso", swap o file di paging chessia evitano che si inneschino i meccanisimi OOM-kill, ma comunque senza entrare in concetti troppo esoterici, io nel ruolo di amministratore di programmazione non devo saper una cippa, devo saper A) eseguire le configurazioni necessarie B) saper intepretare i dati necessari e conoscere i componenti inclusi in modo da consentirmi di stimare adeguatamente il sizing di un determinato deployment C) eseguire il deployment della piattaforma.... fine delle trasmissioni PG piace tanto agli sviluppatori perché è molto versatile e li possono far fare ciò che vogliono, a mio avviso un po' meno agli amministratori perché se ci sono problemi poi l'intervento o lo fai direttamente sull'applicazione che lo utilizza oppure te la butti al culo (con MSSQL ad esempio *non è così*)
[14:18:33]
<Maranda [A]> (Ed è infatti un puro caso che abbia esperienza come sviluppatore e quindi possa comunque fare determinati aggiustamenti)
[14:29:03]
<Maranda [A]> In conclusione, se tu mi dai le informazioni e i requisiti che tu ritieni corretti per la tua applicazione e io eseguo un deployment più che adeguato al compito e poi la suddetta non va un cazzo, delle due l'una o risolvi tu il problema oppure sei uno spaghettaro (nel caso del team di Matrix, sono per la seconda).
[17:33:36]
<Maranda [A]> > <@mzan:matrix.org> Penso che in BSD facciano prima: scelgono un processo che usa troppa RAM o non ritengono utile e fanno kill.
In Linux il concetto è più o meno simile va a memoria utilizzata e "peso", swap o file di paging chessia evitano che si inneschino i meccanisimi OOM-kill, ma comunque senza entrare in concetti troppo esoterici, io nel ruolo di amministratore di programmazione non devo saper una cippa, devo saper A) eseguire le configurazioni necessarie B) saper intepretare i dati necessari e conoscere i componenti inclusi in modo da consentirmi di stimare adeguatamente il sizing di un determinato deployment C) eseguire il deployment della piattaforma.... fine delle trasmissioni. PG piace tanto agli sviluppatori perché è molto versatile e li possono far fare ciò che vogliono, a mio avviso un po' meno agli amministratori perché se ci sono problemi poi l'intervento o lo fai direttamente sull'applicazione che lo utilizza oppure te la butti al culo (con MSSQL ad esempio *non è così*)