[neoseeyou]

Salut a vous,

Vu que je fais ca pour aider un pote avec son site, je n'ai pas envie de perdre trop de temps avec ce serveur. Vu qu'il est engagé sur un mois seulement , je suis en train de regarder ailleurs pour installer le wp et voir si cela vient de WP au final ou du vps

Le vps a tourné correctement pendant 2 jours puis est repartie dans la lenteur et l'instabilité depuis hier soir.
Merci de votre soutien et de vos réponses.

[Dagostino]

As tu essayé d'optimiser mysql au moins ?

Hello Buddy, non pas encore mais ayant retrouver mon site pendant quelques heures avec sa vitesse normale, puis retour de la lenteur (sans modif toujours de ma part), je doute fortement que tout ça vienne de mysql...

EDIT : je viens de lancer un mysqltunner, voilà le résultat, une ligne qui me semble anormal "Highest connection usage: 99% (150/151)"

[--] Up for: 25m 0s (247K q [164.809 qps], 9K conn, TX: 6B, RX: 22M)
[--] Reads / Writes: 99% / 1%
[--] Total buffers: 128.0M global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 533.8M (13% of installed RAM)
[OK] Slow queries: 0% (0/247K)
[!!] Highest connection usage: 99%  (150/151)
[OK] Key buffer size / total MyISAM indexes: 16.0M/104.0K
[OK] Query cache efficiency: 93.4% (151K cached / 161K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 89 sorts)
[OK] Temporary tables created on disk: 0% (98 on disk / 57K total)
[OK] Thread cache hit rate: 91% (852 created / 9K connections)
[OK] Table cache hit rate: 93% (109 open / 116 opened)
[OK] Open file limit used: 4% (50/1K)
[OK] Table locks acquired immediately: 100% (1K immediate / 1K locks)
[OK] InnoDB buffer pool / data size: 64.0M/19.6M
[OK] InnoDB log waits: 0

[Dagostino]

Salut sich,
Voici les résultats sur mon serveur pour ta commande :

300+0 records in
300+0 records out
314572800 bytes (315 MB) copied, 35.1371 s, 9.0 MB/s

EDIT : j'ai réussi à installer FIO, voici ce que ça donne :

Jobs: 1 (f=1): [w(1)] [100.0% done] [0KB/4848KB/0KB /s] [0/1212/0 iops] [eta 00m:00s]
rand-write: (groupid=0, jobs=1): err= 0: pid=6024: Fri Sep  2 11:32:08 2016
  write: io=603072KB, bw=5025.4KB/s, iops=1256, runt=120006msec
    slat (usec): min=1, max=477490, avg=14.48, stdev=1635.75
    clat (usec): min=162, max=527136, avg=25452.55, stdev=24280.76
     lat (usec): min=216, max=527138, avg=25467.27, stdev=24330.12
    clat percentiles (msec):
     |  1.00th=[    4],  5.00th=[    5], 10.00th=[    6], 20.00th=[    7],
     | 30.00th=[    9], 40.00th=[   15], 50.00th=[   20], 60.00th=[   25],
     | 70.00th=[   31], 80.00th=[   40], 90.00th=[   57], 95.00th=[   71],
     | 99.00th=[  106], 99.50th=[  122], 99.90th=[  194], 99.95th=[  293],
     | 99.99th=[  478]
    bw (KB  /s): min=  667, max= 7009, per=100.00%, avg=5041.61, stdev=900.94
    lat (usec) : 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
    lat (msec) : 2=0.27%, 4=2.71%, 10=31.68%, 20=16.31%, 50=36.31%
    lat (msec) : 100=11.26%, 250=1.39%, 500=0.06%, 750=0.01%
  cpu          : usr=0.30%, sys=0.72%, ctx=6514, majf=1, minf=8
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=150768/d=0, short=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
  WRITE: io=603072KB, aggrb=5025KB/s, minb=5025KB/s, maxb=5025KB/s, mint=120006msec, maxt=120006msec

