Memory leak

[sirex]

Server constantly runs out of memory, because of a memory leak. Here is server log:

Currently --max-requests 1000 setting was set as a temporary workaround.

Memory leaks should be identified and eliminated.

• Add memory usage to logs.
• Add PID (Process ID) to logs.
• Rewrite ascii table formatter #359

[sirex]

This also effects swap usage, changed --max-requests to 100, as a temporary fix.

I could not find anything suspicious in logs, but it looks, that this might be caused by jsonl, csv or ascii download of a large dataset. Or a small dataset but with a very large number of columns.

[JuliusLADP]

1.System D serviso auto perkrovimas (auto Spinta pakėlimas) Arnoldas
2. Identifikuoti laikotarpius, kuriems ištraukti atminties overload'as ir išanalizuoti situaciją šiems epizodams (justinas)
3. Identifikuotų priežasčių pataisymas (Justinas)

Traceback analizė (log levelių suskirstymas pagal vartotojo) - yra jau užduotis priežiūra 119

[JustinasKen]

Pasibandžiau lokaliai paleisti 100k užklausų, kurios tik atidarė duomenų rinkinių sąrašą, patikrinau atmintį:

prieš leidžiant užklausas:

                                    types |   # objects |   total size
========================================= | =========== | ============
                                      str |      134092 |     23.41 MB
                                     dict |       69741 |     21.07 MB
                                     code |       47779 |      8.19 MB
                                     type |        6524 |      5.92 MB
                                    tuple |       56788 |      3.48 MB
                                      set |        2753 |      1.77 MB
                                     list |       13509 |      1.23 MB
                                  weakref |       10104 |    710.44 KB
  sqlalchemy.sql.visitors.TraversibleType |         509 |    531.50 KB
                              abc.ABCMeta |         516 |    527.59 KB
                      function (__init__) |        3351 |    445.05 KB
    openpyxl.descriptors.MetaSerialisable |         415 |    431.21 KB
    geoalchemy2.functions._GeoGenericMeta |         410 |    426.02 KB
                                frozenset |        1021 |    407.87 KB

po 100k užklausų:

                                    types |   # objects |   total size
========================================= | =========== | ============
                                     dict |      279947 |     41.92 MB
                                      str |      134103 |     23.41 MB
                                     list |      223711 |     14.17 MB
              ruamel.yaml.docinfo.DocInfo |      213619 |      9.78 MB
                                     code |       47779 |      8.19 MB
                                     type |        6524 |      5.92 MB
                                    tuple |       56788 |      3.48 MB
                                      set |        2753 |      1.77 MB
                                  weakref |       10104 |    710.44 KB
  sqlalchemy.sql.visitors.TraversibleType |         509 |    531.50 KB
                              abc.ABCMeta |         516 |    527.59 KB
                      function (__init__) |        3351 |    445.05 KB
    openpyxl.descriptors.MetaSerialisable |         415 |    431.21 KB
    geoalchemy2.functions._GeoGenericMeta |         410 |    426.02 KB

[JustinasKen]

Pasibandžiau lokaliai paleisti 100k užklausų, kurios tik atidarė duomenų rinkinių sąrašą, patikrinau atmintį:

prieš leidžiant užklausas:

                                    types |   # objects |   total size
========================================= | =========== | ============
                                      str |      134092 |     23.41 MB
                                     dict |       69741 |     21.07 MB
                                     code |       47779 |      8.19 MB
                                     type |        6524 |      5.92 MB
                                    tuple |       56788 |      3.48 MB
                                      set |        2753 |      1.77 MB
                                     list |       13509 |      1.23 MB
                                  weakref |       10104 |    710.44 KB
  sqlalchemy.sql.visitors.TraversibleType |         509 |    531.50 KB
                              abc.ABCMeta |         516 |    527.59 KB
                      function (__init__) |        3351 |    445.05 KB
    openpyxl.descriptors.MetaSerialisable |         415 |    431.21 KB
    geoalchemy2.functions._GeoGenericMeta |         410 |    426.02 KB
                                frozenset |        1021 |    407.87 KB

po 100k užklausų:

                                    types |   # objects |   total size
========================================= | =========== | ============
                                     dict |      279947 |     41.92 MB
                                      str |      134103 |     23.41 MB
                                     list |      223711 |     14.17 MB
              ruamel.yaml.docinfo.DocInfo |      213619 |      9.78 MB
                                     code |       47779 |      8.19 MB
                                     type |        6524 |      5.92 MB
                                    tuple |       56788 |      3.48 MB
                                      set |        2753 |      1.77 MB
                                  weakref |       10104 |    710.44 KB
  sqlalchemy.sql.visitors.TraversibleType |         509 |    531.50 KB
                              abc.ABCMeta |         516 |    527.59 KB
                      function (__init__) |        3351 |    445.05 KB
    openpyxl.descriptors.MetaSerialisable |         415 |    431.21 KB
    geoalchemy2.functions._GeoGenericMeta |         410 |    426.02 KB

Ši problema atsiranda dėl ruamel.yaml bibliotekos 0.18.4 versijos.
Norint, kad nesikartotu reikia limituoti šios bibliotekos versiją iki 0.18.4.

[JustinasKen]

Atlikau platesnį memory leak testavimą.

Bandžiau:

GET all: json, html, jsonl, csv, rdf, ascii
GET one
changelog
pagination
POST
POST su Errors
count()
summary: numeric, time

Leaks:
html - kraunant file paths, kuriamas naujas ExitStack context.

Lėtai veikia:
summary, csv, rdf
Imant įrašus (kai jų yra labai daug), puslapiai, kurie yra arčiau duomenų pabaigos, smarkiai suletėja.

Galimos vietos, kurios sunaudoja atmintį:
html grąžina TemplateResponse, kuris galimai užkrauna visus pateiktu duomenis į atmintį.
summary visada sukuria iki 100 įrašų buckets
manifest render užkrauna viską į atmintį prieš grąžinant (šis funkcionalumas teoriškai dar nėra naudojamas, prisidėjo su inspect API).

summary valgo labai daug duomenų bazės atminties, lokaliai pasibandžiau
15M įrašų padaryti time summary, duomenų bazės virtualiuos mašinos atminties panaudojimas tai užklausai pakilo iš 6GB į 21GB.
Reikia pakeisti summary ARRAY_AGG į kokį nors kitą sprendimą, kuris neužkrauna visko į atmintį.

[JustinasKen]

html memory leak tvarkymo task - #954
summary duomenų bazės atminties sunaudojimo tvarkymo task - #955

[sirex]

html grąžina TemplateResponse, kuris galimai užkrauna visus pateiktu duomenis į atmintį.

Taip viską užkrauna į atmintį, tačiau html atveju yra enforcintas _limit, reikėtu patikrinti ar jis veikia ir neduodi nurodyti didesnio _limit, nei tarkim 100, tada bus apsaugota, kad nesunaudotu daugiau atminties.