Very poor performance on migrating to huge schemas
See original GitHub issueHey,
it seems that the migration hangs when trying to initialize this ESDL schema using edgedb --tls-security=insecure -P 5656 migration create --non-interactive
.
What I’ve tried
- I have tried multiple times and waited 1+ hour (and counting) on it to finish.
- I have also tried using the WSL edgedb instance instead of running edgedb from docker, but I end up with the same result.
My Config Setup
- Docker-compose file
- EdgeDB Version: 1.4+ffe1237
- OS Version: Win11 (docker/wsl)
Server log
(base) C:\work\code\ifcdb\dbs\ifcedge>make up
docker-compose up
[+] Running 1/0
- Container ifcedge-edgedb-1 Created 0.0s
Attaching to ifcedge-edgedb-1
ifcedge-edgedb-1 | Applying schema migrations...
ifcedge-edgedb-1 | INFO 37 2022-06-07T15:18:59.925 edb.server: starting EdgeDB server 1.4+ffe1237, built on 2022-05-16T18:45Z from revision e4c6e5f1c (2022-05-16T01:08Z) for x86_64-unknown-linux-gnu
ifcedge-edgedb-1 | INFO 37 2022-06-07T15:19:01.168 edb.server: Using 159 max backend connections based on total memory.
ifcedge-edgedb-1 | INFO 53 2022-06-07T15:19:01.219 postgres: starting PostgreSQL 13.6 on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
ifcedge-edgedb-1 | INFO 53 2022-06-07T15:19:01.222 postgres: listening on Unix socket "/tmp/tmp.NTtyXnaDNi/.s.PGSQL.5432"
ifcedge-edgedb-1 | INFO 53 2022-06-07T15:19:01.232 postgres: database system was shut down at 2022-06-07 15:18:01 UTC
ifcedge-edgedb-1 | INFO 53 2022-06-07T15:19:01.238 postgres: database system is ready to accept connections
ifcedge-edgedb-1 | INFO 37 2022-06-07T15:19:01.915 edb.server: Connection established to backend database: edgedb
ifcedge-edgedb-1 | INFO 37 2022-06-07T15:19:03.876 edb.server: started 1 compiler worker process
ifcedge-edgedb-1 | INFO 37 2022-06-07T15:19:03.879 edb.server: Serving on 127.0.0.1:35411
ifcedge-edgedb-1 | INFO 37 2022-06-07T15:19:03.879 edb.server: Serving admin on /tmp/tmp.NTtyXnaDNi/.s.EDGEDB.admin.35411
ifcedge-edgedb-1 | INFO 37 2022-06-07T15:19:04.519 edb.server: Connection established to backend database: edgedb
ifcedge-edgedb-1 | Everything is up to date. Revision initial
ifcedge-edgedb-1 | INFO 37 2022-06-07T15:19:04.646 edb.server: Received signal: Signals.SIGTERM.
ifcedge-edgedb-1 | INFO 37 2022-06-07T15:19:04.646 edb.server: Shutting down.
ifcedge-edgedb-1 | INFO 53 2022-06-07T15:19:04.832 postgres: received fast shutdown request
ifcedge-edgedb-1 | INFO 53 2022-06-07T15:19:04.837 postgres: aborting any active transactions
ifcedge-edgedb-1 | INFO 53 2022-06-07T15:19:04.838 postgres: terminating connection due to administrator command
ifcedge-edgedb-1 | INFO 53 2022-06-07T15:19:04.838 postgres: terminating connection due to administrator command
ifcedge-edgedb-1 | INFO 53 2022-06-07T15:19:04.838 postgres: background worker "logical replication launcher" (PID 60) exited with exit code 1
ifcedge-edgedb-1 | INFO 53 2022-06-07T15:19:04.845 postgres: shutting down
ifcedge-edgedb-1 | INFO 53 2022-06-07T15:19:04.883 postgres: database system is shut down
ifcedge-edgedb-1 | INFO 1 2022-06-07T15:19:06.995 edb.server: starting EdgeDB server 1.4+ffe1237, built on 2022-05-16T18:45Z from revision e4c6e5f1c (2022-05-16T01:08Z) for x86_64-unknown-linux-gnu
ifcedge-edgedb-1 | INFO 1 2022-06-07T15:19:08.061 edb.server: Using 159 max backend connections based on total memory.
ifcedge-edgedb-1 | INFO 156 2022-06-07T15:19:08.101 postgres: starting PostgreSQL 13.6 on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
ifcedge-edgedb-1 | INFO 156 2022-06-07T15:19:08.104 postgres: listening on Unix socket "/run/edgedb/.s.PGSQL.5432"
ifcedge-edgedb-1 | INFO 156 2022-06-07T15:19:08.113 postgres: database system was shut down at 2022-06-07 15:19:04 UTC
ifcedge-edgedb-1 | INFO 156 2022-06-07T15:19:08.117 postgres: database system is ready to accept connections
ifcedge-edgedb-1 | INFO 1 2022-06-07T15:19:08.772 edb.server: Connection established to backend database: edgedb
ifcedge-edgedb-1 | INFO 1 2022-06-07T15:19:10.975 edb.server: started 6 compiler worker processes
ifcedge-edgedb-1 | INFO 1 2022-06-07T15:19:10.977 edb.server: Serving on {0.0.0.0, ::}:5656
ifcedge-edgedb-1 | INFO 1 2022-06-07T15:19:10.978 edb.server: Serving admin on /run/edgedb/.s.EDGEDB.admin.5656
ifcedge-edgedb-1 | INFO 1 2022-06-07T15:19:15.993 edb.server: Connection established to backend database: edgedb
ifcedge-edgedb-1 | INFO 1 2022-06-07T15:23:08.973 edb.server: Connection discarded to backend database: edgedb
Can it be due to the size of the schema? If so should I break up my schema into modules, or could there be some definitions inside my schema that are causing stuff to break? Any help on this is much appreciated!
Let me know if there is anything else I can provide to help advance this issue,
Best Regards Kristoffer
Issue Analytics
- State:
- Created a year ago
- Comments:13 (6 by maintainers)
Top Results From Across the Web
A brain dump on schema updates - John Mikael Gundersen
This is a shame since poorly designed SQL schemas often are the ... These are big migration events rarely happening on a frequent...
Read more >Applies to - Oracle Support
BAT UTILITY HAS POOR PERFORMANCE WHEN MIGRATING LARGE DATABASES. Therefore, the migration utility should exhibit dramatic performance ...
Read more >How We Migrated Our Massive Crashes Database
Some migrations cause a high load in the DB cluster. Some tables need to be migrated during the weekend because the migration is...
Read more >Common DB schema change mistakes | Database Lab
I distinguish three big categories of DB schema migration mistakes: ... An UPDATE or DELETE targeting too many rows is a bad idea, ......
Read more >How to solve some common challenges faced while migrating ...
Finally, I'll discuss performance issues to watch for in PostgreSQL after the migration. Extraction phase issues. A common issue during this ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Great Success!
After having tried increments of 600 and 300 (both resulting in
invalid memory alloc
errors)I finally found a working increment size of 100 😃 It took approximately 20 hours to complete, but at least I have a complete schema in my database!Update: Here’s how >1000 entities looks in EdgeDB UI:
Btw: I think I am also pushing the limits of EdgeDB ui with this schema size. It took around 1+ hours to render the graph. Some scrolling lag, but it is still pretty functional 😃
Any chance there is a way to export and transfer my instantiated schema to another EdgeDB database instance without having to spend another 20 hours to create/apply my migrations?
Hah. Looks like we are bumping into internal Postgres limits with the size of the generated migration script. Should be fixable.