Changes between Initial Version and Version 1 of Ticket #34746


Ignore:
Timestamp:
Jul 27, 2023, 2:49:52 PM (14 months ago)
Author:
Rémi Dupré
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #34746

    • Property Summary High CPU/memory consumtion when a 5xx is raised with a large local variable → High CPU/memory consumption when a 5XX is raised with large local variables

  • Ticket #34746 – Description

    initial v1  
    11Hi!
    22
    3 In a view with large variable in scope, if an exception is raised, the worker will freeze and its memory usage will raise. Here is a minimal example:
    4 
     3In a view with large variable in its scope, if an exception is raised, the worker will freeze and its memory usage will raise. Here is a minimal example:
    54
    65{{{
    … …  
    2019}}}
    2120 
    22 When calling /compute-lines/ you will notice the issue.
     21When calling /compute-lines/ you will notice the issue : the server will take a few seconds to responds while its memory raises by ~1GB.
    2322
    2423----
    … …  
    2625After a bit of investigations, it turned out it comes from django.utils.log.AdminEmailHandler in the default logging config. This handler will eventually pretty print the whole context of each trace frame from here : https://github.com/django/django/blob/main/django/views/debug.py#L355
    2726
    28 This implementation ensures that no more than 4kB are included in the formatted result, but the entire variable will still have to be rendered first. I'm not sure how it could be solved, but maybe reprlib can be a clue?
     27This implementation ensures that no more than 4kB are included in the formatted result, but the entire variable will still have to be rendered first. I'm not sure how it could be solved, but maybe [https://docs.python.org/3/library/reprlib.html] can be a clue?
Back to Top