mirror of
https://github.com/neondatabase/neon.git
synced 2026-01-15 01:12:56 +00:00
4be2223a4c
This PR contains the first version of a [FoundationDB-like](https://www.youtube.com/watch?v=4fFDFbi3toc) simulation testing for safekeeper and walproposer. ### desim This is a core "framework" for running determenistic simulation. It operates on threads, allowing to test syncronous code (like walproposer). `libs/desim/src/executor.rs` contains implementation of a determenistic thread execution. This is achieved by blocking all threads, and each time allowing only a single thread to make an execution step. All executor's threads are blocked using `yield_me(after_ms)` function. This function is called when a thread wants to sleep or wait for an external notification (like blocking on a channel until it has a ready message). `libs/desim/src/chan.rs` contains implementation of a channel (basic sync primitive). It has unlimited capacity and any thread can push or read messages to/from it. `libs/desim/src/network.rs` has a very naive implementation of a network (only reliable TCP-like connections are supported for now), that can have arbitrary delays for each package and failure injections for breaking connections with some probability. `libs/desim/src/world.rs` ties everything together, to have a concept of virtual nodes that can have network connections between them. ### walproposer_sim Has everything to run walproposer and safekeepers in a simulation. `safekeeper.rs` reimplements all necesary stuff from `receive_wal.rs`, `send_wal.rs` and `timelines_global_map.rs`. `walproposer_api.rs` implements all walproposer callback to use simulation library. `simulation.rs` defines a schedule – a set of events like `restart <sk>` or `write_wal` that should happen at time `<ts>`. It also has code to spawn walproposer/safekeeper threads and provide config to them. ### tests `simple_test.rs` has tests that just start walproposer and 3 safekeepers together in a simulation, and tests that they are not crashing right away. `misc_test.rs` has tests checking more advanced simulation cases, like crashing or restarting threads, testing memory deallocation, etc. `random_test.rs` is the main test, it checks thousands of random seeds (schedules) for correctness. It roughly corresponds to running a real python integration test in an environment with very unstable network and cpu, but in a determenistic way (each seed results in the same execution log) and much much faster. Closes #547 --------- Co-authored-by: Arseny Sher <sher-ars@yandex.ru>
51 lines
1.4 KiB
Rust
51 lines
1.4 KiB
Rust
use rand::{rngs::StdRng, Rng};
|
|
|
|
/// Describes random delays and failures. Delay will be uniformly distributed in [min, max].
|
|
/// Connection failure will occur with the probablity fail_prob.
|
|
#[derive(Clone, Debug)]
|
|
pub struct Delay {
|
|
pub min: u64,
|
|
pub max: u64,
|
|
pub fail_prob: f64, // [0; 1]
|
|
}
|
|
|
|
impl Delay {
|
|
/// Create a struct with no delay, no failures.
|
|
pub fn empty() -> Delay {
|
|
Delay {
|
|
min: 0,
|
|
max: 0,
|
|
fail_prob: 0.0,
|
|
}
|
|
}
|
|
|
|
/// Create a struct with a fixed delay.
|
|
pub fn fixed(ms: u64) -> Delay {
|
|
Delay {
|
|
min: ms,
|
|
max: ms,
|
|
fail_prob: 0.0,
|
|
}
|
|
}
|
|
|
|
/// Generate a random delay in range [min, max]. Return None if the
|
|
/// message should be dropped.
|
|
pub fn delay(&self, rng: &mut StdRng) -> Option<u64> {
|
|
if rng.gen_bool(self.fail_prob) {
|
|
return None;
|
|
}
|
|
Some(rng.gen_range(self.min..=self.max))
|
|
}
|
|
}
|
|
|
|
/// Describes network settings. All network packets will be subjected to the same delays and failures.
|
|
#[derive(Clone, Debug)]
|
|
pub struct NetworkOptions {
|
|
/// Connection will be automatically closed after this timeout if no data is received.
|
|
pub keepalive_timeout: Option<u64>,
|
|
/// New connections will be delayed by this amount of time.
|
|
pub connect_delay: Delay,
|
|
/// Each message will be delayed by this amount of time.
|
|
pub send_delay: Delay,
|
|
}
|