Author Archive

Транзакции в debug-режиме

26 октября, 2020 | BY Naik | Category: Hibernate, Spring Boot, Transaction | Нет комментариев »

Транзакции в Hibernate работают не всегда прозрачно.

Если для отладки запросов в Hibernate мы используем show-sql: true в application.yml, то для включения логирования транзации нужно переключить уровень логирования на DEBUG для определенного класса.

Следующая настройка для Hibernate 5 и системы логирования SLF4J.

В файл logback-spring.xml (или logback.xml) добавьте следующую строку:

После рестарта приложения в логах должны появится следующие строки:

1) Начало транзакции

...TransactionImpl         : begin

2) Коммит транзакции

...TransactionImpl         : committing

3) Откат транзакции

...TransactionImpl         : rolling back

Во сколько раз Base64 увеличивает размер в байтах

17 сентября, 2020 | BY Naik | Category: Без рубрики | 2 комментария »

Base64 — стандарт кодирования байтов при помощи только 64 символов (A-Z, a-z и 0-9 (62 знака) и 2 дополнительных символа, зависящих от системы реализации).

Одним байтом можно закодировать 256 значений (2⁸ бит), в то время как Base64 только 64 (2⁶ бит).

Из этого следует соотношение 2⁸ + 2⁸ + 2⁸ = 2⁶ + 2⁶ + 2⁶ + 2⁶, т.е. каждые 3 исходных байта кодируются в 4 байта.

Можно вывести формулу:

[Кол-во байт в Base64] = ([Исходное кол-во байт] / 3) * 4
или
[Кол-во байт в Base64] = 4 * [Исходное кол-во байт] / 3
или
[Кол-во байт в Base64] = 4/3 * [Исходное кол-во байт]

Например: Файл размером 1500 байт в Base64 будет занимать 2000 байт (т.е. на 1/3 больше).

Рассмотрим обратную задачу: есть Base64-строка и нужно понять сколько это будет байтов при раскодировке. Из формул выше можно выразить исходное кол-во байт:

[Исходное кол-во байт] = 3/4 * [Кол-во байт в Base64] 
или
[Исходное кол-во байт] = 0.75 * [Кол-во байт в Base64]

Например: Base64-строка размером 2000 байт, декодируется в 1500 байт (т.е. на 1/4 меньше);

TAG:Base64 , Decode , Encode , Размер

Преобразование в сетевой порядок расположения байт (Java)

27 августа, 2020 | BY Naik | Category: Java, Алгоритмы | Нет комментариев »

HtoN (Host to Net) - узловой порядок в сетевой.

Функция htons преобразует узловой порядок расположения байтов в сетевой порядок расположения байтов. В short помещаются все возможные порты от 0 до 65535 (фактически от -32768 до 32767, т.к. в Java знаковый short):

static short htons(short val) {
    return (short) ((val & 0xff) << 8 
            | (val & 0xff00) >>> 8); // >>> - беззнаковый сдвиг
}

Функция htonl() преобразует узловой порядок расположения байтов в сетевой порядок расположения байтов. В int помещаются все возможные адреса IPv4 от 0.0.0.0 до 255.255.255.255 (фактически от -2 147 483 648 до 2 147 483 647, т.к. в Java знаковый int):

static int htonl(int val) {
    return (val & 0xff) << 24
            | (val & 0xff00) << 8
            | (val & 0xff0000) >> 8
            | (val & 0xff000000) >>> 24; // >>> - беззнаковый сдвиг
}

TAG:htonl , htons

Замер времени bash-скриптом

13 августа, 2020 | BY Naik | Category: Bash | Нет комментариев »

Замерить выполнение какого-либо процесса можно из кода самого процесса, но иногда это не получается сделать.

И на помощь приходит внешний замер времени с помощью bash-скрипта.

Сперва запоминаем время запуска (в наносекундах), потом фиксируем время окончания (в наносекундах) и находим разность времени окончания и начала.

Для перевода продолжительности из наносекунд в миллисекунды нужно разделить на один миллион.

Создайте скрипт (timer.sh) со следующим содержимым:

start_time="$(date +%s%N)"
# >>> тут пропишите запуск вашего процесса <<<
end_time="$(date +%s%N)"
elapsed="$(($end_time-$start_time))"
elapsed="$(($elapsed / 1000000))"
echo "Total of $elapsed milliseconds elapsed for process"

Удаление временно ненужных файлов

5 июля, 2020 | BY Naik | Category: Скрипты | Нет комментариев »

В очередной раз у разработчика закончилось место на жестком диске и начинается головоломка: "Что почистить?"

В данной заметке предлагается почистить файлы сборок старых проектов. Ведь непонятно, когда понадобятся сборки и понадобятся ли вообще, а место они занимают много.

Внимание все операции нужно делать с осторожностью, чтобы не удалить ничего лишнего!

Рассмотрим очистку места на примере удаления директорий build и node_modules.

Для начала просканируем директории на наличие build и node_modules:

find . -name build -type d -maxdepth 2