Disk stats (read/write):
  vda: ios=405/152392, merge=0/173, ticks=992/1102040, in_queue=1102968, util=33.16%

C'est moi aussi un vps SSD. Je te remercie pour l'aide !

[sich]

Si le problème vient bien des accès disques optimiser mysql ne fera qu'aider un peu...
J'ai eu des problèmes récemment sur un vps cloud, mais cette fois ci j'ai réussi à faire une demande de changement d'host et le problème semble résolu.
J'ai un soucis depuis 2 jours sur un autre vps cloud (autre DC), je dois faire des tests demain en rescue pour bien valider que le problème ne vient pas de moi.

Si c'est un VPS SSD ce n'est pas de chance, les miens fonctionnent vraiment très bien côté disques. Mais de toute façon le support ne fera rien car il n'y a aucune garantie sur cette gamme. De plus les données étant directement sur l'host je doute qu'il y'ait un process de migration automatique de prévu chez eux.

Que donne à ce jour la commande dd ? Les résultats donnés il y'a quelques jours étaient vraiment très mauvais...

Ce VPS est loué pour combien de temps encore ?

[buddy]

As tu essayé d'optimiser mysql au moins ?

[Dagostino]

Salut,
bon j'ai toujours l'erreur et la lenteur.
J'ai cru que tout était terminé quand le site est devenu rapide comme avant mais en fait quelle déception...
Si j'ai bien suivi votre discussion, ce n'est donc pas de notre faute mais OVH ne fera rien pour nous aider ?
Je les ai contacté il y a 3 jours, à part une réponse pour me dire "je regarde", j'ai rien eu d'autre...

ps: j'ai exactement la même zone que toi Zone : os-sbg1-002 / Cluster : cluster-001

[neoseeyou]

Oui effectivement, la solution du disque additionnel peut etre une solution.

Actuellement le site tourne, meme si il est pas aussi rapide qu'il devrait etre. Meme avec un plugin de mise en cache je le trouve lent. Par contre depuis ce matin pas de soucis connexion à la bdd defaillante. Mon ami peut quand meme faire des ventes.

Je vous tiendrais au courant suite au retour du support, mais j'ai peur que tu ai raison concernant le gain de cause.

[sich]

De tel problèmes sur un vps ssd 3 ?
Boudiou... Ben là pas grand chose à faire vu qu'il n'y a aucune garantie sur la gamme SSD... A part prendre un autre VPS SSD il n'y a pas grand chose à faire.
Pour ma part je préconiserai de prendre une instance SSD en public cloud à l'heure. De là faire quelques tests sur plusieurs jours puis si tout est ok passer à un forfait mensuel puis basculer les données dessus.

Mais sinon un WP avec un disque dans les choux comme ça forcément ça ne fonctionnera pas. Le vps à été loué en public cloud ou sur la gamme VPS "normale" ?
Le truc ça serait de prendre un disque additionnel pour stocker la bdd et les sites histoire de souffrir le moins possible des problèmes de perfs sur le disque.

Mais oui ton problème vient des accès au disque trop lent. Je doute plus que fortement qu'ovh fasse quoi que ce soit. Vu que déjà en gamme cloud c'est galère d'avoir gain de cause, en gamme SSD c'est probablement totalement impossible.

[neoseeyou]

Merci Buddy, en fonction effectivement j'utiliserais mysql tuner pour essayer d'optimiser.

[buddy]

Il faudrait regarder les logs de mysql.

Mais dans tous les cas, ça ne fera pas de mal d'optimiser mysql et apache.

[neoseeyou]

Bonjour Sich

J'ai demandé à mon ami d'ouvrir un ticket au support avec les infos qu'on a retiré du forum.

Pour toi ce soucis de bande passante justifierait qu'on ai principalement des coupures avec le service mysql?

Je pense qu'on est déja sur une offre vps ssd : https://www.ovh.com/fr/vps/vps-ssd.xml (ssd3)

