# Problem with loading dashboards - Data too large **URL:** \ **Category:** Kibana\ **Tags:** dashboard\ **Created:** [January 5, 2024, 8:00am UTC](https://discuss.elastic.co/t/problem-with-loading-dashboards-data-too-large/350437 "2024-01-05T08:00:32Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![PustyB](https://avatars.discourse-cdn.com/v4/letter/p/c67d28/32.png) [@PustyB](https://discuss.elastic.co/u/PustyB)\ **Post date:** [January 5, 2024, 8:00am UTC](https://discuss.elastic.co/t/problem-with-loading-dashboards-data-too-large/350437/1 "2024-01-05T08:00:32Z")
I've been having a problem lately with my elastica stack that was installed on kubernetes. Well, when trying to visualize myself data in kiban when I select a longer period of time (more data) it pops up this error: ```auto Request error: circuit_breaking_exception, [parent] Data too large, data for [indices:data/write/update[s]] would be [31381782974/29.2gb], which is larger than the limit of [30601641984/28.5gb], real usage: [31381782528/29.2gb], new bytes reserved: [446/446b], usages [inflight_requests=19944/19.4kb, request=2307688833/2.1gb, fielddata=186790714/178.1mb, eql_sequence=0/0b, model_inference=0/0b] ``` What is the best way to eliminate these errors? 1. add more ram? I currently have 3 nodes with 64GB RAM each (30GB on JVM) 2. add more nodes? 3. reduce the amount of data displayed on the dashboard? Or maybe something else? ---
**Author:** ![carly.richmond](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/carly.richmond/32/104935_2.png) [@carly.richmond](https://discuss.elastic.co/u/carly.richmond)\ **Post date:** [January 5, 2024, 11:55am UTC](https://discuss.elastic.co/t/problem-with-loading-dashboards-data-too-large/350437/2 "2024-01-05T11:55:55Z")
Hi @PustyB, Welcome back! Are you able to limit the amount of data displayed on your dashboard? ---
**Author:** ![PustyB](https://avatars.discourse-cdn.com/v4/letter/p/c67d28/32.png) [@PustyB](https://discuss.elastic.co/u/PustyB)\ **Post date:** [January 5, 2024, 12:20pm UTC](https://discuss.elastic.co/t/problem-with-loading-dashboards-data-too-large/350437/3 "2024-01-05T12:20:35Z")
I can, however, want to have a summary of, for example, the last two years to compare myself. On this dashboard I have several views. The indexes from which it takes data are saved daily as logs to a separate index. i.e. for example: logs\_2024\_01\_04, logs\_2024\_01\_05 The indexes are about 80-100mb each However, I should aggregate these logs every month or every year? Can this help in loading the data? ---
**Author:** ![Sunile\_Manjee](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sunile_manjee/32/111461_2.png) [@Sunile\_Manjee](https://discuss.elastic.co/u/Sunile_Manjee)\ **Post date:** [January 7, 2024, 4:52am UTC](https://discuss.elastic.co/t/problem-with-loading-dashboards-data-too-large/350437/4 "2024-01-07T04:52:38Z")
> [@PustyB](#): > > ```auto > Request error: circuit_breaking_exception, [parent] Data too large, data for [indices:data/write/update[s]] would be [31381782974/29.2gb], which is larger than the limit of [30601641984/28.5gb], real usage: [31381782528/29.2gb], new bytes reserved: [446/446b], usages [inflight_requests=19944/19.4kb, request=2307688833/2.1gb, fielddata=186790714/178.1mb, eql_sequence=0/0b, model_inference=0/0b] > > ``` without knowing the specifics of your use case, I would start by - Increasing the memory allocation for the es pods - Reducing the size of the request or breaking it into smaller parts \* Use transform to pre aggregate, you still need memory - Optimizing the data structure or query to use less memory ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [February 4, 2024, 4:52am UTC](https://discuss.elastic.co/t/problem-with-loading-dashboards-data-too-large/350437/5 "2024-02-04T04:52:57Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.