Проблемы производительности 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

Viewers also liked

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

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