# Performance impact from large fields.yml? **URL:** \ **Category:** Beats\ **Tags:** metricbeat\ **Created:** [March 16, 2020, 6:50pm UTC](https://discuss.elastic.co/t/performance-impact-from-large-fields-yml/223811 "2020-03-16T18:50:25Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![JD\_Kemsley](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jd_kemsley/32/64112_2.png) [@JD\_Kemsley](https://discuss.elastic.co/u/JD_Kemsley)\ **Post date:** [March 16, 2020, 6:50pm UTC](https://discuss.elastic.co/t/performance-impact-from-large-fields-yml/223811/1 "2020-03-16T18:50:25Z")
After a vanilla install of metricbeat on an EC2 instance, I enabled the system module in `metricbeat.yml`. I did not modify `fields.yml`, and after turning on metricbeat, I now see a huge number of fields in my index pattern: ![Screen Shot 2020-03-16 at 1.40.21 PM](https://us1.discourse-cdn.com/elastic/original/3X/2/6/261585300cee7d1459cd06ff4295a1a5a4caa06b.png) I understand that I can modify `fields.yml` to change what fields metricbeat tells elasticsearch about the index. There are a few questions that remain unanswered in the docs however: 1. What are the performance implications of having so many fields defined this way? There is no data for most of these fields in any of the matching indices. 2. Is there an easy way to manage `fields.yml` to only send info on fields that are used in currently enabled modules? I can technically edit `fields.yml` but editing a 10,000-line file is pretty onerous. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [April 13, 2020, 6:57pm UTC](https://discuss.elastic.co/t/performance-impact-from-large-fields-yml/223811/2 "2020-04-13T18:57:31Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.