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

Cannot start a node with cleveldb enabled #636

Closed
blewater opened this issue Dec 2, 2021 · 14 comments
Closed

Cannot start a node with cleveldb enabled #636

blewater opened this issue Dec 2, 2021 · 14 comments
Assignees

Comments

@blewater
Copy link

blewater commented Dec 2, 2021

Hi,

Osmosis version:

git checkout v3.1.0

Error in Ubuntu 20.04 with the cleveldb option enabled

INF starting ABCI with Tendermint
Error: unknown db_backend cleveldb, expected one of goleveldb,memdb

build Instruction

make build OSMOSIS_BUILD_OPTIONS=cleveldb

go build -mod=readonly -tags "netgo ledger gcc" -ldflags '-X github.com/cosmos/cosmos-sdk/version.Name=osmosis -X github.com/cosmos/cosmos-sdk/version.AppName=osmosisd -X github.com/cosmos/cosmos-sdk/version.Version=3.1.0 -X github.com/cosmos/cosmos-sdk/version.Commit=13916d1e10bca718b6ea7f4b84715710bc319e6d -X "github.com/cosmos/cosmos-sdk/version.BuildTags=netgo,ledger,gcc" -X github.com/cosmos/cosmos-sdk/types.DBBackend=cleveldb -w -s' -trimpath -o /home/mar/go/src/github.com/osmosis-labs/osmosis/build/ ./...

Start script

rm -rf $HOME/.osmosisd/

cd $HOME

osmosisd init --chain-id=testing testing --home=$HOME/.osmosisd
osmosisd keys add validator --keyring-backend=test --home=$HOME/.osmosisd
osmosisd add-genesis-account $(osmosisd keys show validator -a --keyring-backend=test --home=$HOME/.osmosisd) 1000000000stake,1000000000valtoken --home=$HOME/.osmosisd
osmosisd gentx validator 500000000stake --keyring-backend=test --home=$HOME/.osmosisd --chain-id=testing
osmosisd collect-gentxs --home=$HOME/.osmosisd

osmosisd start --home=$HOME/.osmosisd --db_backend=cleveldb

Clevel db build instructions ref

sudo apt-get update
sudo apt install build-essential

sudo apt-get install libsnappy-dev

wget https://github.com/google/leveldb/archive/v1.20.tar.gz && \
  tar -zxvf v1.20.tar.gz && \
  cd leveldb-1.20/ && \
  make && \
  sudo cp -r out-static/lib* out-shared/lib* /usr/local/lib/ && \
  cd include/ && \
  sudo cp -r leveldb /usr/local/include/ && \
  sudo ldconfig && \
  rm -f v1.20.tar.gz

What am I missing?

@daniel-farina daniel-farina self-assigned this Dec 3, 2021
@daniel-farina daniel-farina added this to the 2021 - December Milestone milestone Dec 3, 2021
@daniel-farina
Copy link
Contributor

Sorry not too familiar with cleveldb, what is the reason to use it instead of goleveldb?
Similar issues:
tendermint/tendermint#4003
https://forum.cosmos.network/t/compiling-tendermint-with-cleveldb/5026/2

@blewater
Copy link
Author

blewater commented Dec 3, 2021

We are exploring it for block generation performance gains for our node during epoch settlements. It is the general consensus within the ecosystem that goleveldb is the least performant DB option for running validator nodes; other options being cleveldb, rocksdb.
Cleveldb is the first recommended option by the tendermint team when database trx activity is high (i.e., ref1, ref2)

An example of going as far as making Rocksdb the default option.

@faddat
Copy link
Member

faddat commented Dec 4, 2021

Have you tried with rocksdb?

I have been experimenting with badgerdb.

@blewater
Copy link
Author

blewater commented Dec 4, 2021

@faddat Same result but at least I can get a stripped tendermint node work with cleveldb. I haven't been successful in getting a v34 tendermint node launch with either v5.18.3 or latest v6 Rocksdb built in Ubuntu 20.04, Go 1.17.

@faddat
Copy link
Member

faddat commented Dec 4, 2021

@blewater sooooooo -- I did a bunch of work with RocksDB back in the day. Can confirm that it is very, very performant.

  • Do we know if Desmos is still using Rocks only? (seems not by a glance at Makefile, but not sure)
  • One of the things that helped me a lot with working with all that low level C++ was using Arch linux, and yes, it is a pain to get rolling. Also, I generally did not use gcc, but clang instead. Maybe try making clang your default cxx like:

export CXX=clang

-- and you probably want to make sure it is the very latest clang.

You might need to install additional libraries for this. Our build process for Blurt was always pretty complex. I think I've seen that badger is a pretty good set of tradeoffs between native Goness and speed. That's what I am evaluating and here is how I am compiling-- note that I do not mess with the Makefile:

go install -tags badgerdb ./...

here's how I run osmosis:

ulimit -n 50000
osmosisd start --pruning nothing --db_backend badgerdb --p2p.seeds 1b077d96ceeba7ef503fb048f343a538b2dcdf1b@136.243.218.244:26656,2308bed9e096a8b96d2aa343acc1147813c59ed2@3.225.38.25:26656,902bdfe51b6a97cc9369664a21c87ed61d471d2a@136.243.218.243:26656,085f62d67bbf9c501e8ac84d4533440a1eef6c45@95.217.196.54:26656,f515a8599b40f0e84dfad935ba414674ab11a668@osmosis.blockpane.com:26656,63aba59a7da5197c0fbcdc13e760d7561791dca8@162.55.132.230:2000

Also I need to note that the ulimit thing is very important. I now have a node syncing faster than I've ever seen before.

@faddat
Copy link
Member

faddat commented Dec 4, 2021

Screen.Recording.2021-12-05.at.3.47.49.AM.mov

@faddat
Copy link
Member

faddat commented Dec 4, 2021

go build -mod=readonly -tags "netgo ledger cleveldb gcc" -ldflags '-X github.com/cosmos/cosmos-sdk/version.Name=osmosis -X github.com/cosmos/cosmos-sdk/version.AppName=osmosisd -X github.com/cosmos/cosmos-sdk/version.Version=3.1.0 -X github.com/cosmos/cosmos-sdk/version.Commit=13916d1e10bca718b6ea7f4b84715710bc319e6d -X "github.com/cosmos/cosmos-sdk/version.BuildTags=netgo,ledger,gcc" -X github.com/cosmos/cosmos-sdk/types.DBBackend=cleveldb -w -s' -trimpath -o /home/mar/go/src/github.com/osmosis-labs/osmosis/build/ ./...

@faddat
Copy link
Member

faddat commented Dec 4, 2021

your errors resemble this?

github.com/jmhodges/levigo

../go/pkg/mod/github.com/jmhodges/levigo@v1.0.0/batch.go:4:11: fatal error: 'leveldb/c.h' file not found
#include "leveldb/c.h"
^~~~~~~~~~~~~
1 error generated.

@faddat
Copy link
Member

faddat commented Dec 7, 2021

To make-happy goRocksdb, do exactly, on exactly arch linux:

pacman -Syyu rocksdb base-devel snappy cmake

your go.mod needs to look like, for v4.2.0 w/ speed boosts:

module github.com/osmosis-labs/osmosis

go 1.17

require (
	github.com/cosmos/cosmos-sdk v0.42.9
	github.com/cosmos/go-bip39 v1.0.0
	github.com/cosmos/iavl v0.16.0
	github.com/gogo/protobuf v1.3.3
	github.com/golang/protobuf v1.5.2
	github.com/gorilla/mux v1.8.0
	github.com/grpc-ecosystem/grpc-gateway v1.16.0
	github.com/pkg/errors v0.9.1
	github.com/rakyll/statik v0.1.7
	github.com/regen-network/cosmos-proto v0.3.1
	github.com/spf13/cast v1.3.1
	github.com/spf13/cobra v1.1.3
	github.com/spf13/pflag v1.0.5
	github.com/stretchr/testify v1.7.0
	github.com/tendermint/tendermint v0.34.14
	github.com/tendermint/tm-db v0.6.4
	google.golang.org/genproto v0.0.0-20210114201628-6edceaf6022f
	google.golang.org/grpc v1.40.0
	google.golang.org/protobuf v1.27.0
	gopkg.in/yaml.v2 v2.4.0
)

