Browser out of memory on tasks page

Issue #964 resolved
David Platten created an issue

When viewing the tasks summary page on my test system there are so many “Older tasks” that my browser crashes (Chrome, out of memory error) and is unable to display the page. This is on my laptop with 32 GB RAM.

I have just checked in the database and there are 158366 rows in the backgroundtask table.

Comments (20)

  1. Ed McDonagh

    Any ideas as to how to deal with this? (Configurable) limit of number of old tasks before they are automatically purged? Some sort of archiving?

    I think we can also reduce the impact on the database of the auto-refresh by doing that in a different way.

  2. David Platten reporter

    Hi Ed. Yes, I think we need to configure a limit on the number of task records kept.

    I’ve just deleted all the rows from the table that were completed successfully using PgAdmin4:

    DELETE FROM public.remapp_backgroundtask
    WHERE completed_successfully = TRUE AND complete = TRUE;

  3. David Platten reporter

    This page: https://www.appsloveworld.com/django/100/34/limit-the-number-of-rows-in-a-django-table

    has a snippet of code that removes the oldest entry in a table if the number of entries exceeds some value:

    def my_handler(sender, instance, **kwargs):
        qs = MyModel.objects.order_by('created') #ensure ordering.
        if qs.count() > 10:
            qs[0].delete() #remove the oldest element
    
    class MyModel(models.Model):
        title = models.CharField('title', max_length=200)
        created = models.DateTimeField(auto_add_now=True, editable=False)
    
    post_save.connect(my_handler, sender=MyModel)
    

    Perhaps we could use something like that for the backgroundtask table, where the threshold for deleting is something like 2000 entries?

  4. David Platten reporter

    We could either keep the database table rows below a certain number, or only retrieve the most recent x rows in the appropriate view when populating the task table.

  5. Ed McDonagh

    My preference would be to only keep so many records in the table, as long as we can have an admin config of how many that is?

  6. David Platten reporter

    Added a custom save method to the BackgroundTask table to prevent the number of rows exceeding the value in the max_background_task_rows field in the new BackgroundTaskMaximumRows singleton table. Need to create a simple page for an administrator to modify this value. Refs issue #964

    → <<cset ca6b2b1dc65e>>

  7. David Platten reporter

    Added a form, view and entry in the Config menu for an OpenREM administrator to be able to change the BackgroundTaskMaximumRows singleton table. Refs issue #964

    → <<cset a4f57aef9ca9>>

  8. David Platten reporter

    Using post_save signal rather than overriding the save method of the BackgroundTask. The Internet tells me this is more elegant, and Codacy may be happier with this. Refs issue #964

    → <<cset f4742ea38e0e>>

  9. David Platten reporter

    Re-worded a sentence in the docs to avoid the need for another comma. Added specific link to the task management docs in the task history limit form, and updated the docs link for the task_admin page. Refs issue #964

    → <<cset d8e4791a3d5b>>

  10. Log in to comment