Проблемы производительности open source библиотек

© Netcracker 2016 1
Производительность
open source решений
Владимир Ситников
JPoint 2016

•Владимир Ситников
•Инженер по производительности в Netcracker,
10 лет
•sitnikov@netcracker.com
•@VladimirSitnikv
Кто я

•Spring
•Cglib
•Pgjdbc
•HornetQ
•Wildfly
•Jenkins
План

План
Наш любимый
enterprise
продукт

Внедряем Spring в сжатые сроки
Монолит
spring

Монолит
spring

Core
Security
UI

•Когда нужен бин, то выполняем
beanFactory.getBean(Security.class)
В UI spring пока не наступил

•Но где взять beanFactory?

•Но где взять beanFactory?
•Правильно, Паблик Морозов поможет нам

public class AppContext implements BeanFactoryAware
{
static public BeanFactory beanFactory;
...
Получаем бин

public class AppContext implements BeanFactoryAware
{
static public BeanFactory beanFactory;
...
AppContext.beanFactory.getBean(Security.class)
Получаем бин

•Работает
Spring.getBean

•Работает
•Но медленно-медленно
Spring.getBean

•Работает
•Но медленно-медленно
•На getBean и 50% времени может уходить
Spring.getBean

•Java Flight Recorder
Подходящие для анализа инструменты

•kill -3 profiler (poormansprofiler.org)

•kill -3 profiler (poormansprofiler.org)
•Инструментирующий профилировщик.
Например самописный, настроенный на
getBean

160 секунд на getBean. Здорово?

160 секунд на getBean. Здорово?
•Java 8 / Spring 4.1.7

•SPR-6870 Cache by-type lookups in
DefaultListableBeanFactory
Проверяем известные проблемы

ЯЗЬ!!!

•Fix version: 3.2 M1, а у нас 4.1+ 

Flight Recorder, allocations in new TLAB

protected Object getCacheKey(
Class<?> beanClass, String beanName) {
return beanClass.getName() + "_" + beanName;
}
AbstractAutoProxyCreator

return beanClass.getName() + "_" + beanName;
}

return beanName == null ? beanClass : ...;
}
github.com/spring-projects/spring-
framework/pull/913

public class SharedSecrets {
@Inject
public Security security;
@PostConstruct
public void init() { INSTANCE = this; }
public static volatile SharedSecrets INSTANCE;
Как выжить без обновления Spring?

•Не стоит злоупотреблять prototype
bean’ами. Если singleton, то singleton
Prototype vs singleton

•Не стоит злоупотреблять prototype
bean’ами. Если singleton, то singleton
•Замена getBean на
javax.inject.Provider<...> лишь
ухудшает время работы
•
Prototype vs singleton

@Pointcut(
"execution(
public* my.service.*ServiceImpl.*(..))”
)
Spring AOP

•OutOfMemory: perm gen
Spring AOP

•В хипдампе куча java.lang.reflect.Method
Spring AOP

•Method’ы занимают 100-500MiB
Spring AOP

•Method’ы занимают 100-500MiB
•Все они лежат в AspectJExpressionPointcut
Spring AOP

@Pointcut(
"execution(
public* my.service.*ServiceImpl.*(..))”
)
Spring AOP

•Решение: добавлять
within(my.package.service.business..*)
Spring AOP vs AspectJ

•Решение: добавлять
within(my.package.service.business..*)
•Разумеется, AspectJ рекомендуют
использовать within всегда:
http://dev.eclipse.org/mhonarc/lists/aspectj-
users/msg10969.html
•
Spring AOP vs AspectJ

•Cglib используется много где: рукотворный
код, тот же Spring
Cglib

•Наверняка уже всё исправлено давным-
давно
Cglib

•Наверняка уже всё исправлено давным-
давно
•Наверняка туда давно никто не заглядывал
Cglib

@Benchmark
public Object newProxy() {
return Beans.newProxy(Beans.class);
}
Cglib: замеряем

0
2
4
6
8
10
12
14
16
18
Cglib 3.1
1 поток 2 потока 4 потока 8 потоков
Замеры Cglib, μs/opБыстрее

0
2
4
6
8
10
12
14
16
18
Cglib 3.1 Cglib 3.2.2
1 поток 2 потока 4 потока 8 потоков
Замеры Cglib, μs/opБыстрее

Benchmark Score
newProxy 2.1 ± 0.3 μs/op
newProxy.alloc.rate 1240 B/op
Стало
newProxy 0.14 ± 0.02 μs/op
newProxy.alloc.rate 256 B/op
Cglib 3.2.2: ждём в очередном Spring

•Skip finalize while building proxy
https://github.com/cglib/cglib/pull/51
•Concurrent cache of generated classes
https://github.com/cglib/cglib/pull/53
План захвата Cglib

•А, может, ну его этот cglib, есть же быстрый
ByteBuddy?
Но есть же ByteBuddy

ByteBuddy?
@Benchmark
public ExampleClass benchmarkCglib() {
Enhancer enhancer = new Enhancer();
enhancer.setUseCache(false);
ByteBuddy, jmh тест

ByteBuddy?
@Benchmark
public ExampleClass benchmarkCglib() {
Enhancer enhancer = new Enhancer();
enhancer.setUseCache(false);

•JMH тесты в ByteBuddy показывают
скорость создания классов
•Постоянно создавать классы нехорошо
•Значит, нужно измерять скорость
кэшированного обращения

•КО: «Бери pgjdbc»
Подключаемся к PostgreSQL

•КО: «Используй batch statements»

•КО: «Используй batch statements»
•Что может пойти не так?

Connection con = ...;
PreparedStatement ps =
con.prepareStatement("SELECT...");
...
ps.close();
PreparedStatement

PARSE S_1 as ...; // con.prepareStmt
BIND/EXEC
DEALLOCATE // ps.close()
PARSE S_2 as ...;
BIND/EXEC
DEALLOCATE // ps.close()
Работа с PostgreSQL курильщика

PARSE S_1 as ...; 
BIND/EXEC
BIND/EXEC
BIND/EXEC 
BIND/EXEC
BIND/EXEC
...
DEALLOCATE
Работа с PostgreSQL здорового человека

PARSE S_1 as ...;  1 раз в жизни
BIND/EXEC  обработка REST
BIND/EXEC
BIND/EXEC  ещё REST
BIND/EXEC
BIND/EXEC
...
DEALLOCATE  желательно «никогда»
DEALLOCATE
Работа с PostgreSQL здорового человека

Вывод: чтобы работало быстрее,
закрывать statement’ы не нужно
ps = con.prepareStatement(...)
ps.execueQuery();
ps = con.prepareStatement(...)
ps.execueQuery();
...
Счастливые statement’ов не закрывают

Вывод: чтобы работало быстрее,
закрывать statement’ы не нужно
ps = con.prepare...
ps.execueQuery();
ps = con.prepare...
ps.execueQuery();
...

@Benchmark
public Statement leakStatement() {
return con.createStatement();
}
pgjdbc < 9.4.1202, -Xmx128m, OracleJDK 1.8u40
# Warmup Iteration 1: 1147,070 ns/op
# Warmup Iteration 4: <failure>
java.lang.OutOfMemoryError: GC overhead limit exceeded
OpenJDK: не все JRE одинаково полезны

@Benchmark
public Statement leakStatement() {
return con.createStatement();
}
pgjdbc >= 9.4.1202, -Xmx128m, OracleJDK 1.8u40
# Warmup Iteration 1: 30 ns/op
# Warmup Iteration 2: 27 ns/op
...
github.com/pgjdbc/pgjdbc/pull/299
Убираем finalize из класса PgConnection

Вывод: чтобы работало быстро, нужно
как-то кэшировать statement’ы
ps = con.prepareStatement("select id,
name ...");
ps.execueQuery();
ps.close();
ps2 = con.prepareStatement("select id,
name ...");

•Кэш запросов появился в версии 9.4.1202
(2015-08-27)
см. https://github.com/pgjdbc/pgjdbc/pull/319
Кэш запросов в PgJDBC

(2015-08-27)
•Работает прозрачно для приложения

(2015-08-27)
•Скорость такая, что PL/PgSQL не нужен

(2015-08-27)
•Скорость такая, что PL/PgSQL не нужен
•Server-prepare активируется после 5-го
выполнения (prepareThreshold)

•Конечно, затраты planning time напрямую
зависят от сложности запросов
Цифры где?

•У нас доходило до 20мс+ planning time на
OLTP запросах: 10КиБ запрос, 170 строк
explain
•
Цифры где?

•У нас доходило до 20мс+ planning time на
OLTP запросах: 10КиБ запрос, 170 строк
explain
•Стало ~0мс
Цифры где?

Если типы параметров меняются, то server-
prepared statement приходится менять
ps.setInt(1, 42);
...
ps.setNull(1, Types.VARCHAR);
JDBC: Типы параметров

•Вывод: даже у NULL’ов должен быть
верный тип
JDBC: Тип параметров изменять нельзя

•Вывод: даже у NULL’ов должен быть
верный тип
•Ещё раз: setObject(1, null)
использовать нельзя
JDBC: Тип параметров изменять нельзя

•Перешли на prepared, и запрос замедлился
в 5'000 раз. Как так?
Нежданчик

•Перешли на prepared, и запрос замедлился
в 5'000 раз. Как так?
Нежданчик
A. Бага C. Фича
B. Фича D. Бага

https://gist.github.com/vlsi -> 01_plan_flipper.sql
select *
from plan_flipper -- <- таблица
where skewed = 0 -- 1 млн строк
and non_skewed = 42 -- 20 строк
Нежданчик

0.1мс  1-е выполнение
250 мс  6-е выполнение
Нежданчик

250 мс  6-е выполнение
Нежданчик

Запрещаем использование индекса через +0:
select *
from plan_flipper
where skewed+0 = 0  ~ /*+no_index*/
and non_skewed = 42
Чиним

Как сделать опциональные фичи?
•NO_RESULTS
•BOTH_ROWS_AND_STATUS
•DESCRIBE_ONLY
Фичи

Конечно, enum!
enum ... {
NO_RESULTS,
BOTH_ROWS_AND_STATUS,
DESCRIBE_ONLY;
}
Фичи

Конечно, enum!
enum ... {
NO_RESULTS,
BOTH_ROWS_AND_STATUS,
DESCRIBE_ONLY;
}
А на java 1.4?
Фичи

В java 1.4, конечно, interface!
interface ... {
int NO_RESULTS = 1;
int BOTH_ROWS_AND_STATUS = 2;
int DESCRIBE_ONLY = 4;
}
Фичи: java 1.4 наносит ответный удар

Меняем 1 строку, и скорость работы batch insert
возрастает в 10 раз:
https://github.com/pgjdbc/pgjdbc/pull/380
- static int QUERY_FORCE_DESCRIBE_PORTAL = 128;
+ static int QUERY_FORCE_DESCRIBE_PORTAL = 512;
Ужасы нашего городка

Меняем 1 строку, и скорость работы batch insert
возрастает в 10 раз:
https://github.com/pgjdbc/pgjdbc/pull/380
- static int QUERY_FORCE_DESCRIBE_PORTAL = 128;
+ static int QUERY_FORCE_DESCRIBE_PORTAL = 512;
// оказалось, значение 128 уже было занято
static int QUERY_DISALLOW_BATCHING = 128;
Ужасы нашего городка

•WildFly 8.2, JMS
HornetQ

•WildFly 8.2, JMS
•Всего ~100 JMS/сек
HornetQ

•WildFly 8.2, JMS
•Всего ~100 JMS/сек
•1 вызов sendMessage – 5-30 секунд
HornetQ

at java.util.concurrent.Semaphore.tryAcquire
at org.hornetq ... ClientProducerCreditsImpl.acquireCredits
at com ... JMSSender.sendMessage
kill -3 профайлер

at org.hornetq ... ClientProducerImpl.sendRegularMessage

at org.hornetq ... ClientProducerImpl.doSend

at org.hornetq ... ClientProducerImpl.send

at org.hornetq ... ClientProducerImpl.send
at org.hornetq ... HornetQMessageProducer.doSendx

• 'Producer Window Size’ на connection factory
Backpressure

• address-settings -> address-setting -> max-size-bytes
Backpressure

• Если в JMS очереди накапливается 10МиБ, то отправка
JMS начинает притормаживать
Backpressure

• Если в JMS очереди накапливается 10МиБ, то отправка
JMS начинает притормаживать
<address-settings>
<address-setting match="#">
<max-size-bytes>10 485 760</max-size-bytes>
…
Backpressure

•Настраиваем max-size-bytes для каждой
очереди
Backpressure: чиним

•Настраиваем max-size-bytes для каждой
очереди
•Либо смотрим в сторону RxJava
Backpressure: чиним

•Старт приложения на WF 8.2 занимает 2-5
минут
WildFly: пытаемся взлететь

минут
•Concurrent deploy работает плохо

минут
•Concurrent deploy работает плохо
•Spring xml app config анализирует все
jar’ники

•Уменьшать размер jar (исключать лишние)
• WildFly копирует jar в /tmp при запуске
WildFly: как чинить

•Делать патчи на WF, чтобы он не
складывал строки
• https://github.com/jbossas/jboss-vfs/pull/25
• https://github.com/wildfly/wildfly-core/pull/1219

•Делать патчи на WF, чтобы он не
складывал строки
• https://github.com/jbossas/jboss-vfs/pull/25
• https://github.com/wildfly/wildfly-core/pull/1219
•Профилировать запуск вашего WF (kill -3
profiler)

Самое главное в CI –
переменные окружения
Jenkins

https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin
Jenkins: EnvInjectPlugin

Пишем по образу и подобию:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORAC
LE_HOME/…
PATH=$PATH:$ORACLE/bin:…

EnvInjectEnvVars.resolveVars()

-> hudson.Util.replaceMacro()

-> hudson.Util.replaceMacro()
-> OutOfMemoryError.<init>()

$LD_LIBRARY_PATH:$ORACLE_HOME/lib
:$ORACLE_HOME/lib:$ORACLE_HOME/lib
:$ORACLE_HOME/lib:...

https://issues.jenkins-ci.org/browse/JENKINS-
19856
^^^ с вами с 2013 года

•Общение Jenkins master и slave тщательно
логируется
Jenkins: master vs slave

•«Разумеется», в памяти хранятся
последние 1000 записей

•Н
а эти логи может уходить 100-200МиБ

•Н
•Да, да. Логи хранятся в памяти и никогда не
попадают в файл

•Хорошо, что есть опция
• -Dhudson.remoting.ExportTable.unexportLog=0

•Разумеется, в Google ровно один результат

•Разумеется, в Google ровно один результат
•На исходный код, где она определена :)

•Оказалось, что запуск master занимает 50
минут
• 3000 jobs, 10-500 runs per job
• 24 CPU, 64 GiB RAM
• -Xmx40g
Jenkins: запускаемся

•При старте, Jenkins инициализирует job’ы
Jenkins: файлы разные нужны, файлы разные важны

•Maven job загружает данные по всем
запускам

запускам
•В
каждом запуске есть fingerprint’ы, они тоже
грузятся

запускам
•В
•В итоге много-много операций с диском
•и тоже грузятся

•Решение в лоб: удалить fingerprint’ы перед
запуском
Jenkins: чиним

запуском
•Более сложное: не плодить fingerprint’ы
Jenkins: чиним

запуском
•Поможет и сокращение хранимой истории
Jenkins: чиним

запуском
•Поможет и сокращение хранимой истории
•В идеальном мире нужно разбираться с
maven-jenkins-plugin
Jenkins: чиним

Кто виноват и что делать?

•Владимир Ситников
•Инженер по производительности в Netcracker
•sitnikov@netcracker.com
•@VladimirSitnikv
С вами был

Вопросы?

Проблемы производительности open source библиотек

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Проблемы производительности open source библиотек (20)

Проблемы производительности open source библиотек