Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.38

thread-reuse

Global

Whether to keep finished threads for reuse
in the configuration this is a linethread-reuse true on x86, false on ARMinside the block Global
A setting the vendor asks not to touch on ARM

The default depends on the platform: true on x86 and false on ARM. This is the only directive whose default is declared differently for different architectures.

Normally the engine, having finished with a thread, keeps it for reuse. With the value false threads are discarded immediately.

Why this might be needed, the manual says plainly: it works around external inconveniences — for example, slowness of the top command on Linux, which is hampered by a large number of threads.

And right there — two prices for it. The first: loss of performance. The second is subtler: reuse works around a bug in old versions of glibc (before 2.2.2) that drastically reduces available virtual memory and can bring the node down if the queue grows a lot.

For ARM the manual gives a separate recommendation: do not change the default — enabling it there increases resource usage and can lead to unstable operation.

The main trap is changing a core setting for the convenience of monitoring. The reason the manual itself names is a slow top command. The price is performance and the loss of the workaround for a library bug that can bring the node down with a large queue.

The trade is clearly unprofitable, and it is not easy to see this from the description: “interferes with top” sounds like a real problem, while “a workaround for a glibc bug before 2.2.2” sounds like ancient history.

The second half: on ARM the manual asks not to touch the default at all, and there it is different. A setting copied from an x86 node to ARM lands exactly in the forbidden zone.

What the Hub does. It does not write it — the platform default stays. The fleet’s nodes are x86 — the Hub considers only x86_64 supported — so threads are reused.

The line is worth remembering when moving a configuration between nodes of different architectures: in the manual this is the only directive whose default depends on the platform rather than on the engine version.

Recommended values

What to set. The answer is short:

Value When
do not write it always: the platform default is right for it
false on x86 only if a large number of threads interferes with monitoring, and you accept both prices
true on ARM the manual directly advises against it

If monitoring is hampered, it is better to change the monitoring tool, not how the node works.

Defaults by platform, the reason (slow top), the price in performance and the workaround for the glibc bug before 2.2.2, the recommendation not to change it on ARM come from the manual, § 3.3.1.38. The assessment of the trade is ours.
Example configuration
# it is worth changing only with an understanding of both prices
thread-reuse false
On x86 this turns off thread reuse: the engine loses performance and loses the workaround for the old library bug. On ARM the manual advises against changing the default.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Turning off reuse for the convenience of monitoring

§ 3.3.1.38

What it costsThe node loses performance and loses the workaround for the old library bug — the one that with a large queue reduces available memory and can bring the process down.
How to spot itThe line is off, and the reason is “the process viewer command was slow”.
How to do it rightReturn the default, and set up monitoring with a tool that can collapse threads.

Carrying the setting over from an x86 node to ARM

§ 3.3.1.38

What it costsThe platforms have different defaults, and the manual asks not to change the value on ARM: enabling it increases resource usage and can lead to unstable operation.
How to spot itThe configuration was copied wholesale, and the ARM node behaves worse than before.
How to do it rightRemove the line and keep the platform default.
Compatibility
PowerMTA 6.0
described in the manual of this version · linux
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
thread-reuse <boolean>
Values
yes | no | true | false
Default
true on x86, false on ARM § 3.3.1.38
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive is written at the root of the configuration file and applies to the whole node: threads are shared by the instance. The default, meanwhile, depends on the architecture — a rare case where “not written” means different things on different machines.
How to check on the node
The line is visible in the configuration, the architecture — with a system command:
grep -n 'thread-reuse\|thread-min-priority\|thread-max-priority' /etc/pmta/config
uname -m
The second command matters more than the first: the default depends on the architecture, and the same configuration behaves differently on x86 and on ARM.
In the Hub
Cost of a mistake
dangerous: effects outlast a rollback
Scenarios
Capacity planning