[improvement](memory) fix olap table scan and sink memory usage problem

[xiaokang]

Proposed changes

Issue Number: NA

Problem Summary:

Due to unlimited queue in OlapScanNode and NodeChannel, memory usage can be very large for reading and writting large table, e.g 'insert into tableB select * from tableA'.

Checklist(Required)

1. Does it affect the original behavior: (No)
2. Has unit tests been added: (No)
3. Has document been added or modified: (No Need)
4. Does it need to update dependencies: (No)
5. Are there any changes that cannot be rolled back: (No)

Further comments

1. Add bytes limit (2.5% of query_options.mem_limit) for _scan_row_batches queue in OlapScanNode. There was no limit for _scan_row_batches yet.
2. Add bytes limit (2.5% of exec_mem_limit) for _materialized_row_batches queue in OlapScanNode. There was only queue size limit for _materialized_row_batches before, and it's not enough for data with large average bytes of a single row.
3. Add bytes limit for reading a single batch. A new be config doris_scanner_row_bytes is added and its default value is 10MB. There was only row number limit before, and it's also not enough for data with large average bytes of a single row.
4. Add bytes limit (5% of load_mem_limit) for _max_pending_batches queue in NodeChannel.
5. Fixed an exceptional zero value of max_thread in OlapScanNode.

[morningman]

LGTM, but there are 2 more things:

1. It is better to provide some data to illustrate the memory usage before and after the modification in order to give more information to the reviewer.
2. Also need to modify the src/vec/exec/volap_scan_node.cpp

[xiaokang]

Hi @morningman, Thanks for your quick response!

1. It is better to provide some data to illustrate the memory usage before and after the modification in order to give more information to the reviewer.

Test environment:
A single node cluster with 32g memory and 8 cpu cores. All configuration is default.

Table schema:
CREATE TABLE tableA (
uuid text NULL,
no text NULL,
f text NULL,
m text NULL,
data text NULL,
time1 datetime NULL,
time2 datetime NULL,
p text NOT NULL
) ENGINE=OLAP
DUPLICATE KEY(uuid)
PARTITION BY LIST(p)
(PARTITION p1 VALUES IN ("1"),
...
PARTITION p98 VALUES IN ("98"),
PARTITION p99 VALUES IN ("99"))
DISTRIBUTED BY HASH(uuid) BUCKETS 10
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"in_memory" = "false",
"storage_format" = "V2"
)

Test steps:

1. create tableA and tableB with 100 partition.
2. insert 1 million rows with large average size 100KB to tableA.
3. execute query: 'set batch_size = 128; set exec_mem_limit=8147483648; insert into tableB select * from table A;'

Result:

• master branch: be process quickly consume all 32g memory in about 20 seconds and killed by Linux oom-killer.
• fix branch: The memory usage of be process is 14g memory at peak and fall back to 8g when query finished. 8g is for be storage page cache (32g*20%=6g) and chunk_reserved_bytes (2g).

2. Also need to modify the src/vec/exec/volap_scan_node.cpp

I will try to do the same things for the vectorized code.

[xiaokang]

@morningman volap_scan_node.cpp is done. The test result is almost the same as non-vectorized version.

[morningman]

LGTM

[github-actions]

PR approved by at least one committer and no changes requested.

[github-actions]

PR approved by anyone and no changes requested.