Discussion :

[DaYonyon]

Bonjour,
J'ai un serveur mysql qui tourne très bien depuis 2009.
celui ci est régulièrement mis a jour et n'as jamais planté depuis cette date.
A la base, il était surtout dédié a nos applications web mais nous avons dernièrement démarrer une application interne développer en vb .net.
Depuis le démarrage de cette application, je n'ai jamais eu autant de plantage de la BDD soit une fois par semaine en moyenne et la semaine dernière, nous avons carrément du remonter un dump de la base de cette application (perte de 2 jour d'activité... super...).
Le choix d'une base mysql pour cette application, si il est discutable, s'explique par le besoin de communication entre la base des applications web et de cette application vb. Cela permet par le biai de procédure stocker, de vue ou de requête interne aux applications, de chercher ou mettre à jour les jeux d'informations.

Le contexte étant posé, j'aimerais comprendre et remédier a ce plantage régulier. Quand je regarde le log d'erreur de mysql, voici le dernier en date.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
key_buffer_size=27262976
read_buffer_size=65536
max_used_connections=370
max_threads=800
thread_count=212
connection_count=212
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 288430 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
005E7FA4    mysqld.exe!my_osmaperr()
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
InnoDB: Thread 1776 stopped in file os0sync.c line 474

Je m’interroge donc sur la config du serveur.

La config materiel du serveur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
Machine virtuel (VM WARE)
OS : windows 2003 SR2
MEMORY : 4Giga
Processeur : 2x2000ghz

Version du moteur MySQL : 5.5.15
Le fichier my.ini :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
[client]
port=3306
[mysql]
default-character-set=utf8
[mysqld]
port=3306
basedir="D:/mysql/"
datadir="D:/mysql/db-datas/Data/"
character-set-server=utf8
default-storage-engine=INNODB
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
max_connections=800
query_cache_size=166M
table_cache=1520
tmp_table_size=59M
thread_cache_size=38
myisam_max_sort_file_size=100G
myisam_sort_buffer_size=59M
key_buffer_size=26M
read_buffer_size=64K
read_rnd_buffer_size=256K
sort_buffer_size=256K
innodb_file_per_table
innodb_data_home_dir="D:/mysql/db-datas/"
innodb_additional_mem_pool_size=20M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=10M
innodb_buffer_pool_size=950M
innodb_log_file_size=190M
innodb_thread_concurrency=16
innodb_write_io_threads = 8
innodb_read_io_threads = 8

Est ce que ma config vous semble bonne?
Sur quoi je peu jouer pour l'optimiser ?
Comment prévenir ces crash ?
Autant de question que je me pose et si vous détectiez une anomalie dans ma config, cela m'aiderai grandement.

merci d'avance pour votre aide (et d'avance pardon a toutes personnes choqué par mon orthographe mais au moins je ne la fais pas version SMS...)

[SQLpro]

Déjà une VM est généralement une catastrophe pour tout SGBDR s'il est fortement sollicité.

Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p8...virtualisation

En plus MySQL est farci de bug et visiblement totalement instable. Je n'ai jamais vu de SQL Server ou d'Oracle planté sauf panne matérielle...
A lire : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux

A +

[DaYonyon]

L'article sur les serveur virtuel et les bases de données est intéressant et je vais prendre mes dispositions pour l'isoler sur une machine physique et dédié.

Concernant le choix de MySQL, SQL ou ORACLE, je ne suis pas vraiment d'accord sur le fait que MySQL soit plein de bug. Il a ses défaut et ces qualités tout comme n'importe quel autres moteur mais la n'est pas le débat.

Si nous avons opté pour MySQL, c'est purement financier et au jour d'aujourd'hui je doit trouver une solution pour que ça tourne de façon stable avec les moyens technique a ma disposition...

Ce que j'aimerais comprendre, c'est pourquoi cet perte de stabilité alors que jusqu’à maintenant tout fonctionnait très bien.
Le serveur est peu être plus solliciter qu'avant mais au final pas tant que ça.
Nous avons pléthore de tache de fond (des script remontant des informations des différents service ou partenaire généralement) sollicitant la base de données bien plus que ne saurais le faire une application et cela n'a jamais crée de plantage de la sorte.

Bref je vais essayer d'éliminer le facteur "virtualisation" mais pour le changement de base de données, pour le moment je vais devoir faire avec ce que j'ai.