0

Hello everyone I did follow this guide to run GraphQL with docker-compose: https://github.com/input-output-hk/cardano-graphql

However, inputoutput/cardano-db-sync:12.0.0 is syncing super slow

CONTAINER ID   IMAGE                                                 COMMAND                  CREATED        STATUS                PORTS                                                                       NAMES
ad0aea43554e   inputoutput/cardano-db-sync:12.0.0                    "/nix/store/5ghw8rqx…"   28 hours ago   Up 28 hours                                                                                       cardano-graphql_cardano-db-sync-extended_1
23ebbe6aeed1   inputoutput/cardano-graphql-hasura:6.2.0              "docker-entrypoint.s…"   5 days ago     Up 5 days             0.0.0.0:8090->8080/tcp, :::8090->8080/tcp                                   cardano-graphql_hasura_1
fb2d31b115f3   postgres:11.5-alpine                                  "docker-entrypoint.s…"   5 days ago     Up 5 days             0.0.0.0:5432->5432/tcp, :::5432->5432/tcp                                   cardano-graphql_postgres_1
537147f0d16a   inputoutput/cardano-graphql:6.2.0-mainnet             "node index.js"          5 days ago     Up 28 hours           0.0.0.0:3100->3100/tcp, :::3100->3100/tcp                                   cardano-graphql_cardano-graphql_1
7c47cba2732c   cardanosolutions/cardano-node-ogmios:v5.1.0-mainnet   "/root/cardano-node-…"   5 days ago     Up 5 days (healthy)   3000/tcp, 12788/tcp, 0.0.0.0:1337->1337/tcp, :::1337->1337/tcp, 12798/tcp   cardano-graphql_cardano-node-ogmios_1

I did check the CPU and Memory usage CPUs are at 30% usage and RAM is 27.7/32GB.

After 28 hours it's still at 36.65% and gets slower (it was going faster at the beginning).

{
    "data": {
        "cardanoDbMeta": {
            "initialized": false,
            "syncPercentage": 36.65
        }
    }
}

This is how I start docker I was getting errors so removed RESTORE_SNAPSHOT parameter to retrieve it from the genesis. (I don't know whether the problem is related with it or not).

export NETWORK=mainnet &&\
docker pull inputoutput/cardano-graphql:6.2.0-${NETWORK} &&\
docker pull inputoutput/cardano-graphql-hasura:6.2.0 &&\
docker pull cardanosolutions/cardano-node-ogmios:v5.1.0-${NETWORK} &&\
docker-compose up -d &&\
docker-compose logs -f

1 Answer 1

0

The typical question for this would have been, what is your node and dbsync status, has it gone through a crash recently, etc. But use of < 6 GB out of 32 sounds like your node itself is not yet in sync , atleast as of the time you created the post.

Thus, the question instead would be - What are your baseline expectations for time it'd take to sync node and then dbsync? I'd expect it to take more than a day (perhaps 1.5-2.5) to sync node alone, and then depending on your IO throughput (check db sync sys requirements ), it could take further. The time taken for a particular epoch may be longer gradually as the chain adoption and use cases increase.

Furthermore, if you have restarts/crash during the sync process, it can make your experience substantially worse.

Lastly, when using Snapshots before, you were downloading an already synched to recent epoch snapshot of underlying Postgres DB, but if your node is behind DBSync by few epochs, this could also end up rolling back your DB instead of synching further.

7
  • The node is in sync right now but after 47 hours db is still at 39.66% I mean yesterday it came from 0 to 34 in 24 hours but now 5% in 23 hours. Is there anything I can do? Should I try to start with restore snapshots? Thank you for your assistance sir.
    – korimusk
    Jun 22 at 6:57
  • You can start by checking DBSync logs, uptime of pod/containers (if there was a restart, you'd be adding more hours every time), measure actual IOPs - if it matches upstream. To be sure, you mean your node wasnt in sync yesterday, but has caught up now - is that correct? Assuming the tip % is calculated in slots, for the first 34% you were actually in Byron era - which had 21600 slots per epoch (5 days), and much simpler. With shelley, you have 432000 slots per epoch, thus % distribution (besides, gradually staking, assets, scripts got unlocked) - so sync would be much slower from there on.
    – RdLrT
    Jun 22 at 7:18
  • The node is in sync for 5 days. Is there any difference in terms of speed for Byron and Shelley? or is it just the epoch size that makes it look way slower?
    – korimusk
    Jun 22 at 7:25
  • Here is the logs of db-sync: imgur.com/jGVX1Ha
    – korimusk
    Jun 22 at 7:31
  • > node is in sync for 5 days The resource consumption in OP suggests otherwise. > the epoch size that makes it look way slower Tip based % is slower as explained in previous reply. Logs: Last extract of dbsync image is not exactly helpful. Also, parts of initial reply (eg: actual IOPs requirements) are still to be answered. We often see docker users hit such issues w/resource sizing or gaining app ops experience to troubleshooting individual components - usually more suitable candidates for discord/tg platforms instead of SE (which works for Q&A/discussion formats).
    – RdLrT
    Jun 22 at 23:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.