Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Very slow performance (~2MB/s), process eventually killed #264

Open
samcfinan opened this issue Mar 1, 2023 · 6 comments
Open

Very slow performance (~2MB/s), process eventually killed #264

samcfinan opened this issue Mar 1, 2023 · 6 comments

Comments

@samcfinan
Copy link

samcfinan commented Mar 1, 2023

Hi there,

I'm using 0.10.0 with the following config:

# encryption_key: $MY_PRIVATE_ENC_KEY # optional - encrypt data on datastore
source:
  connection_uri: postgres://XXXX:XXXX@0.0.0.0:5432/XXXX # you can use $DATABASE_URL
datastore:
  gcp:
    bucket: XXXX
    region: us-east1
    access_key: XXXX
    secret: XXXX
destination:
  connection_uri: postgres://XXXX:XXXX@0.0.0.0:3000/XXXX # you can use $DATABASE_URL

The source database is remote, the destination database is running locally in Docker.

The database is approximately 15GB on disk and is running at < 5% CPU utilization. It's a remote database hosted on GCP Cloud SQL. I've observed network activity below 2MB/s while running replibyte. Eventually, the process is killed

[1]    28147 killed     replibyte -c replibyte.conf.yaml dump create
@evoxmusic
Copy link
Contributor

Hi, I am working on improving the overall performance. Watch #257

@ikegentz
Copy link

ikegentz commented Aug 22, 2023

Confirming the same issue, doesn't seem to matter where replibyte is running, I also get ~2MB/s and then the process is killed. FWIW I'm seeing this on mysql

@evoxmusic
Copy link
Contributor

evoxmusic commented Oct 1, 2023

Hi @ikegentz and @samcfinan , FYI, I'm allocating some time now to improve the performance. I found out what was the performance issue and the main issue is how the parsers work. I am right now experimenting with nom, and I got more than 600MB/s IO read. I'll keep you posted.

@pepoviola
Copy link
Contributor

That awesome!! Did you think in pest as alternative?

@evoxmusic
Copy link
Contributor

evoxmusic commented Oct 1, 2023

PEST is a good option as well, but:

  1. I didn't read good things about PEST and their performances.
  2. They admit that they have lower performances :D

CleanShot 2023-10-01 at 9 19 08

Performance is key for Replibyte.

@pepoviola
Copy link
Contributor

Yes, that true. A high optimized nom parser will be great 🙌. Ping me if I can help you with the impl.

Thx!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants