Seuil d'utilisation de la mémoire par MySQL dépassé

Bonjour,

Hier j’ai reçu ce message par mail automatique depuis le serveur :

Le statut d’utilisation de la mémoire est critique !
La valeur actuelle est 1.64 GiB.

Cette valeur a même légèrement augmenté depuis hier (1,697G).

Selon ce qui me montre Advanced Monitoring, l’utilisation de la mémoire MySQL augment constamment : 1022MiB le 12 décembre dernier, ensuite de plus en plus, à peu près toutes les semaines.

Qu’est-ce que je dois faire pour arrêter cela ? Je suis vraiment inquiet, à ce rythme-là dans quelques jours/heures c’est le crash.

Est-ce qu’il faut purger cette mémoire ? Désolé si je dis n’importe quoi, mes connaissances en la matière sont vraiment microscopiques –merci d’avance pour un conseil !

Voici quelques infos utiles :

C’est un forfait avec 8G de RAM

PHP 7.4.13

Debian 10

MySQL version 10.3.27

Il faudrait donner un peu plus d’informations.
S’agit-il d’un site avec cms ou pas
Sinon tu peux regarder du côté de MySQL Query Cache
Et tu peux regarder et éventuellement posté en cliquant ici

Vous voyez je ne savais même pas ce que veut dire ‘site avec un CSM’ :- Apparemment non, c’est un WordPress hébergé par Nuxit.

J’irai voir ce que vous m’avez montré, merci. Mais si entre temps quelqu’un puisse me donner quelques infos… :-

J’ai fait une optimisation de la base de données avec le plugin Advanced DB Cleaner qui est installé sur le site (General clean up qui concernait plus 120 000 éléments). Mais ça n’a rien donné puisque le niveau d’utilisation de la mémoire MySQL continue à grimper, j’ai peur qu’à ce rythme c’est le crash assuré.

D’où vient cette charge de mémoire, est-ce qu’on peut la vider, optimiser, voir – augmenter la limite ? Chez moi, du moins ce que je vois sur le graphique ci-joint, le maximum est de 1,9G et je suis déjà a plus de 1,7G.

Merci encore
image

Wordpress et un CMS… cela fait quant même un peu peur pour quelqu’un qui gère visiblement un site lui même !
Il existe effectivement de nombreux module wp pour nettoyer et optimiser la bd.
Mais cela ne doit pas être l’unique raison.
C’est un VPS infogéré je suppose. Si tel est le cas tu peux augmenter certaines valeurs au niveau du serveur qui seront différentes si tu utilises Nginx ou Apache. Ou modifier les valeurs dans php.ini que tu trouves dans l’arborescence du site (via SFTP).
Comme cela je dirais que tu as un « bug » au niveau des modules. Et donc il convient de les désactiver 1 par 1 pour voir ce qui cause cela. Il existe également certains modules pour analyser le site. Ou encore, toujours dans l’arborescence du site vérifier que tout est ok et pas un truc bizarre ! Bref les causes sont multiples et donc parfois c’est un travail de fourmi.
Tu peux avoir aussi une recrudescence de fréquentation et là il te faudra augmenter la RAM.
Ne pas savoir que wp est un cms me faire dire que tu devrais essayer de trouver quelqu’un qui puisse d’aider, mais plus dans le détail.

Je suis entièrement d’accord avec l’idée de trouver quelqu’un avec des compétences en la matière, c’est malheureusement pas possible en ce moment pour des raisons financières. Il faut que je me débrouille tout seul pour le moment.

Je ne veux pas prendre sur ton temps mais tu as des idées précises – je peux aller partout dans le site et le serveur (oui, c’est un VPS infogéré), vérifier et aussi intervenir si nécessaire.

Non, ce n’est pas la fréquentation qui a augmenté brusquement.

Dans php.info la seule ligne qui s’y trouve est la suivante : max_input_vars = 3000;

Sinon, c’est un Apache avec Nginx, FPM servi par Apache – je peux allez trouver toute info sur les réglages actuels, si tu as une idée d’où peut venir le probleme.

Ici c’est le graphique depuis 3 mois, c’est très bizarre comment l’utilisation de la mémoire MySQL monte et descend…Mais maintenant elle ne fait que monter.

