# ECE RAM to Storage Ratio

**URL:** <https://discuss.elastic.co/t/ece-ram-to-storage-ratio/101878>\
**Category:** Elastic Cloud Enterprise (ECE)\
**Created:** [September 26, 2017, 3:35pm UTC](https://discuss.elastic.co/t/ece-ram-to-storage-ratio/101878 "2017-09-26T15:35:14Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![Alex\_Piggott](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alex_piggott/32/11053_2.png) [@Alex\_Piggott](https://discuss.elastic.co/u/Alex_Piggott)\
**Post date:** [September 27, 2017, 1:55pm UTC](https://discuss.elastic.co/t/ece-ram-to-storage-ratio/101878/10 "2017-09-27T13:55:46Z")

</div>

@IanGabes

The 2 other "override" fields that have proven useful so far are:

```auto
  "resources": {
    "cpu": {
      "hard_limit": true
    }
  },

```

If you set `hard_limit` to `false` then the cluster gets the entire CPU of the host instead of a sub-set determined by its size. Obviously this is not without risk to the overall platform stability

```auto
  "overrides": {
   "resources": { // (needed for 1.1+)
       "cpu": {
         "factor": 1.3
       }
   }
  },

```

A safer way of boosting the CPU for a given cluster is by setting `factor` ... eg to double the CPU available change from `1.3` (the default) to `2.6`

(at the same level as `factor` is `processors`, an integer which determines how many processors Elasticsearch believes its container has, so will change the thread pool defaults etc - we haven't found any case where this makes a noticeable change over the hand-curated-vs-cluster-size defaults)

---

_[View the full topic](https://discuss.elastic.co/t/ece-ram-to-storage-ratio/101878)._