Plantage jeedom a 1h31

jpty · Décembre 21, 2021, 11:03

Ca peut se faire dans un bloc code de scenario avec un message entre chaque fonction:

Ca donne en log du scénario:

[2021-12-22 00:00:40][SCENARIO] Start : Scenario lance manuellement.
[2021-12-22 00:00:40][SCENARIO] Exécution du sous-élément de type [action] : code
[2021-12-22 00:00:40][SCENARIO] Exécution d'un bloc code
[2021-12-22 00:00:41][SCENARIO] scenario::cleanTable() OK
[2021-12-22 00:00:41][SCENARIO] scenario::consystencyCheck() OK
[2021-12-22 00:00:45][SCENARIO] log::chunk() OK
[2021-12-22 00:00:45][SCENARIO] cron::clean() OK
[2021-12-22 00:00:45][SCENARIO] report::clean() OK
[2021-12-22 00:02:24][SCENARIO] DB::optimize() OK
[2021-12-22 00:02:28][SCENARIO] cache::clean() OK
[2021-12-22 00:02:28][SCENARIO] listener::clean() OK
[2021-12-22 00:02:28][SCENARIO] user::regenerateHash() OK
[2021-12-22 00:02:28][SCENARIO] Fin correcte du scénario

Le bloc code en texte:

try {
			scenario::cleanTable();
  $scenario->setLog('scenario::cleanTable() OK');
			scenario::consystencyCheck();
  $scenario->setLog('scenario::consystencyCheck() OK');
			log::chunk();
  $scenario->setLog('log::chunk() OK'); 
			cron::clean();
  $scenario->setLog('cron::clean() OK'); 
			report::clean();
   $scenario->setLog('report::clean() OK'); 
			DB::optimize();
   $scenario->setLog('DB::optimize() OK'); 
			cache::clean();
   $scenario->setLog('cache::clean() OK'); 
			listener::clean();
   $scenario->setLog('listener::clean() OK'); 
			user::regenerateHash();
   $scenario->setLog('user::regenerateHash() OK'); 
} catch (Exception $e) {
		log::add('jeedom', 'error', $e->getMessage());
} catch (Error $e) {
		log::add('jeedom', 'error', $e->getMessage());
}

Et le bloc code pour les repos:

try {
	foreach((update::listRepo()) as $name => $repo) {
		$class = 'repo_' . $name;
$scenario->setLog("Repo $class");
		if (class_exists($class) && method_exists($class, 'cronDaily') && config::byKey($name . '::enable') == 1) {
                   $scenario->setLog("Repo $class cronDaily() exists");
			$class::cronDaily();
                   $scenario->setLog("$class::cronDaily() OK"); 
		}
	}
} catch (Exception $e) {
	log::add('jeedom', 'error', $e->getMessage());
} catch (Error $e) {
	log::add('jeedom', 'error', $e->getMessage());
}

Correction: Ce n’est pas le cronDaily des plugins, c’est l’exec des cronDaily des repos. Il n’y a pas de cronDaily pour les repos chez moi Jeedom 4.1.28.

sangohan123 · Décembre 22, 2021, 7:54

Hello,

Donc effectivement le problème viens bien de DB::optimize si je le commente je n’ai pas d’erreur.
si je l’exécute seul j’ai l’erreur et le plantage …

Maintenant que le problème est clairement bien identifier que faire ?

Mips · Décembre 22, 2021, 8:01

Tout est dit je pense:

Vérifiez la taille des tables via l’outils DB

meute · Décembre 22, 2021, 8:04

Soit ta db souffre de corruptions et dans ce cas tes backups également, il faut donc réussir à réparer cette db, étrange que les outils de vérification et de réparation inclus à jeedom ne donnent pas d’erreurs.
En même temps vu que sur une autre machine hors VM tout semble bien fonctionner avec ton backup je ne pense pas que ce soit la DB qui soit vérolée.

