1 votes

La mise à jour Ubuntu 20.04 a détruit les performances des applications Java/Mysql

Je travaille sur une application Java / MySQL et les tests de traitement par lots prenaient 3 à 4 secondes sur Ubuntu 18.04.

J'ai fait la mise à jour vers Ubuntu 20.04 la nuit dernière, et j'ai gardé le même fichier de conf mysql, et maintenant la même application prend 1min et 45-47 secondes !!!

6.27user 0.41system 1:45.53elapsed 6%CPU (0avgtext+0avgdata 168724maxresident)k
0inputs+384outputs (0major+42056minor)pagefaults 0swaps

J'ai remarqué avec lscpu que le serveur fonctionne maintenant en fréquence minimale en moyenne. J'ai essayé d'ajouter "acpi=ht" à /etc/default/Grub, et j'ai redémarré la machine, pour désactiver la gestion de l'énergie mais les processeurs fonctionnent toujours à basse fréquence et l'augmentation de fréquence ne fonctionne probablement pas.

On-line CPU(s) list:             0-15
Thread(s) per core:              2
Core(s) per socket:              4
Socket(s):                       2
NUMA node(s):                    2
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           44
Model name:                      Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz
Stepping:                        2
Frequency boost:                 enabled
CPU MHz:                         1599.592
CPU max MHz:                     2401.0000
CPU min MHz:                     1600.0000
BogoMIPS:                        4799.75
Virtualization:                  VT-x
L1d cache:                       256 KiB
L1i cache:                       256 KiB
L2 cache:                        2 MiB
L3 cache:                        24 MiB

En utilisant mysqltuner pour vérifier les métriques InnoDB du serveur, les choses semblent correctes, il semble donc que le problème soit lié aux paramètres du CPU.

-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 8
[OK] InnoDB File per table is activated
[OK] InnoDB buffer pool / data size: 9.0G/2.6G
[OK] Ratio InnoDB log file size / InnoDB Buffer pool size: 1.0G * 2/9.0G should be equal 25%
[OK] InnoDB buffer pool instances: 9
[--] Number of InnoDB Buffer Pool Chunk : 72 for 9 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: 99.90% (2901594 hits/ 2904524 total)
[!!] InnoDB Write Log efficiency: 75.47% (19033 hits/ 25219 total)
[OK] InnoDB log waits: 0.00% (0 waits / 6186 writes)

L'exécution de top pendant que l'application est en cours d'exécution montre que Java n'utilise que <1% du processeur après le démarrage.

   2113 mysql     20   0   25.7g   2.7g  36264 S   4.3  11.6   0:12.35 mysqld
    353 root      20   0       0      0      0 S   2.7   0.0   0:02.99 md0_raid5
    244 root       0 -20       0      0      0 I   0.7   0.0   0:00.98 kworker/10:1H-kblockd
    248 root       0 -20       0      0      0 I   0.7   0.0   0:00.07 kworker/8:1H-kblockd
    399 root      20   0       0      0      0 D   0.7   0.0   0:00.61 jbd2/md0-8
   2372 bias      20   0 5597164 180592  27784 S   0.7   0.7   0:07.54 java

En mode stress, j'obtiens une utilisation complète du processeur

   4654 user      20   0    3856    100      0 R 100.0   0.0   0:13.88 stress
   4643 user      20   0    3856    100      0 R 100.0   0.0   0:13.82 stress
   4645 user      20   0  134932   3272    272 R 100.0   0.0   0:13.84 stress
   4646 user      20   0    3856    100      0 R 100.0   0.0   0:13.80 stress

Existe-t-il un moyen simple de forcer l'OS à utiliser la vitesse maximale du CPU (ou de tester le turbo boost) ? Ou de revenir à la version 18.04 ? Y a-t-il des problèmes connus avec la version 20.04 et mysql ou java ?

1 votes

Si l'impression du haut est faite pendant que l'application fonctionne, alors il est clair que l'horloge du CPU ne change pas parce que vous êtes ne pas utiliser substantiellement l'unité centrale (vous pouvez prouver que cela fonctionne en utilisant des utilitaires tels que stress pour créer une charge artificielle).

0 votes

@anx en exécutant le stress il utilise 100% cpu sans problème donc il semble que c'est un problème avec java / mysql.

2voto

bias Points 225

Le comportement par défaut du pilote MySQL JDBC a apparemment changé lors de la mise à jour du système d'exploitation.

Le pilote précédent a désactivé les transactions automatiques commits pour les mises à jour Java batch - ajout/exécution manuelle. setAutoCommit(false) sur la connexion de données a ramené le temps d'exécution à la normale (apparemment, il s'agissait de transactions atomiques pour 1000 insertions).

C'est un bon exemple de la raison pour laquelle les gens devraient coder de manière défensive et ajouter du code intentionnel même si le comportement/la configuration par défaut est ce qui est utilisé dans le code - le défaut peut et va changer !

https://coderanch.com/t/299833/databases/Batch-update-setAutoCommit-false

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X