require (
	github.com/99designs/keyring v1.1.6 // indirect
	github.com/ChainSafe/go-schnorrkel v0.0.0-20200405005733-88cbf1b4c40d // indirect
	github.com/DataDog/zstd v1.4.5 // indirect
	github.com/Workiva/go-datastructures v1.0.52 // indirect
	github.com/armon/go-metrics v0.3.8 // indirect
	github.com/beorn7/perks v1.0.1 // indirect
	github.com/bgentry/speakeasy v0.1.0 // indirect
	github.com/btcsuite/btcd v0.21.0-beta // indirect
	github.com/cespare/xxhash v1.1.0 // indirect
	github.com/cespare/xxhash/v2 v2.1.1 // indirect
	github.com/confio/ics23/go v0.6.6 // indirect
	github.com/cosmos/ledger-cosmos-go v0.11.1 // indirect
	github.com/cosmos/ledger-go v0.9.2 // indirect
	github.com/danieljoos/wincred v1.0.2 // indirect
	github.com/davecgh/go-spew v1.1.1 // indirect
	github.com/dgraph-io/badger/v2 v2.2007.2 // indirect
	github.com/dgraph-io/ristretto v0.0.3 // indirect
	github.com/dgryski/go-farm v0.0.0-20200201041132-a6ae2369ad13 // indirect
	github.com/dustin/go-humanize v1.0.0 // indirect
	github.com/dvsekhvalnov/jose2go v0.0.0-20200901110807-248326c1351b // indirect
	github.com/enigmampc/btcutil v1.0.3-0.20200723161021-e2fb6adb2a25 // indirect
	github.com/felixge/httpsnoop v1.0.1 // indirect
	github.com/fsnotify/fsnotify v1.4.9 // indirect
	github.com/go-kit/kit v0.10.0 // indirect
	github.com/go-logfmt/logfmt v0.5.0 // indirect
	github.com/godbus/dbus v0.0.0-20190726142602-4481cbc300e2 // indirect
	github.com/gogo/gateway v1.1.0 // indirect
	github.com/golang/snappy v0.0.3-0.20201103224600-674baa8c7fc3 // indirect
	github.com/google/btree v1.0.0 // indirect
	github.com/google/orderedcode v0.0.1 // indirect
	github.com/gorilla/handlers v1.5.1 // indirect
	github.com/gorilla/websocket v1.4.2 // indirect
	github.com/grpc-ecosystem/go-grpc-middleware v1.3.0 // indirect
	github.com/gsterjov/go-libsecret v0.0.0-20161001094733-a6f4afe4910c // indirect
	github.com/gtank/merlin v0.1.1 // indirect
	github.com/gtank/ristretto255 v0.1.2 // indirect
	github.com/hashicorp/go-immutable-radix v1.0.0 // indirect
	github.com/hashicorp/golang-lru v0.5.4 // indirect
	github.com/hashicorp/hcl v1.0.0 // indirect
	github.com/inconshreveable/mousetrap v1.0.0 // indirect
	github.com/jmhodges/levigo v1.0.0 // indirect
	github.com/keybase/go-keychain v0.0.0-20190712205309-48d3d31d256d // indirect
	github.com/lib/pq v1.2.0 // indirect
	github.com/libp2p/go-buffer-pool v0.0.2 // indirect
	github.com/magiconair/properties v1.8.5 // indirect
	github.com/mattn/go-isatty v0.0.12 // indirect
	github.com/matttproud/golang_protobuf_extensions v1.0.1 // indirect
	github.com/mimoo/StrobeGo v0.0.0-20181016162300-f8f6d4d2b643 // indirect
	github.com/minio/highwayhash v1.0.1 // indirect
	github.com/mitchellh/go-homedir v1.1.0 // indirect
	github.com/mitchellh/mapstructure v1.3.3 // indirect
	github.com/mtibben/percent v0.2.1 // indirect
	github.com/pelletier/go-toml v1.8.1 // indirect
	github.com/petermattis/goid v0.0.0-20180202154549-b0b1615b78e5 // indirect
	github.com/pmezard/go-difflib v1.0.0 // indirect
	github.com/prometheus/client_golang v1.10.0 // indirect
	github.com/prometheus/client_model v0.2.0 // indirect
	github.com/prometheus/common v0.23.0 // indirect
	github.com/prometheus/procfs v0.6.0 // indirect
	github.com/rcrowley/go-metrics v0.0.0-20200313005456-10cdbea86bc0 // indirect
	github.com/rs/cors v1.7.0 // indirect
	github.com/rs/zerolog v1.21.0 // indirect
	github.com/sasha-s/go-deadlock v0.2.1-0.20190427202633-1595213edefa // indirect
	github.com/spf13/afero v1.3.4 // indirect
	github.com/spf13/jwalterweatherman v1.1.0 // indirect
	github.com/spf13/viper v1.7.1 // indirect
	github.com/subosito/gotenv v1.2.0 // indirect
	github.com/syndtr/goleveldb v1.0.1-0.20200815110645-5c35d600f0ca // indirect
	github.com/tecbot/gorocksdb v0.0.0-20191217155057-f0fad39f321c // indirect
	github.com/tendermint/btcd v0.1.1 // indirect
	github.com/tendermint/crypto v0.0.0-20191022145703-50d29ede1e15 // indirect
	github.com/tendermint/go-amino v0.16.0 // indirect
	github.com/zondax/hid v0.9.0 // indirect
	go.etcd.io/bbolt v1.3.5 // indirect
	golang.org/x/crypto v0.0.0-20201221181555-eec23a3978ad // indirect
	golang.org/x/net v0.0.0-20210903162142-ad29c8ab022f // indirect
	golang.org/x/sys v0.0.0-20210903071746-97244b99971b // indirect
	golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1 // indirect
	golang.org/x/text v0.3.6 // indirect
	gopkg.in/ini.v1 v1.61.0 // indirect
	gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c // indirect
)