Est-ce qu’il existe une purge de cette mémoire comme dans le cache ? Est-ce qu’un plugin/site de teste etc peut déterminer ce qu’il fait grimper cette valeur sans cesse ?..
image

Bonjour,

Il n’y a pas d’outils magiques pour savoir d’où cela vient. C’est à toi d’auditer les applications qui tournent sur ton serveur et la configuration pour savoir ce qui provoque cela.
Vu que cela semble augmenter sans cesse le coupable est probablement un script mal foutu avec des requêtes SQL bien pourries. La piste des extensions Wordpress suggérées par @Archinformatique est la première chose à vérifier. Il faudrait également vérifier la configuration de MySQL.

Sinon, d’où vient ce graphe ? Quel outil de surveillance est utilisé ? As-tu des graphes des connexions et des requêtes SQL, y compris les requêtes lentes (slow queries) ?
Pourquo
i as-tu PHP 7.4 alors que la version officielle de Debian Buster est la 7.3 ?

Infogéré par qui ? S’il y a une prestation d’infogérance il faut faire appel à ceux/celles qui s’en occupe. C’est leur travail.

que donne

free -m

Tu peux aussi regarder le module suivant

Query Monitor

Cela devrait confirmer l’avis de @Bruno1

Merci Bruno !
Dans phpMyAdmin, je vois 108 tables pour un total de 272,5 Moi, on est loin de 1,74G utilisé par MySQL, n’est-ce pas ?

Infogéré : pardon, je me suis mal exprimé – c’est un VPS mais je n’ai pas pris l’option d’infogérance (faute moyens en ce moment).

Aucun plugin n’a été ajouté récemment, c’est toujours la même config depuis un moment. Est-ce que vraiment c’est un plugin, donc, qui en serait la cause ?

Le graph vient du Advanced Monitoring dans Plesk. Malheureusement il ne montre pas des connexions et des requêtes SQL – où est-ce que je peux me les procurer ?

Je le ferai volontiers – quelles valeurs dois-je vérifier ?

Archinformatique :

que donne

free –m

Que cela veut dire, stp ?

En ligne de commande donne le retour de la requête suivante

free -m

Et tu devrais installer Query Monitor, cela devrait éclairer tes recherches

Je crois que j’ai trouvé les connections SQL (dans phpMyAdmin)
image
Le tableau continue encore mais les requesttes principales sont là.
Query Monitor est installé, qu’est-ce qu’il faut que regarde ?

@Archinformatique - qu’est-ce que je dois faire concrètement : écrire juste cela

free –m

mais où, et ensuite qu’est ce que cela va faire ?

Merci à vous

ça c’est pour Query Monitor : Query Monitor

@Archinformatique - qu’est-ce que je dois faire concrètement : écrire juste cela

free –m

mais où, et ensuite qu’est ce que cela va faire ?

En ligne de commande veux dire dans le shell. Tu as accès à ton serveur autre que Plesk (je ne connais pas du tout). Si oui alors tu tapes juste cette requête après d’être connecté à ton serveur.
Cela donnera un tableau avec des données et rien d’autre. Aucun impact ailleurs.

Merci, c’est super sympa !

Juste 2 questions :

  1. Qu’est-ce que je dois chercher dans Query Monitor qui pourra m’éclairer concernant l’utilisation excessive de la mémoire de MySQL ?

  2. Je peux me connecter au serveur par Filezilla ou Plesk, mais à vrai dire je ne vois pas où je peux taper free-m… ?

Bonjour

michel@debT450:~$ free -m
              total       utilisé      libre     partagé tamp/cache   disponible
Mem:          15713        1102       13514         166        1097       14156
Partition d'échange:       16383           0       16383
michel@debT450:~$ 

Je ne connais pas Query Monitor, mais si le problème vient de WordPress ou de l’une de ses extensions, cela sera très utile. Il faudra indiquer aussi la version de WordPress et la liste complète des extensions utilisées.
En attendant je vois 79800 requêtes select par heure, , soit 22 par seconde, ce qui est relativement élevé : à voir suivant la fréquentation du site web. Cela explique l’occupation de la mémoire.

