starrocks 并发查询不符合预期

💬 StarRocks 用户问答 性能相关
#1

为了更快的定位您的问题，请提供以下信息，谢谢
【详述】问题详细描述
【背景】做过哪些操作？
【业务影响】
【StarRocks版本】例如：3.1.0
【集群规模】例如：3fe（1 follower+2observer）+3be）
【机器信息】CPU虚拟核/内存/网卡，例如：24C/72G/万兆
【联系方式】 963841621@qq.com - 滴滴小贺
【附件】

  • 并行度：show variables like ‘%parallel_fragment_exec_instance_num%’ =4;
    show variables like ‘%pipeline_dop%’ = 0;
  • pipeline是否开启：show variables like ‘%pipeline%’;
    | enable_pipeline_engine | true |
    | enable_pipeline_query_statistic | true |
    | max_pipeline_dop | 64 |
    | pipeline_dop | 0 |
    | pipeline_profile_level | 1 |
    | pipeline_sink_dop | 0
  • 执行计划：所有的sql都命中了物化视图。
  • be节点cpu 50%左右 和内存使用率 55% 左右。
    我有三十个sql， 查询计划看都是命中了物化视图， 并且单个查询最多耗时不超过3s。 但是当这个三十个sql并发查询时，耗时会达到20-30秒的样子。不符合预期
#2

3.1版本上 parallel_fragment_exec_instance_num 参数已经失效了，开启pipeline的话，主要是 pipeline_dop来控制查询并行度。

高并发场景，可以 set global pipeline_dop=1 ，避免资源争抢。

可以再测试下 pipeline_dop=1；pipeline_dop=2；pipeline_dop=4 这几种配置下并发查询性能

#3

好的 我测试一下

#4

