# What is the good ratio of the storage processes and the log processes, and the associated metrics for monitoring?

**URL:** https://forums.foundationdb.org/t/what-is-the-good-ratio-of-the-storage-processes-and-the-log-processes-and-the-associated-metrics-for-monitoring/1418
**Category:** Using FoundationDB
**Tags:** performance
**Created:** [June 3, 2019, 2:57pm UTC](https://forums.foundationdb.org/t/what-is-the-good-ratio-of-the-storage-processes-and-the-log-processes-and-the-associated-metrics-for-monitoring/1418 "2019-06-03T14:57:46Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![jltz](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jltz](https://forums.foundationdb.org/u/jltz)
#### Post date: [June 3, 2019, 2:57pm UTC](https://forums.foundationdb.org/t/what-is-the-good-ratio-of-the-storage-processes-and-the-log-processes-and-the-associated-metrics-for-monitoring/1418/1 "2019-06-03T14:57:46Z")

</div>

In the FDB architecture document, [https://apple.github.io/foundationdb/configuration.html#guidelines-process-class-config](https://apple.github.io/foundationdb/configuration.html#guidelines-process-class-config), it is stated that “…The recommended minimum number of `class=transaction` (log server) processes is 8 (active) + 2 (standby)…”.

I am now running a cluster with 60 Kubernetes Storage pods (in a single DC) with each pod having 3 storage processes. I would like to know how I should scale the number of the log processes correspondingly. Certainly different write workload would require different number of the log processes. So the related question is, what are the performance metrics that I can found in the status.json that allow me to determine whether the log processes get saturated or not.

---

<div class="post-metadata">

### Author: ![alexmiller](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alexmiller/32/326_2.png) [@alexmiller](https://forums.foundationdb.org/u/alexmiller)
#### Post date: [June 3, 2019, 8:22pm UTC](https://forums.foundationdb.org/t/what-is-the-good-ratio-of-the-storage-processes-and-the-log-processes-and-the-associated-metrics-for-monitoring/1418/2 "2019-06-03T20:22:57Z")

</div>

… man, we really need to go clean up and rewrite most of the docs surrounding recommended configuration and performance numbers.

It really depends on your storage characteristics. For running on physical SSDs, which isn’t the network attached storage that Kubernetes deployments sometimes have, we’ve typically seen something around 1:8 for `ssd` and 1:2 for `memory` being near optimal. Running a write benchmark and seeing if it improves if you add more logs is the easy and accurate way to find your optimal ratio.

---

<div class="post-metadata">

### Author: ![jltz](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jltz](https://forums.foundationdb.org/u/jltz)
#### Post date: [June 5, 2019, 8:35am UTC](https://forums.foundationdb.org/t/what-is-the-good-ratio-of-the-storage-processes-and-the-log-processes-and-the-associated-metrics-for-monitoring/1418/3 "2019-06-05T08:35:24Z")

</div>

A related question: What about the number of the proxies? The FDB architecture document only states the minimum number for class=stateless processes is 4 proxies. Should that the number of the proxies be increased with the number of the storage pods as well, or the number can be fixed?

---

<div class="post-metadata">

### Author: ![alexmiller](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alexmiller/32/326_2.png) [@alexmiller](https://forums.foundationdb.org/u/alexmiller)
#### Post date: [June 5, 2019, 5:51pm UTC](https://forums.foundationdb.org/t/what-is-the-good-ratio-of-the-storage-processes-and-the-log-processes-and-the-associated-metrics-for-monitoring/1418/4 "2019-06-05T17:51:17Z")

</div>

My personal benchmarking has generally found keeping number of proxies and number of logs roughly the same is optimal. I found diminishing returns for each additional proxy added above the number of logs. Depending on your particular workload, this could change, but it’s probably a decent starting place.
