-
Notifications
You must be signed in to change notification settings - Fork 968
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
Perf doc #1996
Perf doc #1996
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These performance docs are great! I mentioned a few minor formatting issues, but the content is perfect. Thanks so much for putting this guide together 🎉 .
docs/software/performance.md
Outdated
The performance of a `stellar-core` node varies in two main dimensions: | ||
|
||
1. _What it is configured to do_: | ||
* As discussed in the [admin.md](./admin.md) file, nodes may be configured as watchers, archivers, basic validators or full validators. These roles have different performance costs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These list items aren't rendering right (I think you just need a newline)
docs/software/performance.md
Outdated
* Each such role may have a variety of options enabled or disabled at varying costs to the node. | ||
|
||
2. _How it is physically and logically configured to do its job_: | ||
* The physical hardware -- disks, CPUs, memory and networking equipment -- supporting the node can substantially affect performance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
docs/software/performance.md
Outdated
|
||
1. The `BUCKET_DIR_PATH` config option sets the location that `stellar-core` places its buckets while (re)writing the bucket list. This should be located on a relatively fast, low-latency local disk. Ideally SSD or NVMe or similar. The faster the better. It does not need to be _very_ large and should not grow in usage _very_ fast, though `stellar-core` will fail if it fills up, so keep an eye on its utilization and make sure there's plenty of room. | ||
2. The `DATABASE` config value controls not only which _kind_ of database the node is performing transactions against, but also _where_ the database is located. Unlike with many database-backed programs, the _content_ of the database in a `stellar-core` installation is somewhat ephemeral: every node has a complete copy of it, as does every history archive, and the database can always be restored / rebuilt from history archives (it is in fact being continuously backed up every 5 minutes). So the main thing to optimize for here is latency, especially on nodes doing consensus. We recommend either: | ||
* SQLite on a fast, local disk. This is probably the fastest option and is perfectly adequate for many types of node. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
35828fa
to
14996e3
Compare
r+ 8683e14 |
Perf doc Reviewed-by: graydon
This just adds a new (preliminary!) performance.md doc as we've been discussing, that talks explicitly about sources of load on stellar-core nodes and ways to configure it to control for them.
Additions welcome. I figured I'd get a sketch done and we could build it out with contributions from operators.
(There are 2 doc-maintenance commits in here too, the only one about performance.md is the third commit)