# Requete Timeout kibana
**URL:** https://discuss.elastic.co/t/requete-timeout-kibana/123240
**Category:** Discussions en français
**Created:** [March 9, 2018, 9:55am UTC](https://discuss.elastic.co/t/requete-timeout-kibana/123240 "2018-03-09T09:55:04Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@rmarin](https://discuss.elastic.co/u/rmarin)
#### Post date: [March 9, 2018, 9:55am UTC](https://discuss.elastic.co/t/requete-timeout-kibana/123240/1 "2018-03-09T09:55:04Z")
Bonjour,
Voici mon infra :
4 noeud ElasticSearch DATA avec la config suivante :
- 6 CPU
- 62 Go de RAM (XMS et XMX configurer à 31 Go)
- 500Go de disque pour le data (Seul elasticsearch installé dessus)
2 noeud ElasticSearch Client (sans data) avec Kibana dessus (chaque kibana pointe vers le noeud elasitc de local) :
- 8 CPU
- 32 Go de RAM (XMS et XMX configurer à 16 Go)
Tous les nœuds sont en version 6.1.1 et sous Centos
Chaque jour, 4 index sont créer (composé chacun de 4 shards active et de 4 replica). Tous les jours, nous supprimons les replica de la veille pour garder que les shards actif. nous gardons les shards 5 jours
La quantité de logs est environ de :
- 1 index : 180 m de events/ jour
- 1 index : 55 m de events /jour
- 2 index : 25 m de events chacun / jour
Mon problème est lorsque j'essaie de faire une recherche sur une période supérieur à 3/4 heures et j'atteins le request timeout de kibana.
J'ai déjà essayé de l'augmenter jusqu'à 120 secs mais je l'atteins toujours.
Quelqu'un saurais t'il m'aider ?
---
### Author:  [@rashmi](https://discuss.elastic.co/u/rashmi)
#### Post date: [March 9, 2018, 4:05pm UTC](https://discuss.elastic.co/t/requete-timeout-kibana/123240/2 "2018-03-09T16:05:49Z")
copying my colleague @dadoonet
---
### Author:  [@dadoonet](https://discuss.elastic.co/u/dadoonet)
#### Post date: [March 9, 2018, 4:11pm UTC](https://discuss.elastic.co/t/requete-timeout-kibana/123240/3 "2018-03-09T16:11:30Z")
Bonjour Rémi
J'ai déplacé ton message dans #Discussions en français
Quelques remarques:
Pour les noeuds clients, la notion d'attribuer 50% à la JVM et le reste à l'OS pour le cache FS n'a aucun intérêt ici puisqu'il n'y a pas de data sur disque.
Donc tu pourrais éventuellement augmenter la taille de la HEAP sur ces machines pour avoir d'avantage de mémoire là.
> Tous les jours, nous supprimons les replica de la veille pour garder que les shards actif.
Tu veux dire que tous les jours tu supprimes les "index" les plus vieux ?
Si ce n'est pas ce que tu voulais dire, j'aimerais mieux comprendre ce que tu fais. Peux-tu donner le genre de commande tu passes à Elasticsearch pour cela ?
> composé chacun de 4 shards active et de 4 replica
Donc en language elasticsearch: 4 primary shards et un replica shard (par primary), right?
Pourquoi 4 ? Comment as-tu trouvé cette valeur ?
---
### Author:  [@rmarin](https://discuss.elastic.co/u/rmarin)
#### Post date: [March 20, 2018, 9:54am UTC](https://discuss.elastic.co/t/requete-timeout-kibana/123240/4 "2018-03-20T09:54:40Z")
Bonjour dadoonet,
Merci pour ton retour.
> Pour les noeuds clients, la notion d'attribuer 50% à la JVM et le reste à l'OS pour le cache FS n'a aucun intérêt ici puisqu'il n'y a pas de data sur disque.
Je vais modifier le pourcentage de repartions de la RAM sur les nœuds client.
Quel pourcentage préconises tu ? 70% ? Sachant que sur ces machine j'ai également Kibana qui tourne.
> [@dadoonet](#):
>
> > Tous les jours, nous supprimons les replica de la veille pour garder que les shards actif.
>
> Tu veux dire que tous les jours tu supprimes les "index" les plus vieux ?
>
> Si ce n'est pas ce que tu voulais dire, j'aimerais mieux comprendre ce que tu fais. Peux-tu donner le genre de commande tu passes à Elasticsearch pour cela ?
Tous les jours, nous supprimons les "index" les plus vieux et nous retirons le replica des index de la veille.
Pour cela, nous utilisons 2 actions curator :
```
actions:
1:
action: delete_indices
description: >-
Delete indices older than 7 days (based on index name), for logstash-
prefixed indices. Ignore the error if the filter does not result in an
actionable list of indices (ignore_empty_list) and exit cleanly.
options:
ignore_empty_list: True
disable_action: False
filters:
- filtertype: pattern
kind: regex
value: "^(logstash-|.monitoring-es-|.watcher-history-|.monitoring-logstash|.monitoring-kibana|shrink-logstash).*$"
- filtertype: age
source: name
direction: older
timestring: '%Y.%m.%d'
unit: days
unit_count: 7
2:
action: replicas
description: >-
Set the number of replicas per shard for selected indices to 'count'
options:
count: 0
wait_for_completion: True
max_wait: 600
wait_interval: 10
filters:
- filtertype: pattern
kind: regex
value: "^(logstash-|.monitoring-es-|.watcher-history-|.monitoring-logstash|.monitoring-kibana).*$"
- filtertype: age
source: creation_date
direction: older
unit: days
unit_count: 1
```
A l'installation, nous utilisions 5 shards primary. Mais je me suis rendu compte que la répartition de la charge entre les nœuds DATA n'était pas homogène. Sur les nœuds où j'avais 2 shards d'un index qui a beaucoup d'activité, le CPU tournais autour de 80% de CPU alors que les autres était à 60%.
En utilisant 4 shards, je reparti la charge de façon homogène sur les 4 nœuds DATA
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [April 17, 2018, 9:54am UTC](https://discuss.elastic.co/t/requete-timeout-kibana/123240/5 "2018-04-17T09:54:57Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.