Ou ton système/vm/hyperviseur/RAID ne « supporte » pas la charge d’une optimisation de la DB ce qui fait cracher ton serveur mariaDB, suite à des problèmes de lecture/écriture disques par exemple.
On en revient à ton premier log ou on peut voir plusieurs soucis d’accès disque avant que mariaDB se crashe …

Est-ce que ces erreur d’accès sont une des conséquences ou la cause du problème que tu as ?, ça reste à définir

meute · Décembre 22, 2021, 8:07

On a déjà vérifié, et j’ai perso une DB 2 fois plus grosse que la sienne (j’utilise aussi le plugin suivi conso et ma table fait 900Mo, la sienne en fait un peu plus de 400 je pense), et je n’ai pas de problème particulier. Et toutes mes autres tables sont plus grosses que les siennes.

sangohan123 · Décembre 22, 2021, 8:10

Mettre en cause le matériel pourquoi pas, cependant il reste quand même ces question :

Pourquoi ca merde après la MAJ ?
Pourquoi je n’ai aucun problème sur d’autre parti de jeedom?
Pourquoi je n’ai aucun problème sur mes 10autres VM ?

Je pense plutôt a un timeout quelque part qui me fait planter le bordel dans apache2 ou php … possible ?

jpty · Décembre 22, 2021, 8:10

Bonjour,
Trouver la table qui est corrompue.
Avec le code suivant issu de DB::optimize à placer dans un bloc code de scenario:

$tables = DB::Prepare("SELECT TABLE_NAME FROM information_schema.TABLES WHERE Data_Free > 0", array(), DB::FETCH_TYPE_ALL);
	foreach ($tables as $table) {
		$table = array_values($table);
		$table = $table[0];
  $scenario->setLog('DB '.$table);
		// DB::Prepare('OPTIMIZE TABLE `' . $table . '`', array(), DB::FETCH_TYPE_ROW);
$scenario->setLog('optimize DB OK');
	}

Ce code ne permet que de voir les tables qui vont etre optimisées et ne va pas planter.
Il faut ensuite decommenter la ligne DB::Prepare et comme ca va planter vous n’aurez pe pas de resultat

sangohan123 · Décembre 22, 2021, 8:14

------------------------------------
[2021-12-22 09:12:30][SCENARIO] -- Start : Scenario lance manuellement.
[2021-12-22 09:12:30][SCENARIO] - Exécution du sous-élément de type [action] : action
[2021-12-22 09:12:30][SCENARIO] Exécution d'un bloc élément : 1181
[2021-12-22 09:12:30][SCENARIO] Exécution d'un bloc élément : 1182
[2021-12-22 09:12:30][SCENARIO] - Exécution du sous-élément de type [action] : code
[2021-12-22 09:12:30][SCENARIO] Exécution d'un bloc code 
[2021-12-22 09:12:30][SCENARIO] DB cmd
[2021-12-22 09:12:30][SCENARIO] optimize DB OK
[2021-12-22 09:12:30][SCENARIO] DB historyArch
[2021-12-22 09:12:30][SCENARIO] optimize DB OK
[2021-12-22 09:12:30][SCENARIO] DB history
[2021-12-22 09:12:30][SCENARIO] optimize DB OK
[2021-12-22 09:12:30][SCENARIO] Fin correcte du scénario

meute · Décembre 22, 2021, 8:14

