Scénario #30878: HORUS 2.6 : erreur restauration baréos, problème valeur variable innodb_buffer_pool_size - Distribution EOLE - Ensemble Ouvert Libre Évolutif

Scénario #30878

HORUS 2.6 : erreur restauration baréos, problème valeur variable innodb_buffer_pool_size

Added by Yoni Baude almost 3 years ago. Updated about 2 years ago.

Status:

Terminé (Sprint)

Priority:

Normal

Assigned To:

Joël Cuissinat

Category:

Target version:

sprint 2021 26-34 Equipe MENSR (été)

Start date:

07/06/2021

Due date:

08/27/2021

% Done:

100%

Story points:

1.0

Remaining (hours):

0.00 hour

Velocity based estimate:

Release:

EOLE 2.6.2.2

Release relationship:

Auto

Description

Bonjour,

Sur un horus 2.6, nous avons eu un problème de restauration de fichier via baréos. Mysql plante lors de la construction l'arborescence pour les JobIds sélectionnés. Extrait du log mysql ci-dessous :

2020-10-17T10:38:17.588401Z 1696 [Warning] InnoDB: Difficult to find free blocks in the buffer pool (245 search iterations)! 245 failed attempts to flush a page! Consider increasing the buffer pool size. It is also possible that in your Unix version fsync is very slow, or completely frozen inside the OS kernel. Then upgrading to a newer version of your operating system may help. Look at the number of fsyncs in diagnostic info below. Pending flushes (fsync) log: 0; buffer pool: 0. 254108 OS file reads, 14470 OS file writes, 911 OS fsyncs. Starting InnoDB Monitor to print further diagnostics to the standard output.

Ensuite baréos ne fonctionne plus, mais également GFC WINDOWS ne fonctionne plus.

Pour résoudre le problème de restauration, j'ai modifier la variable innodb_buffer_pool_size du fichier /etc/mysql/conf.d/capti.cnf. J'ai mis 128M (valeur par défaut) à la place de 16M (valeur capti). Après avoir redémarré le service mysql, j'ai pu effectuer la restauration d'un fichier via bconsole.

Pourriez-vous me confirmer que la valeur 16Mo pour innodb_buffer_pool_size n'est pas adapté pour baréos et alerter l'équipe de qualification GFC de Montpellier ?
Y a-t-il une contre indication de généraliser la valeur 128M pour innodb_buffer_pool_size pour tous les Horus 2.6 ? (patch possible pour /usr/share/eole/creole/distrib/capti.cnf)

Bien à vous,
Yoni

Subtasks

History

#1 Updated by Yoni Baude almost 3 years ago

Pour info, la requête mysql pour déterminer la taille du innodb_buffer_pool_size, indique 1G, mais je ne suis pas un expert mysql.

mysql> SELECT CEILING(Total_InnoDB_Bytes*1.6/POWER(1024,3)) RIBPS FROM (SELECT SUM(data_length+index_length) Total_InnoDB_Bytes FROM information_schema.tables WHERE engine='InnoDB') A;
+-------+
| RIBPS |
+-------+
|     1 |
+-------+
1 row in set (1.78 sec)

#2 Updated by Yoni Baude almost 3 years ago

En complément le contenu du fichier /etc/mysql/conf.d/capti.cnf sur les serveurs horus 2.6 :

root@horus:~# cat /etc/mysql/conf.d/capti.cnf 
[mysqld]
# !MODIF GFC POUR CAPTI!
lower_case_table_names=1
log_bin_trust_function_creators=1
innodb_buffer_pool_size = 16M
#innodb_log_arch_dir = /var/lib/mysql
#innodb_log_group_home_dir = /var/lib/mysql
innodb_data_file_path = ibdata1:10M:autoextend:max:2048M
innodb_log_file_size = 5M
innodb_log_buffer_size = 8M
innodb_log_files_in_group=2
innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 0
root@horus:~#

#3 Updated by Gilles Grandgérard over 2 years ago

Status changed from Nouveau to En attente d'informations

Bonjour,

La modification semble être une bonne idée. D'ailleurs, les autres paramètres devraient être actualisé aussi. Mais, il s'agit de la configuration de GFC.

Le Pôle EOLE ne peut pas confirmer cette valeur à la place de l'équipe de qualification de GFC à Montpellier. Il me semble que la demande devrait être faite auprès de l'équipe de qualification de GFC à Montpellier.

Une fois la réponse obtenu, nous pourrons l'intégrer sur la distribution.

Je place cette demande en attente d'information.