Page History
...
Og disse overholdes fint qua ovenstående tabeloversigt. I iteration 8 på docker02, hvor tallene er højest, er 99,5 % under 6,5 og 15,5 sekunder.
Vmstat log
Denne log findes for hver applikations server (docker container). Både for registration og kafka-consumer. Den viser resultatet af kommandoen vmstat
Udtræk omkring cpu fra denne log vises i de følgende grafer.
Data serier i grafen er:
- cpuNonKernel (rød): tid brugt på non-kernel opgaver
- cpuKernel (blå): tid brugt på kernel opgaver
- cpuIdle (grøn): tid brugt på ingenting
- cpuWaitIO (gul): tid brugt på at vente på i/o
- iterationerne (sort) er en cirka placering, da wmstat loggen ikke indeholder tidstempel
Registration:
- Man kan se at cpuIdle og cpuNonKernel påvirkes lidt som servicen presses mere. cpuIdle ligger lavere over tid, mens cpuNonKernel grafen ligger en smule højere over tid. Den generelle flyt af kurverne er dog ikke faretruende. I iteration 7 og 8 er der lidt mere udsving for docker02.
Kafka-consumer:
- cpuIdle og cpuNonKernel ligger meget konstant over iterationerne.
Udtræk omkring io læs og skriv fra vmstat vises i de følgende grafer.
Data serier i grafen er:
- ioBlockRead (rød): læsning på disk (blokke)
- ioBlockWrite (blå): skriving på disk (blokke)
- iterationerne (sort) er en cirka placering, da wmstat loggen ikke indeholder tidstempel
Registration:
- Der er lidt løbende skriv til disken mens testen kører, og i slutningen af iteration 7 en del på docker02. Sammenligner man graferne fra før på cpu forbrug, ses det, at de store udsving i skrivninger falder sammen med at cpuKernal går op og cpuIdle går ned.
Kafka-consumer:
- Der er lidt løbende skriv til disken mens testen kører, og igen falder de få store udsving i skrivninger falder sammen med at cpuKernal går op og cpuIdle går ned.
Vurdering
Der er intet negativt at bemærke omkring cpu forbruget eller disk io.
Jstat log
Denne log findes for hver applikations server (docker container). Både for registration og kafka-consumer. Loggen viser resultatet af kommandoen jstat. Jstat siger noget om, hvordan JVM'en har det.
Udtræk omkring hukommelse og garbage collection fra denne log vises i de følgende grafer.
Data serier i grafen er:
- YGC (rød): young generation garbage collection events, antal af "ung" garbage collection siden start
- FGC (blå): full garbage collection events, antal af fuldstændig garbage collection siden start
- HeapU (gul): består af S0U+S1U+EU fra jstat loggen. Young generation memory utilization. "Ung" hukommelses forbrug
- HeapC (grøn): består af S0C+S1C+EC fra jstat loggen. Young generation memory capacity. "Ung" hukommelses kapacitet
- OU_MB (pink): old space utilization. "Ældre" hukommelses forbrug
- OC: oldx space capacity. "Ældre" hukommelses kapacitet er ikke en del af grafen men er konstant på 1.398.272 KB.
- Iterationer (sort) er baseret på det tidstempel, som findes i jstatloggen
Registration:
- Det kan være lidt svært at se graferne for full garbage collection (FGC). Kigger man nærmere på datagrundlaget bag graferne, ses det, at der kørt full garbage collection for servicen under testen en enkelt gang i starten af første iteration.
- Der er en meget svag stigende tendens på den ældre hukommelse (OU_MB). Man må gå ud fra, at kommer den op på en kritisk grænse, da vil systemet køre en full garbage collection (FGC).
- Der køres ofte garbage collection på den yngre hukommelse, hvilket holder HeapU - yngre hukommelses forbrug - nede så den kun svinger inden for et konstant interval.
Kafka-consumer:
- Her er der ikke kørt fuld garbage collecion (FGC) under testen.
- Der er ikke brug for at køre meget garbage collection på den yngre hukommelse, og den yngre hukommelse (HeapU) holdes nede.
Vurdering
Den yngre forbrugte hukommelse eskalerer ikke. Garbage collecteren gør sit arbejde.