doubled memory consumption during incoming AXFR

Summary

BIND v9.20.2 configured as secondary has doubled peak memory consumption when doing AXFR from a primary, compared to v9.18.29.

BIND versions affected

• Affects v9.20: v9.20.2
• Affects v9.21: 27c4d7ef

Steps to reproduce

1. Obtain copy of the ch. TLD from here
2. Configure primary: primary.conf

• we don't want to overload SWITCH's data source, so we use a local copy to run repeated tests

3. Configure secondary: secondary.conf
4. Start primary first and wait until it prints running message: named -g -c primary.conf
5. Start secondary: named -g -c secondary.conf
6. Observe memory consumption during the transfer: See CGroup tricks for a possible way to exactly measure process's memory usage.

What is the current bug behavior?

Memory consumption during the initial AXFR to secondary has a large peak.

Starting points on the X axis of the chart do not match because the primary itself is also faster at loading the zone from disk, but I think it's pretty from the chart what is going on.

What is the expected correct behavior?

Preferably not 2x memory peak when doing AXFR.

Relevant logs

v9.18.29

Transfer completed: 47721 messages, 14505839 records, 694180134 bytes, 29.630 secs (23428286 bytes/sec) (serial 2024100915)

v9.20.2

Transfer completed: 47747 messages, 14505839 records, 691138912 bytes, 26.081 secs (26499709 bytes/sec) (serial 2024100915)

The total time is ~ 12 % shorter, but of course that is not happening in isolation. Primary seems to be also faster at loading data from disk and uses more CPU to push the outgoing AXFR out, presumably pointing to a better ability to utilize available resources.