Mosquitto handles a surprising number of MQTT connections for a small process, but the limit that bites operators is rarely the broker itself. It is file descriptors, TLS handshake CPU, or a persistence setting that turns a 5,000-message-per-second stream into a disk-bound crawl. Sizing a broker properly means working out three numbers: memory per connection, cost per persisted message, and the CPU budget for TLS.<\/p>\n
The figures below come from Mosquitto 2.0.18 on a 2 vCPU \/ 4 GB instance running Debian 12, with clients connecting over TLS and a mix of QoS 0, 1, and 2 traffic. For instance sizing that matches these loads, check the VPS tiers<\/a> before you start.<\/p>\n\n An idle MQTT connection over TCP costs Mosquitto roughly 2 to 3 KB, plus kernel socket buffers of about 4 KB each way once data flows, so budget 10 KB per connection to be safe. Ten thousand idle connections therefore need around 100 MB, not 10 GB. The base process uses 8 to 12 MB before any client connects.<\/p>\n Active connections change the picture. Each in-flight QoS 1 or 2 message needs a copy of the payload for every subscriber, plus a 2 KB fixed per-message overhead in the broker’s queues. A 1 KB payload fanned out to 50 subscribers is 50 KB per publish, transient but real. With With persistence disabled, QoS 1 publishes live only in memory and cost less than 100 microseconds of broker CPU each. With QoS 2 adds a four-part handshake per message, so CPU per publish roughly doubles against QoS 1 and latency rises with round trips. For durable delivery, QoS 1 plus a persistent session ( These five settings together determine your worst case. Calculate it as connections times queued messages times payload size, and keep the result under half of available RAM. Then verify with Every client needs one file descriptor, and if you raise On the kernel side, raise A full RSA-2048 handshake costs about 1 ms on a modern core; ECDSA P-256 cuts that to roughly a third and halves the bytes exchanged. That sounds trivial until 2,000 devices reconnect simultaneously after a power cut, which is 2 seconds of pure handshake work plus the connection churn on top. Use ECDSA certificates, enable TLS 1.3 to benefit from session resumption, and set a session ticket lifetime of several hours so reconnects skip the expensive path.<\/p>\n On 2 vCPU, expect about 4,500 new TLS connections per second in a handshake-only benchmark, dropping below 2,000 once message traffic shares the cores. If your fleet is larger than a few thousand devices, put a TLS-terminating proxy or a load balancer in front, or accept longer reconnect storms. Bridges replicate topics between brokers, typically from an edge node to a central one. Configure them in Two settings matter for throughput. The four metrics that predict failure are connected clients, messages stored, heap or RSS growth, and file descriptors in use. Watch Alert on three conditions: RSS above 70 percent of the instance, file descriptors above 60 percent of Connection-count memory math<\/h2>\n
max_inflight_messages<\/code> at its default of 20, a single slow client can hold 20 queued messages; ten slow clients hold 200. Cap queue depth and you cap memory.<\/p>\n\nWhat QoS 1 and QoS 2 actually cost to persist<\/h2>\n
persistence true<\/code>, Mosquitto writes sessions and retained messages to mosquitto.db<\/code>, not every message. Retained messages are the expensive part: 100,000 retained topics at 200 bytes average grew the database file to about 60 MB and added 2.5 seconds to startup while it loaded.<\/p>\nclean_session false<\/code>, or MQTT 5 session-expiry-interval<\/code>) gives almost the same guarantee with less overhead. Reserve QoS 2 for billing or command messages where duplicates are genuinely unacceptable, and measure: we saw 9,000 messages per second at QoS 1 drop to 5,200 at QoS 2 on the same box.<\/p>\n\nmax_connections, max_inflight_messages, and queue limits<\/h2>\n
\n
max_connections<\/code> defaults to unlimited, which means the OS limit becomes the real cap. Set it explicitly to a number you have sized for, such as 5000.<\/li>\nmax_inflight_messages<\/code> defaults to 20; lower it to 8 to 10 for constrained clients and memory predictability.<\/li>\nmax_queued_messages<\/code> defaults to 1000 per client; at 1 KB average that is 1 MB per stalled client, so 500 stalled clients would need 500 MB.<\/li>\nmax_packet_size<\/code> defaults to 256 MB; set it to 256 KB or 1 MB unless you send large images, to stop a single client exhausting memory.<\/li>\nmessage_size_limit<\/code> and max_keepalive<\/code> bound the remaining edges.<\/li>\n<\/ul>\nmosquitto_sub -t '$SYS\/#' -v<\/code>, which exposes $SYS\/broker\/clients\/connected<\/code> and $SYS\/broker\/messages\/stored<\/code>.<\/p>\n\nFile descriptors and kernel sysctl limits<\/h2>\n
max_connections<\/code> without raising limits the broker will fail to accept new sockets with a vague error. systemd’s default LimitNOFILE<\/code> is often 1024. Set LimitNOFILE=65536<\/code> in the unit file, and confirm with cat \/proc\/$(pidof mosquitto)\/limits<\/code>.<\/p>\nnet.core.somaxconn<\/code> to 4096, net.ipv4.tcp_max_syn_backlog<\/code> to 8192, and fs.file-max<\/code> to 2097152. For brokers with tens of thousands of mostly idle connections, net.ipv4.tcp_keepalive_time<\/code> at 300 seconds clears dead sockets faster than the minute-long MQTT keepalive on its own. Write these into \/etc\/sysctl.d\/99-mosquitto.conf<\/code> and reload, not into a shell one-liner you will forget.<\/p>\n\nTLS handshake CPU cost<\/h2>\n
per_listener_settings true<\/code> lets you keep a plaintext listener on localhost for bridges and monitoring without TLS overhead.<\/p>\n\nBridging to a second broker<\/h2>\n
mosquitto.conf<\/code> with connection<\/code>, address<\/code>, and topic<\/code> lines, setting bridge_protocol_version mqttv311<\/code> unless both ends speak MQTT 5. Use try_private false<\/code> when bridging to non-Mosquitto brokers such as HiveMQ or EMQX, or the bridge fails silently.<\/p>\nnotifications_local_only true<\/code> stops looped bridge messages from bouncing between nodes. bridge_queue_qos<\/code> and the per-bridge queue length, default 64 messages, determine how much traffic survives a WAN blip; raise it to 1000 if your link is flaky, but remember every queued message is memory. Restrict bridge topics to narrow prefixes rather than #<\/code>, because copying all traffic to a second site doubles bandwidth and persistence load for no benefit.<\/p>\n\nMonitoring what actually breaks first<\/h2>\n
$SYS\/broker\/clients\/connected<\/code>, $SYS\/broker\/messages\/stored<\/code>, $SYS\/broker\/load\/messages\/received\/1min<\/code>, and the process RSS from node_exporter. A steady climb in messages stored means clients are not acknowledging and queues are filling; that is your first sign of a network or client bug, not a broker bug.<\/p>\nLimitNOFILE<\/code>, and any drop in connected clients greater than 10 percent in a minute. For persistence, watch mosquitto.db<\/code> growth; if it exceeds a few hundred megabytes, prune retained topics with mosquitto_sub -t '$SYS\/broker\/retained messages\/count'<\/code> and a null-payload publish. Choose an instance with headroom for a reconnect storm, as described on the hosting plans page<\/a>, and size for twice your steady client count.<\/p>\n\nA workable starting configuration<\/h2>\n