Update content/devops-blog/nextcloud-incident.da.md
This commit is contained in:
benjaoming
parent
5141ff6225
commit
65d170e42c
1 changed files with 42 additions and 29 deletions
|
|
@ -1,63 +1,72 @@
|
|||
---
|
||||
title: Performance problemer grundet bug i Nextcloud
|
||||
summary: En fejl i synkronisering af Nextcloud servere resulterede i dårlig performance af data.coops server.
|
||||
title: Performance-problemer grundet bug i Nextcloud 🐞 🔍
|
||||
summary: En fejl i synkronisering af Nextcloud-servere resulterede i dårlig ydeevne på data.coops server.
|
||||
date: 2025-02-22
|
||||
params:
|
||||
author: Reynir (admin team)
|
||||
---
|
||||
|
||||
**Den korte version:** der er tilsyneladende en bug i synkronisering mellem Nextcloud-servere samt i log vieweren i admin-panelet. Medlemmer bør derfor indtil videre ikke sætte synkronisering op mellem cloud.data.coop og andre Nextcloud servere uden nærmere aftale med administratorholdet.
|
||||
**Den korte version:** der er tilsyneladende en bug i synkronisering mellem Nextcloud-servere samt i log vieweren i Nexclouds adminpanel. Medlemmer bør derfor indtil videre ikke sætte synkronisering op mellem cloud.data.coop og andre Nextcloud-servere uden nærmere aftale med administratorholdet.
|
||||
|
||||
I mindst en måned har data.coop haft udfordringer på performance og disk plads.
|
||||
I mindst en måned har data.coop haft udfordringer med CPU, hukommelse og disk plads.
|
||||
Det har vi i [admin-teamet](/rights/#-7-administratorer) haft kig på når vi har kunne finde tid.
|
||||
Vi fandt nogle årsager:
|
||||
|
||||
- [Mastodon remote profilbilleder, der aldrig bliver ryddet op i](https://git.data.coop/data.coop/ansible/pulls/228)
|
||||
- [bots der scraper dyre forgejo endpoints,](https://git.data.coop/data.coop/ansible/pulls/233)
|
||||
- [nginx-proxy logs der aldrig bliver roteret eller ryddet op i,](https://git.data.coop/data.coop/ansible/pulls/234)
|
||||
- [Synapse (matrix server) database der vokser sig gevaldigt stor,](https://element-hq.github.io/synapse/latest/usage/administration/state_groups.html)
|
||||
- og Nextcloud bruger meget CPU tid i cron.php.
|
||||
- [bots scraper dyre forgejo endpoints,](https://git.data.coop/data.coop/ansible/pulls/233)
|
||||
- [nginx-proxy logs blev aldrig roteret eller ryddet op i,](https://git.data.coop/data.coop/ansible/pulls/234)
|
||||
- [Synapse (matrix server) database vokser sig gevaldigt stor](https://element-hq.github.io/synapse/latest/usage/administration/state_groups.html)
|
||||
- og Nextcloud bruger for meget CPU-tid i cron.php.
|
||||
|
||||
Problemet med Synapse har er endnu uløst. Der findes et værktøj til at komprimere den problematiske tabel, men vi har endnu ikke undersøgt om det virker for os.
|
||||
Problemet med Synapse er endnu uløst. Der findes et værktøj til at komprimere den problematiske tabel, men vi har endnu ikke undersøgt, om det virker for os.
|
||||
Vi står over for at migrere vores services over til vores anden server, der har langt større diskkapacitet.
|
||||
|
||||
Denne artikel kommer dog til at handle om problemet i Nextcloud:
|
||||
hvordan vi identificerede det og hvad vi gjorde for at løse det.
|
||||
Hvordan vi identificerede det og hvad vi gjorde for at løse det.
|
||||
|
||||
## Nextcloud
|
||||
|
||||
På [cloud.data.coop](https://cloud.data.coop/) kører vi en filsynkroniserings- og delingssoftware Nextcloud til vores medlemmer.
|
||||
Det er et stykke software der kan utroligt meget[^for-meget] udover at gemme og synkronisere filer.
|
||||
På [cloud.data.coop](https://cloud.data.coop/) kører vi en filsynkroniserings- og delingssoftware [Nextcloud]({{ ref "/services/nextcloud" }}) til vores medlemmer.
|
||||
Det er et stykke software, der kan utroligt meget[^for-meget] udover at gemme og synkronisere filer.
|
||||
Det er en service vi har kørt længe.
|
||||
|
||||
Indtil for nylig har det kørt relativt godt.
|
||||
|
||||
Men så begyndte vi at se en process `php -f /var/www/nextcloud/cron.php` bruge meget CPU-tid.
|
||||
Navnet `cron.php` leder tankerne hen på UNIX-programmet `cron` som er et program til at planlægge og køre programmer på faste tidspunkter.
|
||||
Det bliver typisk brugt til eks. at køre oprydningsjobs om natten.
|
||||
Ved at køre `lsof -p $pid_for_cron.php` kunne jeg få indsigt i hvilke filer processen har åben.
|
||||
Der bed jeg mærke i `nextcloud.log`.
|
||||
|
||||
Da jeg begyndte at undersøge det nærmere kiggede jeg i admin-interfacet i Nextcloud.
|
||||
Det er ikke et stykke software jeg personligt har meget erfaring med at køre, så jeg måtte kigge rundt og opdage hvad der var muligt at lære om hvad `cron.php` har gang i.
|
||||
Jeg fandt desværre ikke meget andet en generel information om systemet og en side med logs som ikke virkede.
|
||||
Da jeg begyndte at undersøge det nærmere, kiggede jeg i admin-interfacet i Nextcloud.
|
||||
Det er ikke et stykke software, jeg personligt har meget erfaring med at køre, så jeg måtte kigge rundt og opdage, hvad der var muligt at lære om `cron.php`.
|
||||
Jeg fandt desværre ikke meget andet en generel information om systemet og en side med logs (som ikke virkede!).
|
||||
|
||||
|
||||
|
||||
Log-siden gav en fejlbesked.
|
||||
Noget i retning af at det gik for langsomt at få fat i logs.
|
||||
Noget i retning af, at det gik for langsomt at få fat i logs.
|
||||
|
||||
Det fik mig til at lede efter logfilerne via ssh.
|
||||
Logfilerne viste sig at være flere GB store, og programmer som `less` havde svært ved at håndtere at læse og vise de store filer.
|
||||
Nextcloud skriver [json][json]-objekter i sine logs, og det viste sig at flere af linjerne var over 100 MB store.
|
||||
Altimens oplevede jeg at serveren blev langsommere og langsommere, og der kom flere og flere apache processer fra Nextcloud-containeren som brugte 100% CPU-tid (dvs. en hel CPU-kerne).
|
||||
Nextcloud skriver [json][json]-objekter i sine logs, og det viste sig, at flere af linjerne var over 100 MB store ‼️.
|
||||
Altimens oplevede jeg at serveren blev langsommere og langsommere, og der kom flere og flere apache processer fra Nextcloud-containeren som brugte 100% CPU-tid (dvs. en hel CPU-kerne ‼️).
|
||||
|
||||
Det blev nødvendigt at lukke Nextcloud ned, så vores andre services kunne køre videre.
|
||||
Jeg åbnede et maintenance window i [status.data.coop](https://status.data.coop/) og meldte ud på vores Matrix-kanal.
|
||||
|
||||
Ved hjælp af [`jq`][jq] kunne jeg få *pretty printet* logfilen så linjerne ikke blev så lange, og `less` kunne følge med.
|
||||
Det viste sig at `cron.php` kørte synkronisering mod et medlems egen Nextcloud-server.
|
||||
Det i sig selv er fint, men der var tilsyneladende en bug som gjorde at når vores Nextcloud skannede medlemets Nextcloud for filer i en bestemt mappe blev der sat en ekstra skråstreg på og scannet rekursivt igen.
|
||||
Sådan blev det ved indtil der var næsten 9000 skråstreger(!!), hvor programmet så kunne finde en videofil (lad os kalde den `foo.mkv`).
|
||||
|
||||
Det er der ingenting galt med; men der var tilsyneladende en bug som gjorde, at når vores Nextcloud scannede medlemmets Nextcloud for filer i en bestemt mappe, så blev der sat en ekstra skråstreg på og scannet rekursivt igen.
|
||||
|
||||
Sådan blev det ved, indtil der var næsten 9000 skråstreger ‼️, hvor programmet så kunne finde en videofil (lad os kalde den `foo.mkv`).
|
||||
Så var programmet glad, og prøvede at tilføje metadata om filen til databasen.
|
||||
|
||||
Her blev databasen så utilfreds!
|
||||
|
||||
For i tabellen må filnavne højest være 4000 tegn langt!
|
||||
|
||||
Det resulterede i en fejl (exception) som blev logget inklusive de næsten 9000 rekursive kald inklusive argumenter!
|
||||
Det var altså årsagen til den problematiske logfil.
|
||||
|
||||
|
|
@ -197,32 +206,36 @@ Det skaber selvfølgelig problemer at vise så lange linjer i en web browser, s
|
|||
|
||||
</details>
|
||||
|
||||
I logfilen stod der et brugernavn på medlemmet som gjorde at vi kunne komme i kontakt med vedkommende.
|
||||
I logfilen stod der et brugernavn på medlemmet, som gjorde at vi kunne komme i kontakt med vedkommende.
|
||||
Medlemmet slog så synkronisering fra på sin Nextcloud-server, og vi kunne starte vores service op dagen efter uden problemer.
|
||||
|
||||
### Den egentlige performance-killer
|
||||
|
||||
Det blev først _*rigtigt*_ et problem med performance efter jeg begyndte at undersøge hvad Nextcloud havde gange i.
|
||||
Min teori er at Nextcloud forsøgte at læse den enormt store logfil og præsentere den for min browser.
|
||||
Det blev først _*rigtigt*_ et problem med performance, efter jeg begyndte at undersøge hvad Nextcloud havde gange i.
|
||||
Min teori er, at Nextcloud forsøgte at læse den enormt store logfil og præsentere den for min browser.
|
||||
Det tager selvsagt lidt tid at læse så store filer, og min browser har tænkt at det tog for lang tid.
|
||||
Der hvor jeg tror det gik galt er at min browser måske forsøgte dernæst at få nextcloud til at læse logfilen igen!
|
||||
Og så videre.
|
||||
Resulterende i efterhånden mange processer der forsøgte at læse og forstå de gigantiske logfiler.
|
||||
|
||||
Ideelt set bør vi undersøge problemet nærmere, evt. prøve at reproducere og skrive en god bug report til Nextcloud.
|
||||
Ideelt set bør vi undersøge problemet nærmere, evt. prøve at reproducere og skrive en god bug-report til Nextcloud.
|
||||
Desværre er Nextcloud-kodebasen meget stor, med rigtig mange plugins, og det hele er skrevet i et sprog jeg ikke har erfaring med (PHP).
|
||||
Derfor bliver det ikke til andet end at vi prøver at opgradere Nextcloud og håber det er et kendt problem de har løst.
|
||||
Derfor bliver det ikke til andet, end at vi prøver at opgradere Nextcloud og håber det er et kendt problem de har løst.
|
||||
|
||||
## Afsluttende noter
|
||||
## Afsluttende eftertanker
|
||||
|
||||
Som administratorer hviler der et stort ansvar på os.
|
||||
Vi sørger efter bedste evne, og den tid vi har til det frivillige arbejde, at sørge for at data.coops services fungerer i et acceptabelt niveau.
|
||||
|
||||
Vi forsøger efter bedste evne (f.eks. den tid vi har til det frivillige arbejde) at sørge for, at data.coops services fungerer på et acceptabelt niveau.
|
||||
|
||||
Til det har vi nogle gange brug for at kigge i logs og undersøge systemet.
|
||||
Det kan nogle gange gå lidt på tværs med vores mål om privatlivsbeskyttelse og zero-knowledge.
|
||||
|
||||
Det kan nogle gange gå lidt på tværs med vores mål om privatlivsbeskyttelse og zero-knowledge 🤔
|
||||
|
||||
I denne omgang har jeg lært et medlems mappenavn og filnavn på en af deres filer via logfilerne.
|
||||
I forsøg på at lokalisere problemet har jeg kigget i mine **egne** Nextcloud filer i filsystemet og derefter søgt filsystemet for den problematiske fil (uden held).
|
||||
Det er noget vi for så vidt muligt prøver at minimere.
|
||||
|
||||
Det er noget, vi for så vidt muligt prøver at minimere; men det er også noget, vi skal diskutere løbende og aftale faste rammer omkring.
|
||||
|
||||
[json]: https://www.json.org/json-en.html
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue