Télécharger en tant que PDF, PPTX
![#backdaybyxebia
JMH
public class JMHSample_03_States {
@State(Scope.Thread)
public static class ThreadState {
volatile double x = Math.PI;
}
@Benchmark
public void measureUnshared(ThreadState state) {
state.x++;
}
public static void main(String[] args) throws RunnerException {
Options opt = new OptionsBuilder()
.include(JMHSample_03_States.class.getSimpleName())
.warmupIterations(5)
.measurementIterations(5)
.threads(4)
.forks(1)
.build();
new Runner(opt).run();
}
}
APP](https://image.slidesharecdn.com/backday-xebia-chercher-performance-150605075804-lva1-app6891/85/Backday-xebia-Chercher-la-performance-efficacement-66-320.jpg)
Téléchargé parPublicis Sapient Engineering
Backday xebia - Chercher la performance efficacement
Le document traite de l'optimisation de la performance des applications Java, en abordant des concepts clés tels que les tests de performance, l'utilisation efficace de la mémoire et les stratégies de garbage collection. Il met en lumière les problèmes fréquents rencontrés dans les applications, notamment la mauvaise utilisation des collections et l'absence de cache, tout en proposant des conseils pratiques pour améliorer la performance. Plusieurs outils et techniques, tels que JMX, Gatling et VisualVM, sont recommandés pour diagnostiquer et optimiser les performances.
Backday xebia - Chercher la performance efficacement
- 1. #backdaybyxebia William Montaz -Jean-Pascal Thiery Construire le SI de demain Chercher la performance efficace
- 2. #backdaybyxebia#perfEfficace @willymontaz @jpthiery Laperformance, c’est quoi ? « Mon Application, elle poutre ! » « Il faut moins de 2 heures à mon batch pour s`exécuter.» « Mon algorithme utilise moins de 10% du CPU.» - Ensemble de données chiffrables - Des niveaux de tolérance qui dépendent du type de traitement.
- 3. #backdaybyxebia#perfEfficace @willymontaz @jpthiery Laperformance, pourquoi ? Make it work Make it right Make it fast
- 4. #backdaybyxebia#perfEfficace @willymontaz @jpthiery Laperformance, quand ? Tests de performance Production Cycle de développement
- 5. #backdaybyxebia#perfEfficace @willymontaz @jpthiery Laperformance, comment ? L’environnement :
- 6. #backdaybyxebia#perfEfficace @willymontaz @jpthiery Laperformance, comment ? L’environnement, les extras : JMX
- 7. #backdaybyxebia#perfEfficace @willymontaz @jpthiery Injecteurs Graphite Gatling Gatling Gatling Laperformance, comment ? Jenkins Jenkins Slave Jenkins Slave Jenkins Slave Entrypoint AppA Grafana Report Gatling
- 8.
- 9. #backdaybyxebia BIG THANKS Kodewerk, KirkPepperdine Java Performance Tuning
- 10.
- 11. #backdaybyxebia OS JVM Application Actors J’utilise bien monOS ? - CPU - Mémoire - IO
- 12. #backdaybyxebia OS JVM Application Actors J’utilise bien maJVM ? - Optimisation de bytecode - Gestion de la mémoire
- 13. #backdaybyxebia OS JVM Application Actors Mon application est-elleefficace ? - Architecture - Algorithmes
- 14. #backdaybyxebia OS JVM Application Actors Mon application est-ellebien utilisée ? - Utilisation de l’application par des éléments extérieurs (utilisateurs, applications tierces, batchs, etc…)
- 15.
- 16.
- 17.
- 18.
- 19.
- 20. #backdaybyxebia CS -> 80000 cycles, 6000CS pour 2GHZ -> 24% context switching Context Switch Context Switch Context Switch OS Syscall
- 21.
- 22. #backdaybyxebia context switch ? Scheduling Locking I/O Syscall OS +10%CPU Kernel space -> Problème
- 23. #backdaybyxebia Dead lock Problème d’I/O: Disque, Network, Système externe Scheduling CPU par l’hyperviseur Problème de scheduling OS Je n’utilise pas 100% du CPU OS
- 24.
- 25.
- 26.
- 27.
- 28. #backdaybyxebia JIT Compiler =>10 000 appels (CompileThreshold) JVM
- 29.
- 30. #backdaybyxebia Huge Methods =>8k bytecode, pas de compilation ! JVM
- 31.
- 32. #backdaybyxebia Inlining: auto si <35 bytes bytecode 325 bytes pour les « Hot Methods » JVM https://github.com/AdoptOpenJDK/jitwatch/wiki/JarScan
- 33. #backdaybyxebia Call Stack &Récursivité JVM
- 34.
- 35. #backdaybyxebia Coût de créationdes objets JVM
- 36. #backdaybyxebia Coût de créationdes objets Exemple : Object foo = cache.get(val1 + ‘’-‘’ + val2) JVM
- 37. #backdaybyxebia Coût de créationdes objets Exemple : Object foo = cache.get(val1 + ‘’-‘’ + val2) Object foo = cache.get(new Key(val1, val2)) JVM NB: en java 8, la concaténation de string est optimisée par le compilateur
- 38.
- 39.
- 40.
- 41.
- 42.
- 43. #backdaybyxebia Hypothèse générationnelle Beaucoup d’objetssont transients Seulement quelques objets ont une longue durée de vie JVM
- 44.
- 45.
- 46.
- 47.
- 48. #backdaybyxebia Promotion • Tenuring Threshold •Survivor plein JVM
- 49.
- 50. #backdaybyxebia GC Roots ? stackframes JVM
- 51. #backdaybyxebia GC Roots ? stackframes References JNI JVM
- 52. #backdaybyxebia GC Roots ? stackframes References JNI Class loaders JVM
- 53. #backdaybyxebia GC Roots ? stackframes References JNI Class loaders Objets dans le Tenured Space ! JVM
- 54. #backdaybyxebia GC Young Generation SerialCollector ParallelGC +Efficace si beaucoup d’objets morts - Stop-of-the world JVM
- 55. #backdaybyxebia GC Old Generation Serial(-XX:+UseParallelGC) Parallel (-XX:+UseParallelOldGC par défaut sur Java 7u4) + Pas d’overhead + Compaction de la heap - Stop-of-the-world Concurrent Mark-and-Sweep (CMS -XX:+UseConcMarkSweepGC) + (Presque) pas stop-of-the-world - Overhead CPU (10-40%) - Fragmentation !! Peut déclencher des FullGC JVM
- 56. #backdaybyxebia Combinaison des GC uinti = 0; if (UseSerialGC) i++; if (UseConcMarkSweepGC || UseParNewGC) i++; if (UseParallelGC || UseParallelOldGC) i++; if (UseG1GC) i++; if (i > 1) { jio_fprintf(defaultStream::error_stream(), "Conflicting collector combinations in option list; " "please refer to the release notes for the combinations " "allowedn"); status = false; } JVM
- 57. #backdaybyxebia Log GC Beaucoup d’infos Exploitablesdirectement dans des outils dédiés GCViewer Censum -verbose:gc -XX:+PrintGCDetails -XX:+PrintTenuringDistribution -Xloggc:filename JVM
- 58.
- 59. #backdaybyxebia Memory Leak HEAP DUMP-> Memory Analysis Tool JVM
- 60. #backdaybyxebia JIT Friendly Chauffer laJVM Eviter les changements de class loaders Choisir un GC adapté (throughput vs disponibilité) Aider le GC si besoin (référence null) Dimensionner correctement les pools Notamment les survivors ! Utilisez les log GC JVM Ajout suite à la présentation -> Essayer de passer en Java 8 +15% de performances Utilisation du GC G1 qui peut résoudre d’un coup beaucoup de problèmes de GC
- 61.
- 62.
- 63. #backdaybyxebia Detecter les problèmesde lock THREAD DUMP ! APP
- 64. #backdaybyxebia Detecter les problèmesd’architecture/d’algorithme Utiliser un profiler VisualVM JProfiler Faire des benchmarks Pas d’instrumentation Reflet de la réalité (caches CPU, TLB, paging, …) APP
- 65. #backdaybyxebia Le benchmarking, c’esttrès dur !! Optimisations JIT Chauffe de la JVM Profile-guided optims Loop unrolling, Dead code False sharing Déclenchement de GC Synchronisation des threads Variance APP
- 66. #backdaybyxebia JMH public class JMHSample_03_States{ @State(Scope.Thread) public static class ThreadState { volatile double x = Math.PI; } @Benchmark public void measureUnshared(ThreadState state) { state.x++; } public static void main(String[] args) throws RunnerException { Options opt = new OptionsBuilder() .include(JMHSample_03_States.class.getSimpleName()) .warmupIterations(5) .measurementIterations(5) .threads(4) .forks(1) .build(); new Runner(opt).run(); } } APP
- 67.
- 68. #backdaybyxebia Problèmes fréquents Pas decache Mauvaise utilisation des collections Mauvaise implémentation : ConcurrentHashMap ConcurrencyLevel (LockStriping/Segment jdk < 1.8) Lock ConcurrentSkipListMap LockFree Pas de sizing initial APP
- 69. #backdaybyxebia Problèmes fréquents Pas decache Mauvaise utilisation des collections Mauvaise implémentation : ConcurrentHashMap ConcurrencyLevel (LockStriping/Segment jdk < 1.8) Lock ConcurrentSkipListMap LockFree Pas de sizing initial Logs Trop de logs Trop de processing Date -> timestamp APP
- 70. #backdaybyxebia Problèmes fréquents Pas decache Mauvaise utilisation des collections Mauvaise implémentation : ConcurrentHashMap ConcurrencyLevel (LockStriping/Segment jdk < 1.8) Lock ConcurrentSkipListMap LockFree Pas de sizing initial Logs Trop de logs Trop de processing Date -> timestamp Serialisation APP
- 71. #backdaybyxebia Problèmes fréquents Pas decache Mauvaise utilisation des collections Mauvaise implémentation : ConcurrentHashMap ConcurrencyLevel (LockStriping/Segment jdk < 1.8) Lock ConcurrentSkipListMap LockFree Pas de sizing initial Logs Trop de logs Trop de processing Date -> timestamp Serialisation Pool sous/sur-dimensionné Circuit breaker APP
- 72. #backdaybyxebia Pratiques Low Level: NIO epoll FileChannels AlgosLockFree Volatile, Compare And Swap Affinité de cache L1: 32KB 1ns (4 c), L2: 256KB 3-4ns (12 c), L3: plusieurs MB (30c) 12-15ns, RAM 70-100ns Memory Acces Patterns : affinité temporelle, affinité spaciale, predictible Translation Lookaside Buffers (TLB) Virtual Pages -> Physical pages in page table TLB -> cache local pour éviter le parcours de la « page table » Utiliser les Huge Pages (4MB) -> plus d’adresses mémoire dans les TLB APP
- 73.