N'importe qui peut m'aider à vérifier cette configuration MySQL? J'ai un VPS 32 Go RAM - 8 vcpu et 1 commerce électronique en cours d'exécution.
MySQLTuner me renvoie:
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
join_buffer_size (> 140.0M, or always use indexes with JOINs)
tmp_table_size (> 32M)
max_heap_table_size (> 32M)
table_open_cache (> 407)
my.cnf
les paramètres sont:
key_buffer_size = 256M
join_buffer_size = 140M
tmp_table_size = 80M
max_heap_table_size = 80M
thread_pool_size = 24
innodb_buffer_pool_instances = 6
innodb_buffer_pool_size = 6G
innodb_log_file_size = 768M
table_open_cache = 4000
skip_name_resolve = 1
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
max_connections = 200
#table_cache = 1024
#thread_concurrency = 40
tmp-table-size = 32M
max-heap-table-size = 32M
query_cache_limit = 4M
query_cache_size = 0
query_cache_type = 0
Informations supplémentaires
-------- Storage Engine Statistics -----------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MEMORY +MRG_MYISAM +MyISAM +PERFORMANCE_SCHEMA
[--] Data in InnoDB tables: 76.4M (Tables: 102)
[--] Data in MyISAM tables: 1.3G (Tables: 229)
[OK] Total fragmented tables: 0
-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 1d 19h 15m 53s (19M q [124.090 qps], 69K conn, TX: 21G, RX: 6G)
[--] Reads / Writes: 98% / 2%
[--] Binary logging is disabled
[--] Physical Memory : 31.5G
[--] Max MySQL memory : 33.8G
[--] Other process memory: 650.8M
[--] Total buffers: 6.3G global + 140.8M per thread (200 max threads)
[--] P_S Max memory usage: 72B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 9.5G (30.04% of installed RAM)
[!!] Maximum possible memory usage: 33.8G (107.34% of installed RAM)
[!!] Overall possible memory usage with other process exceeded memory
[OK] Slow queries: 0% (114/19M)
[OK] Highest usage of available connections: 11% (23/200)
[OK] Aborted connections: 0.01% (5/69987)
[OK] Query cache is disabled by default due to mutex contention on multiprocessor machines.
[OK] Sorts requiring temporary tables: 0% (3K temp sorts / 5M sorts)
[!!] Joins performed without indexes: 604
[!!] Temporary tables created on disk: 31% (796K on disk / 2M total)
[OK] Thread cache hit rate: 99% (29 created / 69K connections)
[!!] Table cache hit rate: 0% (400 open / 5M opened)
[OK] Open file limit used: 42% (440/1K)
[OK] Table locks acquired immediately: 99% (33M immediate / 33M locks)
-------- MyISAM Metrics ----------------------------------------------------------------------------
[!!] Key buffer used: 19.4% (52M used / 268M cache)
[OK] Key buffer size / total MyISAM indexes: 256.0M/66.2M
[OK] Read Key buffer hit rate: 98.8% (991M cached / 12M reads)
[!!] Write Key buffer hit rate: 51.6% (511K cached / 263K writes)
-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 0
[OK] InnoDB File per table is activated
[OK] InnoDB buffer pool / data size: 6.0G/76.4M
[OK] Ratio InnoDB log file size / InnoDB Buffer pool size: 768.0M * 2/6.0G should be equal 25%
[OK] InnoDB buffer pool instances: 6
[--] Number of InnoDB Buffer Pool Chunk : 48 for 6 Buffer Pool Instance(s)
[OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
[OK] InnoDB Read buffer efficiency: 100.00% (518324644 hits/ 518327944 total)
[!!] InnoDB Write Log efficiency: 38.31% (36637 hits/ 95624 total)
[OK] InnoDB log waits: 0.00% (0 waits / 58987 writes)
Rapport MySQLTuner complet:
SHOW GLOBAL STATUS;
SHOW GLOBAL VARIABLES;
htop
root@xxxxxxxxxxx ~ # ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 128903
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 128903
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
Dois-je ALTER toutes les tables MySQL en InnoDB?
Taux par seconde = RPS Suggestions à considérer pour votre section my.cnf [mysqld]
join_buffer_size=256K # from 140M for row pointers
thread_cache_size=40 # from 8 to avoid thread starvation
query_cache_limit=0 # from 4M since you have QC turned OFF
innodb_lru_scan_depth=100 # from 1024 to reduce CPU busy every SECOND
key_cache_age_threshold=7200 # from 300 seconds to reduce key_reads RPS
key_cache_division_limit=50 # from 100 percent for HOT/WARM caches
key_cache_block_size=16K # from 1K to evict bigger block when full
open_files_limit=30000 # from 1024 to reduce opened_files RPS
table_open_cache=10000 # from 407 to reduce opened_tables RPS
table_definition_cache=2000 # from 603 to reduce opened_table_definitions RPS
Observations:
Les problèmes les plus importants:
Passez de MyISAM à InnoDB (pour de nombreuses raisons). Conversion de MyISAM à InnoDB
Comme vous ne disposez que d'une petite quantité de données, il n'est pas nécessaire d'augmenter key_buffer_size
ou innodb_buffer_pool_size
. Cela devrait être réadressé si vous augmentez considérablement la taille de l'ensemble de données.
Augmenter ulimit -n
dans l'OS; il semble y avoir une limite par défaut de 1024 par processus. Cela permettra à plusieurs caches d'être plus volumineux. table_open_cache
a été (je suppose) ajusté à 407, mais cela semble trop faible. En augmentant la limite du système d'exploitation, les caches seront probablement agrandis automatiquement.
Certaines requêtes semblent être moins efficaces qu'elles ne le pourraient. Si vous pouvez les identifier, discutons-en. Cela peut impliquer de meilleurs index, des index composites, en évitant TEXT
, en évitant SELECT *
, etc.
Détails et autres observations:
( Opened_tables ) = 8,715,435 / 245130 = 36 /sec
- Fréquence d'ouverture des tables - augmenter table_open_cache
( open_files_limit ) = 1,024
- ulimit -n - Pour autoriser plus de fichiers, modifiez ulimit ou /etc/security/limits.conf ou dans sysctl.conf (kern.maxfiles & kern.maxfilesperproc) ou autre chose (selon le système d'exploitation)
( Table_open_cache_overflows ) = 8,713,321 / 245130 = 36 /sec
- Peut-être besoin d'augmenter table_open_cache
( Table_open_cache_misses ) = 8,715,416 / 245130 = 36 /sec
- Peut-être besoin d'augmenter table_open_cache
( expand_fast_index_creation ) = expand_fast_index_creation = OFF
- ALTER et OPTIMIZE peuvent être considérablement accélérés en utilisant ON. - Probablement mieux d'être ON.
( query_prealloc_size / _ram ) = 8,192 / 32768M = 0.00%
- Pour l'analyse. Pct de RAM - 16K
( query_alloc_block_size / _ram ) = 8,192 / 32768M = 0.00%
- Pour l'analyse. Pct de RAM - 16K
( local_infile ) = local_infile = ON
- local_infile = ON est un problème de sécurité potentiel
( Key_blocks_used * 1024 / key_buffer_size ) = 14,984 * 1024 / 256M = 5.7%
- Pourcentage de key_buffer utilisé. High-water-mark. - Réduisez key_buffer_size pour éviter une utilisation inutile de la mémoire.
( Key_writes / Key_write_requests ) = 445,704 / 787046 = 56.6%
- efficacité de key_buffer pour les écritures - Si vous avez suffisamment de RAM, cela vaudrait la peine d'augmenter key_buffer_size.
( Key_reads ) = 19,835,995 / 245130 = 81 /sec
- Taux de lecture (à partir du disque) de l'index MyISAM - Si vous avez suffisamment de RAM, cela vaudrait la peine d'augmenter key_buffer_size.
( Key_reads + Key_writes ) = (19835995 + 445704) / 245130 = 83 /sec
- Taux d'E/S d'index MyISAM - Si vous avez suffisamment de RAM, il serait utile d'augmenter key_buffer_size.
( Created_tmp_disk_tables ) = 1,260,364 / 245130 = 5.1 /sec
- Fréquence de création de tables disque "temp" dans le cadre de SELECT complexes - augmentez tmp_table_size et max_heap_table_size. Vérifiez les règles des tables temporaires lorsque MEMORY est utilisé à la place de MyISAM. Des modifications mineures de schéma ou de requête peuvent peut-être éviter MyISAM. De meilleurs index et une reformulation des requêtes sont plus susceptibles de vous aider.
( Created_tmp_disk_tables / Questions ) = 1,260,364 / 31058077 = 4.1%
- Nombre de requêtes nécessitant une table tmp sur disque. - De meilleurs index/aucun blobs/etc.
( Com_delete / Com_insert ) = 62,986 / 50111 = 125.7%
- Supprime/insère (comme un PC). (Ignore CHARGER, REMPLACER, etc.)
( Select_scan ) = 1,928,326 / 245130 = 7.9 /sec
- analyses complètes des tables - Ajouter des index/optimiser les requêtes (sauf s'il s'agit de petites tables)
( Select_scan / Com_select ) = 1,928,326 / 30171997 = 6.4%
-% de sélections effectuant une analyse complète de la table. (Peut être trompé par les routines stockées.) - Ajouter des index/optimiser les requêtes
( back_log / max_connections ) = 90 / 200 = 45.0%
Anormalement grand:
Com_show_profile = 0.044 /HR
Select_full_range_join = 61,564
Select_range / Com_select = 23.8%
join_buffer_size = 140MB
Flush_commands = 0.19 /HR
Taux par seconde = RPS Suggestions supplémentaires à considérer pour votre section my.cnf [mysqld]
max_heap_table_size=48M # from 32M for additional capacity
tmp_table_size=48M # from 32M to reduce created_tmp_disk_tables count
innodb_io_capacity=1600 # from 200 to allow more IOPS
read_rnd_buffer_size=192K # from 256K to reduce handler_read_rnd_next RPS
sort_buffer_size=2M # from 256K to reduce sort_merge_passes count
Pour d'autres personnes (pas cet OP car il utilise des tables MyISAM), dans MySQL 5.7, en supposant que vous utilisez principalement des tables INNODB, vous pouvez voir la quantité de mémoire actuellement utilisée en exécutant cette requête:
SHOW ENGINE INNODB STATUS
Vous pouvez voir la quantité maximale de mémoire dont votre instance pourrait avoir besoin pour la mise en mémoire tampon UNIQUEMENT en exécutant cette requête:
SELECT ( @@key_buffer_size
+ @@query_cache_size
+ @@innodb_buffer_pool_size
+ @@innodb_log_buffer_size
+ @@max_allowed_packet
+ @@max_connections * (
@@read_buffer_size
+ @@read_rnd_buffer_size
+ @@sort_buffer_size
+ @@join_buffer_size
+ @@binlog_cache_size
+ @@net_buffer_length
+ @@net_buffer_length
+ @@thread_stack
+ @@tmp_table_size )
) / (1024 * 1024 * 1024) AS MAX_MEMORY_GB;
Cette quantité maximale de mémoire est-elle supérieure à celle dont dispose votre serveur? Surtout dans AWS Aurora, cela entraînera un redémarrage régulier de votre base de données.
Ne définissez pas join_buffer_size, tmp_table_size, max_heap_table_size si haut. En supposant que vous ayez atteint les 200 max_connections, les requêtes dans le pire des cas pourraient utiliser (join_buffer_size + max (tmp_table_size, max_heap_size) + autres allocations) par connexion. C'est assez proche de votre limite de mémoire.
De grandes valeurs pour ces tampons ne sont pas toujours utiles.
Sur la base des "statistiques du moteur de stockage", il semble que vous ayez un VPS trop volumineux.
Basé sur les statistiques du moteur de stockage. La plupart de vos données reposent sur des tables basées sur MyISAM. Ce qui apparaît comme la partie problématique. Vous devez passer à InnoDB pour profiter du verrouillage au niveau des lignes et de meilleures performances. Si vous avez la majorité de la charge de travail en lecture, vous seul devez utiliser MyISAM, sinon passez à InnoDB en suivant les étapes suivantes:
Étape 1: sauvegardez votre base de données avant d'appliquer les modifications.
Étape 2: générer des requêtes alter pour toutes les tables dans MyISAM
SELECT CONCAT('ALTER TABLE ', TABLE_SCHEMA, '.', TABLE_NAME, ' engine=InnoDB;')
FROM information_schema.TABLES WHERE ENGINE = 'MyISAM'
AND TABLE_SCHEMA NOT IN ('mysql', 'sys');
Étape 3: Exécuter toutes les requêtes de modification reçues en sortie de l'étape 2
Si vous souhaitez continuer avec MyISAM. Vous devez modifier les éléments suivants
key_buffer_size = 256M innodb_buffer_pool_size = 6G
à
key_buffer_size = 512M innodb_buffer_pool_size = 3G