# High delay (8m) on Matching ClientGetTaskQueueUserData in local cluster

**URL:** <https://community.temporal.io/t/high-delay-8m-on-matching-clientgettaskqueueuserdata-in-local-cluster/19258>\
**Category:** Server Deployment\
**Created:** [February 9, 2026, 2:02pm UTC](https://community.temporal.io/t/high-delay-8m-on-matching-clientgettaskqueueuserdata-in-local-cluster/19258 "2026-02-09T14:02:21Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![AndExpo](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/andexpo/32/6740_2.png) [@AndExpo](https://community.temporal.io/u/AndExpo)\
**Post date:** [February 9, 2026, 2:02pm UTC](https://community.temporal.io/t/high-delay-8m-on-matching-clientgettaskqueueuserdata-in-local-cluster/19258/1 "2026-02-09T14:02:21Z")

</div>

Hi everyone,

I’m running a Temporal cluster locally on my PC using K3s, and I’m experiencing a very high delay (~8 minutes) on:

```auto
Matching ClientGetTaskQueueUserData

```

as shown in my Grafana dashboard (screenshot attached).

I’m using the Helm chart version **1.0.0-rc**.

I would really appreciate any guidance on what I might be misconfiguring.

* * *

## Environment

- Local machine

- K3s single node

- 16 CPUs

- 15 GiB RAM available

- PostgreSQL 12

- Helm-based deployment (chart 1.0.0-rc)

* * *

## Temporal Configuration

### Persistence

```auto
config:
  persistence:
    numHistoryShards: 1024
    datastores:
      default:
        sql:
          pluginName: postgres12
          driverName: postgres12
          connectProtocol: tcp
          databaseName: temporal

      visibility:
        sql:
          pluginName: postgres12
          driverName: postgres12
          connectProtocol: tcp
          databaseName: temporal_visibility

  namespaces:
    create: true
    namespace:
      - name: default
        retention: 1d

```

* * *

### Dynamic Config

```auto
dynamicConfig:
  frontend.WorkerHeartbeatsEnabled:
    - value: true
      constraints: {}

```

* * *

### Services

```auto
frontend:
  replicaCount: 3
  resources:
    requests:
      cpu: 200m
      memory: 256Mi
    limits:
      cpu: 1000m
      memory: 512Mi

history:
  replicaCount: 8
  resources:
    requests:
      cpu: 800m
      memory: 512Mi
    limits:
      cpu: 2000m
      memory: 1Gi

matching:
  replicaCount: 4
  resources:
    requests:
      cpu: 500m
      memory: 600Mi
    limits:
      cpu: 1000m
      memory: 1Gi

worker:
  replicaCount: 1
  resources:
    requests:
      cpu: 200m
      memory: 256Mi
    limits:
      cpu: 1000m
      memory: 512Mi

```

* * *

## PostgreSQL Configuration

Postgres runs in the same cluster with:

```auto
resources:
  limits:
    cpu: 4000m
    memory: 4Gi
  requests:
    cpu: 1000m
    memory: 2Gi

```

Extended configuration:

```auto
max_connections = 500
max_prepared_transactions = 100

shared_buffers = 1536MB
effective_cache_size = 3584MB
work_mem = 32MB
maintenance_work_mem = 768MB

max_locks_per_transaction = 512
max_pred_locks_per_transaction = 512
deadlock_timeout = 5s

wal_buffers = 32MB
min_wal_size = 2GB
max_wal_size = 8GB
wal_compression = on
wal_writer_delay = 200ms
checkpoint_completion_target = 0.9
checkpoint_timeout = 15min

default_statistics_target = 200
random_page_cost = 1.1
effective_io_concurrency = 200

autovacuum = on
autovacuum_max_workers = 4
autovacuum_naptime = 30s
autovacuum_vacuum_scale_factor = 0.1
autovacuum_analyze_scale_factor = 0.05

```

* * *

## Observed Issue

From Grafana:

- `Matching ClientGetTaskQueueUserData` latency ≈ 8 minutes

---

<div class="post-metadata">

**Author:** ![tihomir](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/tihomir/32/6580_2.png) [@tihomir](https://community.temporal.io/u/tihomir)\
**Post date:** [February 10, 2026, 12:41am UTC](https://community.temporal.io/t/high-delay-8m-on-matching-clientgettaskqueueuserdata-in-local-cluster/19258/2 "2026-02-10T00:41:06Z")

</div>

GetTaskQueueUserData is used for propagating task queue user data.  
it is a long poll operation, so its ok for it to take longer. typically tho its around 5min, seeing it as 8 is somewhat elevated. can you share query you use in graph?

---

<div class="post-metadata">

**Author:** ![AndExpo](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/andexpo/32/6740_2.png) [@AndExpo](https://community.temporal.io/u/AndExpo)\
**Post date:** [February 10, 2026, 8:47am UTC](https://community.temporal.io/t/high-delay-8m-on-matching-clientgettaskqueueuserdata-in-local-cluster/19258/3 "2026-02-10T08:47:08Z")

</div>

Thanks for the clarification.

I’m using the following Prometheus query in the graph:

```auto
histogram_quantile(
  0.95,
  sum(
    rate(client_latency_bucket{type="frontend", service_role="matching"}[5m])
  ) by (operation, le)
)

```

In particular, I’m looking at the `operation="GetTaskQueueUserData"` label and checking the p95.