# History instance CPU cannot scale up

**URL:** <https://community.temporal.io/t/history-instance-cpu-cannot-scale-up/5041>\
**Category:** Community Support\
**Tags:** metrics\
**Created:** [June 23, 2022, 2:32am UTC](https://community.temporal.io/t/history-instance-cpu-cannot-scale-up/5041 "2022-06-23T02:32:42Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![ridwan.santoso](https://avatars.discourse-cdn.com/v4/letter/r/3ec8ea/32.png) [@ridwan.santoso](https://community.temporal.io/u/ridwan.santoso)\
**Post date:** [June 23, 2022, 2:32am UTC](https://community.temporal.io/t/history-instance-cpu-cannot-scale-up/5041/1 "2022-06-23T02:32:42Z")

</div>

Hi All,

Got a scale up issue here with history instance, using the 2 history instances (while FE, matching, worker are all 1 instance) the CPU utilization is around 3 CPU each (total around 6 CPU), but when increase to 3 history instance the total CPU utilization is still around 6 CPU (so around 2 CPU for each history instance). The temporal instances are running in docker on VM so there should not be limit to CPU (can max out to host VM which is still plenty).

What are the possible cause the total History CPU cannot be scale up? Tried to increase history shard from 4096 to 8192 does not have much effect. Also increase the partition from 8 to 16 even makes the performance worse. Also tried to increase workflow workers and pollers also not really help. The DB is cassandra and don’t suspect the bottleneck is in cassandra.

Any thoughts?

Thanks  
-ridwan-

---

<div class="post-metadata">

**Author:** ![ridwan.santoso](https://avatars.discourse-cdn.com/v4/letter/r/3ec8ea/32.png) [@ridwan.santoso](https://community.temporal.io/u/ridwan.santoso)\
**Post date:** [June 23, 2022, 2:46am UTC](https://community.temporal.io/t/history-instance-cpu-cannot-scale-up/5041/2 "2022-06-23T02:46:47Z")

</div>

adding monitoring metric here

 ![temporal1](https://us1.discourse-cdn.com/flex016/uploads/temporal/original/2X/8/83d131d8c4dec76307770d9824d7eb335ecb7174.jpeg)  
 ![temporal2](https://us1.discourse-cdn.com/flex016/uploads/temporal/original/2X/d/dd7fa79040e8f9a26e66eee377d8b24c8768c202.jpeg)

---

<div class="post-metadata">

**Author:** ![ridwan.santoso](https://avatars.discourse-cdn.com/v4/letter/r/3ec8ea/32.png) [@ridwan.santoso](https://community.temporal.io/u/ridwan.santoso)\
**Post date:** [June 23, 2022, 3:17am UTC](https://community.temporal.io/t/history-instance-cpu-cannot-scale-up/5041/3 "2022-06-23T03:17:42Z")

</div>

there are delays in activity started and child flow execution completed:

 ![activity delay 1](https://us1.discourse-cdn.com/flex016/uploads/temporal/original/2X/d/d03f97b59f2228617d3cd9f938165c521b92e7f7.jpeg)  
 ![activity delay 2 - in child](https://us1.discourse-cdn.com/flex016/uploads/temporal/original/2X/6/60585987f3a8b27638e57f3ad096a4fc4ce43813.jpeg)

---

<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:** [June 23, 2022, 2:52pm UTC](https://community.temporal.io/t/history-instance-cpu-cannot-scale-up/5041/4 "2022-06-23T14:52:06Z")

</div>

Your sync match rate should ideally be over 99%, the dip shown is concerning. This typically indicates you need more workers (increase capacity), see worker tuning guide [here](https://docs.temporal.io/operation/how-to-tune-workers/).

On the SDK metrics side did you have a chance to look at workflow\_task\_schedule\_to\_start\_latency and activity\_schedule\_to\_start\_latency metrics during this time?

Also on persistence latencies can you focus on operations `CreateWorkflowExecution`, `UpdateWorkflowExecution` and `UpdateShard`, little hard to see from picture