Bonjour,

La version de WordPress est 5.6. Une précision : il y a le site PROD mais aussi DEV, à 90% identique.

La fréquentation du site est très basse depuis que le covid est arrivé, 50-60 par jour. Dans ce cas, est-ce que la valeur Select est anormal ?

Voici la liste des plugins actifs

  1. advanced-custom-fields
  2. advanced-database-cleaner
  3. all-404-redirect-to-homepage
  4. all-in-one-favicon
  5. amp
  6. arfaly-press
  7. backupbuddy
  8. better-wp-security
  9. categories-images
  10. check-email
  11. classic-editor
  12. code-snippets
  13. contact-form-7
  14. cookie-law-info
  15. cool-tag-cloud
  16. duplicator
  17. easy-digital-downloads
  18. easy-digital-downloads-variable-defaults
  19. edd-enhanced-ecommerce-tracking
  20. edd-featured-downloads
  21. edd-recommended-products
  22. edd-stripe
  23. edd-variable-pricing-descriptions
  24. emailTag
  25. gravityforms
  26. head-footer-code
  27. http-https-remover
  28. lazy-loading-responsive-images
  29. loco-translate
  30. miniorange-2-factor-authentication
  31. popup-maker
  32. premium-seo-pack
  33. query monitor
  34. server-ip-memory-usage
  35. simple-css
  36. simple-download-monitor
  37. simple-page-ordering
  38. simple-taxonomy
  39. taxonomy-terms-order
  40. tiny-compress-images
  41. turbo-widgets
  42. use-any-font
  43. waveplayerwordfence
  44. wordpress-php-info
  45. wp-crontrol
  46. wp-file-manager
  47. wp-rocket
  48. wp-rocket-static-exclude-opt-css

Et je me rends compte qu’être débutant c’est vraiment ingrat ! je comprends 1 chose sur 10. Par ex. Query Monitor sera très utile – utile comment, qu’est-ce qu’il faut voir et comment l’interpreter ?

