noisia

Noisia

Harmful workload generator for PostgreSQL.

Supported workloads:

• idle transactions - active transactions on hot-write tables that do nothing during their lifetime.
• rollbacks - fake invalid queries that generate errors and increase rollbacks counter.
• waiting transactions - one holder cycles an ACCESS EXCLUSIVE lock on a single table while a rate-limited manager opens N separate connections (--wait-xacts.waiters) that each block on it — a flickering staircase of blocked sessions that, unbounded (--wait-xacts.waiters=0), climbs until max_connections is exhausted and new clients get FATAL: sorry, too many clients already.
• deadlocks - simultaneous transactions where each holds locks that the other transactions want.
• temporary files - queries that sort a seeded dataset larger than work_mem, spilling to on-disk temporary files on a default-configured server; raising work_mem (per-role/-database) makes the same query run in memory — the spill disappears (the remediation demo).
• terminate backends - terminate random backends (or queries) using pg_terminate_backend(), pg_cancel_backend().
• failed connections - exhaust all available connections (other clients unable to connect to Postgres).
• fork connections - execute single, short query in a dedicated connection (lead to excessive forking of Postgres backends).
• backend-killer - single session leaks prepared statements (plan-cache growth) inflating its backend's memory until OOM-kill restarts the whole instance; a very large --backend-killer.plan-size makes each PREPARE heavy/slow.
• slot-bloat - a single un-consumed physical replication slot pins WAL so pg_wal grows without bound → disk full → instance PANIC; the data never grows and checkpoints keep running, yet the disk still fills.
• wal-flood - many parallel UPDATE-churn workers (--jobs) flood WAL on the primary by raw write rate, driving replication lag and — when recycle/archiving can't keep up — pg_wal growth toward disk-full; the visible-activity counterpart of slot-bloat (disk-full here is environment-dependent, not guaranteed).
• bloat-churn - many parallel UPDATE-churn workers (--jobs) outrun a still-enabled autovacuum by raw rate, breaking HOT with an indexed updated_at = now() so heap and index bloat while the untouched table tail keeps VACUUM from truncating the file; the remediable rate-attack counterpart to xmin-horizon-holder — same symptom, but after stopping noisia the table is repairable with VACUUM FULL / pg_repack / REINDEX CONCURRENTLY.
• ...see built-in help for more runtime options.

Disclaimer

ATTENTION: USE ONLY FOR TESTING PURPOSES, DO NOT EXECUTE NOISIA WITHOUT COMPLETE UNDERSTANDING WHAT YOU REALLY DO, RECKLESS USAGE WILL CAUSE PROBLEMS.

DISCLAIMER: THIS SOFTWARE PROVIDED AS-IS WITH NO CARES AND GUARANTEES RELATED TO YOUR DATABASES. USE AT YOUR OWN RISK.

Installation and usage

Check out releases page.

Using Docker

docker pull lesovsky/noisia:latest
docker run --rm -ti lesovsky/noisia:latest noisia --help

Using in your own code

You can import noisia and use necessary workloads in your code. Always use contexts to avoid infinite run. See tiny example below:

package main

import (
	"context"
	"fmt"
	"github.com/lesovsky/noisia/waitxacts"
	"github.com/rs/zerolog"
	"log"
	"os"
	"time"
)

func main() {
	config := waitxacts.Config{
		Conninfo:       "host=127.0.0.1",
		Waiters:        10,
		WaitersRate:    1,
		ReportInterval: 1*time.Second,
		LocktimeMin:    5*time.Second,
		LocktimeMax:    20*time.Second,
	}

	logger := zerolog.New(zerolog.ConsoleWriter{Out: os.Stdout, TimeFormat: time.RFC3339}).Level(zerolog.InfoLevel).With().Timestamp().Logger()

	ctx, cancel := context.WithTimeout(context.Background(), 4*time.Second)
	defer cancel()

	w, err := waitxacts.NewWorkload(config, logger)
	if err != nil {
		log.Panicln(err)
	}
	
	err = w.Run(ctx)
	if err != nil {
		fmt.Println(err)
	}
}

Workload impact

Running workloads could impact already running workloads produced by other applications. This impact might be expressed as performance degradation, transactions getting stuck, cancelled queries, disconnected clients, etc.

Demo & tuning guides

The escalating workloads each have a dedicated demo and tuning guide covering how to build a reliable stand, tune the pressure, read the self-report, and recover afterwards:

• docs/workloads/backend-killer.md — drive a single backend to OOM and an instance restart; cap memory, disable swap, and turn up the plan pressure.
• docs/workloads/slot-bloat.md — fill pg_wal with one forgotten replication slot until the disk is full; CLI flags, two stand recipes, and slot-crash recovery.
• docs/workloads/wal-flood.md — flood WAL with parallel UPDATE-churn workers; the honest env-dependent contract, the disk-full conditions, demo parameters, and how it differs from slot-bloat.
• docs/workloads/bloat-churn.md — outrun autovacuum by raw rate to grow remediable heap+index bloat; the trio that builds it, the post-stop repair reveal (VACUUM FULL / pg_repack / REINDEX CONCURRENTLY), what to watch via pgstattuple, and how a rate attack differs from xmin-horizon-holder's horizon attack.
• docs/workloads/tempfiles.md — spill on-disk temp files by sorting a seeded dataset larger than work_mem on a default-configured server; how to watch temp_files/temp_bytes and log_temp_files, and the headline remediation — raise work_mem and the spill disappears.
• docs/workloads/waitxacts.md — build a pile of blocked waiter sessions behind one held table lock; the observation demo (a flickering staircase of wait_event_type='Lock') and the cascade demo (unbounded waiters until max_connections is exhausted), plus the superuser_reserved_connections role trick that keeps a postgres monitor alive while app clients are refused.

Contribution

• PR's are welcome.
• Ideas could be proposed here
• About grammar issues or typos let me know here.

License

BSD-3. See LICENSE for more details.