# Logstash : IdentityMapCodec has reached 100% capacity

**URL:** <https://discuss.elastic.co/t/logstash-identitymapcodec-has-reached-100-capacity/40210>\
**Category:** Discussions en français\
**Created:** [January 27, 2016, 9:44am UTC](https://discuss.elastic.co/t/logstash-identitymapcodec-has-reached-100-capacity/40210 "2016-01-27T09:44:54Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![C\_H](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/c_h/32/20796_2.png) [@C\_H](https://discuss.elastic.co/u/C_H)\
**Post date:** [January 27, 2016, 9:44am UTC](https://discuss.elastic.co/t/logstash-identitymapcodec-has-reached-100-capacity/40210/1 "2016-01-27T09:44:54Z")

</div>

Bonjour,

j'obtiens ce genre d'erreur quand logstash (v2.1.1 sur RHEL 6.4) parse un trop grand nombre de fichiers :

```
failed to open /apps/logstash/input/sibr/crs/1/parv07416142.crs.160111.csv: Permission denied - /apps/logstash/input/sibr/crs/1/parv07416142.crs.160111.csv {:level=>:warn}

```

Il est dit que c'est lié à un trop grand nombre de fichiers en entrée pour LS, dans mon cas, +60000.  
J'ai réduit par bloc de 10000 fichiers, mais j'ai toujours le même souci.

Quelle est la limite acceptable du nombre de fichiers à donner à LS pour ne pas avoir ce problème ?  
_--\> modification du ulimit_ (voir post 5)

Dorénavant, avec un trop grand nombre de fichiers, c'est cette erreur que j'obtiens :

> IdentityMapCodec has reached 100% capacity {:current\_size=\>20000, :upper\_limit=\>20000, :level=\>:error}

Comment l'évitez ?

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [January 27, 2016, 10:23am UTC](https://discuss.elastic.co/t/logstash-identitymapcodec-has-reached-100-capacity/40210/2 "2016-01-27T10:23:35Z")

</div>

Aucune idée pour ma part. @colinsurprenant ? Saurais-tu cela ?

---

<div class="post-metadata">

**Author:** ![colinsurprenant](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/colinsurprenant/32/14776_2.png) [@colinsurprenant](https://discuss.elastic.co/u/colinsurprenant)\
**Post date:** [January 27, 2016, 2:04pm UTC](https://discuss.elastic.co/t/logstash-identitymapcodec-has-reached-100-capacity/40210/3 "2016-01-27T14:04:22Z")

</div>

Pourriez vous partager la version de logstash que vous utilisez ainsi que votre configuration?

A priori ca semble relié à la limite du système d'exploitation sur le nombre maximum de fichiers ouverts. Nous avons justement découvert un problème avec le file input plugin lorsque le pattern de fichiers de l'option `:path` résulte dans la découverte de plus de fichiers que la limite permise par l'OS. Nous prévoyons sortir une nouvelle version du plugin d'ici peu (peut-être aujourd'hui) pour régler ce problème.

Si vous ne voulez que lire et traiter un ensemble de fichiers statiques de façon adhoc sans nécessairement surveiller les changements à ces fichiers (tailing) alors peut-être serait-il possible d'utiliser une autre stratégie temporairement avec le plugin stdin input et un script simple qui lit les fichier et les pipe dans logstash?

Colin

---

<div class="post-metadata">

**Author:** ![C\_H](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/c_h/32/20796_2.png) [@C\_H](https://discuss.elastic.co/u/C_H)\
**Post date:** [January 27, 2016, 2:19pm UTC](https://discuss.elastic.co/t/logstash-identitymapcodec-has-reached-100-capacity/40210/4 "2016-01-27T14:19:13Z")

</div>

J'utilise logstash en version 2.1.1 sur un RHEL 6.4

Au cas où vous me poseriez la question, le ulimit :

> logstash@srv\_test:/apps/logstash/logstash-2.1.1 # ulimit -a  
> core file size (blocks, -c) 0  
> data seg size (kbytes, -d) unlimited  
> scheduling priority (-e) 0  
> file size (blocks, -f) unlimited  
> pending signals (-i) 30511  
> max locked memory (kbytes, -l) 64  
> max memory size (kbytes, -m) unlimited  
> open files (-n) 1024  
> pipe size (512 bytes, -p) 8  
> POSIX message queues (bytes, -q) 819200  
> real-time priority (-r) 0  
> stack size (kbytes, -s) 10240  
> cpu time (seconds, -t) unlimited  
> max user processes (-u) 1024  
> virtual memory (kbytes, -v) unlimited  
> file locks (-x) unlimited

Le problème serait-ce lié à open files fixé à "seulement" 1024 ?

---

<div class="post-metadata">

**Author:** ![C\_H](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/c_h/32/20796_2.png) [@C\_H](https://discuss.elastic.co/u/C_H)\
**Post date:** [January 27, 2016, 2:39pm UTC](https://discuss.elastic.co/t/logstash-identitymapcodec-has-reached-100-capacity/40210/5 "2016-01-27T14:39:25Z")

</div>

Je m'auto-réponds : j'ai changé la valeur dans /etc/security/limits.conf pour le user logstash :

```
logstash soft nofile 102400
logstash hard nofile 102400

```

Maintenant, plus de problème pour logstash, cependant je reste sur mes lotissements à 10.000 fichiers / lot.

Edit : j'ai quand même tenté l'expérience avec tous mes fichiers et j'ai une autre erreur :

```
IdentityMapCodec has reached 100% capacity {:current_size=>20000, :upper_limit=>20000, :level=>:error}
LogStash::Codecs::IdentityMapCodec::IdentityMapUpperLimitException: LogStash::Codecs::IdentityMapCodec::IdentityMapUpperLimitException
               visit at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-codec-multiline-2.0.4/lib/logstash/codecs/identity_map_codec.rb:36
    check_map_limits at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-codec-multiline-2.0.4/lib/logstash/codecs/identity_map_codec.rb:245
  record_codec_usage at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-codec-multiline-2.0.4/lib/logstash/codecs/identity_map_codec.rb:231
        stream_codec at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-codec-multiline-2.0.4/lib/logstash/codecs/identity_map_codec.rb:222
              decode at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-codec-multiline-2.0.4/lib/logstash/codecs/identity_map_codec.rb:143
                 run at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-input-file-2.0.3/lib/logstash/inputs/file.rb:195
          _read_file at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/tail.rb:183
                each at org/jruby/RubyArray.java:1613
          _read_file at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/tail.rb:182
                loop at org/jruby/RubyKernel.java:1479
          _read_file at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/tail.rb:178
           subscribe at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/tail.rb:84
                each at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/watch.rb:92
                each at org/jruby/RubyArray.java:1613
                each at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/watch.rb:89
                call at org/jruby/RubyProc.java:281
        synchronized at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/watch.rb:201
         synchronize at org/jruby/ext/thread/Mutex.java:149
        synchronized at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/watch.rb:201
                each at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/watch.rb:87
           subscribe at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/watch.rb:145
           subscribe at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/tail.rb:75
                 run at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-input-file-2.0.3/lib/logstash/inputs/file.rb:193
         inputworker at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-core-2.1.1-java/lib/logstash/pipeline.rb:206
         start_input at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-core-2.1.1-java/lib/logstash/pipeline.rb:199
Pipeline shutdown complete. {:level=>:info}
Logstash shutdown completed

```

Une idée ?

---

<div class="post-metadata">

**Author:** ![colinsurprenant](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/colinsurprenant/32/14776_2.png) [@colinsurprenant](https://discuss.elastic.co/u/colinsurprenant)\
**Post date:** [January 28, 2016, 5:09am UTC](https://discuss.elastic.co/t/logstash-identitymapcodec-has-reached-100-capacity/40210/6 "2016-01-28T05:09:17Z")

</div>

Oui, il y a en effet une limite de 20k "stream identities" dans le codec multiline. la logique actuelle fait une nettoyage périodique des identités non utilisées. mais dans votre cas, clairement le nombre de fichiers lus est trop rapide.

Il faut comprendre que le file input (avec le multiline codec) à été pensé et conçu, à l'origine, pour un modèle de suivi en continu de fichiers (tailing). Présentement ce combo ne fonctionne pas très bien dans une situation de traitement d'une très grande quantité simultanés de fichiers statiques.

Notez que nous venons de compléter un "refactor" de cette logique pour pouvoir mieux supporter ce type d'utilisation. Nous en sommes aux dernières étapes de validation avant de mettre en ligne une nouvelle version.

J'ai aussi ouvert un issue pour s'assurer de capturer votre problème en particulier, voir [https://github.com/logstash-plugins/logstash-codec-multiline/issues/25](https://github.com/logstash-plugins/logstash-codec-multiline/issues/25)

Colin

---

<div class="post-metadata">

**Author:** ![C\_H](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/c_h/32/20796_2.png) [@C\_H](https://discuss.elastic.co/u/C_H)\
**Post date:** [January 28, 2016, 7:49am UTC](https://discuss.elastic.co/t/logstash-identitymapcodec-has-reached-100-capacity/40210/7 "2016-01-28T07:49:36Z")

</div>

Bonjour @colinsurprenant

merci pour votre retour.

De mon côté je vais mettre en standby ce use-case, et je vais me concentrer sur une utilisation plus appropriée d'ELK pour faire du suivi en temps réel de log applicative 🙂

Charles-Henri

---

<div class="post-metadata">

**Author:** ![colinsurprenant](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/colinsurprenant/32/14776_2.png) [@colinsurprenant](https://discuss.elastic.co/u/colinsurprenant)\
**Post date:** [January 28, 2016, 12:56pm UTC](https://discuss.elastic.co/t/logstash-identitymapcodec-has-reached-100-capacity/40210/8 "2016-01-28T12:56:48Z")

</div>

@C_H comme je disais dans mon premier message, dans l'interim peut-etre serait-il possible de tout simplement utiliser le stdin input avec quelque chose du genre:

```auto
for f in somefile.*; do cat $f; done | bin/logstash ...

```

Colin

---

<div class="post-metadata">

**Author:** ![C\_H](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/c_h/32/20796_2.png) [@C\_H](https://discuss.elastic.co/u/C_H)\
**Post date:** [January 29, 2016, 7:22am UTC](https://discuss.elastic.co/t/logstash-identitymapcodec-has-reached-100-capacity/40210/9 "2016-01-29T07:22:07Z")

</div>

Bonjour Colin,

oui c'est une façon de voir aussi les choses, plutôt que de partir sur de gros lotissements.  
Malheureusement ou pas, mon use-case est aussi un cas pilote pour "Splunk", et comme c'est le produit que la maison a retenu, je mettrais mes efforts dessus en temps voulu.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 1:49pm UTC](https://discuss.elastic.co/t/logstash-identitymapcodec-has-reached-100-capacity/40210/10 "2017-07-06T13:49:45Z")

</div>