Et pour free-m : je vois le tableau de donnée présenté par MicP (merci à lui :- mais je ne sais toujours pas comment l’obtenir : j’ai essayé de taper free-m en l’ajoutant à l’url du site, j’ai regardé dans Plesk et Filezilla, sans succès. Damm…

Non, ce n’est pas normal s’il y a un seul site WorpPress accessible publiquement. Je suppose que la version « dev » ne l’est pas.

Dans Query Monitor regarde « queries by component » cela devrait te permetre d’identifier l’extension qui génére toutes ces requêtes.

La commande free -m doit être exécutée dans une console, typiquement en te connectant en SSH à ton serveur.

Et pour « completer » la réponse de @Bruno1, j’ai comme le sentiment que tu n’as jamais accédé à ton serveur en direct. Si tel est le cas, il te faudra installer Putty (car je suppose encore que ton ordinateur fonctionne avec un environnement Windows) qui te permettra de te connecter en SSH. Il te faut récupérer l’adresse IP du serveur et le MDP.

Dommage mais je ne peux toujours pas faire free-m, j’ai dû louper une étape mais directement dans Putty ça ne marche pas.
image

Par contre j’ai fait MySQLTuner check (dans Putty, youpi !), je donne le résultat plus bas. Mais là je me rends compte que les extraterrestres existent vraiment et ils parlent cette langue, malheureusement moi pas du tout du tout (je suis musicien et occasionnellement ingé-son).
A la limite je comprends que la mémoire de MySQL est de 871.4M (ligne 45) : sur le total de 8G de RAM et en sachant qu’il y a aussi le site DEV, est-ce que c’est envisageable d’augmenter cette limite ?

  1. MySQLTuner 1.7.13 - Major Hayden major@mhtx.net

  2. Bug reports, feature requests, and downloads at http://mysqltuner.com/

  3. Run with ‹ –help › for additional options and output filtering

  4. [–] Skipped version check for MySQLTuner script
  5. [OK] Currently running supported MySQL version 10.3.27-MariaDB-0+deb10u1
  6. [OK] Operating on 64-bit architecture
  7. -------- Log file Recommendations ------------------------------------------------------------------
  8. [–] Log file: /var/log/mysql/error.log(639B)
  9. [OK] Log file /var/log/mysql/error.log exists
  10. [OK] Log file /var/log/mysql/error.log is readable.
  11. [OK] Log file /var/log/mysql/error.log is not empty
  12. [OK] Log file /var/log/mysql/error.log is smaller than 32 Mb
  13. [!!] /var/log/mysql/error.log contains 4 warning(s).
  14. [!!] /var/log/mysql/error.log contains 3 error(s).
  15. [–] 0 start(s) detected in /var/log/mysql/error.log
  16. [–] 0 shutdown(s) detected in /var/log/mysql/error.log
  17. -------- Storage Engine Statistics -----------------------------------------------------------------
  18. [–] Status: +Aria +CSV +InnoDB +MEMORY +MRG_MyISAM +MyISAM +PERFORMANCE_SCHEMA +SEQUENCE
  19. [–] Data in InnoDB tables: 476.5M (Tables: 447)
  20. [–] Data in MyISAM tables: 40.0K (Tables: 14)
  21. [OK] Total fragmented tables: 0
  22. -------- Analysis Performance Metrics --------------------------------------------------------------
  23. [–] innodb_stats_on_metadata: OFF
  24. [OK] No stat updates during querying INFORMATION_SCHEMA.
  25. -------- Security Recommendations ------------------------------------------------------------------
  26. [OK] There are no anonymous accounts for any database users
  27. [OK] All database users have passwords assigned
  28. [!!] User ‹ wordpress_7@% › does not specify hostname restrictions.
  29. [!!] User ‹ wp_clone_user@% › does not specify hostname restrictions.
  30. [–] There are 618 basic passwords in the list.
  31. -------- CVE Security Recommendations --------------------------------------------------------------
  32. [OK] NO SECURITY CVE FOUND FOR YOUR VERSION
  33. -------- Performance Metrics -----------------------------------------------------------------------
  34. [–] Up for: 29d 1h 44m 27s (70M q [27.874 qps], 1M conn, TX: 5607G, RX: 21G)
  35. [–] Reads / Writes: 92% / 8%
  36. [–] Binary logging is disabled
  37. [–] Physical Memory : 8.0G
  38. [–] Max MySQL memory : 871.4M
  39. [–] Other process memory: 1.2G
  40. [–] Total buffers: 432.0M global + 2.9M per thread (151 max threads)
  41. [–] P_S Max memory usage: 0B
  42. [–] Galera GCache Max memory usage: 0B
  43. [OK] Maximum reached memory usage: 496.0M (6.05% of installed RAM)
  44. [OK] Maximum possible memory usage: 871.4M (10.64% of installed RAM)
  45. [OK] Overall possible memory usage with other process is compatible with memory available
  46. [OK] Slow queries: 0% (5/70M)
  47. [OK] Highest usage of available connections: 14% (22/151)
  48. [OK] Aborted connections: 0.00% (0/1141305)
  49. [!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance
  50. [!!] Query cache may be disabled by default due to mutex contention.
  51. [OK] Query cache efficiency: 24.6% (18M cached / 73M selects)
  52. [!!] Query cache prunes per day: 225787
  53. [OK] Sorts requiring temporary tables: 0% (56 temp sorts / 4M sorts)
  54. [!!] Joins performed without indexes: 41121
  55. [!!] Temporary tables created on disk: 82% (7M on disk / 9M total)
  56. [OK] Thread cache hit rate: 99% (22 created / 1M connections)
  57. [OK] Table cache hit rate: 81% (942 open / 1K opened)
  58. [OK] Open file limit used: 0% (113/16K)
  59. [OK] Table locks acquired immediately: 100% (1K immediate / 1K locks)
  60. -------- Performance schema ------------------------------------------------------------------------
  61. [–] Performance schema is disabled.
  62. [–] Memory used by P_S: 0B
  63. [–] Sys schema isn’t installed.
  64. -------- ThreadPool Metrics ------------------------------------------------------------------------
  65. [–] ThreadPool stat is enabled.
  66. [–] Thread Pool Size: 6 thread(s).
  67. [–] Using default value is good enough for your version (10.3.27-MariaDB-0+deb10u1)
  68. -------- MyISAM Metrics ----------------------------------------------------------------------------
  69. [!!] Key buffer used: 18.3% (24M used / 134M cache)
  70. [OK] Key buffer size / total MyISAM indexes: 128.0M/164.0K
  71. [OK] Read Key buffer hit rate: 99.1% (2K cached / 24 reads)
  72. -------- InnoDB Metrics ----------------------------------------------------------------------------
  73. [–] InnoDB is enabled.
  74. [–] InnoDB Thread Concurrency: 0
  75. [OK] InnoDB File per table is activated
  76. [!!] InnoDB buffer pool / data size: 128.0M/476.5M
  77. [!!] Ratio InnoDB log file size / InnoDB Buffer pool size (75 %): 48.0M * 2/128.0M should be equal 25%
  78. [OK] InnoDB buffer pool instances: 1
  79. [–] Number of InnoDB Buffer Pool Chunk : 1 for 1 Buffer Pool Instance(s)
  80. [OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
  81. [OK] InnoDB Read buffer efficiency: 99.97% (14545978885 hits/ 14550837280 total)
  82. [OK] InnoDB Write log efficiency: 90.81% (33940926 hits/ 37375855 total)
  83. [OK] InnoDB log waits: 0.00% (0 waits / 3434929 writes)
  84. -------- AriaDB Metrics ----------------------------------------------------------------------------
  85. [–] AriaDB is enabled.
  86. [OK] Aria pagecache size / total Aria indexes: 128.0M/1B
  87. [!!] Aria pagecache hit rate: 94.5% (141M cached / 7M reads)
  88. -------- TokuDB Metrics ----------------------------------------------------------------------------
  89. [–] TokuDB is disabled.
  90. -------- XtraDB Metrics ----------------------------------------------------------------------------
  91. [–] XtraDB is disabled.
  92. -------- Galera Metrics ----------------------------------------------------------------------------
  93. [–] Galera is disabled.
  94. -------- Replication Metrics -----------------------------------------------------------------------
  95. [–] Galera Synchronous replication: NO
  96. [–] No replication slave(s) for this server.
  97. [–] Binlog format: MIXED
  98. [–] XA support enabled: ON
  99. [–] Semi synchronous replication Master: OFF
  100. [–] Semi synchronous replication Slave: OFF
  101. [–] This is a standalone server
  102. -------- Recommendations ---------------------------------------------------------------------------
  103. General recommendations:
  104.    Control warning line(s) into /var/log/mysql/error.log file
    
  105.    Control error line(s) into /var/log/mysql/error.log file
    
  106.    Restrict Host for user@% to user@SpecificDNSorIp
    
  107.    Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1
    
  108.    Adjust your join queries to always utilize indexes
    
  109.    When making adjustments, make tmp_table_size/max_heap_table_size equal
    
  110.    Reduce your SELECT DISTINCT queries which have no LIMIT clause
    
  111.    Performance schema should be activated for better diagnostics
    
  112.    Consider installing Sys schema from https://github.com/mysql/mysql-sys
    
  113.    Before changing innodb_log_file_size and/or innodb_log_files_in_group read this: https://bit.ly/2TcGgtU
    
  114. Variables to adjust:
  115.    query_cache_size (=0)
    
  116.    query_cache_type (=0)
    
  117.    query_cache_size (> 16M)
    
  118.    join_buffer_size (> 256.0K, or always use indexes with JOINs)
    
  119.    tmp_table_size (> 16M)
    
  120.    max_heap_table_size (> 16M)
    
  121.    performance_schema = ON enable PFS
    
  122.    innodb_buffer_pool_size (>= 476.5M) if possible.
    
  123.    innodb_log_file_size should be (=16M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.
    

C’est :

free -m

Avant de lancer MySQLTunner il faut comprendre pourquoi tu as autant de requête SQL. Et donc examiner Query Monitor comme je l’ai demandé.

Ensuite tu pourras effectivement ajuster les variables de configuration MySQL suivant les recommandations de MySQLTunner.