> Dec 20 01:31:52 JeedomV5 kernel: [1812305.995199] print_req_error: 1 callbacks suppressed
> Dec 20 01:31:52 JeedomV5 kernel: [1812305.995229] print_req_error: I/O error, dev vda, sector 15325944
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.015100] print_req_error: I/O error, dev vda, sector 15327992
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.015699] EXT4-fs warning (device dm-0): ext4_end_bio:323: I/O error 10 writing to inode 390358 (offset 0 size 0 starting block 1721951)
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.015704] buffer_io_error: 3062 callbacks suppressed
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.015706] Buffer I/O error on device dm-0, logical block 1721695
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.016099] Buffer I/O error on device dm-0, logical block 1721696
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.016558] Buffer I/O error on device dm-0, logical block 1721697
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.016968] Buffer I/O error on device dm-0, logical block 1721698
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.017306] Buffer I/O error on device dm-0, logical block 1721699
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.017697] Buffer I/O error on device dm-0, logical block 1721700
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.018042] Buffer I/O error on device dm-0, logical block 1721701
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.018415] Buffer I/O error on device dm-0, logical block 1721702
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.018762] Buffer I/O error on device dm-0, logical block 1721703
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.019076] Buffer I/O error on device dm-0, logical block 1721704
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.019782] print_req_error: I/O error, dev vda, sector 15330040
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.020034] print_req_error: I/O error, dev vda, sector 15332088
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.020404] EXT4-fs warning (device dm-0): ext4_end_bio:323: I/O error 10 writing to inode 390358 (offset 0 size 0 starting block 1722463)
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.020793] print_req_error: I/O error, dev vda, sector 15334136
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.021058] print_req_error: I/O error, dev vda, sector 15336168
> Dec 20 01:31:52 JeedomV5 kernel: [1812306.021359] EXT4-fs warning (device dm-0): ext4_end_bio:323: I/O error 10 writing to inode 390358 (offset 0 size 0 starting block 1722973)

Sincèrement en voyant ce log… je ne pense pas que ton système soit aussi sain et stable que tu ne le pense …

jpty · Décembre 22, 2021, 8:14

C’est MariaDB qui plante et redémarre dans les logs du 1er post

meute · Décembre 22, 2021, 8:16

Oui et il pante suite à des erreurs d’accès disque … ça parait évident.

meute · Décembre 22, 2021, 8:22

Moi je penche pour un soucis au niveau RAID directement vu que 2 VM (l’ancienne et la nouvelle) posent le même problème …

Tu ne peux pas mettre ta VM sur un disque non RAID pour voir ? ou au pire vu qu’il me semble que tu n’as que du RAID dans ton serveur, un avec du SSD et un autre avec des HDD, peut-être mettre la VM sur le RAID HDD pour tester.

Ca expliquerait aussi en partie ton bench pas terrible et ta charge moyenne de la VM jeedom qui me parait depuis le début trop élevée, … car je pense que ton système passe son temps à corriger les erreurs d’accès disques et dès que trop d’accès sont faits comme lors d’une optimisation de la DB alors ça part en vrille.

olive · Décembre 22, 2021, 8:27

Do not use ZFS on top of a hardware RAID controller which has its own cache management. ZFS needs to communicate directly with the disks. An HBA adapter or something like an LSI controller flashed in “IT” mode is more appropriate.

sangohan123 · Décembre 22, 2021, 8:28

les SSD ne sont pas en RAID matériel il sont en SATA directement et le RAID logiciel ZFS

titof2375 · Décembre 22, 2021, 8:38

Ça c’est pour proxmox?

olive · Décembre 22, 2021, 8:47

yes
https://pve.proxmox.com/wiki/ZFS_on_Linux

sangohan123 · Décembre 22, 2021, 9:00

en fait il faudrait que je rajoute un SSD simple genre 128go et que je l’attribut a mon jeedom directement.

ça dois être faisable il me reste 2 prise sata de mémoire sur le serveur

j’ai ça sout la main tout neuf pratiquement Drevo X1 60 GB SSD 2.5 Pouces SATA III Interne Solid State Dur Disque MLC pour ordinateur portable + 3.5 pouces Montage Support pour PC de bureau | AliExpress

ça pourrait faire un bon test ?

meute · Décembre 22, 2021, 9:05

Oui, n’importe quel disque fera l’affaire, le but est simplement de tester sans ton RAID … as-tu testé sur l’autre RAID (HDD) pour voir ?
C’est le premier test le plus rapide à faire …

sangohan123 · Décembre 22, 2021, 9:12

oui j’ai fait le test sur la jeedom neuve que j’ai installé hier c’était pareil, alors que la on est sur du raid matériel.
Je ferai le test ce soir la je suis au taf

jpty · Décembre 22, 2021, 9:16

Dans les 3 tables cmd, historyArch et history qui devraient être optimisées, il y en a au moins une qui est corrompue.