On va voir ce qui va en sortir de notre discussion avec le support.

Merci

[sich]

Bizarre car tu as de bon résultats sur la commande fio mais les résultats sont catastrophiques avec dd....
Il faudrait que tu donnes ces résultats au support. Mais effectivement tu ne pourras pas utiliser ce vps dans ces conditions. Il y'a un soucis de bande passante entre l'host et le cluster à priori.

[EDIT]
Une réinstall ne servira à rien. Au pire tu peux essayer de rebooter en mode rescue et de refaire ces commandes sur le disque de ton VPS, tu dois le monter au préalable.. Je n'ai pas fait la manip depuis longtemps je ne pourrai plus te dire exactement comment faire, peut être même qu'il est déjà monté à la base.

L'autre solution c'est de prendre un VPS SSD au lieu d'un cloud. J'ai moins de panne sur les SSD que sur les Cloud de mon côté ce qui est assez hallucinant au final.
[/EDIT]

[neoseeyou]

Ok merci pour tes précisions

Déja tu me rassure un peu car je commencais à me demander ce que j'avais bien pu faire pour saturer le vps comme ca.

Je suis pas venu sur le forum les mains dans les poches en disant; "ca marche pas". J'ai fait quelques jours de recherche, tenter de faire des modifs dans les configs sql et apache (que j'ai remis à l'origine par la suite) , upgrade du vps pensant qu'un ajout de ram aiderait et pourtant rien n'y fait.

Pour la commande FIO je viens de l'installe et voila ce que ca me donne

Jobs: 1 (f=1): [w(1)] [100.0% done] [0KB/7343KB/0KB /s] [0/1835/0 iops] [eta 00m:00s]
rand-write: (groupid=0, jobs=1): err= 0: pid=3108: Mon Aug 29 23:30:50 2016
write: io=902772KB, bw=7522.9KB/s, iops=1880, runt=120004msec
slat (usec): min=1, max=849770, avg=53.12, stdev=2323.40
clat (usec): min=90, max=984089, avg=16952.93, stdev=19233.27
lat (usec): min=119, max=984092, avg=17006.26, stdev=19347.99
clat percentiles (msec):
| 1.00th=[ 3], 5.00th=[ 4], 10.00th=[ 6], 20.00th=[ 9],
| 30.00th=[ 12], 40.00th=[ 15], 50.00th=[ 16], 60.00th=[ 17],
| 70.00th=[ 18], 80.00th=[ 21], 90.00th=[ 26], 95.00th=[ 31],
| 99.00th=[ 81], 99.50th=[ 141], 99.90th=[ 221], 99.95th=[ 255],
| 99.99th=[ 848]
bw (KB /s): min= 80, max= 9752, per=100.00%, avg=7574.99, stdev=1210.65
lat (usec) : 100=0.01%, 250=0.07%, 500=0.05%, 750=0.12%, 1000=0.10%
lat (msec) : 2=0.45%, 4=6.46%, 10=15.70%, 20=56.10%, 50=19.43%
lat (msec) : 100=0.71%, 250=0.76%, 500=0.05%, 1000=0.01%
cpu : usr=0.64%, sys=0.88%, ctx=24660, majf=0, minf=8
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=225693/d=0, short=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
WRITE: io=902772KB, aggrb=7522KB/s, minb=7522KB/s, maxb=7522KB/s, mint=120004msec, maxt=120004msec

Disk stats (read/write):
vda: ios=391/242952, merge=0/30, ticks=1320/1883840, in_queue=1885276, util=64.66%

Je n'ai pas tenté de la refaire à intervalle régulier mais voici un second test (c'est encore pire)

314572800 octets (315 MB) copiés, 42,172 s, 7,5 MB/s

Enfin voici la zone et le cluster du vps

os-sbg1-002
cluster-001

J'avais bien envie de reinstaller un debian neuf sur mon vps et refaire toute l'installe moi meme via ssh mais si c'est la node est saturé c'est pas la peine (ce n'etait pas comme ca il y a un petit mois)

Merci pour ton aide

[sich]

ouch, tu as testé cette commande à intervalle régulier ?
Parce que là effectivement ton serveur doit pas fonctionner terrible avec ça.
Si les chiffres restent aussi mauvais ouvre un incident au support....
Pour la commande fio il faut l'installer... .Si tu es sous Debian il faut juste faire un : apt-get install fio
fio permet d'avoir les IOPS, sur les VPS c'est bridé légèrement en dessous des 1000. Mais vu les résultats tu devrais plutôt être à 500 surement.

Probablement la node qui est surchargée, voir le cluster, mais je pense plutôt pour la node.

Perso j'ai eu un VPS comme ça, mais le support ne fait rien sur ce problème et j'ai fini par en louer un autre dans un autre DC pour être sûr de ne pas tomber sur le même host.

dans quel DC est ton VPS ? Sur quel cluster et dans quelle "zone" ? Normalement tu as les infos sur la page de ton VPS dans le panel.

[EDIT]
Pour ma part mon VPS totalement inutilisable au vu des perfs déplorable est ici :
Zone os-gra1-007
Cluster cluster-001

Le cluster n'est pas en cause car j'ai un autre VPS sur ce cluster qui fonctionne extrêmement bien. Mais l'autre VPS est sur une autre "Zone".
Depuis j'ai pris un autre VPS sur SBG qui fonctionne bien mieux. Celui sur os-gra1-007 a tjrs des perfs catastrophiques et pourtant il ne fait rien. Aucun retour significatif de la part du support malgré la bonne volonté de la personne avec qui j'ai pu échanger au support. Mais à priori aucun retour pertinent et efficace de la part des admins au dessus.
[/EDIT]

[neoseeyou]

Merci, voici le résultat des deux commandes:

Pour la premiere commande: -bash: fio : commande introuvable

Pour la seconde commande: 300+0*enregistrements lus
300+0*enregistrements écrits
314572800*octets (315 MB) copiés, 12,8071*s, 24,6 MB/s

[sich]

La seule chose qui merdouille côté VPS Cloud (et non pas les SSD) c'est les accès disques.
Que donne la commande suivante ? :
fio --name=rand-write --ioengine=libaio --iodepth=32 --rw=randwrite --invalidate=1 --bsrange=4k:4k,4k:4k --size=512m --runtime=120 --time_based --do_verify=1 --direct=1 --group_reporting --numjobs=1

Et celle ci :
/bin/dd if=/dev/zero of=/tmp/speedtest bs=1M count=300 conv=fdatasync

[buddy]

Si relancer mysql permet de régler le soucis, c'est qu'il y a un problème logiciel je pense.
Notamment un dépassement de la mémoire vive maximale du VPS.

il faut probablement optimiser Apache et Mysql.
même si vous n'avez "Que" 300 visiteurs par jour, il ne faut pas oublier tous les robots divers et variés qui parcourent le web. Il n'y a pas que Bing et Google, plein d'autres parcourent le web et parfait de façon "agressive".

[neoseeyou]

Ce qui est drôle (et puis on arrêtera la vous et moi car ça n aide pas à la résolution du probleme) c est que je suis d accord avec vous sur la gestion d un vps vis à vis d un mutualisé, cependant aucun hébergeur n est infaillible. Vous même dans un de vos posts , vous ne comprenez pas pourquoi certains ssd perdaient en performances sans raison, pourtant vous semblez avoir pas mal de compétences dans le domaine non?

J ai déjà eu à gérer partiellement un dédié et je sais qu on est vite livre à soit même surtout quand ce n'est pas sa branche d activité première.

Bref si vous voulez reellement nous aider à résoudre le soucis vous êtes le bienvenue.

[sich]

Mon commentaire n'est peut être pas constructif mais en louant un VPS vous reconnaissez avoir les compétences techniques pour le gérer.
Je le redis, un VPS n'est pas un hébergement mutualisé.

La seule chose que doit vous fournir ovh c'est une machine virtuelle sur laquelle vous êtes les seuls maitres ensuite.
Mais qui dit liberté d'action dit aussi responsabilité de gestion et d'optimisation.

[neoseeyou]

Merci pour votre réponse buddy, pour ma part je relance seulement mysql en ssh.
Je vais aller regarder vos liens avec intérêt.

[buddy]

Bonjour,

quand vous parlez de redémarrer le VPS, vous le redémarrer comment ?
via le manager OVH ou en vous connectant en SSH puis en tapant reboot ?

Il se pourrait que çà soit utile d'optimiser la configuration de votre mysql. (pour éviter par exemple une saturation de la RAM)
https://www.geeek.org/mysql-tuning-p...mysql-274.html
et
https://wiki.deimos.fr/MysqlTuner_:_..._serveur_MySQL

[neoseeyou]

Le com super utile qui n apporte aucune aide constructive, merci ;-)

