<p>So i built the latest node and db-sync releases from source. My node works great it was fully synced fairly quickly. the db-sync got to around %78 and then started going insanely slow. I still have about 400GB free, only using about 30/48GB of memory.</p>
<p>This is</p>
<pre><code>ubuntu 22 with 
db sync 13.1.1.3
node 8.7.2
ghc 8.10
</code></pre>
<p>It updates about .01% everyday. So its just barely faster then the new transactions on the node each day. I have little script that compares the latest slot number between the node and the database. At this rate it wouldn't be updated for over 3 years</p>
<p>I don't have any errors I can find. the hard drive space and memory don't seem to be leaking. Any thoughts as to what the problem might be or how it can be optimized?</p>

CC BY-SA 4.0
2024-01-15T19:21:58.577Z
Is you disk storage for the database directly attached or network attached. Network attached storage is specifically advised against https://github.com/IntersectMBO/cardano-db-sync#system-requirements
Erik de Castro Lopo
CC BY-SA 4.0
2024-01-15T22:48:18.570Z
yeah, its a local hoard drive, everything is on the same OS/hardrive, including the postgres server. It updated quick until about 75%, then just slowed down.
noone392
CC BY-SA 4.0
2024-01-17T00:31:39.290Z
Does your machine meet the system requirements in the document above? Are you on an SSD drive rather than an electro-mechanical one? Is this dedicated hardware or something like an AMazon AWS system? Please provide comprehensive info about your setup.
Erik de Castro Lopo
CC BY-SA 4.0
2024-01-18T02:27:41.333Z
Its my home server. Its just a virtual box image. where I allocated 48 GB of memory and about 900 GB on a SSD that is supposed to be around 300+MB/S. Its not an M2 SSD but a SATA SSD. I allocated 4 cores of my 8 core processor.
noone392
CC BY-SA 4.0
2024-01-18T02:28:54.087Z
I should note the Drive symbol is always 100% lit, even though its not really filling up any more space. Even if it were magnetic, It would be filling the space 100x faster then it currently is
noone392
CC BY-SA 4.0
2024-01-18T04:54:18.477Z
Your system seems very similar to mine. MIne is a KVM virtual machine writing to a SATA SSD drive. One thing I do know about SSDs is that writes seem to slow down as the number of write cycles increases (I killed an SSD during the development of `db-sync`). If yours a new or an old SSD? You still have not shared details of the host machine that the VM runs on (`dstat` maybe?)). This seems like a system performance issue rather than a `db-sync` issue.
Erik de Castro Lopo
CC BY-SA 4.0
2024-01-18T14:22:30.427Z
That's fair. My host machine has 64 gb of ddr4 memory, 8core ryzen 9 processor, and about 5 different hard drives. IMO this is a dbsync problem. It should be faster then this on a magnetic drive. I should say, just to experiment I moved the VM to a different hard drive with no changed results. IMO DB sync is just doing stuff way to inefficiently. I have decided to move to Kupo
noone392
<cardano-db-sync>
DB-Sync insanely slow
# DB-Sync insanely slow

(Asked by: username_0 on 2024-01-15)

So i built the latest node and db-sync releases from source. My node works great it was fully synced fairly quickly. the db-sync got to around %78 and then started going insanely slow. I still have about 400GB free, only using about 30/48GB of memory.
This is
ubuntu 22 with 
db sync 13.1.1.3
node 8.7.2
ghc 8.10

It updates about .01% everyday. So its just barely faster then the new transactions on the node each day. I have little script that compares the latest slot number between the node and the database. At this rate it wouldn't be updated for over 3 years
I don't have any errors I can find. the hard drive space and memory don't seem to be leaking. Any thoughts as to what the problem might be or how it can be optimized?

**Tags:** cardano-db-sync
> **Comments:**
> **username_1**: Is you disk storage for the database directly attached or network attached. Network attached storage is specifically advised against https://github.com/IntersectMBO/cardano-db-sync#system-requirements  
> **username_0**: yeah, its a local hoard drive, everything is on the same OS/hardrive, including the postgres server. It updated quick until about 75%, then just slowed down.  
> **username_1**: Does your machine meet the system requirements in the document above? Are you on an SSD drive rather than an electro-mechanical one? Is this dedicated hardware or something like an AMazon AWS system? Please provide comprehensive info about your setup.  
> **username_0**: Its my home server. Its just a virtual box image. where I allocated 48 GB of memory and about 900 GB on a SSD that is supposed to be around 300+MB/S. Its not an M2 SSD but a SATA SSD. I allocated 4 cores of my 8 core processor.  
> **username_0**: I should note the Drive symbol is always 100% lit, even though its not really filling up any more space. Even if it were magnetic, It would be filling the space 100x faster then it currently is  
> **username_1**: Your system seems very similar to mine. MIne is a KVM virtual machine writing to a SATA SSD drive. One thing I do know about SSDs is that writes seem to slow down as the number of write cycles increases (I killed an SSD during the development of `db-sync`). If yours a new or an old SSD? You still have not shared details of the host machine that the VM runs on (`dstat` maybe?)). This seems like a system performance issue rather than a `db-sync` issue.  
> **username_0**: That's fair. My host machine has 64 gb of ddr4 memory, 8core ryzen 9 processor, and about 5 different hard drives. IMO this is a dbsync problem. It should be faster then this on a magnetic drive. I should say, just to experiment I moved the VM to a different hard drive with no changed results. IMO DB sync is just doing stuff way to inefficiently. I have decided to move to Kupo  

---

## 0 answers