replace (
	github.com/cosmos/cosmos-sdk => github.com/notional-labs/cosmos-sdk v0.42.10-0.20211206231125-a8c81adde57a
	github.com/gogo/protobuf => github.com/regen-network/protobuf v1.3.3-alpha.regen.1
	github.com/tecbot/gorocksdb => github.com/cosmos/gorocksdb v0.0.0-20211202124722-2c356d6d98e4
	github.com/tendermint/tendermint => github.com/tendermint/tendermint v0.34.14
	github.com/tendermint/tm-db => github.com/osmosis-labs/tm-db v0.6.5-0.20210911033928-ba9154613417
	google.golang.org/grpc => google.golang.org/grpc v1.33.2

)

For 3.1.0 w/o speed boosts:

module github.com/osmosis-labs/osmosis

go 1.15

require (
	github.com/cosmos/cosmos-sdk v0.42.9
	github.com/cosmos/go-bip39 v1.0.0
	github.com/cosmos/iavl v0.16.0
	github.com/gogo/protobuf v1.3.3
	github.com/golang/protobuf v1.5.2
	github.com/gorilla/mux v1.8.0
	github.com/grpc-ecosystem/grpc-gateway v1.16.0
	github.com/pkg/errors v0.9.1
	github.com/rakyll/statik v0.1.7
	github.com/regen-network/cosmos-proto v0.3.1
	github.com/spf13/cast v1.3.1
	github.com/spf13/cobra v1.1.3
	github.com/spf13/pflag v1.0.5
	github.com/stretchr/testify v1.7.0
	github.com/tendermint/tendermint v0.34.11
	github.com/tendermint/tm-db v0.6.4
	google.golang.org/genproto v0.0.0-20210114201628-6edceaf6022f
	google.golang.org/grpc v1.37.0
	google.golang.org/protobuf v1.26.0
	gopkg.in/yaml.v2 v2.4.0
)

replace google.golang.org/grpc => google.golang.org/grpc v1.33.2

replace github.com/gogo/protobuf => github.com/regen-network/protobuf v1.3.2-alpha.regen.4

replace github.com/tecbot/gorocksdb => github.com/cosmos/gorocksdb v0.0.0-20211202124722-2c356d6d98e4

replace github.com/cosmos/cosmos-sdk => github.com/osmosis-labs/cosmos-sdk v0.42.10-0.20210806040506-92afdc8963ca

If you value your time & sanity, do use arch linux.

@faddat
Copy link
Member

faddat commented Dec 7, 2021

I think that we can eliminate badgerdb from the competition. It is really, really slow doing the update from v3.1.0 to v4.2.0, even with the caching changes. I will still run this archive node to the tip, check the size of the node when it is finished updating, and the like.