不行 越来越慢了 30多秒四十秒了
±---------------------------------------------±--------------------------+
| Variable_name | Value |
±---------------------------------------------±--------------------------+
| SQL_AUTO_IS_NULL | false |
| activate_all_roles_on_login | true |
| analyze_mv | sample |
| auto_increment_increment | 1 |
| autocommit | true |
| big_query_log_cpu_second_threshold | 480 |
| big_query_log_scan_bytes_threshold | 10737418240 |
| big_query_log_scan_rows_threshold | 1000000000 |
| broadcast_row_limit | 15000000 |
| cbo_cte_reuse | true |
| cbo_enable_low_cardinality_optimize | true |
| cbo_max_reorder_node_use_dp | 10 |
| cbo_max_reorder_node_use_exhaustive | 4 |
| cbo_push_down_distinct_below_window | true |
| cbo_reorder_threshold_use_exhaustive | 6 |
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_results | utf8 |
| character_set_server | utf8 |
| collation_connection | utf8_general_ci |
| collation_database | utf8_general_ci |
| collation_server | utf8_general_ci |
| connector_io_tasks_per_scan_operator | 16 |
| connector_scan_use_query_mem_ratio | 0.3 |
| count_distinct_column_buckets | 1024 |
| default_rowset_type | alpha |
| default_table_compression | lz4_frame |
| disable_colocate_join | false |
| disable_join_reorder | false |
| div_precision_increment | 4 |
| enable_adaptive_sink_dop | true |
| enable_big_query_log | true |
| enable_cbo_table_prune | false |
| enable_collect_table_level_scan_stats | true |
| enable_connector_adaptive_io_tasks | true |
| enable_deliver_batch_fragments | true |
| enable_distinct_column_bucketization | false |
| enable_filter_unused_columns_in_scan_stage | true |
| enable_global_runtime_filter | true |
| enable_groupby_use_output_alias | false |
| enable_hive_column_stats | true |
| enable_hive_metadata_cache_with_insert | false |
| enable_incremental_mv | false |
| enable_insert_strict | true |
| enable_load_profile | false |
| enable_local_shuffle_agg | true |
| enable_materialized_view_rewrite | true |
| enable_materialized_view_union_rewrite | true |
| enable_materialized_view_view_delta_rewrite | true |
| enable_multicolumn_global_runtime_filter | false |
| enable_mv_planner | false |
| enable_outer_join_reorder | true |
| enable_parallel_merge | true |
| enable_pipeline_engine | true |
| enable_pipeline_query_statistic | true |
| enable_populate_block_cache | true |
| enable_predicate_reorder | false |
| enable_profile | false |
| enable_prune_complex_types | true |
| enable_query_cache | false |
| enable_query_dump | false |
| enable_query_queue_load | false |
| enable_query_queue_select | true |
| enable_query_queue_statistic | false |
| enable_rbo_table_prune | false |
| enable_rewrite_groupingsets_to_union_all | false |
| enable_rewrite_simple_agg_to_meta_scan | false |
| enable_rewrite_sum_by_associative_rule | true |
| enable_rule_based_materialized_view_rewrite | true |
| enable_runtime_adaptive_dop | false |
| enable_scan_block_cache | false |
| enable_shared_scan | false |
| enable_sort_aggregate | false |
| enable_spill | false |
| enable_sync_materialized_view_rewrite | true |
| enable_tablet_internal_parallel | true |
| event_scheduler | OFF |
| force_schedule_local | false |
| forward_to_leader | false |
| full_sort_late_materialization | false |
| group_concat_max_len | 65535 |
| hash_join_push_down_right_table | true |
| hive_partition_stats_sample_size | 3000 |
| hudi_mor_force_jni_reader | false |
| init_connect | |
| innodb_read_only | true |
| interactive_timeout | 3600 |
| io_tasks_per_scan_operator | 4 |
| join_implementation_mode_v2 | auto |
| language | /starrocks/share/english/ |
| license | Apache License 2.0 |
| load_mem_limit | 0 |
| load_transmission_compression_type | NO_COMPRESSION |
| log_rejected_record_num | 0 |
| lower_case_table_names | 0 |
| materialized_view_rewrite_mode | DEFAULT |
| max_allowed_packet | 33554432 |
| max_parallel_scan_instance_num | -1 |
| max_pipeline_dop | 64 |
| max_pushdown_conditions_per_column | -1 |
| max_scan_key_num | -1 |
| nested_mv_rewrite_max_level | 3 |
| net_buffer_length | 16384 |
| net_read_timeout | 60 |
| net_write_timeout | 60 |
| new_planner_agg_stage | 0 |
| new_planner_optimize_timeout | 3000 |
| parallel_exchange_instance_num | 1 |
| parallel_fragment_exec_instance_num | 1 |
| parse_tokens_limit | 3500000 |
| partial_update_mode | auto |
| performance_schema | false |
| pipeline_dop | 2 |
| pipeline_profile_level | 1 |
| pipeline_sink_dop | 0 |
| prefer_compute_node | false |
| query_cache_agg_cardinality_limit | 5000000 |
| query_cache_entry_max_bytes | 4194304 |
| query_cache_entry_max_rows | 409600 |
| query_cache_force_populate | false |
| query_cache_hot_partition_num | 3 |
| query_cache_size | 1048576 |
| query_cache_type | 0 |
| query_delivery_timeout | 300 |
| query_mem_limit | 0 |
| query_queue_concurrency_limit | 1000 |
| query_queue_cpu_used_permille_limit | 800 |
| query_queue_fresh_resource_usage_interval_ms | 5000 |
| query_queue_max_queued_queries | 1024 |
| query_queue_mem_used_pct_limit | 0.9 |
| query_queue_pending_timeout_second | 300 |
| query_timeout | 300 |
| range_pruner_max_predicate | 100 |
| resource_group | |
| runtime_filter_on_exchange_node | false |
| runtime_join_filter_push_down_limit | 1024000 |
| runtime_profile_report_interval | 10 |
| scan_use_query_mem_ratio | 0.3 |
| spill_encode_level | 7 |
| spill_mode | auto |
| sql_dialect | StarRocks |
| sql_mode | |
| sql_quote_show_create | true |
| sql_safe_updates | 0 |
| sql_select_limit | 9223372036854775807 |
| statistic_collect_parallel | 1 |
| storage_engine | olap |
| streaming_preaggregation_mode | auto |
| system_time_zone | Asia/Shanghai |
| time_zone | Asia/Shanghai |
| transaction_isolation | REPEATABLE-READ |
| transmission_compression_type | NO_COMPRESSION |
| transmission_encode_level | 7 |
| tx_isolation | REPEATABLE-READ |
| tx_visible_wait_timeout | 10 |
| use_compute_nodes | -1 |
| use_page_cache | true |
| version | 5.1.0 |
| version_comment | 3.1.2-4f3a2ee |
| wait_timeout | 28800 这是我所有的变量 然后设置了资源组 并发请求 cpu 。

#5

BE机器是多少核的？

#6

压测的时候，可以BE机器上执行perf top 截个图吗？

#7

24核 我们是跑在k8s上的 三个fe 和be

#8

所有的sql 都命中了物化视图， 30并发都把cpu打满了。 我给那个database创建了资源组， 我发现物化视图的计算创建了默认的资源组， 并且default_mv_wg资源组cpu长期百分之百(因为我们的数据量很大，需要做聚合计算)。 我怀疑资源组的隔离是不是导致了 我的sql查询改写失败了(但是explain sql 看是命中物化视图的)

#9
  1. default_mv_wg 是在后台维护 MV，占用的资源应该不多？
  2. 你们多少并发就可以用满CPU资源？如果 3～5个并发查询就用满CPU资源，说明查询很消耗 CPU，其实耗时变慢是符合预期的，这时候需要考虑加机器了。
#10

麻烦提供一下 profile 和 perf

#11

default_mv_wg 是默认的物化视图资源组， 我们的物化视图有大量计算，这个组的cpu是也是一直打满的。 我们的所有查询explain看都是命中物化视图的。 但是 在资源组的cpu打满的时候，集群的cpu利用率是50%左右。 我机器的配置是24C 72G。 我资源组的配置 cup_core_limit 是 24

#12

意思是 default_mv_wg 利用 50% 的 CPU 了？

#13

不是 是这个资源组的cpu打满了。 这个默认的资源组 不知道cpu_core_limit是多少

#14

从 profile 看是 scan 太耗时，建议增加 scan 的线程数。

京ICP备2022026421号-1