I'm easily reaching 30GB/s with a single client:

    dd if=/dev/zero of=/dev/null bs=1M status=progress

A second dd process hits the same speed.

My artisanal architecture design uses writes with a few characters and uses unix pipes:

    yes | pv > /dev/null

I hope that in my next rewrite I can advance to larger block sizes.

Interestingly I tried this as well and was disappointed with the results:

  yes $(printf %1024s | tr " " "y") | pv > /dev/null

About the same throughput as letting yes output a single character. I guess Unix pipes are slow.

> I guess Unix pipes are slow.

Or string concatenation, or pipeviewer.

yes doesn't do string concatenation, at least not in the loop that matters. It just prepares a buffer of bytes once and writes it to stdout repeatedly.

https://github.com/coreutils/coreutils/blob/master/src/yes.c

Compare https://codegolf.stackexchange.com/questions/199528/fastest-...

What's the best hardware for running a /dev/null instance for production?

A single resistor at ground voltage.

That doesn't support expected features like 'stat /dev/null'.

I usually do a kubernetes cluster on top of VMs. But sometimes when I really want to scale the standard cloud server less platforms all support /dev/null out of the box. (Except for Windows...)

> Except for Windows...

copy c:\file nul

It's been there since DOS or more likely CP/M :)

   set "nul1=1>nul"
   set "nul2=2>nul"
   set "nul6=2^>nul"
   set "nul=>nul 2>&1"

just saw this in a .cmd script

Still need an adapter library though! Fortunately there are about 7 competing implementations on npm and most of them only have 5-6 transitive dependencies.

How did you measure this? Do you know that /dev/null is the limiting factor, or could it be the data source that is limiting?