find . -name node_modules -type d -maxdepth 2

maxdepth - максимальная глубина сканирования

Следующим шагом вычисляем размеры найденных директорий и анализируем:

find . -name build -type d -maxdepth 2 -exec du -sh {} \;

find . -name node_modules -type d -maxdepth 2 -exec du -sh {} \;

Далее генерируем скрипты удаления директорий (это еще не удаление, а echo):

find . -name build -type d -maxdepth 2 -exec echo rm -rf {} \;

find . -name node_modules -type d -maxdepth 2 -exec echo rm -rf {} \;

Внимание все операции нужно делать с осторожностью, чтобы не удалить ничего лишнего!

Теперь можно взять сгенерированные скрипты и выполнить их все или точечно.

Место свободно!

Hibernate Envers проблема с размером приращения последовательности

12 апреля, 2020 | BY Naik | Category: Hibernate | Нет комментариев »

В проект трехлетней давности не получилось прикрутить Hibernate Envers, возникала ошибка при запуске приложения:

Caused by: org.hibernate.MappingException: 
The increment size of the [hibernate_sequence] sequence is set to [1] 
in the entity mapping while the associated database sequence increment size is [50].

На том проекте Envers не сильно нужен был, поэтому обошлись без него.

На новом проекте все-таки возникла острая необходимость в использовании Envers, пришлось потратить время, чтобы решить данную проблему.

В нашем проект используется не hibernate_sequence, а sequence_generator, но принцип тот же.

Проблема в том, что в базе данных у sequence шаг приращения 50 (в целях производительности), а в коде у какой-то сущности с данным sequence приращение равно 1. Эта сущность - revinfo.

Нужно переопределить RevInfo, добавив следующую сущность в ваш проект:

@Entity
@Table(name = "revinfo")
@RevisionEntity
public class CustomRevisionEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "sequenceGenerator")
    @SequenceGenerator(name = "sequenceGenerator")
    @RevisionNumber
    private long rev;

    @RevisionTimestamp
    private long timestamp;

    public long getRev() {
        return rev;
    }

    public void setRev(long rev) {
        this.rev = rev;
    }

    public long getTimestamp() {
        return timestamp;
    }

    public void setTimestamp(long timestamp) {
        this.timestamp = timestamp;
    }
}

Ключевое изменение - это строки:

 @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "sequenceGenerator")
 @SequenceGenerator(name = "sequenceGenerator")

Которые явно задают sequence, который будет использовать таблица revinfo. В нашем случае - это sequence_generator.

Если помогло, отпишитесь в комментах. 🙂

p.s. Дефолтная revinfo какая-то косячная.

Идентификатор ревизии почему-то integer, а не long.

Также не читабельна ревизия в виде long timestamp, но есть две альтернативы. Либо только дата, либо только время. Что еще неудобнее, а хотелось бы человекочитаемую дату со временем.

Совет: лучше переопределить revinfo, даже если у вас нет проблем с последовательностями.

Полное удаление метрик Prometheus

11 марта, 2020 | BY Naik | Category: Prometheus | Нет комментариев »

В один прекрасный день у нас на тестовом сервере поломался Prometheus, возможно, из-за частой смены времени на сервере (это нужно было для целей тестирования основной системы).

Удалять метрики можно через API, но в моем случае это почему-то не помогло, поэтому пришлось применить радикальный способ.

Способ заключается в удалении содержимого директории базы данных временных рядов /var/lib/prometheus/.

Расположение этой директории можно узнать с помощью команды:

sudo service prometheus status

Выполнив команду, вы увидите --storage.tsdb.path /var/lib/prometheus/ - путь к базе данных временных рядов.

Степени двойки

19 февраля, 2020 | BY Naik | Category: Без рубрики | Нет комментариев »

Список степени двойки.

Степени двойки позволяют оценить алгоритмы, работающие за логарифмическое время.

Степень двойки (2^x)	Значение
0	1
1	2
2	4
3	8
4	16
5	32
6	64
7	128
8	256
9	512
10	1 024
11	2 048
12	4 096
13	8 192
14	16 384
15	32 768
16	65 536
17	131 072
18	262 144
19	524 288
20	1 048 576
21	2 097 152
22	4 194 304
23	8 388 608
24	16 777 216
25	33 554 432
26	67 108 864
27	134 217 728
28	268 435 456
29	536 870 912
30	1 073 741 824
31	2 147 483 648
32	4 294 967 296
33	8 589 934 592
34	17 179 869 184
35	34 359 738 368
36	68 719 476 736
37	137 438 953 472
38	274 877 906 944
39	549 755 813 888
40	1 099 511 627 776
41	2 199 023 255 552
42	4 398 046 511 104
43	8 796 093 022 208
44	17 592 186 044 416
45	35 184 372 088 832
46	70 368 744 177 664
47	140 737 488 355 328
48	281 474 976 710 656
49	562 949 953 421 312
50	1 125 899 906 842 624
51	2 251 799 813 685 248
52	4 503 599 627 370 496
53	9 007 199 254 740 992
54	18 014 398 509 481 984
55	36 028 797 018 963 968
56	72 057 594 037 927 936
57	144 115 188 075 855 872
58	288 230 376 151 711 744
59	576 460 752 303 423 488
60	1 152 921 504 606 846 976
61	2 305 843 009 213 693 952
62	4 611 686 018 427 387 904

