# Error: Request Timeout after 30000ms - número excesivo de fragmentos

**URL:** <https://discuss.elastic.co/t/error-request-timeout-after-30000ms-numero-excesivo-de-fragmentos/118676>\
**Category:** Elastic en Español\
**Created:** [February 6, 2018, 3:43pm UTC](https://discuss.elastic.co/t/error-request-timeout-after-30000ms-numero-excesivo-de-fragmentos/118676 "2018-02-06T15:43:03Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Josmell\_Chavarri](https://avatars.discourse-cdn.com/v4/letter/j/977dab/32.png) [@Josmell\_Chavarri](https://discuss.elastic.co/u/Josmell_Chavarri)\
**Post date:** [February 6, 2018, 3:43pm UTC](https://discuss.elastic.co/t/error-request-timeout-after-30000ms-numero-excesivo-de-fragmentos/118676/1 "2018-02-06T15:43:03Z")

</div>

Hola

Estoy utilizando una implementación de la herramienta Wazuh 2.0 [https://documentation.wazuh.com/2.0/getting-started/index.html](https://documentation.wazuh.com/2.0/getting-started/index.html), en una instalación agente-Servidor tengo instalado 31 agentes y mi servidor cuenta con una instalación de ELK para el manejo de los registros que envíen los agentes.

Desde hace unas semanas estoy teniendo el siguiente error en el kibana:

Error: Request Timeout after 30000ms  
ErrorAbstract@[http://xxxxxxxx:5601/bundles/kibana.bundle.js?v=14849:12:24939](http://xxxxxxxx:5601/bundles/kibana.bundle.js?v=14849:12:24939)  
StatusCodeError@[http://xxxxxxxx5601/bundles/kibana.bundle.js?v=14849:12:28395](http://xxxxxxxx5601/bundles/kibana.bundle.js?v=14849:12:28395)  
Transport.prototype.request/requestTimeoutId\<@[http://xxxxxxxxx:5601/bundles/kibana.bundle.js?v=14849:13:4431](http://xxxxxxxxx:5601/bundles/kibana.bundle.js?v=14849:13:4431)  
Transport.prototype.\_timeout/id\<@[http://xxxxxxxxx:5601/bundles/kibana.bundle.js?v=14849:13:4852](http://xxxxxxxxx:5601/bundles/kibana.bundle.js?v=14849:13:4852)

Y también este error :

Error: in cell #1: [illegal\_argument\_exception] Trying to query 1401 shards, which is over the limit of 1000. This limit exists because querying many shards at the same time can make the job of the coordinating node very CPU and/or memory intensive. It is usually a better idea to have a smaller number of larger shards. Update [action.search.shard\_count.limit] to a greater value if you really want to query that many shards at the same time.  
at throwWithCell (/usr/share/kibana/src/core\_plugins/timelion/server/handlers/chain\_runner.js:30:11)  
at /usr/share/kibana/src/core\_plugins/timelion/server/handlers/chain\_runner.js:160:13  
at arrayEach (/usr/share/kibana/node\_modules/lodash/index.js:1289:13)  
at Function. (/usr/share/kibana/node\_modules/lodash/index.js:3345:13)  
at /usr/share/kibana/src/core\_plugins/timelion/server/handlers/chain\_runner.js:152:9  
at bound (domain.js:280:14)  
at runBound (domain.js:293:12)  
at tryCatcher (/usr/share/kibana/node\_modules/bluebird/js/main/util.js:26:23)  
at Promise.\_settlePromiseFromHandler (/usr/share/kibana/node\_modules/bluebird/js/main/promise.js:503:31)  
at Promise.\_settlePromiseAt (/usr/share/kibana/node\_modules/bluebird/js/main/promise.js:577:18)  
at Promise.\_settlePromises (/usr/share/kibana/node\_modules/bluebird/js/main/promise.js:693:14)  
at Async.\_drainQueue (/usr/share/kibana/node\_modules/bluebird/js/main/async.js:123:16)  
at Async.\_drainQueues (/usr/share/kibana/node\_modules/bluebird/js/main/async.js:133:10)  
at Immediate.Async.drainQueues (/usr/share/kibana/node\_modules/bluebird/js/main/async.js:15:14)  
at runCallback (timers.js:666:20)  
at tryOnImmediate (timers.js:639:5)

\*\*\*\*\*\*\*\*\*Algunos datos del servidor:

[root@xxxxxxx ~]# df -h  
S.ficheros Tamaño Usados Disp Uso% Montado en  
/dev/mapper/cl-root 97G 40G 58G 42% /  
devtmpfs 3,9G 0 3,9G 0% /dev  
tmpfs 3,9G 0 3,9G 0% /dev/shm  
tmpfs 3,9G 17M 3,8G 1% /run  
tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup  
/dev/sda1 1014M 230M 785M 23% /boot  
tmpfs 782M 0 782M 0% /run/user/0

[root@xxxxxxxx ~]# free  
total used free shared buff/cache available  
Mem: 8002828 2283280 132632 16928 5586916 5312056  
Swap: 2097148 0 2097148

\*\*\*\*\*\*\*\*\*\*\*\*Versiones utilizadas

CentOS 7  
Elasticsearch 5.5.0  
Logstash 5.5.0  
Kibana 5.5.0

\*\*\*\*\*\*Elasticsearch:

GET Health Status ---------------------------

[root@xxxxxxx ~]# curl 'localhost:9200/\_cat/health?v'  
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending\_tasks max\_task\_wait\_time active\_shards\_percent  
1517923628 07:27:08 wazuh yellow 1 1 1411 1411 0 0 10 0 - 99.3%

# GET Nodes -----------------------------------

[root@xxxxxxx ~]# curl 'localhost:9200/\_cat/nodes?v'  
ip heap.percent ram.percent cpu load\_1m load\_5m load\_15m node.role master name  
127.0.0.1 94 98 23 0.55 0.85 0.92 mdi \* node-1

# GET cluster health --------------------------

[root@xxxxxxx~]# curl -XGET '[http://localhost:9200/\_cluster/health?pretty=true](http://localhost:9200/_cluster/health?pretty=true)'  
{  
"cluster\_name" : "wazuh",  
"status" : "yellow",  
"timed\_out" : false,  
"number\_of\_nodes" : 1,  
"number\_of\_data\_nodes" : 1,  
"active\_primary\_shards" : 1411,  
"active\_shards" : 1411,  
"relocating\_shards" : 0,  
"initializing\_shards" : 0,  
"unassigned\_shards" : 10,  
"delayed\_unassigned\_shards" : 0,  
"number\_of\_pending\_tasks" : 0,  
"number\_of\_in\_flight\_fetch" : 0,  
"task\_max\_waiting\_in\_queue\_millis" : 0,  
"active\_shards\_percent\_as\_number" : 99.29627023223082

# GET cluster health indices --------------------------

[root@xxxxxx ~]# curl -XGET '[http://localhost:9200/\_cluster/health?level=indices?pretty=true](http://localhost:9200/_cluster/health?level=indices?pretty=true)'

{  
"cluster\_name":"wazuh",  
"status":"yellow",  
"timed\_out":false,  
"number\_of\_nodes":1,  
"number\_of\_data\_nodes":1,  
"active\_primary\_shards":1411,  
"active\_shards":1411,  
"relocating\_shards":0,  
"initializing\_shards":0,  
"unassigned\_shards":10,  
"delayed\_unassigned\_shards":0,  
"number\_of\_pending\_tasks":0,  
"number\_of\_in\_flight\_fetch":0,  
"task\_max\_waiting\_in\_queue\_millis":0,  
"active\_shards\_percent\_as\_number":9

# GET cluster health shards --------------------------

[root@xxxxxxxx ~]# curl -XGET '[http://localhost:9200/\_cluster/health?level=shards?pretty=true](http://localhost:9200/_cluster/health?level=shards?pretty=true)'

{  
"cluster\_name":"wazuh",  
"status":"yellow",  
"timed\_out":false,  
"number\_of\_nodes":1,  
"number\_of\_data\_nodes":1,  
"active\_primary\_shards":1411,  
"active\_shards":1411,  
"relocating\_shards":0,  
"initializing\_shards":0,  
"unassigned\_shards":10,  
"delayed\_unassigned\_shards":0,  
"number\_of\_pending\_tasks":0,  
"number\_of\_in\_flight\_fetch":0,  
"task\_max\_waiting\_in\_queue\_millis":0,  
"active\_shards\_percent\_as\_number":99.2962702322

* * *

Según esos resultados veo que tengo una gran cantidad de fragmentos para un solo nodo  
¿ Cómo podría reducir esos fragmentos? para ver si se corrige el problema.

O en tal caso crear otro nodo en el mismo servidor para mejorar el rendimiento.

En lo que me puedan ayudar se los agradecería.

Saludos

---

<div class="post-metadata">

**Author:** ![Ugo\_Sangiorgi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ugo_sangiorgi/32/146361_2.png) [@Ugo\_Sangiorgi](https://discuss.elastic.co/u/Ugo_Sangiorgi)\
**Post date:** [February 6, 2018, 5:04pm UTC](https://discuss.elastic.co/t/error-request-timeout-after-30000ms-numero-excesivo-de-fragmentos/118676/2 "2018-02-06T17:04:12Z")

</div>

Hola Josmell,  
Usted puede controlar la cantidad de shards primarios y replicas usando la API settings en sus indices:  
[https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-update-settings.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-update-settings.html)

Los valores por defecto son 5 shards primarios y 1 replica por shard (total de 10 shards por indice), lo que talvez sea demasiado para su caso.

No es posible alterar la cantidad de shards primarios despues de creado el indice, por lo que usted debe hacer un **reindex** si quieres reducir la cantidad de shards primarios.  
La cantidad de replicas puede ser alterada de manera dinamica (despues de creado el indice) sin problema.

Si sus indices son creados de manera automatica (por ejemplo indices diarios criados desde logstash) es importante tener templates para gerenciar la cantidad de shards: [https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-templates.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-templates.html)

---

<div class="post-metadata">

**Author:** ![Josmell\_Chavarri](https://avatars.discourse-cdn.com/v4/letter/j/977dab/32.png) [@Josmell\_Chavarri](https://discuss.elastic.co/u/Josmell_Chavarri)\
**Post date:** [February 19, 2018, 6:39pm UTC](https://discuss.elastic.co/t/error-request-timeout-after-30000ms-numero-excesivo-de-fragmentos/118676/3 "2018-02-19T18:39:07Z")

</div>

Hola Ugo

Muchas gracias por la respuesta, efectivamente se están generando indices diarios y estoy utilizando un template.

Lo primero que hice fue verificar los fragmentos que no estaban asignados por alguna razón, te colocó un extracto del resultado

GET \_cat/shards?h=index,shard,prirep,state,unassigned.reason

indice-2017.10.31 4 p STARTED  
indice-2017.10.31 3 p STARTED  
indice-2017.10.31 1 p STARTED  
indice-2017.10.31 2 p STARTED  
indice-2017.10.31 0 p STARTED  
indice-2018.02.07 3 p STARTED  
indice-2018.02.07 3 r UNASSIGNED CLUSTER\_RECOVERED  
indice-2018.02.07 4 p STARTED  
indice-2018.02.07 4 r UNASSIGNED CLUSTER\_RECOVERED  
indice-2018.02.07 1 p STARTED  
indice-2018.02.07 1 r UNASSIGNED CLUSTER\_RECOVERED  
indice-2018.02.07 2 p STARTED  
indice-2018.02.07 2 r UNASSIGNED CLUSTER\_RECOVERED  
indice-2018.02.07 0 p STARTED  
indice-2018.02.07 0 r UNASSIGNED CLUSTER\_RECOVERED

Con esto verifiqué lo que me comentaste que tenia los valores por defecto de 5 shards con 1 replica para cada shards.

Luego modifique el template que se esta utilizando agregando las siguientes opciones para poder cambiar el número de shards y replicas que se generaban.

{  
"orden" : 0 ,  
"plantilla" : "template" ,  
"configuración" : {  
"index.refresh\_interval" : "5s" ,  
"number\_of\_shards" : 1 ,  
"number\_of\_replicas" : 0  
},  
"mappings" : {  
"..." : "..."  
}  
}

Luego de cargar nuevamente el template obtuve estos resultados:

1.- Las replicas se eliminaron  
2.- Los indices nuevos que se generaron ya tienen 1 shards y sin réplicas.  
3.- Aunque me sigue mostrando el error de "timeout after 30000 ms ", luego de ese tiempo ya me muestra los datos de la búsqueda.

indice-2018.02.08 0 p STARTED --------\> índice nuevo  
indice-2018.02.07 1 p STARTED  
indice-2018.02.07 3 p STARTED  
indice-2018.02.07 4 p STARTED  
indice-2018.02.07 2 p STARTED  
indice-2018.02.07 0 p STARTED

Luego hice el reindex y se fue el error.

Saludos

---

<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:** [March 19, 2018, 6:39pm UTC](https://discuss.elastic.co/t/error-request-timeout-after-30000ms-numero-excesivo-de-fragmentos/118676/4 "2018-03-19T18:39:20Z")

</div>

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