# Discourse Fails to update in the Admin UI - No matter what

**URL:** https://meta.discourse.org/t/discourse-fails-to-update-in-the-admin-ui-no-matter-what/376244
**Category:** Self-hosting
**Created:** [July 28, 2025, 6:33pm UTC](https://meta.discourse.org/t/discourse-fails-to-update-in-the-admin-ui-no-matter-what/376244 "2025-07-28T18:33:43Z")
**Posts on this page:** 1
**Showing post:** 24

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [July 29, 2025, 2:55pm UTC](https://meta.discourse.org/t/discourse-fails-to-update-in-the-admin-ui-no-matter-what/376244/24 "2025-07-29T14:55:21Z")

</div>

> [@jdc20181](#):
>
> Here you go. Reproduced Today.

Certainly looks like a shortage of virtual memory, which means adding swap should solve it.

But see also

> [@MKJ's Opinionated Discourse Deployment Configuration](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/1):
>
> ## Kernel configuration
> 
> Redis (one of the key components on which Discourse is built) [strongly recommends disabling transparent huge pages when using on-disk persistence](https://redis.io/docs/management/optimization/latency/#latency-induced-by-transparent-huge-pages) (which Discourse does), and I also allow memory overcommit.
> 
> ```plaintext
> echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
> echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
> sysctl --system
> 
> ```

I never quite gave myself the time to do the controlled experiments, but I very much believe that once you’ve set overcommit you will need less swap.

---

_[View the full topic](https://meta.discourse.org/t/discourse-fails-to-update-in-the-admin-ui-no-matter-what/376244)._