# 从 tombstone 恢复的速度异常缓慢

**URL:** <https://meta.discourse.org/t/recover-from-tombstone-insanely-slow/84752>\
**Category:** Product Support\
**Created:** [2018 年4 月 6 日 20:12 UTC](https://meta.discourse.org/t/recover-from-tombstone-insanely-slow/84752 "2018-04-06T20:12:32Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

作者： ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\
发布日期： [2018 年4 月 6 日 20:12 UTC](https://meta.discourse.org/t/recover-from-tombstone-insanely-slow/84752/1 "2018-04-06T20:12:32Z")

</div>

I’ve got a big import that’s got a bunch of tombstoned images. This happens from time to time and I’m not sure why, but that’s not why I’m here.

I’m running `rake uploads:recover_from_tombstone` and it’s taking well over a minute per upload (I think that’s what those 45471 things that it needs to process are). So, I’m looking at a month for it to finish. 👎

And the 25 that it processed appeared not to have done anything (the most recent one did reported that it was restoring an image to its proper place).

It’s a [standard install](https://meta.discourse.org/t/142537?silent=true) on an 8GB Digital Ocean “optimized” droplet.

I’ve set

```plaintext
  db_shared_buffers: "2048MB"
  db_work_mem: "80MB"
  UNICORN_WORKERS: 4

```

At one point I tried increasing `num_connections` up to 200 (a new trick I learned recently), but that didn’t seem to help either.

```plaintext
              total used free shared buff/cache available
Mem: 7.8G 1.7G 133M 1.0G 6.0G 4.8G
Swap: 2.0G 691M 1.3G

```

I’m pretty stumped.

EDIT: I think it’s just that the database is not on SSD, but whatever DO calls their extra space and it’s a huge community with a couple million posts.

---

_[View the full topic](https://meta.discourse.org/t/recover-from-tombstone-insanely-slow/84752)._