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

Issue with bootstrap.sh #3931

Closed
rafael opened this issue May 15, 2018 · 2 comments
Closed

Issue with bootstrap.sh #3931

rafael opened this issue May 15, 2018 · 2 comments

Comments

@rafael
Copy link
Member

rafael commented May 15, 2018

After syncing with vitess upstream master, my local environment started to fail. I'm getting this error when trying to run govendor sync:

Updating govendor dependencies...
Error: lstat /vagrant/src/vitess.io/vitess/src: no such file or directory
govendor sync
	Ensures the contents of the vendor folder matches the vendor file.
	Options:
		-n           dry run, print out action only
		-insecure    allow downloading over insecure connection
		-v           verbose output

I think the issue was caused by this change: 9a6f21e#diff-ddc2cfd1974a9de860d19fbdc66bbe83R114.

Without the fix, bootstrap.sh works in my environment 😅 - @michael-berlin, do you know why we need to add $VTROOT to the gopath? Can we remove this line altogether ?

@michael-berlin
Copy link
Contributor

Yes, $VTROOT must be in your $GOPATH. In fact, it's the only thing in my Go path:

# This is my $VTTOP i.e. where Git is checked out.
$ pwd
/home/mberlin/workspace/vitess/src/vitess.io/vitess

$ echo $VTROOT
/home/mberlin/workspace/vitess

$ echo $GOPATH
/home/mberlin/workspace/vitess

@rafael
Copy link
Member Author

rafael commented May 16, 2018

Hmm - I see.

I recreated my env from scratch and it fixed the problem. Going to close this.

@rafael rafael closed this as completed May 16, 2018
mattrobenolt added a commit to mattrobenolt/vitess that referenced this issue Jul 22, 2024
On Linux, the fadvise(2) syscall can be leveraged to hint to to kernel
to readahead disk pages since the file is intended to be read
sequentially.

This works well with our use of opening this file, then slamming it into
`io.Copy`.

In benchmarking, this alone yields around ~50% improvement on the read
side without other tunings.

In a naive test, the setup was simply an io.Copy with an os.File for
src, and io.Discard for dest:

  no fadvise: 222.41 MB/s
with fadvise: 344.69 MB/s

This is with no other tunings to the kernel.

Refs vitessio#3931

Signed-off-by: Matt Robenolt <[email protected]>
mattrobenolt added a commit to mattrobenolt/vitess that referenced this issue Jul 22, 2024
On Linux, the fadvise(2) syscall can be leveraged to hint to to kernel
to readahead disk pages since the file is intended to be read
sequentially.

This works well with our use of opening this file, then slamming it into
`io.Copy`.

In benchmarking, this alone yields around ~50% improvement on the read
side without other tunings.

In a naive test, the setup was simply an io.Copy with an os.File for
src, and io.Discard for dest:

  no fadvise: 222.41 MB/s
with fadvise: 344.69 MB/s

This is with no other tunings to the kernel.

Refs vitessio#3931

Signed-off-by: Matt Robenolt <[email protected]>
mattrobenolt added a commit to mattrobenolt/vitess that referenced this issue Jul 22, 2024
On Linux, the fadvise(2) syscall can be leveraged to hint to the kernel
to readahead disk pages since the file is intended to be read
sequentially.

This works well with our use of opening this file, then slamming it into
`io.Copy`.

In benchmarking, this alone yields around ~50% improvement on the read
side without other tunings.

In a naive test, the setup was simply an io.Copy with an os.File for
src, and io.Discard for dest:

  no fadvise: 222.41 MB/s
with fadvise: 344.69 MB/s

This is with no other tunings to the kernel.

Refs vitessio#3931

Signed-off-by: Matt Robenolt <[email protected]>
mattrobenolt added a commit to mattrobenolt/vitess that referenced this issue Jul 23, 2024
On Linux, the fadvise(2) syscall can be leveraged to hint to the kernel
to readahead disk pages since the file is intended to be read
sequentially.

This works well with our use of opening this file, then slamming it into
`io.Copy`.

In benchmarking, this alone yields around ~50% improvement on the read
side without other tunings.

In a naive test, the setup was simply an io.Copy with an os.File for
src, and io.Discard for dest:

  no fadvise: 222.41 MB/s
with fadvise: 344.69 MB/s

This is with no other tunings to the kernel.

Refs vitessio#3931

Signed-off-by: Matt Robenolt <[email protected]>
mattrobenolt added a commit to mattrobenolt/vitess that referenced this issue Jul 24, 2024
On Linux, the fadvise(2) syscall can be leveraged to hint to the kernel
to readahead disk pages since the file is intended to be read
sequentially.

This works well with our use of opening this file, then slamming it into
`io.Copy`.

In benchmarking, this alone yields around ~50% improvement on the read
side without other tunings.

In a naive test, the setup was simply an io.Copy with an os.File for
src, and io.Discard for dest:

  no fadvise: 222.41 MB/s
with fadvise: 344.69 MB/s

This is with no other tunings to the kernel.

Refs vitessio#3931

Signed-off-by: Matt Robenolt <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants