SlideShare uma empresa Scribd logo
1 de 49
Baixar para ler offline
1
<Insert Picture Here>




Java Platform Performance BoF
Sergey Kuksenko, Aleksey Shipilev
О чём у нас
• Отвечаем на вопросы по Java Performance
   – В основном, предварительно собранные в разных местах Рунета
   – Есть возможность задать вопрос прямо здесь
      • Пишем на бумажке, передаём вперёд ;)
• Сначала вводные слова про:
   – Performance Engineering
   – Startup
   – JIT
   – Concurrency and synchronization
• Другие сессии:
   – “Искусное тестирование производительности (Java)”, завтра, 11-45
   – “Диагностика и настройка GC”, сегодня, только что закончилось
   – “JDK7”, параллельно с нами

                                                                        3
Performance
Engineering




              4
Performance Engineering
абстрактно и отлично об отличиях в абстракциях
• Computer Science → Software Engineering
   – Строим приложения по функциональным требованиям
   – В большой степени абстрактно, в “идеальном мире”
      • Теоретически неограниченная свобода – искусство!
      • Можно строить воздушные зАмки
   – Рассуждения при помощи формальных методов
• Software Performance Engineering
   – “Real world strikes back!”
   – Исследуем взаимодействие софта с железом на типичных данных
      • Производительность уже нельзя оценить
      • Производительность можно только измерить
   – Естественно-научные методы



                                                                   5
Performance Engineering
первый шаг

• Классические ошибки первого шага
  – “я вижу, что метод foo() реализован неэффективно”
  – “по профилю видно, что метод bar() – самый горячий и занимает 5%”
  – “по-моему, у нас тормозит БД, и необходимо перейти с DBX на DBY”
• Правильный первый шаг:
  – Необходимо выбрать метрику
     • ops/sec, transactions/sec
     • время исполнения
     • время отклика
  – Убедиться в корректности метрики
     • релевантна (учитывает реальный сценарий работы приложения)
     • повторяема
                       ЦЕЛЬ → улучшение метрики!

                                                                        6
Performance Engineering
анализ узких мест (tips)
• Низкая утилизация CPU
   – Высокая дисковая, сетевая активность
   – Конфликт блокировок
   – Конфликт ресурсов ОС
   – Слабая параллелизация приложения
• Высокая утилизация ядра ОС
   – Частые блокировки
   – Частое обращение к ОС
• Высокая утилизация CPU
   – Неоптимальная архитектура приложения
   – Неправильное использование API
   – Неоптимизированные горячие методы
   – Неоптимальные настройки GC


                                            7
Performance Engineering
инструменты для анализа системы

            Solaris               Linux             Windows   Что смотрим
    Сеть    netstat, dtrace       netstat           perfmon   количество
                                                              соединений, объем
                                                              трафика
    Диск    iostat, dtrace        iostat            perfmon   количество
                                                              обращений к диску,
                                                              задержка
   Память   vmstat, prstat,       vmstat, top       perfmon   подкачка страниц,
            dtrace                                            размер памяти

 Процессы   ps, vmstat, mpstat,   ps, vmstat, top   perfmon   количество нитей,
            prstat, dtrace                                    состояние нитей,
                                                              переключения
                                                              контекста
  Ядро ОС   mpstat, lockstat,     vmstat            perfmon   kernel time,
            plockstat, dtrace,                                блокировки,
            intrstat, vmstat                                  системные вызовы,
                                                              прерывания ...


                                                                                   8
Performance Engineering
tools, tools, tools again, more tools
• VisualVM
   –   http://visualvm.dev.java.net

• JRockit Mission Control
   –   http://www.oracle.com/technetwork/middleware/jrockit/mission-control/index.html

• Sun Studio Analyzer
   –   http://www.oracle.com/technetwork/server-storage/solarisstudio/overview/index.html

• DTrace
   –   http://www.oracle.com/technetwork/systems/dtrace/dtrace/index.html

• Ещё могут быть полезны:
   –   JProbe
   –   OptimizeIt
   –   YourKit




                                                                                            9
JVM tuning
настройка параметров JVM

• Что настраивать?
   –   http://blogs.sun.com/watt/resource/jvm-options-list.html
   –   http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html




                                                                                      10
JVM tuning
настройка параметров JVM


• JVM сама подбирает оптимальные параметры своей работы
  – Server vs. Client
  – Large pages (Solaris)
  – CompressedOops (64-bit VM)
• Так что же настраивать?
  – GC/Heap tuning
  – -XX:+UseNUMA (Solaris, Linux)
  – -XX+:UseLargePages (Linux, Windows)
     • http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html

• Не забыть
  – Использовать последнюю версию JDK


                                                                                        11
Startup




          12
Startup
как измерять?




                13
Startup
как измерять?




                До входа в main()?



                                     14
Startup
как измерять?




                До первого ответа от приложения?



                                                   15
Startup
как измерять?




                До “стабильного состояния”?



                                              16
Startup
как измерять?




                Время на пуск-остановку?

                                           17
Startup
Eclipse
• Типичная конфигурация:
   – 2x2 Intel i5 2.6 Ghz, Ubuntu 10.10 i686, JDK 6u25
   – Eclipse JDT (Galileo)


• Типичные метрики:
   – 6.000 загруженных классов
   – 1.000 методов скомпилировано
   – 512 Mb зарезервированного пространства в куче
   – 25 Mb кучи использовано после стартапа


• Известные “проблемы”:
   – Загрузка и верификация классов
   – JIT-компиляция


                                                         18
Startup
Eclipse
• Метрика: секунд на запуск-завершение
   – Файловые кеши прогреты, практически нулевой дисковый I/O

                       default               CDS                CDS + no-verify

   абсолютное
     время            5.83                 4.81                    4.61
                     [5.74; 5.92]         [4.73; 4.84]            [4.56; 4.74]

     загрузка
     классов          5.01                 3.39                    3.01
                     [4.91; 5.11]         [3.12; 3.66]            [2.94; 3.08]

   компиляция
                      0.51                 0.51                    0.51
                     [0.43; 0.59]         [0.44; 0.58]            [0.42; 0.60]




                                                                                  19
Startup
длинные приложения
• Важно только для коротких приложений
   – Чем дольше работает приложение, тем меньше удельные затраты на загрузку
     классов и компиляцию
• Пример: 8 часа работает IntelliJ IDEA 10.x:
   – 26.600 классов загружено
   – 5315 методов скомпилировано
   – Загрузка классов:
       • Всего потрачено 202 с., ~0.7% общего времени
       • 10 мсек на класс
   – Компиляция:
      • Всего потрачено 112 с., ~0.03% общего времени
       • 20 мсек на метод




                                                                               20
Concurrency




              21
Concurrency
общие соображения

• Только мы научились программировать, новая беда
  – Новое входное данное в программе: время
  – Подавляющее большинство concurrency-багов – гейзен-баги!
     • TDD “отдыхает”
• • Читаем хорошие книги
  – “Учиться, учиться и ещё раз учиться” (с)
  – “Java Concurrency in Practice”
  – “The Art Of Multiprocessor Programming”
  – “JSR 133 Cookbook”
  – “A Little Book of Semaphores”
• Пользуемся высокоуровневыми примитивами
  – java.util.concurrent.*
  – ... или другими, построенными на их основе


                                                               22
JIT




      23
JIT
факты
• … есть
• … работает
• … работает хорошо
• … знает о железе всё:
  – Количество и тип CPU, поддерживаемые инcтрукции (SSEx, AVX, VIS)
  – Топологию памяти (в т.ч. размеры кэшей и их характеристики)
• … знает о приложении много всего:
  – Иерархию загруженных классов
  – Актуальную статистику создания объектов
  – Горячий код
  – Какие ветвления исполнялись, какие значения использовались
• … не боится использовать эти знания для компиляции



                                                                       24
JIT
оптимизации




              25
JIT
    performance urban legends
                                               final дает лучшую
                                              производительность
        копируйте поля в
     локальные переменные!
                                    Reflection –         volatile запрещает JIT
                                      дорого            оптимизировать доступ
                                                                  к полю
 вызов виртуального
   метода - дорого                 избегайте get/set                 вручную вылизанный метод
                                    методов внутри                    лучше аналога из classlib
                                     самого класса
immutable классы –
      плохо                                                              вручную выполненый
                         native методы дорогие, System.arraycopy()          inline – хорошо
                                    нативный – значит ...

  Java медленна потому, что нельзя вручную                создание объектов дорого –
    выключить проверку выхода индекса за                   используйте Object pooling
              границы массива


                                                                                                  26
JIT
как писать код
• Используйте стандартные библиотеки
   – Зачем писать собственный стандартный контейнер?
• Используйте высокоуровневый API:
   – java.util.*, java.util.concurrent.*, NIO, NIO.2
   – вообще библиотеки
• Код должен правильным и понятным
   – Сначала правильно, потом алгоритмически “быстро”
   – Код не должен быть JIT-oriented
• Правильно используйте возможности языка
   – EPIC FAIL: штатная передача управления exception'ами
   – FAIL: Возврат “исключения” через return <код_ошибки>
   – FAIL: int вместо Enum или boolean




                                                            27
JIT
для любопытных


• Как получить ассемблерный код метода?

      • Обычным дебаггером ;)


      • JVMTI


      • -XX:+PrintAssembly
        – http://wikis.sun.com/display/HotSpotInternals/PrintAssembly




                                                                        28
Q/A




      29
<Insert Picture Here>




Appendix




                             30
Reflection
вопрос из зала


• Сравнение вызова reflection vs. cglib
   – raw:                                         59044.74 ± 8212.66
   – сglib:                                       1530.23 ± 41.04
   – cglib (cache args):                          2175.41 ± 114.74
   – reflection                                   45.19 ± 1.07
   – reflection (accessible = true):              1276.77 ± 14.46
   – reflection (accessible = true) (cache args): 1758.70 ± 72.03
• MethodHandle увеличит производительность ещё сильнее




                                                                       31
Performance Engineering
итеративный подход

                                          Измерения
                                          (эксперименты)


                 Разработка                                Сбор и обработка данных
Старт         (кодирование решений)                          (профилировка, статистика)



                    Поиск решений
                                                           Анализ узких мест
                     (прототипирование)



 Важно:
 –Одно изменение за цикл!
 –Документировать все изменения


                                                                                          32
Performance Engineering
анализ узких мест




     •Что ограничивает скорость работы приложения?
       – CPU
       – Ядро ОС
       – I/O (Сеть, Диск)




                                                     33
Performance Engineering
”нисходящий” метод поиска узких мест
          • Уровень системы
             –   Сеть
             –   Диск
             –   Database
             –   Операционная система
             –   Процессор/память
          • Уровень приложения
             –   Блокировки, синхронизация
             –   Execution Threads
             –   API
             –   Алгоритмические проблемы
          • Уровень JVM
             –   Выбор JVM
             –   Heap tuning
             –   JVM tuning



                                             34
Java 7, Java 8
что ожидать в области производительности


• Java 7
   – invokedynamic
   – NIO.2
   – Concurrency and Collection updates (Fork/Join)
   – XRender pipeline for Java2D (client)


• Java 8 (или позже)
   – Модульность
   – λ-выражения (замыкания)
   – Collection updates (filter, map, reduce)




                                                      35
Обратная совместимость


• Мешает ли улучшать производительность JVM?
  – Да, поэтому иногда расширяемся:
     • invokedynamic
     • Модульность


• Стоит ли расширяться по первому требованию?
  – Нет, развитие JVM/JIT, реализация новых методов оптимизации
    позволяет получить бОльший выигрыш
     • Вложенные классы
     • Reflection



                                                                  36
Лучшая ОС для Java
угадайте, какая?


                                    Solaris
• Высокопроизводительный TCP/IP стек
   – low-latency
   – up to 50% faster
• DTrace
   – мониторинг
• NUMA
   – MPO, Memory Placement Optimization
• Large Pages
   – Автоматическая аллокация
   – Разные размеры



                                              37
Concurrency
элементная база

• OS Threading
  – мьютексы
     • mutex_lock()/mutex_unlock()
  – conditional waits
     • cond_wait()/cond_signal()
     • WaitForSingleObject

• Compare-and-Swap (CAS)
  – CAS(x1, x2, x3) = { if (x1 == x2) { x1 = x3 }; }
  – атомарная операция, поддерживаемая в “железе”: из нескольких одновременных
    CAS'ов успешно завершается только один
  – Миф: локальный CAS блокирует шину, и стоит больше на многопроцессорных
    системах
  – Факт: глобальный CAS требует трафика на шине



                                                                                 38
Concurrency
atomics
• java.util.concurrent.Atomic*
   – обеспечивают атомарные операции над примитивами и указателями
   – альтернатива: synchronized {} или Lock'и
• Трюк в использовании CAS'а:
   – Изменение состояния атомика делается при помощи одного CAS'а
   – Чтение состояния не требует CAS'а
                                                      mov    %ecx,%edx
          public final int incrementAndGet() {        mov    0x8(%ecx),%eax
              for (;;) {                              lea    0x8(%ecx),%edi
                  int current = get();                mov    %eax,%ecx
                  int next = current + 1;             inc    %ecx
                  if (compareAndSet(current, next))   lock cmpxchg %ecx,(%edi)
                      return next;                    mov    $0x0,%ebx
              }                                       jne    [ok]
          }                                           mov    $0x1,%ebx
                                                      test   %ebx,%ebx
                                                      je     [ok]

                                                                                 39
Concurrency
volatile
• Volatile определяет порядок чтения-записей в поле
   – НЕ обеспечивает атомарности
    – Реализуется расстановкой барьеров
       • Какие из них вставятся в код, зависит от Hardware Memory Model
           • Эффект барьера зависит от HMM
                    PUSHL   EBP
                    SUB     ESP,8             push   %ebp
                    MOV     EBX,[ECX + #12]   sub    $0x8,%esp
                    MEMBAR-acquire            mov    0xc(%ecx),%ebx
                    MEMBAR-release            inc    %ebx
                    INC     EBX               mov    %ebx,0xc(%ecx)
                    MOV     [ECX + #12],EBX   lock addl $0x0,(%esp)
                    MEMBAR-volatile           add    $0x8,%esp
                    LOCK ADDL [ESP + #0], 0   pop    %ebp
                    ADD     ESP,8             test   %eax,0xb779c000
                    POPL    EBP               ret
                    TEST    PollPage,EAX
                    RET
                                                                          40
Concurrency
intrinsic synchronization



• synchronized(object) { }, 4 состояния:
   – Init
        – Biased
           • Захватывается одним “владеющим” потоком, нет конфликтов
                 • Захват владельцем: проверка на threadID
                 • Захват не-владельцем: переход либо в Biased, либо в Thin
        – Thin
           • Захватывается несколькими потоками, но конфликтов нет
                 • Захват: CAS
                 • Конфликтный захват: переход в Fat
        – Fat
           • Захватывается несколькими потоками, конфликт на блокировке
                 • Вызов примитива синхронизации из ОС



                                                                              41
Concurrency
java.util.concurrent.Lock
• Построены на базе j.u.c.AbstractQueueSynchronizer
   – Использует CAS
   – Использует Unsafe.park()/unpark() → cond_wait()/cond_signal()/WaitForSingleObject()
• ReentrantLock
   – По семантике эквивалентен synchronized {}
   – Ставит потоки во внутреннюю очередь и делает park()
   – Non-Fair (default)
       • Не гарантирует отсутствие starvation, ибо barging FIFO (CAS)
       • Лучшая производительность
   – Fair
      • Гарантирует отсутствие starvation, FIFO
       • Честность в обмен на производительность




                                                                                           42
Concurrency
атомарный счётчик
                    private AtomicInteger atomic = new AtomicInteger();
                    private ReentrantLock lock = new ReentrantLock();
                    private final Object intrinsicLock = new Object();
                    private int primCounter = 0;


                    @GenerateMicroBenchmark
                    public void testAtomicInteger() {
                        atomic.incrementAndGet();
                    }


                    @GenerateMicroBenchmark
                    public void testReentrantLock() {
                        lock.lock();
                        primCounter++;
                        lock.unlock();
                    }


                    @GenerateMicroBenchmark
                    public void testIntrinsicLock() {
                        synchronized (intrinsicLock) {
                            primCounter++;
                        }
                    }



                                                                          43
Concurrency
атомарный счётчик




                    Intel Xeon (Westmere-EP), 3.0 Ghz, 2x6x2 = 24 HW threads, SLES 11 x86_64, JDK 6u25


                                                                                                         44
Concurrency
ReentrantLock vs. synchronized
• Семантика одинакова
   – Требования к видимости памяти
   – Рекурсивный
• Плюсы j.u.c.RL
   – Очередь потоков держится на стороне JVM
       • опционально, FIFO-политика при захвате-освобождении
       • позволяет быть “честным” на любой платформе
   – Barging FIFO policy
      • lock() может быть сразу удовлетворён, даже если в очереди есть потоки
       • сильно улучшает производительность при конфликте блокировок
   – Допускается несколько Condition
• Минусы j.u.c.RL
   – Нет scope'ов, требуется ручной unlock() через finally


                                                                                45
Concurrency
производительность захвата




                   Intel Xeon (Westmere-EP), 3.0 Ghz, 2x6x2 = 24 HW threads, SLES 11 x86_64, JDK 6u25


                                                                                                        46
47
The preceding is intended to outline our general product
direction. It is intended for information purposes only,
and may not be incorporated into any contract. It is
not a commitment to deliver any material, code, or
functionality, and should not be relied upon in making
purchasing decisions.
The development, release, and timing of any features
or functionality described for Oracle’s products remains
at the sole discretion of Oracle.


                                                           48
49

Mais conteúdo relacionado

Mais procurados

Лев Казаркин, Удивительные приключения регистров SSE или в поисках одного бага
Лев Казаркин, Удивительные приключения регистров SSE или в поисках одного багаЛев Казаркин, Удивительные приключения регистров SSE или в поисках одного бага
Лев Казаркин, Удивительные приключения регистров SSE или в поисках одного багаSergey Platonov
 
Владимир Алаев "Разработка на Node.js: инструменты, библиотеки, сервисы"
Владимир Алаев "Разработка на Node.js: инструменты, библиотеки, сервисы"Владимир Алаев "Разработка на Node.js: инструменты, библиотеки, сервисы"
Владимир Алаев "Разработка на Node.js: инструменты, библиотеки, сервисы"Yandex
 
Распределенные системы в Одноклассниках
Распределенные системы в ОдноклассникахРаспределенные системы в Одноклассниках
Распределенные системы в Одноклассникахodnoklassniki.ru
 
Mysql replication DevConf 2012
Mysql replication DevConf 2012Mysql replication DevConf 2012
Mysql replication DevConf 2012Alex Chistyakov
 
Dz Java Hi Load 0.4
Dz Java Hi Load 0.4Dz Java Hi Load 0.4
Dz Java Hi Load 0.4HighLoad2009
 
Операционные системы 2015, лекция № 1
Операционные системы 2015, лекция № 1Операционные системы 2015, лекция № 1
Операционные системы 2015, лекция № 1Aleksey Bragin
 
CUDA Course 2010 at MSU
CUDA Course 2010 at MSUCUDA Course 2010 at MSU
CUDA Course 2010 at MSUlarhat
 
Веб-сервер Phantom
Веб-сервер PhantomВеб-сервер Phantom
Веб-сервер Phantomyaevents
 
Практический опыт использования некоторых современных решений репликации MySQL
Практический опыт использования некоторых современных решений репликации MySQLПрактический опыт использования некоторых современных решений репликации MySQL
Практический опыт использования некоторых современных решений репликации MySQLAlex Chistyakov
 
Multithreading in JS. Myth or reality?
Multithreading in JS. Myth or reality?Multithreading in JS. Myth or reality?
Multithreading in JS. Myth or reality?Alexander Syrotenko
 
Операционные системы 2015, лекция № 4
Операционные системы 2015, лекция № 4Операционные системы 2015, лекция № 4
Операционные системы 2015, лекция № 4Aleksey Bragin
 
Операционные системы 2015, лекция № 5
Операционные системы 2015, лекция № 5Операционные системы 2015, лекция № 5
Операционные системы 2015, лекция № 5Aleksey Bragin
 
Сергей Житинский, Александр Чистяков (Git in Sky)
Сергей Житинский, Александр Чистяков (Git in Sky)Сергей Житинский, Александр Чистяков (Git in Sky)
Сергей Житинский, Александр Чистяков (Git in Sky)Ontico
 
Опыт применения виртуализации для web-систем часть 2
Опыт применения виртуализации для web-систем часть 2Опыт применения виртуализации для web-систем часть 2
Опыт применения виртуализации для web-систем часть 2Alex Chistyakov
 
ReactOS Tech Talk (ВМК МГУ, ИСП РАН)
ReactOS Tech Talk (ВМК МГУ, ИСП РАН)ReactOS Tech Talk (ВМК МГУ, ИСП РАН)
ReactOS Tech Talk (ВМК МГУ, ИСП РАН)Aleksey Bragin
 
Методы оптимизации вычислений на CPU
Методы оптимизации вычислений на CPUМетоды оптимизации вычислений на CPU
Методы оптимизации вычислений на CPUMSU GML VideoGroup
 
Производительность Unity3D: подводные камни / Алексей Чубарь (BIT.GAMES)
Производительность Unity3D: подводные камни / Алексей Чубарь (BIT.GAMES)Производительность Unity3D: подводные камни / Алексей Чубарь (BIT.GAMES)
Производительность Unity3D: подводные камни / Алексей Чубарь (BIT.GAMES)Ontico
 
Как сделать ваш JavaScript быстрее
Как сделать ваш JavaScript быстрееКак сделать ваш JavaScript быстрее
Как сделать ваш JavaScript быстрееRoman Dvornov
 
Как устроена MySQL-репликация, Андрей Аксенов (Sphinx)
Как устроена MySQL-репликация, Андрей Аксенов (Sphinx)Как устроена MySQL-репликация, Андрей Аксенов (Sphinx)
Как устроена MySQL-репликация, Андрей Аксенов (Sphinx)Ontico
 
Другая виртуализация
Другая виртуализацияДругая виртуализация
Другая виртуализацияYandex
 

Mais procurados (20)

Лев Казаркин, Удивительные приключения регистров SSE или в поисках одного бага
Лев Казаркин, Удивительные приключения регистров SSE или в поисках одного багаЛев Казаркин, Удивительные приключения регистров SSE или в поисках одного бага
Лев Казаркин, Удивительные приключения регистров SSE или в поисках одного бага
 
Владимир Алаев "Разработка на Node.js: инструменты, библиотеки, сервисы"
Владимир Алаев "Разработка на Node.js: инструменты, библиотеки, сервисы"Владимир Алаев "Разработка на Node.js: инструменты, библиотеки, сервисы"
Владимир Алаев "Разработка на Node.js: инструменты, библиотеки, сервисы"
 
Распределенные системы в Одноклассниках
Распределенные системы в ОдноклассникахРаспределенные системы в Одноклассниках
Распределенные системы в Одноклассниках
 
Mysql replication DevConf 2012
Mysql replication DevConf 2012Mysql replication DevConf 2012
Mysql replication DevConf 2012
 
Dz Java Hi Load 0.4
Dz Java Hi Load 0.4Dz Java Hi Load 0.4
Dz Java Hi Load 0.4
 
Операционные системы 2015, лекция № 1
Операционные системы 2015, лекция № 1Операционные системы 2015, лекция № 1
Операционные системы 2015, лекция № 1
 
CUDA Course 2010 at MSU
CUDA Course 2010 at MSUCUDA Course 2010 at MSU
CUDA Course 2010 at MSU
 
Веб-сервер Phantom
Веб-сервер PhantomВеб-сервер Phantom
Веб-сервер Phantom
 
Практический опыт использования некоторых современных решений репликации MySQL
Практический опыт использования некоторых современных решений репликации MySQLПрактический опыт использования некоторых современных решений репликации MySQL
Практический опыт использования некоторых современных решений репликации MySQL
 
Multithreading in JS. Myth or reality?
Multithreading in JS. Myth or reality?Multithreading in JS. Myth or reality?
Multithreading in JS. Myth or reality?
 
Операционные системы 2015, лекция № 4
Операционные системы 2015, лекция № 4Операционные системы 2015, лекция № 4
Операционные системы 2015, лекция № 4
 
Операционные системы 2015, лекция № 5
Операционные системы 2015, лекция № 5Операционные системы 2015, лекция № 5
Операционные системы 2015, лекция № 5
 
Сергей Житинский, Александр Чистяков (Git in Sky)
Сергей Житинский, Александр Чистяков (Git in Sky)Сергей Житинский, Александр Чистяков (Git in Sky)
Сергей Житинский, Александр Чистяков (Git in Sky)
 
Опыт применения виртуализации для web-систем часть 2
Опыт применения виртуализации для web-систем часть 2Опыт применения виртуализации для web-систем часть 2
Опыт применения виртуализации для web-систем часть 2
 
ReactOS Tech Talk (ВМК МГУ, ИСП РАН)
ReactOS Tech Talk (ВМК МГУ, ИСП РАН)ReactOS Tech Talk (ВМК МГУ, ИСП РАН)
ReactOS Tech Talk (ВМК МГУ, ИСП РАН)
 
Методы оптимизации вычислений на CPU
Методы оптимизации вычислений на CPUМетоды оптимизации вычислений на CPU
Методы оптимизации вычислений на CPU
 
Производительность Unity3D: подводные камни / Алексей Чубарь (BIT.GAMES)
Производительность Unity3D: подводные камни / Алексей Чубарь (BIT.GAMES)Производительность Unity3D: подводные камни / Алексей Чубарь (BIT.GAMES)
Производительность Unity3D: подводные камни / Алексей Чубарь (BIT.GAMES)
 
Как сделать ваш JavaScript быстрее
Как сделать ваш JavaScript быстрееКак сделать ваш JavaScript быстрее
Как сделать ваш JavaScript быстрее
 
Как устроена MySQL-репликация, Андрей Аксенов (Sphinx)
Как устроена MySQL-репликация, Андрей Аксенов (Sphinx)Как устроена MySQL-репликация, Андрей Аксенов (Sphinx)
Как устроена MySQL-репликация, Андрей Аксенов (Sphinx)
 
Другая виртуализация
Другая виртуализацияДругая виртуализация
Другая виртуализация
 

Semelhante a Java Platform Performance BoF

Оптимизация производительности нагруженных веб-систем на Java
Оптимизация производительности нагруженных веб-систем на JavaОптимизация производительности нагруженных веб-систем на Java
Оптимизация производительности нагруженных веб-систем на JavaAlex Chistyakov
 
SmartOS/Solaris app tuning tools/technologies on HL++ 2013
SmartOS/Solaris app tuning tools/technologies on HL++ 2013SmartOS/Solaris app tuning tools/technologies on HL++ 2013
SmartOS/Solaris app tuning tools/technologies on HL++ 2013Alex Chistyakov
 
Git in Sky presentation @ HighLoad++ 2013
Git in Sky presentation @ HighLoad++ 2013Git in Sky presentation @ HighLoad++ 2013
Git in Sky presentation @ HighLoad++ 2013Serguei Gitinsky
 
Игры с виртуализацией в JavaScript, или как я переписал эмулятор, Евгений Пот...
Игры с виртуализацией в JavaScript, или как я переписал эмулятор, Евгений Пот...Игры с виртуализацией в JavaScript, или как я переписал эмулятор, Евгений Пот...
Игры с виртуализацией в JavaScript, или как я переписал эмулятор, Евгений Пот...Ontico
 
Excelsior JET в действии
Excelsior JET в действииExcelsior JET в действии
Excelsior JET в действииNikita Lipsky
 
CodeFest 2012. Липский Н. — JIT vs. AOT. Единство и борьба динамического и ст...
CodeFest 2012. Липский Н. — JIT vs. AOT. Единство и борьба динамического и ст...CodeFest 2012. Липский Н. — JIT vs. AOT. Единство и борьба динамического и ст...
CodeFest 2012. Липский Н. — JIT vs. AOT. Единство и борьба динамического и ст...CodeFest
 
TMPA-2013 Sartakov: Genode
TMPA-2013 Sartakov: GenodeTMPA-2013 Sartakov: Genode
TMPA-2013 Sartakov: GenodeIosif Itkin
 
2014.12.23 Александр Андреев, Parallels
2014.12.23 Александр Андреев, Parallels2014.12.23 Александр Андреев, Parallels
2014.12.23 Александр Андреев, ParallelsNikolay Samokhvalov
 
How to cook a blockchain and not get burned
How to cook a blockchain and not get burned How to cook a blockchain and not get burned
How to cook a blockchain and not get burned Alexander Syrotenko
 
Java Ahead-Of-Time compilation
Java Ahead-Of-Time compilationJava Ahead-Of-Time compilation
Java Ahead-Of-Time compilationNikita Lipsky
 
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...Yandex
 
развертывание среды Rails (антон веснин, Locum Ru)
развертывание среды Rails (антон веснин, Locum Ru)развертывание среды Rails (антон веснин, Locum Ru)
развертывание среды Rails (антон веснин, Locum Ru)guest40e031
 
антон веснин Rails Application Servers
антон веснин Rails Application Serversантон веснин Rails Application Servers
антон веснин Rails Application Serversrit2010
 
Жизнь проекта на production
Жизнь проекта на productionЖизнь проекта на production
Жизнь проекта на productionNikolay Sivko
 
20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения ...
20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения ...20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения ...
20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения ...IT-Portfolio
 
Daemons In Web on #devrus
Daemons In Web on #devrusDaemons In Web on #devrus
Daemons In Web on #devrusAlex Chistyakov
 
PostgreSQL performance recipes
PostgreSQL performance recipesPostgreSQL performance recipes
PostgreSQL performance recipesAlexey Ermakov
 
IT-инфраструктура. FAQ для разработчика
IT-инфраструктура. FAQ для разработчикаIT-инфраструктура. FAQ для разработчика
IT-инфраструктура. FAQ для разработчикаMikhail Chinkov
 

Semelhante a Java Platform Performance BoF (20)

Оптимизация производительности нагруженных веб-систем на Java
Оптимизация производительности нагруженных веб-систем на JavaОптимизация производительности нагруженных веб-систем на Java
Оптимизация производительности нагруженных веб-систем на Java
 
SmartOS/Solaris app tuning tools/technologies on HL++ 2013
SmartOS/Solaris app tuning tools/technologies on HL++ 2013SmartOS/Solaris app tuning tools/technologies on HL++ 2013
SmartOS/Solaris app tuning tools/technologies on HL++ 2013
 
Git in Sky presentation @ HighLoad++ 2013
Git in Sky presentation @ HighLoad++ 2013Git in Sky presentation @ HighLoad++ 2013
Git in Sky presentation @ HighLoad++ 2013
 
Игры с виртуализацией в JavaScript, или как я переписал эмулятор, Евгений Пот...
Игры с виртуализацией в JavaScript, или как я переписал эмулятор, Евгений Пот...Игры с виртуализацией в JavaScript, или как я переписал эмулятор, Евгений Пот...
Игры с виртуализацией в JavaScript, или как я переписал эмулятор, Евгений Пот...
 
Excelsior JET в действии
Excelsior JET в действииExcelsior JET в действии
Excelsior JET в действии
 
CodeFest 2012. Липский Н. — JIT vs. AOT. Единство и борьба динамического и ст...
CodeFest 2012. Липский Н. — JIT vs. AOT. Единство и борьба динамического и ст...CodeFest 2012. Липский Н. — JIT vs. AOT. Единство и борьба динамического и ст...
CodeFest 2012. Липский Н. — JIT vs. AOT. Единство и борьба динамического и ст...
 
TMPA-2013 Sartakov: Genode
TMPA-2013 Sartakov: GenodeTMPA-2013 Sartakov: Genode
TMPA-2013 Sartakov: Genode
 
2014.12.23 Александр Андреев, Parallels
2014.12.23 Александр Андреев, Parallels2014.12.23 Александр Андреев, Parallels
2014.12.23 Александр Андреев, Parallels
 
How to cook a blockchain and not get burned
How to cook a blockchain and not get burned How to cook a blockchain and not get burned
How to cook a blockchain and not get burned
 
Java Ahead-Of-Time compilation
Java Ahead-Of-Time compilationJava Ahead-Of-Time compilation
Java Ahead-Of-Time compilation
 
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...
 
развертывание среды Rails (антон веснин, Locum Ru)
развертывание среды Rails (антон веснин, Locum Ru)развертывание среды Rails (антон веснин, Locum Ru)
развертывание среды Rails (антон веснин, Locum Ru)
 
антон веснин Rails Application Servers
антон веснин Rails Application Serversантон веснин Rails Application Servers
антон веснин Rails Application Servers
 
Жизнь проекта на production
Жизнь проекта на productionЖизнь проекта на production
Жизнь проекта на production
 
Sivko
SivkoSivko
Sivko
 
20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения ...
20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения ...20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения ...
20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения ...
 
Daemons In Web on #devrus
Daemons In Web on #devrusDaemons In Web on #devrus
Daemons In Web on #devrus
 
PostgreSQL performance recipes
PostgreSQL performance recipesPostgreSQL performance recipes
PostgreSQL performance recipes
 
IT-инфраструктура. FAQ для разработчика
IT-инфраструктура. FAQ для разработчикаIT-инфраструктура. FAQ для разработчика
IT-инфраструктура. FAQ для разработчика
 
Java Performance
Java PerformanceJava Performance
Java Performance
 

Mais de Dmitry Buzdin

How Payment Cards Really Work?
How Payment Cards Really Work?How Payment Cards Really Work?
How Payment Cards Really Work?Dmitry Buzdin
 
Как построить свой фреймворк для автотестов?
Как построить свой фреймворк для автотестов?Как построить свой фреймворк для автотестов?
Как построить свой фреймворк для автотестов?Dmitry Buzdin
 
How to grow your own Microservice?
How to grow your own Microservice?How to grow your own Microservice?
How to grow your own Microservice?Dmitry Buzdin
 
How to Build Your Own Test Automation Framework?
How to Build Your Own Test Automation Framework?How to Build Your Own Test Automation Framework?
How to Build Your Own Test Automation Framework?Dmitry Buzdin
 
Delivery Pipeline for Windows Machines
Delivery Pipeline for Windows MachinesDelivery Pipeline for Windows Machines
Delivery Pipeline for Windows MachinesDmitry Buzdin
 
Big Data Processing Using Hadoop Infrastructure
Big Data Processing Using Hadoop InfrastructureBig Data Processing Using Hadoop Infrastructure
Big Data Processing Using Hadoop InfrastructureDmitry Buzdin
 
Developing Useful APIs
Developing Useful APIsDeveloping Useful APIs
Developing Useful APIsDmitry Buzdin
 
Архитектура Ленты на Одноклассниках
Архитектура Ленты на ОдноклассникахАрхитектура Ленты на Одноклассниках
Архитектура Ленты на ОдноклассникахDmitry Buzdin
 
Riding Redis @ask.fm
Riding Redis @ask.fmRiding Redis @ask.fm
Riding Redis @ask.fmDmitry Buzdin
 
Rubylight JUG Contest Results Part II
Rubylight JUG Contest Results Part IIRubylight JUG Contest Results Part II
Rubylight JUG Contest Results Part IIDmitry Buzdin
 
Rubylight Pattern-Matching Solutions
Rubylight Pattern-Matching SolutionsRubylight Pattern-Matching Solutions
Rubylight Pattern-Matching SolutionsDmitry Buzdin
 
Refactoring to Macros with Clojure
Refactoring to Macros with ClojureRefactoring to Macros with Clojure
Refactoring to Macros with ClojureDmitry Buzdin
 
Poor Man's Functional Programming
Poor Man's Functional ProgrammingPoor Man's Functional Programming
Poor Man's Functional ProgrammingDmitry Buzdin
 
Rubylight programming contest
Rubylight programming contestRubylight programming contest
Rubylight programming contestDmitry Buzdin
 
Continuous Delivery
Continuous Delivery Continuous Delivery
Continuous Delivery Dmitry Buzdin
 
Introduction to DevOps
Introduction to DevOpsIntroduction to DevOps
Introduction to DevOpsDmitry Buzdin
 
Thread Dump Analysis
Thread Dump AnalysisThread Dump Analysis
Thread Dump AnalysisDmitry Buzdin
 

Mais de Dmitry Buzdin (20)

How Payment Cards Really Work?
How Payment Cards Really Work?How Payment Cards Really Work?
How Payment Cards Really Work?
 
Как построить свой фреймворк для автотестов?
Как построить свой фреймворк для автотестов?Как построить свой фреймворк для автотестов?
Как построить свой фреймворк для автотестов?
 
How to grow your own Microservice?
How to grow your own Microservice?How to grow your own Microservice?
How to grow your own Microservice?
 
How to Build Your Own Test Automation Framework?
How to Build Your Own Test Automation Framework?How to Build Your Own Test Automation Framework?
How to Build Your Own Test Automation Framework?
 
Delivery Pipeline for Windows Machines
Delivery Pipeline for Windows MachinesDelivery Pipeline for Windows Machines
Delivery Pipeline for Windows Machines
 
Big Data Processing Using Hadoop Infrastructure
Big Data Processing Using Hadoop InfrastructureBig Data Processing Using Hadoop Infrastructure
Big Data Processing Using Hadoop Infrastructure
 
JOOQ and Flyway
JOOQ and FlywayJOOQ and Flyway
JOOQ and Flyway
 
Developing Useful APIs
Developing Useful APIsDeveloping Useful APIs
Developing Useful APIs
 
Whats New in Java 8
Whats New in Java 8Whats New in Java 8
Whats New in Java 8
 
Архитектура Ленты на Одноклассниках
Архитектура Ленты на ОдноклассникахАрхитектура Ленты на Одноклассниках
Архитектура Ленты на Одноклассниках
 
Dart Workshop
Dart WorkshopDart Workshop
Dart Workshop
 
Riding Redis @ask.fm
Riding Redis @ask.fmRiding Redis @ask.fm
Riding Redis @ask.fm
 
Rubylight JUG Contest Results Part II
Rubylight JUG Contest Results Part IIRubylight JUG Contest Results Part II
Rubylight JUG Contest Results Part II
 
Rubylight Pattern-Matching Solutions
Rubylight Pattern-Matching SolutionsRubylight Pattern-Matching Solutions
Rubylight Pattern-Matching Solutions
 
Refactoring to Macros with Clojure
Refactoring to Macros with ClojureRefactoring to Macros with Clojure
Refactoring to Macros with Clojure
 
Poor Man's Functional Programming
Poor Man's Functional ProgrammingPoor Man's Functional Programming
Poor Man's Functional Programming
 
Rubylight programming contest
Rubylight programming contestRubylight programming contest
Rubylight programming contest
 
Continuous Delivery
Continuous Delivery Continuous Delivery
Continuous Delivery
 
Introduction to DevOps
Introduction to DevOpsIntroduction to DevOps
Introduction to DevOps
 
Thread Dump Analysis
Thread Dump AnalysisThread Dump Analysis
Thread Dump Analysis
 

Java Platform Performance BoF

  • 1. 1
  • 2. <Insert Picture Here> Java Platform Performance BoF Sergey Kuksenko, Aleksey Shipilev
  • 3. О чём у нас • Отвечаем на вопросы по Java Performance – В основном, предварительно собранные в разных местах Рунета – Есть возможность задать вопрос прямо здесь • Пишем на бумажке, передаём вперёд ;) • Сначала вводные слова про: – Performance Engineering – Startup – JIT – Concurrency and synchronization • Другие сессии: – “Искусное тестирование производительности (Java)”, завтра, 11-45 – “Диагностика и настройка GC”, сегодня, только что закончилось – “JDK7”, параллельно с нами 3
  • 5. Performance Engineering абстрактно и отлично об отличиях в абстракциях • Computer Science → Software Engineering – Строим приложения по функциональным требованиям – В большой степени абстрактно, в “идеальном мире” • Теоретически неограниченная свобода – искусство! • Можно строить воздушные зАмки – Рассуждения при помощи формальных методов • Software Performance Engineering – “Real world strikes back!” – Исследуем взаимодействие софта с железом на типичных данных • Производительность уже нельзя оценить • Производительность можно только измерить – Естественно-научные методы 5
  • 6. Performance Engineering первый шаг • Классические ошибки первого шага – “я вижу, что метод foo() реализован неэффективно” – “по профилю видно, что метод bar() – самый горячий и занимает 5%” – “по-моему, у нас тормозит БД, и необходимо перейти с DBX на DBY” • Правильный первый шаг: – Необходимо выбрать метрику • ops/sec, transactions/sec • время исполнения • время отклика – Убедиться в корректности метрики • релевантна (учитывает реальный сценарий работы приложения) • повторяема ЦЕЛЬ → улучшение метрики! 6
  • 7. Performance Engineering анализ узких мест (tips) • Низкая утилизация CPU – Высокая дисковая, сетевая активность – Конфликт блокировок – Конфликт ресурсов ОС – Слабая параллелизация приложения • Высокая утилизация ядра ОС – Частые блокировки – Частое обращение к ОС • Высокая утилизация CPU – Неоптимальная архитектура приложения – Неправильное использование API – Неоптимизированные горячие методы – Неоптимальные настройки GC 7
  • 8. Performance Engineering инструменты для анализа системы Solaris Linux Windows Что смотрим Сеть netstat, dtrace netstat perfmon количество соединений, объем трафика Диск iostat, dtrace iostat perfmon количество обращений к диску, задержка Память vmstat, prstat, vmstat, top perfmon подкачка страниц, dtrace размер памяти Процессы ps, vmstat, mpstat, ps, vmstat, top perfmon количество нитей, prstat, dtrace состояние нитей, переключения контекста Ядро ОС mpstat, lockstat, vmstat perfmon kernel time, plockstat, dtrace, блокировки, intrstat, vmstat системные вызовы, прерывания ... 8
  • 9. Performance Engineering tools, tools, tools again, more tools • VisualVM – http://visualvm.dev.java.net • JRockit Mission Control – http://www.oracle.com/technetwork/middleware/jrockit/mission-control/index.html • Sun Studio Analyzer – http://www.oracle.com/technetwork/server-storage/solarisstudio/overview/index.html • DTrace – http://www.oracle.com/technetwork/systems/dtrace/dtrace/index.html • Ещё могут быть полезны: – JProbe – OptimizeIt – YourKit 9
  • 10. JVM tuning настройка параметров JVM • Что настраивать? – http://blogs.sun.com/watt/resource/jvm-options-list.html – http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html 10
  • 11. JVM tuning настройка параметров JVM • JVM сама подбирает оптимальные параметры своей работы – Server vs. Client – Large pages (Solaris) – CompressedOops (64-bit VM) • Так что же настраивать? – GC/Heap tuning – -XX:+UseNUMA (Solaris, Linux) – -XX+:UseLargePages (Linux, Windows) • http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html • Не забыть – Использовать последнюю версию JDK 11
  • 12. Startup 12
  • 14. Startup как измерять? До входа в main()? 14
  • 15. Startup как измерять? До первого ответа от приложения? 15
  • 16. Startup как измерять? До “стабильного состояния”? 16
  • 17. Startup как измерять? Время на пуск-остановку? 17
  • 18. Startup Eclipse • Типичная конфигурация: – 2x2 Intel i5 2.6 Ghz, Ubuntu 10.10 i686, JDK 6u25 – Eclipse JDT (Galileo) • Типичные метрики: – 6.000 загруженных классов – 1.000 методов скомпилировано – 512 Mb зарезервированного пространства в куче – 25 Mb кучи использовано после стартапа • Известные “проблемы”: – Загрузка и верификация классов – JIT-компиляция 18
  • 19. Startup Eclipse • Метрика: секунд на запуск-завершение – Файловые кеши прогреты, практически нулевой дисковый I/O default CDS CDS + no-verify абсолютное время 5.83 4.81 4.61 [5.74; 5.92] [4.73; 4.84] [4.56; 4.74] загрузка классов 5.01 3.39 3.01 [4.91; 5.11] [3.12; 3.66] [2.94; 3.08] компиляция 0.51 0.51 0.51 [0.43; 0.59] [0.44; 0.58] [0.42; 0.60] 19
  • 20. Startup длинные приложения • Важно только для коротких приложений – Чем дольше работает приложение, тем меньше удельные затраты на загрузку классов и компиляцию • Пример: 8 часа работает IntelliJ IDEA 10.x: – 26.600 классов загружено – 5315 методов скомпилировано – Загрузка классов: • Всего потрачено 202 с., ~0.7% общего времени • 10 мсек на класс – Компиляция: • Всего потрачено 112 с., ~0.03% общего времени • 20 мсек на метод 20
  • 22. Concurrency общие соображения • Только мы научились программировать, новая беда – Новое входное данное в программе: время – Подавляющее большинство concurrency-багов – гейзен-баги! • TDD “отдыхает” • • Читаем хорошие книги – “Учиться, учиться и ещё раз учиться” (с) – “Java Concurrency in Practice” – “The Art Of Multiprocessor Programming” – “JSR 133 Cookbook” – “A Little Book of Semaphores” • Пользуемся высокоуровневыми примитивами – java.util.concurrent.* – ... или другими, построенными на их основе 22
  • 23. JIT 23
  • 24. JIT факты • … есть • … работает • … работает хорошо • … знает о железе всё: – Количество и тип CPU, поддерживаемые инcтрукции (SSEx, AVX, VIS) – Топологию памяти (в т.ч. размеры кэшей и их характеристики) • … знает о приложении много всего: – Иерархию загруженных классов – Актуальную статистику создания объектов – Горячий код – Какие ветвления исполнялись, какие значения использовались • … не боится использовать эти знания для компиляции 24
  • 26. JIT performance urban legends final дает лучшую производительность копируйте поля в локальные переменные! Reflection – volatile запрещает JIT дорого оптимизировать доступ к полю вызов виртуального метода - дорого избегайте get/set вручную вылизанный метод методов внутри лучше аналога из classlib самого класса immutable классы – плохо вручную выполненый native методы дорогие, System.arraycopy() inline – хорошо нативный – значит ... Java медленна потому, что нельзя вручную создание объектов дорого – выключить проверку выхода индекса за используйте Object pooling границы массива 26
  • 27. JIT как писать код • Используйте стандартные библиотеки – Зачем писать собственный стандартный контейнер? • Используйте высокоуровневый API: – java.util.*, java.util.concurrent.*, NIO, NIO.2 – вообще библиотеки • Код должен правильным и понятным – Сначала правильно, потом алгоритмически “быстро” – Код не должен быть JIT-oriented • Правильно используйте возможности языка – EPIC FAIL: штатная передача управления exception'ами – FAIL: Возврат “исключения” через return <код_ошибки> – FAIL: int вместо Enum или boolean 27
  • 28. JIT для любопытных • Как получить ассемблерный код метода? • Обычным дебаггером ;) • JVMTI • -XX:+PrintAssembly – http://wikis.sun.com/display/HotSpotInternals/PrintAssembly 28
  • 29. Q/A 29
  • 31. Reflection вопрос из зала • Сравнение вызова reflection vs. cglib – raw: 59044.74 ± 8212.66 – сglib: 1530.23 ± 41.04 – cglib (cache args): 2175.41 ± 114.74 – reflection 45.19 ± 1.07 – reflection (accessible = true): 1276.77 ± 14.46 – reflection (accessible = true) (cache args): 1758.70 ± 72.03 • MethodHandle увеличит производительность ещё сильнее 31
  • 32. Performance Engineering итеративный подход Измерения (эксперименты) Разработка Сбор и обработка данных Старт (кодирование решений) (профилировка, статистика) Поиск решений Анализ узких мест (прототипирование) Важно: –Одно изменение за цикл! –Документировать все изменения 32
  • 33. Performance Engineering анализ узких мест •Что ограничивает скорость работы приложения? – CPU – Ядро ОС – I/O (Сеть, Диск) 33
  • 34. Performance Engineering ”нисходящий” метод поиска узких мест • Уровень системы – Сеть – Диск – Database – Операционная система – Процессор/память • Уровень приложения – Блокировки, синхронизация – Execution Threads – API – Алгоритмические проблемы • Уровень JVM – Выбор JVM – Heap tuning – JVM tuning 34
  • 35. Java 7, Java 8 что ожидать в области производительности • Java 7 – invokedynamic – NIO.2 – Concurrency and Collection updates (Fork/Join) – XRender pipeline for Java2D (client) • Java 8 (или позже) – Модульность – λ-выражения (замыкания) – Collection updates (filter, map, reduce) 35
  • 36. Обратная совместимость • Мешает ли улучшать производительность JVM? – Да, поэтому иногда расширяемся: • invokedynamic • Модульность • Стоит ли расширяться по первому требованию? – Нет, развитие JVM/JIT, реализация новых методов оптимизации позволяет получить бОльший выигрыш • Вложенные классы • Reflection 36
  • 37. Лучшая ОС для Java угадайте, какая? Solaris • Высокопроизводительный TCP/IP стек – low-latency – up to 50% faster • DTrace – мониторинг • NUMA – MPO, Memory Placement Optimization • Large Pages – Автоматическая аллокация – Разные размеры 37
  • 38. Concurrency элементная база • OS Threading – мьютексы • mutex_lock()/mutex_unlock() – conditional waits • cond_wait()/cond_signal() • WaitForSingleObject • Compare-and-Swap (CAS) – CAS(x1, x2, x3) = { if (x1 == x2) { x1 = x3 }; } – атомарная операция, поддерживаемая в “железе”: из нескольких одновременных CAS'ов успешно завершается только один – Миф: локальный CAS блокирует шину, и стоит больше на многопроцессорных системах – Факт: глобальный CAS требует трафика на шине 38
  • 39. Concurrency atomics • java.util.concurrent.Atomic* – обеспечивают атомарные операции над примитивами и указателями – альтернатива: synchronized {} или Lock'и • Трюк в использовании CAS'а: – Изменение состояния атомика делается при помощи одного CAS'а – Чтение состояния не требует CAS'а mov %ecx,%edx public final int incrementAndGet() { mov 0x8(%ecx),%eax for (;;) { lea 0x8(%ecx),%edi int current = get(); mov %eax,%ecx int next = current + 1; inc %ecx if (compareAndSet(current, next)) lock cmpxchg %ecx,(%edi) return next; mov $0x0,%ebx } jne [ok] } mov $0x1,%ebx test %ebx,%ebx je [ok] 39
  • 40. Concurrency volatile • Volatile определяет порядок чтения-записей в поле – НЕ обеспечивает атомарности – Реализуется расстановкой барьеров • Какие из них вставятся в код, зависит от Hardware Memory Model • Эффект барьера зависит от HMM PUSHL EBP SUB ESP,8 push %ebp MOV EBX,[ECX + #12] sub $0x8,%esp MEMBAR-acquire mov 0xc(%ecx),%ebx MEMBAR-release inc %ebx INC EBX mov %ebx,0xc(%ecx) MOV [ECX + #12],EBX lock addl $0x0,(%esp) MEMBAR-volatile add $0x8,%esp LOCK ADDL [ESP + #0], 0 pop %ebp ADD ESP,8 test %eax,0xb779c000 POPL EBP ret TEST PollPage,EAX RET 40
  • 41. Concurrency intrinsic synchronization • synchronized(object) { }, 4 состояния: – Init – Biased • Захватывается одним “владеющим” потоком, нет конфликтов • Захват владельцем: проверка на threadID • Захват не-владельцем: переход либо в Biased, либо в Thin – Thin • Захватывается несколькими потоками, но конфликтов нет • Захват: CAS • Конфликтный захват: переход в Fat – Fat • Захватывается несколькими потоками, конфликт на блокировке • Вызов примитива синхронизации из ОС 41
  • 42. Concurrency java.util.concurrent.Lock • Построены на базе j.u.c.AbstractQueueSynchronizer – Использует CAS – Использует Unsafe.park()/unpark() → cond_wait()/cond_signal()/WaitForSingleObject() • ReentrantLock – По семантике эквивалентен synchronized {} – Ставит потоки во внутреннюю очередь и делает park() – Non-Fair (default) • Не гарантирует отсутствие starvation, ибо barging FIFO (CAS) • Лучшая производительность – Fair • Гарантирует отсутствие starvation, FIFO • Честность в обмен на производительность 42
  • 43. Concurrency атомарный счётчик private AtomicInteger atomic = new AtomicInteger(); private ReentrantLock lock = new ReentrantLock(); private final Object intrinsicLock = new Object(); private int primCounter = 0; @GenerateMicroBenchmark public void testAtomicInteger() { atomic.incrementAndGet(); } @GenerateMicroBenchmark public void testReentrantLock() { lock.lock(); primCounter++; lock.unlock(); } @GenerateMicroBenchmark public void testIntrinsicLock() { synchronized (intrinsicLock) { primCounter++; } } 43
  • 44. Concurrency атомарный счётчик Intel Xeon (Westmere-EP), 3.0 Ghz, 2x6x2 = 24 HW threads, SLES 11 x86_64, JDK 6u25 44
  • 45. Concurrency ReentrantLock vs. synchronized • Семантика одинакова – Требования к видимости памяти – Рекурсивный • Плюсы j.u.c.RL – Очередь потоков держится на стороне JVM • опционально, FIFO-политика при захвате-освобождении • позволяет быть “честным” на любой платформе – Barging FIFO policy • lock() может быть сразу удовлетворён, даже если в очереди есть потоки • сильно улучшает производительность при конфликте блокировок – Допускается несколько Condition • Минусы j.u.c.RL – Нет scope'ов, требуется ручной unlock() через finally 45
  • 46. Concurrency производительность захвата Intel Xeon (Westmere-EP), 3.0 Ghz, 2x6x2 = 24 HW threads, SLES 11 x86_64, JDK 6u25 46
  • 47. 47
  • 48. The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. 48
  • 49. 49