# Max\_docs\_per\_index exceeded

**URL:** <https://community.graylog.org/t/max-docs-per-index-exceeded/26421>\
**Category:** Graylog Central (peer support)\
**Created:** [November 5, 2022, 5:34pm UTC](https://community.graylog.org/t/max-docs-per-index-exceeded/26421 "2022-11-05T17:34:30Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Dimitri](https://avatars.discourse-cdn.com/v4/letter/d/dc4da7/32.png) [@Dimitri](https://community.graylog.org/u/Dimitri)\
**Post date:** [November 5, 2022, 5:34pm UTC](https://community.graylog.org/t/max-docs-per-index-exceeded/26421/1 "2022-11-05T17:34:30Z")

</div>

Hi, all.  
During this week I noticed that my Elasticsearch server is running out of disk space. It’s configured to store 240 indices with up to 20 mln docs in each one. Having checked the size of indices on disk, I quickly noticed that one of them is significantly larger than all others. It contains 517,161,309 documents and keeps growing. It’s not active, but its size in GB keeps changing up and down between 160GB to 240GB. What do you think could be the cause and what can I do besides decreasing the maximum number of indices and waiting for it to stop growing?

Graylog 4.2.13 and ElasticSearch 7.10.1 running on Debian.

Thanks.

 ![Screenshot 2022-11-05 at 17-31-44 Graylog - Index Set - Default index set](https://us1.discourse-cdn.com/flex016/uploads/graylog/original/2X/e/e8fbc883c37c2edcc275d0d807abea4b8c1e5240.png)

---

<div class="post-metadata">

**Author:** ![gsmith](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/gsmith/32/1222_2.png) [@gsmith](https://community.graylog.org/u/gsmith)\
**Post date:** [November 8, 2022, 2:29am UTC](https://community.graylog.org/t/max-docs-per-index-exceeded/26421/2 "2022-11-08T02:29:32Z")

</div>

Hello @Dimitri

It might be creating new fields from the logs, more fields created could increase the amount of volume used.

EDIT: @Dimitri can I ask why you use message count then a Day count for a Rotation period? Documents can vary in size same as amount per day but having a Rotation period per day give a better understand on how many Indices Graylog server can handle.

Example here is my lab. **Red** boxes show the details I’m referring to. So if I’m limited on HDD space I can either shrink the amount of shards or indices to fit my needs

 ![image](https://us1.discourse-cdn.com/flex016/uploads/graylog/original/2X/5/5fc536e39c03170289e446af6057922e988af9c8.png)

This shows the amount of space used.

```auto
[root@graylog streams]# df -hT
Filesystem Type Size Used Avail Use% Mounted on
devtmpfs devtmpfs 5.7G 0 5.7G 0% /dev
tmpfs tmpfs 5.7G 7.1M 5.7G 1% /dev/shm
tmpfs tmpfs 5.7G 587M 5.1G 11% /run
tmpfs tmpfs 5.7G 0 5.7G 0% /sys/fs/cgroup
/dev/mapper/centos-root xfs 484G 373G 112G 78% /
/dev/sda1 xfs 194M 139M 56M 72% /boot
tmpfs tmpfs 1.2G 0 1.2G 0% /run/user/1000
[root@graylog streams]#

```

---

<div class="post-metadata">

**Author:** ![Dimitri](https://avatars.discourse-cdn.com/v4/letter/d/dc4da7/32.png) [@Dimitri](https://community.graylog.org/u/Dimitri)\
**Post date:** [November 8, 2022, 4:30pm UTC](https://community.graylog.org/t/max-docs-per-index-exceeded/26421/3 "2022-11-08T16:30:35Z")

</div>

Thanks for the response. My idea was that by limiting the number of stored documents I could get also more or less stable disk space consumption, given that the average size of documents is approximately the same.

I understand that new fields, new types of documents and even changing share of a certain type of documents may lead to problems with disk space, but that’s not the case. It’s not the physical size of that index that has grown (but it has, too, of course), but the number of documents in one specific index. So, the problem is that ES breaks the limits set in the configuration file (unless I’m exceptionally stupid, which may also be true, from my experience).

---

<div class="post-metadata">

**Author:** ![gsmith](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/gsmith/32/1222_2.png) [@gsmith](https://community.graylog.org/u/gsmith)\
**Post date:** [November 9, 2022, 6:02am UTC](https://community.graylog.org/t/max-docs-per-index-exceeded/26421/4 "2022-11-09T06:02:30Z")

</div>

Hey,

> [@Dimitri](#):
>
> It’s not the physical size of that index that has grown (but it has, too, of course), but the number of documents in one specific index

Ok I understand now, I call that “Graylog’s Dark Magic”.

I see that index graylog\_588 is 164 GB and the rest are 6-7 GB. I’m not sure, the only thing I can think of is that index with 164 GB received large doc’s during that time or Elasticsearch forgot to count correctly. Hence why I try to stay clear of counting documents and go by Date/time. Maybe someone here can shade some light on what’s going on with that.

By all means that is kind of strange, first time I’ve heard of something like that.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex016/uploads/graylog/original/3X/c/7/c7c09c6b5099570133d6502b83f50ba4430de5b6.png) [@system](https://community.graylog.org/u/system)\
**Post date:** [November 23, 2022, 6:03am UTC](https://community.graylog.org/t/max-docs-per-index-exceeded/26421/5 "2022-11-23T06:03:01Z")

</div>

Closed on November 23, 2022, 6:03am UTC

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

---

<div class="post-metadata">

**Author:** ![joe.gross](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/joe.gross/32/13372_2.png) [@joe.gross](https://community.graylog.org/u/joe.gross)\
**Post date:** [April 19, 2023, 5:18pm UTC](https://community.graylog.org/t/max-docs-per-index-exceeded/26421/6 "2023-04-19T17:18:50Z")

</div>

Hard to say why it happened. Any chance someone changed the settings on the index rotation and they were changed back after?

@gsmith is right, unless it somehow lost count, the only explanation is a batch of very large messages. Try using size or time as your rotation strategy and see if it happens again.
