# Recover from a very slow database

**URL:** https://meta.discourse.org/t/recover-from-a-very-slow-database/68793
**Category:** Self-Hosting
**Tags:** how-to
**Created:** [25 Agosto 2017, 5:49pm UTC](https://meta.discourse.org/t/recover-from-a-very-slow-database/68793 "2017-08-25T17:49:02Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![Discourse](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/discourse/32/148734_2.png) [@Discourse](https://meta.discourse.org/u/Discourse)
#### Post date: [25 Agosto 2017, 5:49pm UTC](https://meta.discourse.org/t/recover-from-a-very-slow-database/68793/1 "2017-08-25T17:49:02Z")

</div>

Rarely, the database can get into a state where it is so slow it appears broken (I have seen 3 instances of this issue in the last 4 years)

### How can you tell you are impacted?

It is quite easy to tell the difference between database is under load, or database is under-provisioned to a **broken** state.

Likely symptoms:

- Everything suddenly got **extremely** slow

- A rebuild does not fix the problem

- You see multiple **postgres** threads consuming 100% CPU when you run `top`

 ![image](https://global.discourse-cdn.com/meta/original/3X/a/e/ae61fba68ba9698cdc38eb5b875bc6078c3f8d17.jpg)

### Definate diagnosis

To ensure 100% you are impacted by this, **stop** the app and run a search:

```plaintext
./launcher restart app
./launcher enter app
sv stop unicorn
% rails c
> Search.new('testing').execute
> Search.new('testing').execute
> Search.new('testing').execute

```

On a functioning DB a search will take under a second. On a DB that is gone into 🤪 mode expect this to take more than **20 seconds**

### How to repair

The consistent way we were able to repair this was by dumping the database to disk and restoring:

```plaintext
./launcher enter app
sv stop unicorn
cd /shared
sudo -u postgres pg_dump discourse > db.dump
sudo -u postgres dropdb discourse
sudo -u postgres createdb discourse
sudo -u postgres psql discourse < db.dump

```

⏰ ⚠ 👨🏼‍🌾 **note**

It is very unlikely you are experiencing this issue, we saw it about 3 times in 4 years. However, if you just ran a GIANT import I would strongly recommend following this so you start from a proper clean slate.

> Last edited by @JammyDodger 2024-05-25T11:35:59Z
> 
> > **Check document**
> >
> > Perform check on document:

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [25 Agosto 2017, 7:40pm UTC](https://meta.discourse.org/t/recover-from-a-very-slow-database/68793/2 "2017-08-25T19:40:31Z")

</div>

Did you do a

`vacuum full`

which requires a full outage? I had to do this on migrated sites in the past to get the database to normal query speeds.

---

<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: [25 Agosto 2017, 7:41pm UTC](https://meta.discourse.org/t/recover-from-a-very-slow-database/68793/3 "2017-08-25T19:41:37Z")

</div>

> [@codinghorror](#):
>
> Did you do a
> 
> vacuum full
> 
> which requires a full outage?

Absolutely, I also tried a restore using our UI, both did not correct the issue.

Restore using the UI still keeps the database around so it does not correct the underlying issue with the db on disk.