Резервное копирование в Vertica

10 февраля, 2020 | BY Naik | Category: Vertica | Нет комментариев »

В Vertica мы храним аналитические данные, которые в принципе можно не бэкапировать, т.к. объем данных - не велик, и можно перезалить в любой момент. Но это касается лишь новых данных, есть часть данных из старых источников: Oracle, Excel и текстовых документов, которые не желательно перезаливать. Лучше восстановить данные из бэкапа, чем собирать данные из старых источников, которые, возможно, уже и не существуют или с ними что-то случилось.

Снимать бэкап нужно под пользователем dbadmin:

su dbadmin

Создайте директорию, в которую будет записана резервная копия:

mkdir /home/dbadmin/backups20190207

В Vertica создание резервной копии и восстановление из нее осуществуляется с помощью утилиты vbr (думаю, это означает Vertica Backup and Restore). Для vbr нужно создать конфигурационный файл, который используется как для создания копии, так и для восстановления из нее.

Примеры конфигурационных файлов можно посмотреть в каталоге:

/opt/vertica/share/vbr/example_configs

Создайте новый конфигурационный файл /opt/vertica/share/vbr/example_configs/backup_restore_your_database.ini со следующим содержимым:

[Mapping]
v_your_database_node0001 = []:/home/dbadmin/backups20190207
#v_your_database_node0002 = []:/home/dbadmin/backups20190207

[Misc]
tempDir = /tmp

[Database]
dbName = YOUR_DATABASE
dbUser = dbadmin
dbPassword = YOUR_PASSWORD
#dbPromptForPassword = True

Нужно перечислить все узлы вашего кластера: v_your_database_node0001, v_your_database_node0002 и т.д. В нашем случае кластера нет, поэтому одна нода.

В dbName, dbUser и dbPassword укажите параметры подключения к вашей базе данных.

Пароль можно не прописывать, а каждый раз запрашивать, расскомментировав строку: dbPromptForPassword = True.

Возможные проблемы

В данной инструкции явно прописана учетка и пароль, т.к. без этого возникала проблема подключения:

Unable to log vbr invocations. Error SQL command "select log_vbr_invocations('Full Backup Task', '/tmp/vbr_2020-01-04-115520.log', 'SQL6F52TLDAFPCZ9YZEOH83P9YYKL9HW', 'Fail');" failed: vsql: FATAL 3781:  Invalid username or password
Error: SQL command "select name,catalogpath from v_internal.vs_nodes;" failed: vsql: FATAL 3781:  Invalid username or password
Backup FAILED.

Инициализация директории

Перед непосредственным созданием бэкапа нужно проинициализировать указанную в конфиге директорию:

/opt/vertica/bin/vbr -t init -c /opt/vertica/share/vbr/example_configs/backup_restore_your_database.ini

Создание резервной копии

После инициализации директории выполните команду:

/opt/vertica/bin/vbr -t backup -c /opt/vertica/share/vbr/example_configs/backup_restore_your_database.ini

Восстановление из резервной копии

Для восстановления из резервной копии выполните команду:

/opt/vertica/bin/vbr -t restore -c /opt/vertica/share/vbr/example_configs/backup_restore_your_database.ini

TAG:Backup , Restore , vbr , Vertica

Профилирование CPU с помощью Flame Graph

5 февраля, 2020 | BY Naik | Category: Flame Graph, Профилирование | Нет комментариев »

Flame Graph позволяет визуально увидеть чем были заняты процессоры в течении определенного периода.

Снять Flame Graph можно по классической инструкции: https://github.com/BrendanGregg/FlameGraph, что требует некоторых манипуляций.

Но можно пойти более легким путем, используя async-profiler:

Скачиваем стабильный релиз в виде архива
Распаковываем архив
Выполняем команду:
```
./profiler.sh -d 30 -f /tmp/flamegraph.svg 
```
Где <PID> - это идентификатор Java-процесса.
-d 30 - продолжительность профилирования, в секундах.
/tmp/flamegraph.svg - файл сохранения Flame Graph.

Flame Graph можно прекрасно просматрировать в браузере без использования каких-либо дополнительных средств.

В этом можно убедиться на следующем примере Flame Graph (можно кликать на области):

Поиск искомого Java-процесса можно осуществляется через утилиту jps.

Скрипт, автоматизирующий поиск и снятие Flame Graph:

PID=`jps | grep YOUR_APP_NAME | awk '{print $1}'`
echo PID = $PID
FG=/tmp/flamegraph$PID.svg
echo FG = $FG
~/soft/async-profiler-1.6-macos-x64/profiler.sh -d 30 -f $FG $PID

p.s. Этому блогу исполнилось 7 лет!