C est aussi facile pour un grand groupe de nous renvoyer la faute à nous utilisateur. Le support dit amen avec peu de vrai "support" finalement , et je dois donc me fouetter pour mon incompetence. Si j etais le seul dans ce cas de figure mais apparemment ça n à pas l air d être le cas.

[Dagostino]

Mouahah elle est pas mal celle là...
ça n'a rien à voir avec ce que j'ai pu faire ou pas : je n'ai rien touché, tout allait bien et aujourd'hui tout va mal, alors toi le grand pro, dit moi ce qui a bien pu se passer ?

Je ne me suis pas connecté au ftp, ni au manager, ni même au BO de wordpress.

[sich]

En même temps avoir un VPS ce n'est pas comme un hébergement mutualisé... Faut savoir ce que l'on fait !
Considérer qu'OVH n'est pas un bon prestataire parce que vous n'êtes pas en mesure de faire fonctionner votre serveur c'est fort quand même...

[Dagostino]

ça m'étonnais que ça vienne d'un manque de mémoire comme ça d'un coup...
je pense que ça vient de chez eux, de toute façon c'est simple, je n'ai touché à rien entre le moment ou ça fonctionnait et le maintenant, je ne m'étais même pas connecté sur mon manager OVH.
Si ça dure trop longtemps je ferai comme toi, et je déménagerai ailleurs.
Je leur ai envoyé un ticket, on va voir, mais je sens qu'ils vont me dire qu'ils ne feront rien, sauf si je paye x)

[neoseeyou]

Salut dagostino,

Nous sommes passé sur un vps supérieur avec 8go de ram et toujours le même soucis, des déconnections de la base de données, des lenteurs extrême inexpliqués alors que nous avons qu un wp d installe et moins de 300 visites par jour. Faut pas déconner alors qu il y a un mois tout marchait nickel. Je pense que je vais conseiller à mon ami de quitter ovh pour un concurrent

[Dagostino]

Bonjour à tous,
j'ai exactement le même soucis, la seule façon de récupérer le site c'est de redémarrer mon VPS. En checkant sur les logs j'ai aussi la même erreur :

160829 12:35:14 InnoDB: Completed initialization of buffer pool
160829 12:35:14 InnoDB: Fatal error: cannot allocate memory for the buffer pool
160829 12:35:14 [ERROR] Plugin 'InnoDB' init function returned error.
160829 12:35:14 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
160829 12:35:14 [ERROR] Unknown/unsupported storage engine: InnoDB
160829 12:35:14 [ERROR] Aborting

mais quelques instants après, l'erreur "error establishing a database connection" revient (entre 5 et 40 minutes selon)
Je veux bien que le soucis vienne du manque de mémoire, mais le site marchait très bien y'a quelques jours, je n'ai fait aucune modifs dessus, rien ajouter.
ça semble bizzare que la mémoire soit tout d'un coup en manque non ?
Au délà de l'erreur, j'ai une lenteur extrême (genre 20 secondes pour charger une page) que je n'avais pas avant.
J'ai tenté la solution numéro 3, à voir si ça fonctionne (en tout cas, ça n'a aucun impact sur la lenteur).

EDIT 1h après : bon je n'ai toujours pas eu l'erreur c'est plutôt bon signe, mais c'est vraiment lent :/

[Dagostino]

Bonjour,

de mémoire y a pas de SWAP sur les VPS OVH.

Sinon pourquoi ne pas passer sur un VPS plus gros si il consomme autant que ça ?

Cordialement, janus57

Bonjour à tous,
j'ai exactement le même soucis, pourtant le site tournait bien sans que je touche quoique se soit.
Je veux bien que le site consomme mais pourquoi du jour au lendemain sans que je n'ajoute rien, la mémoire viendrait à manquer ?

Quand je redémarre mon VPS, le site refonctionne pendant un laps de temps (allant de 5 à 30 min), il est par contre extrêmement lent, genre 20 secondes pour afficher une page, et ensuite vient l'erreur "error establishing a database connection" et en checkant les logs je m’aperçoit que j'ai la même erreur que neoseeyou :

160829 12:35:14 InnoDB: Completed initialization of buffer pool
160829 12:35:14 InnoDB: Fatal error: cannot allocate memory for the buffer pool
160829 12:35:14 [ERROR] Plugin 'InnoDB' init function returned error.
160829 12:35:14 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
160829 12:35:14 [ERROR] Unknown/unsupported storage engine: InnoDB
160829 12:35:14 [ERROR] Aborting

J'ai tenté la 3eme solution comme noseeyou l'a suggéré, pour l'instant le site fonctionne mais ça ne joue pas du tout sur la lenteur qui elle est toujours présente.
Une idée ?

[neoseeyou]

Merci, au moins ca m'evitera de perdre du temps avec cette solution ;-)

Avant de partir sur la solution d'upgrade du vps, je voulais voir si il n'y avait pas d'autres solutions. Pour le moment , la manoeuvre de réduire la taille du innodb_buffer_pool_size a l'air de fonctionner.

Si ca replante je vais voir avec mon ami pour qu'il prenne un vps plus gros effectivement.

[janus57]

Bonjour,

de mémoire y a pas de SWAP sur les VPS OVH.

Sinon pourquoi ne pas passer sur un VPS plus gros si il consomme autant que ça ?

Cordialement, janus57

[neoseeyou]

Bonsoir Janus,

Oui c'est ca, j'ai relancé manuellement Mysql. Effectivement j'ai continué à investigué et je suis tombé la dessus en regardant les logs a nouveau:

160822 13:12:05 InnoDB: Fatal error: cannot allocate memory for the buffer pool

En regardant sur google, je suis tombé sur ce site: http://www.webtrafficexchange.com/so...ry-buffer-pool

Actuellement j'ai appliqué leur solution numéro 3 (ca peut servir à d'autres personnes qui auraient ce soucis)

Si cela ne fonctionne pas, j'appliquerais leur solution numéro 2 avec un swap space

[janus57]

Bonjour,

vous avez regardé les logs ?
MySQL est coupé et vous le re-lancé ? si oui c'est peut être un problème de RAM insuffisant que le fait d'augmenter la mémoire de PHP peu empirer le problème.

Cordialement, janus57

[neoseeyou]

Je ne pense pas que cela résolve mon soucis mais apres vérification des infos sur phpinfo.php, j'ai remarqué que la memory limit etait de 128mo, or sur wordpress, celle ci est indiqué à 256mo.

Je viens donc de modifier le php ini du vps pour que le memory limit passe a 256 egalement

[neoseeyou]

Bonjour à tous

Je suis webdesigner, j'ai monté un site pour un ami en utilisant un vps ovh (jusque la je pense que je suis dans la bonne section )

Ce site tourne avec plusieurs plugins dont woocommerce et la vente d'ebooks avec un syteme de tamponnage des pdf (précision car cela impact sur la ram).

Au lieu de mettre une distrib Linux, mon ami et moi avons opté pour une installe wordpress pour gagner du temps. Pendant un mois et demi aucun soucis, le site tournait comme une horloge.

Cependant depuis deux semaines, le site devient inaccessible avec ce message 'Error establishing a database connection'. N'étant pas un expert en config serveur mais manipulant un peu SSH, j'ai pu relancer la fonction mysql sur le vps. Dès lors le site remarchait sans problème, mais tous les X temps, mysql s’arrêtait et à nouveau le message "Error establishing a database connection".

J'ai bien sur vérifié le fichier wp-config, enlevé puis rechargé celui ci sans effet. Seul la relance du service sql par ligne de commande fonctionnait mais temporairement.

J'ai envoyé le log d'erreur au support OVH qui me répond "Comme le confirme ce retour, vous pouvez effectuer différents réglages dans le fichier my.cnf pour que votre service mysql ne s’arrête pas."

Le soucis c'est que ca dépasse actuellement mes compétences sur le sujet.

Voici le log d'erreur

160822 12:41:19 mysqld_safe Number of processes running now: 0
160822 12:41:19 mysqld_safe mysqld restarted
160822 12:41:20 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
160822 12:41:20 [Note] /usr/sbin/mysqld (mysqld 5.5.50-0+deb8u1) starting as process 32494 ...
160822 12:41:20 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
160822 12:41:20 [Note] Plugin 'FEDERATED' is disabled.
160822 12:41:20 InnoDB: The InnoDB memory heap is disabled
160822 12:41:20 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160822 12:41:20 InnoDB: Compressed tables use zlib 1.2.8
160822 12:41:20 InnoDB: Using Linux native AIO
160822 12:41:20 InnoDB: Initializing buffer pool, size = 128.0M
160822 12:41:20 InnoDB: Completed initialization of buffer pool
160822 12:41:20 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 758127822
160822 12:41:20  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 758141385
160822 12:41:20  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
160822 12:41:20  InnoDB: Waiting for the background threads to start
160822 12:41:21 InnoDB: 5.5.50 started; log sequence number 758141385
160822 12:41:21 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
160822 12:41:21 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
160822 12:41:21 [Note] Server socket created on IP: '127.0.0.1'.
160822 12:41:21 [Note] Event Scheduler: Loaded 0 events
160822 12:41:21 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.50-0+deb8u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)
Killed
160822 13:12:04 mysqld_safe Number of processes running now: 0
160822 13:12:04 mysqld_safe mysqld restarted
160822 13:12:05 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
160822 13:12:05 [Note] /usr/sbin/mysqld (mysqld 5.5.50-0+deb8u1) starting as process 4669 ...
160822 13:12:05 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
160822 13:12:05 [Note] Plugin 'FEDERATED' is disabled.
160822 13:12:05 InnoDB: The InnoDB memory heap is disabled
160822 13:12:05 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160822 13:12:05 InnoDB: Compressed tables use zlib 1.2.8
160822 13:12:05 InnoDB: Using Linux native AIO
160822 13:12:05 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
160822 13:12:05 InnoDB: Completed initialization of buffer pool
160822 13:12:05 InnoDB: Fatal error: cannot allocate memory for the buffer pool
160822 13:12:05 [ERROR] Plugin 'InnoDB' init function returned error.
160822 13:12:05 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
160822 13:12:05 [ERROR] Unknown/unsupported storage engine: InnoDB
160822 13:12:05 [ERROR] Aborting

160822 13:12:05 [Note] /usr/sbin/mysqld: Shutdown complete

160822 13:12:06 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

Tout aide de votre part nous serait vraiment utile.

En vous remerciant par avance