Rocksdb seems like it is off to a very strong start indeed.

Our relayers run against full archive nodes, so when rocks, goleveldb, and badger are fully synced, it'll be possible to have a compeition of sorts. I don't really see any advantages to using cleveldb-- are there any>?

@blewater
Copy link
Author

blewater commented Dec 7, 2021

@faddat thanks for all the detailed input!

I think that we can eliminate badgerdb from the competition. It is really, really slow doing the update from v3.1.0 to v4.2.0, even with the caching changes.

ACK

I don't really see any advantages to using cleveldb-- are there any>?

Based on older community feedback at least modest performance improvements with a relatively easy build process.
Have you tested it against the latest SDK nodes to validate whether it sustains its performance edge compared to goleveldb?

Desmos is still using Rocks only? (seems not by a glance at Makefile, but not sure)

They still offer it as an option for validators to choose. https://docs.desmos.network/fullnode/rocksdb-installation/
But I haven't been able to run it following their instructions.

I distilled installation instructions for a functional Ubuntu (tested in v20.04) rocksdb installation from this issue

git clone https://github.com/facebook/rocksdb.git
cd rocksdb
git checkout v5.18.3
make clean
make shared_lib -j4
sudo cp --preserve=links ./librocksdb.* /usr/local/lib/
sudo cp -r ./include/rocksdb/ /usr/local/include/
sudo ldconfig

To test a successful check the following commands whether they link with the rocksdb shared lib.
Note the content of test.cpp is found here

cd /tmp
g++ -std=c++11 -o rocksdbtest test.cpp -lrocksdb -lpthread -ldl
./rocksdbtest
get bar success!!

Yet gorocksdb is still unhappy; I still run into the following issues when I run the following:

CGO_CFLAGS="-I/path/to/rocksdb/include" \
CGO_LDFLAGS="-L/path/to/rocksdb -lrocksdb -lstdc++ -lm -lz -lbz2 -lsnappy -llz4 -lzstd" \
  go get github.com/tecbot/gorocksdb
# github.com/tecbot/gorocksdb
../../../../pkg/mod/github.com/roysc/gorocksdb@v1.1.1/transactiondb.go:255:17: could not determine kind of name for C.rocksdb_optimistictransactiondb_checkpoint_object_create
../../../../pkg/mod/github.com/roysc/gorocksdb@v1.1.1/transactiondb.go:208:12: could not determine kind of name for C.rocksdb_optimistictransactiondb_property_value
../../../../pkg/mod/github.com/roysc/gorocksdb@v1.1.1/transactiondb.go:236:2: could not determine kind of name for C.rocksdb_optimistictransactiondb_write
../../../../pkg/mod/github.com/roysc/gorocksdb@v1.1.1/transactiondb.go:59:12: could not determine kind of name for C.rocksdb_transactiondb_property_value

If you value your time & sanity, do use arch linux. [Rocksdb installation]

Unfortunately, not an available option.

@faddat
Copy link
Member

faddat commented Dec 8, 2021

I built https://github.com/notional-labs/sos around arch because it was the only place I could get C++ builds to work correctly, consistently. ah, I think you missed something in my directions-- check out the info on go.mod

morpheus voice

What if I told you Arch is always an option, but you just didn't know how bad the version soup is elsewhere?

@ValarDragon
Copy link
Member

Sorry, behind on following up on this. Will read through in a bit more detail in a few days, currently trying to get v5 testing things through before focusing much more time on performance issues.

LevelDB is a pretty bad fit for our access patterns, so it seems like we should not use this. I'd heavily recommend not focusing on CLevelDB. Rocks DB and BadgerDB are the places we should put more focus on imo.

@ValNodes is looking into the data structures / db configurations in more detail to get better opinions on which is better for our use case. We're also working on getting much better data access patterns in IAVL for most usecases.

@faddat faddat mentioned this issue Dec 10, 2021
4 tasks
@daniel-farina daniel-farina removed this from the 2021-12 Milestone milestone Dec 24, 2021
@daniel-farina
Copy link
Contributor

We decided to use rocksdb for now. There are significant issues with leveldb that will not work with our use case. Thank you for the suggestion!

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

No branches or pull requests

4 participants