蚂蚁金服JVM Architect李三红 - Java企业应用-性能优化原则，方法与策略

2020-02-27 946浏览

  • 1.Java企业应用 -性能优化原则, 方法与策略 阿里巴巴 李三红
  • 2.自我介绍 • 2014年 加入蚂蚁金服，目前在阿里基础架构事业群，基础 软件部门： • 开发基于OpenJDK阿里定制版本：AJDK • 开发性能故障诊断工具： ZProfiler，ZDebugger，PIPA • 联系方式mail:sanhong.lsh@alibaba-inc.com 微博: sanhong_li
  • 3.Outline 1. Performance Basics and Methodology 2. Fundamentals of Performance Tuning • Profiling Driven Optimization • JVM Tuning • GC • JIT 3. Optimization Strategy for JavaEE 4. Recap
  • 4.Recall Little‘s law L = λ*W In queueing theory, the long-term average number of customers in a stable system, L，is equal to the long-term average arrival rate, λ, multiplied by the average time a customer spends in the system, Wsource:https://en.wikipedia.org/wiki/Little%27s_law
  • 5.Throughput and RT MeanNumberInSystem = MeanThroughput* MeanResponseTime  Throughput and RT are related  Decreasing RT ”almost always” improves Throughput  Throughput improving doesn’t necessarily mean RT decreasing  Performance tuning and cost saving  More higher throughput/lower RT but without adding new hardwaresource:https://en.wikipedia.org/wiki/Little%27s_law
  • 6.Approaches to Performance App AppServer Java VM Operating System Hardware Java’s view • Algorithm optimization • Profiling-driven • Upgrade (JDK&OS) • JVM(OS) Tuning • Specialization • Use new hardware • Use cheaper hardwareApproaches:a) Outside in approach(performance baseline) b) Layered approach(“Bottom up” or “Top down”) c) A hybrid of both a), b)
  • 7.Amdahl's Scaling Law Speedup = 1 ??????+1???−?????????F:is fraction of work that is serialN:is number of threadssource:https://en.wikipedia.org/wiki/Amdahl%27s_law• Reduce the amount of serial work performed
  • 8.Costs Reduce Scaling 1. Potential contributors toF: Synchronization(synchronized&j.u.c.Lock) • data structures need to be thread safe • communication overhead between threads  Infamous “stop the world” (aka STW) in JVM 2. Cost incurred when the N gets increased  Thread context switch  JConsole (MXBean)  Java Mission Control  JProfiler  HealthCenter&jucProfiler
  • 9.Profiling:Sampling vs Instrument sampling bar foo method call bar foo main main bar Instrument foo main AvailableTechnology:BCI, JVMTi, javax.management, System.currentTimeMillis()
  • 10.Sampling vs Instrument  Sampling  Lower overhead (determined by sampling interval)  Discover unknown code  Non intrusive  No execution path  Periodicity Bias  Instrument  Wall time (estimate IO time)  Full execution path  Configuration on what methods to instrument  Generally more data to be collected
  • 11.Safepoint Bias  Stack trace sampling happens only when the given thread at a safepoint  The hot loop may not get profiled anymore  Use following tools instead  Java Mission Control  Honest Profiler(githup)  ZProfiler(alipay internal profiling tool)
  • 12.Tools for Diagnostics • Most of them could be found in JAVA_HOEM/bin • Goodreference:Troubleshooting Guide for JavaSE 6 with HotSpotVM
  • 13.Basics of JVM Tuning
  • 14.Guild for GC Tuning • Select the right GC algorithm • parallel old ,CMS and G1 collector • Rule ofthumb:GC overhead is ideally < 10% • Choose the right heap sizesource:Charlie Hunt, Binu John JavaTM performance • Configure the appropriate GG parameters
  • 15.JIT and common optimization • Important concepts • Profiler guided optimization(PGO) • Optimization decisions are made dynamically • Mix mode execution • Some common optimization • Inlining • Intrinsic • Monomorphic dispatch •…  Liskov substitution principle Subtypes MUST be substitutable for their base types
  • 16.JIT Profiling with JITWatch •JITWatch:a graphical visualization and analysis tool for understanding the JIT Enabledby:-XX:+UnlockDiagnosticVMOptions-XX:+TraceClassLoading-XX:+LogCompilation-XX:+PrintAssembly
  • 17.Typical distributed JEE architecture Java EE Container Java EE Application REST Service via HTTP System A cloud Remote Bean via RMI DB via JDBC System B cloud System C cloud
  • 18.The problem…  Add communication cost  RPC  serialization/deserialization  Can not shift resources towards demand  Can not share the underlying Java artifacts(such as JIT)
  • 19.Multitenancy for JavaEE App AppServer Java VM Operating System Hardware App1 App2 App3 Appx AppServer Java VM Operating System Hardware  Run multiple Java EE applications (as tenants) into same Java EE container
  • 20.High Density Cloud for JavaEE The JavaEE applications developed separately can be deployed seamlessly into the same container. • devOps  Orchestrate JavaEE application at scale • Infrastructure  ‘Multi-tenant’ JavaEE container  ‘Virtualized’ JVMsource:https://www.dreamstime.com
  • 21.Tomcat/JDK extended for PaaS •AliTomcat:run multiple apps side-by-side safely • AJDK allows for collocation of multiple JEE App1 App2 App3 Appx AliTomcat(Multi-tenant) PaaS apps(as tenant) in a single instance ofJVM:AJDK(Virtualized) • Isolate application from one another. • Share metadata aggressively and OS transparently, suchas:Hardware  bytecodes of methods  GC  JIT : Alibaba/Alipay JDK, based on OpenJDK
  • 22.AAE:Alibaba Application Engine • Scaling tenant application with AAE • spread application evenly across hosts • but pack applications on the single JVM as mush as possible, based on its resourcecapacity:• CPU usage • Memory(monitoring GC) AAE DC-1 DC-2 e c bd aa g F a AB AB
  • 23.Benefits CPU 100% (100* 30% + 100*70% ) /200 = 50% 50% AB A+B
  • 24.Benefits(Cont.) • Eliminate the unnecessary RPC • Minimize the cost caused by object serialization/de- serialization • Share underlying Java artifacts as much as possible • GC • JIT • Heap
  • 25.Compared with Docker D CPU AB C Mem OS Hardware CPU overcommit via docker D CPU C B A Mem OS Hardware ‘shared memory’ via Multitenancy
  • 26.Summary • What wecovered:• Performance basics& methodology • Performance tuning • Profiling • Tuning from JVM perspective • Multitenancy for JavaEE
  • 27.reach tome:mail:sanhong.lsh@alibaba-inc.comweibo:sanhong_li