Replies: 3 comments 1 reply
-
Hi, we've just started using Mimir, and our volume is much smaller than yours, but our latency is higher than what's shown in the chart. Can you share your Mimir configuration? Here's my current configuration:
My current configuration may not be optimal, which is likely causing high system latency. Can you give me some advice? Thank you very much. |
Beta Was this translation helpful? Give feedback.
-
You can use version 2.10.5, the delay can be reduced to less than 100ms. After I upgraded to 2.13, the delay increased several times activity_tracker:
filepath: /data/metrics-activity.log
blocks_storage:
backend: s3
bucket_store:
# ignore_blocks_within: 0s
sync_interval: 3m0s
block_sync_concurrency: 60
tenant_sync_concurrency: 4
meta_sync_concurrency: 60
max_concurrent: 300
chunks_cache:
attributes_ttl: 24h
# max_get_range_requests: 6
backend: memcached
memcached:
addresses: dns+memcached.mimir.svc.cluster.local:11211
max_idle_connections: 500
connect_timeout: 8s
timeout: 3s
max_item_size: 10485760
index_cache:
backend: memcached
memcached:
addresses: dns+memcached.mimir.svc.cluster.local:11211
max_idle_connections: 500
connect_timeout: 8s
timeout: 3s
max_item_size: 10485760
metadata_cache:
backend: memcached
memcached:
addresses: dns+memcached.mimir.svc.cluster.local:11211
max_idle_connections: 500
connect_timeout: 8s
timeout: 3s
max_item_size: 10485760
sync_dir: /data/tsdb-sync
s3:
***
tsdb:
dir: /data/tsdb
flush_blocks_on_shutdown: false
# retention_period: 9h
wal_compression_enabled: true
wal_segment_size_bytes: 536870912
# head_compaction_interval: 20
compactor:
compaction_interval: 15m
compaction_concurrency: 4
max_compaction_time: 2h
data_dir: /data
deletion_delay: 1h
max_closing_blocks_concurrency: 4
max_opening_blocks_concurrency: 4
max_block_upload_validation_concurrency: 4
sharding_ring:
wait_stability_min_duration: 1m
distributor:
remote_timeout: 6s
max_recv_msg_size: 1073741824
reusable_ingester_push_workers: 4000
# direct_otlp_translation_enabled: true
retry_after_header:
enabled: true
base_seconds: 5
max_backoff_exponent: 20
ha_tracker:
enable_ha_tracker: true
kvstore:
store: inmemory
instance_limits:
max_inflight_push_requests: 1500
max_inflight_push_requests_bytes: 3145728000
max_ingestion_rate: 700000
frontend:
grpc_client_config:
grpc_compression: ""
max_recv_msg_size: 8589934592
max_send_msg_size: 8589934592
log_queries_longer_than: 10s
# scheduler_worker_concurrency: 30
parallelize_shardable_queries: true
cache_results: true
results_cache:
backend: memcached
memcached:
addresses: dns+memcached.mimir.svc.cluster.local:11211
max_idle_connections: 500
connect_timeout: 8s
timeout: 3s
max_item_size: 10485760
scheduler_address: mimir-query-scheduler-headless.mimir.svc:9095
frontend_worker:
# response_streaming_enabled: true
grpc_client_config:
grpc_compression: ""
max_recv_msg_size: 8589934592
max_send_msg_size: 8589934592
scheduler_address: mimir-query-scheduler-headless.mimir.svc:9095
ingester:
instance_limits:
max_inflight_push_requests: 3000
ring:
final_sleep: 0s
kvstore:
store: memberlist
min_ready_duration: 30s
num_tokens: 512
tokens_file_path: /data/tokens
ingester_client:
grpc_client_config:
grpc_compression: ""
max_recv_msg_size: 8589934592
max_send_msg_size: 8589934592
limits:
accept_ha_samples: true
compactor_block_upload_enabled: true
#compactor_blocks_retention_period: 15d
ha_cluster_label: cluster
ha_max_clusters: 1000
ha_replica_label: prometheus_replica
ingestion_burst_size: 4000000
ingestion_rate: 5000000
results_cache_ttl: 24h
compactor_split_and_merge_shards: 16
compactor_split_groups: 4
cache_unaligned_requests: false
# results_cache_ttl_for_out_of_order_time_window: 30m
label_values_max_cardinality_label_names_per_request: 300
# max_fetched_series_per_query: 250000
max_cache_freshness: 10m
max_global_series_per_user: 0
query_sharding_total_shards: 16
# max_label_names_per_series: 600
# max_metadata_length: 102400
max_query_parallelism: 30
#max_total_query_length: 15d
# out_of_order_time_window: 2h
memberlist:
abort_if_cluster_join_fails: false
compression_enabled: false
join_members:
- dns+mimir-gossip-ring.mimir.svc.cluster.local:7946
multitenancy_enabled: false
querier:
max_concurrent: 128
# query_store_after: 8h
# query_ingesters_within: 9h
query_scheduler:
max_outstanding_requests_per_tenant: 3200
runtime_config:
file: /var/mimir/runtime.yaml
server:
grpc_server_max_concurrent_streams: 4000
grpc_server_max_connection_age: 10m
grpc_server_max_connection_age_grace: 10m
grpc_server_max_connection_idle: 10m
grpc_server_keepalive_time: 2h
grpc_server_num_workers: 2000
log_format: json
log_level: info
store_gateway:
sharding_ring:
tokens_file_path: /data/tokens
wait_stability_min_duration: 1m
zone_awareness_enabled: false |
Beta Was this translation helpful? Give feedback.
-
In the Kubernetes (K8s) environment, the version of Mimir being used is 2.11.0. (Version 2.13 has higher latency.) Here's my current configuration:
The Ingester is using 80 pods here, with each pod utilizing approximately 2.5 CPU cores and 4 GB of memory. I feel that the Ingester is using a very high amount of resources. Could you provide information on the resource usage of your various components? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
All reactions