# Very slow Sidekiq issue with large queue due to massive numbers of unread user notifications

**URL:** <https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716>\
**Category:** Self-hosting\
**Created:** [February 5, 2020, 12:07pm UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716 "2020-02-05T12:07:57Z")\
**Posts on this page:** 1\
**Showing post:** 49

<div class="post-metadata">

**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\
**Post date:** [February 23, 2020, 7:31pm UTC](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716/49 "2020-02-23T19:31:58Z")

</div>

I actually think we ought to have a default on setting here, there is almost zero value in a single user having more than 10,000 notifications, we should just purge anything beyond 10,000 out of the box

@codinghorror you happy with this ?

There is arguably value in capping unread at an even lower value like say 1000 per user, but the strong notification cap would completely resolve the issue experienced here anyway

---

_[View the full topic](https://meta.discourse.org/t/very-slow-sidekiq-issue-with-large-queue-due-to-massive-numbers-of-unread-user-notifications/140716)._
