Avviksrapport for FS database FS01ORD
Dato: 2021-03-04
Skrevet av: audunle
Databasen FS01PRD som kjører FS for følgende institusjoner ble utilgjengelig som følge av swap'ing da SGA komponenten av Oracle minnet ikke ble allokert i det avsatte HugePages området. Førte til at den brukte opp alt minne på server når det ble nok brukere.
FSATH.uio.no
FSHIOF.uio.no
FSNMBU.uio.no
FSNUC.uio.no
FSUIA.uio.no
FSHSN.uio.no
Beskrivelse av avviket og feilrettingsprosess
Dette er en beskrivelse av hva som skjedde og hvordan situasjonen ble rettet. Gjennomgangen bør være ganske detaljert med tidspunkt, navn på personer, konkret hva som ble gjort ala:
- 03-03 2253: Siste restart av 3 av databasen FS01PRD i forbindelse med innlegging av FLIS - FS funksjonell patch i basen. Ved denne restarten blir ikke SGA minnet på 48GB allokert i HugePages som forventet, men i vanlig minneområde. Det er ikke gjort noen endringer på DB'ens minneparametre i forbindelse med FLIS.
- 03-04 0946: Minnevarsel kommer og forsvinner i Zabbix og CloudControl. Blir oppdaget i ettertid.
- 03-04 1029: DBD)varsler på intern MatterMost kanal om problemer med å logge på server. Zabbix-varsel 10:14 om FS01PRD down blir oppdaget samtidig. Basen er tilgjengelig men treg for de som har sesjon innlogget.
- 03-04 1033: I vSphere ser maskinen ok ut og kjører - ingen tegn til swaping eller varsler.
- 03-04 1044: DBD får logget inn med ssh, men serveren responderer sakte/ikke
- 03-04 1046: proesser kjører som normalt - oppdages at maskinen har swap'et 1GB.
- 03-04 1053: DBD kontakter amedow direkte på Matermost og får 8GB mer minne til server. Får litt respons men fortsatt så treg at vi ikke får feilsøkt i noen stor grad.
- 03-04 1103: DBD kontakter virt-vakt ketilni på Mattermost. Får svar etter få minutter. Serveren henger fortsatt mye med en load på 300+ uten at problemene er synlige fra virt-siden. Gjør litt feilsøking sammen
- 03-04 1107: Fortsatt ikke mottatt noen feilmeldinger fra brukere via RT.
- 03-04 1111: Zabbix melder OK status på basen og vi får logget inn med ssh
KiB Mem : 15048929+total, 703500 free, 10385854+used, 45927252 buff/cache
KiB Swap: 4194300 total, 1677344 free, 2516956 used. 1218216 avail Mem
- 03-04 1121: Server utilgjengelig for nye sesjoner igjen.
- 03-04 1127: Enighet om å gi serveren ytterligere 20GB til 170GB minne. Litt problematisk å få alt minne online. Server swap'er og bruker opp også all swap. Prosesser blir stoppet av server selv.
- 03-04 1139: Server treg - brukt opp swap:
KiB Mem : 15048929+total, 651568 free, 10650592+used, 43331804 buff/cache
KiB Swap: 4194300 total, 0 free, 4194300 used. 245968 avail Mem
- 03-04 1140: temsgea varsler om at det kommer inn flere RT-saker om problemer. jonvenb svarer på dem.
- 03-04 1141:UNIT ringer DBD og varsler at de mottar meldinger om problemer med FS01PRD
- 03-04 1150: DBD sender epost med varsel til UNIT cc Ola Ødegård, USIT
- 03-04 1151: Server har fortsatt ikke klart og aktivere de 20 siste GB med minne den ble tildelt.
- 04-03 1159: DBD restarter server.
- 04-03 1203: server oppe igjen med riktig med minne. Basen kommer opp automatisk, nå med SGA riktig i HugePages området. Gjør sjekker av serverminne, database og alert.log for å verifisere at status er OK.
KiB Mem : 17519419+total, 11433969+free, 58833252 used, 2021244 buff/cache
KiB Swap: 4194300 total, 4194300 free, 0 used. 11522617+avail Mem
- 03-04 1206: DBD sender mail til UNIT cc Ola Ødegård USIT om at FS01PRD nå er oppe og i vanlig drift igjen
Konsekvenser
Databasen benyttes av 6 forskjellige institusjoner for FS. Disse rapporterte inn om tregheter og senere i praksis utilgjengelig FS system. Sesjoner som allerede var logget inn når problemet oppstod fungerte var fortsatt tilgjengelige. Tregheter fra 10:30, sannsynlig helt utilgjengelig fra ca kl 11:30 til 12:05.
Hva skulle vi gjort for at situasjonen ikke oppsto?
Årsak til at databasen ved restart ikke frigjorde HugePages minne og dermed ved oppstart allokerte SGA i vanlig minneområde som følge at 3 prosesser holdt på minnet ved shutdown. Har sett samme melding i alert.log tidligere, men da har prosessene vært borte og minneområde frigjort ved oppstart.
Manuell kontrollsjekk av alert.log til databasen etter restart ville ha avdekket problemet.
Sette parameter i databasene som skal bruke HugePages ville forhindret oppstart om ikke SGA ble allokert riktig. Denne blir tatt opp til diskusjon:
USE_LARGE_PAGES=ONLY
Hva kunne USIT gjort bedre?
Raskere varsling av UNIT om problemene.
Tiltak
DBD vurderer om parameteren USE_LARGE_PAGES=ONLY i oracle skal settes for databaser som har satt opp HugePages.