AL
Size: a a a
2021 March 22
MA
а. а то я не понял
Обсуждалось тут: https://github.com/tarantool/tarantool/discussions/5641, с картинками
DS
Всем Привет ,возникли вопросы по работе с cartridge.
Вводная:
У меня есть следующая топология реализованная тарантулами и мне нужно перейти на катридж:
1) Роутер
2) Репликасеты с функциональностью A отмасштабированные
3) Репликасет с функциональностью B
Вопросы:
1) как мне строить взаимодействие с репликасетами группы A через роутер, я правильно понимаю что это делается как то так :
local router_role = cartridge.service_get('vshard-router')
local default_router = router_role.get()
Или все таки можно написать обращение к роли с вычисленным bucket_id , что то на подобие cartridge.rpc_call ?
Оформление роли всегда предполагает помещение функции роли в таблицу return или я просто расшарю свою таблицу , которая будет доступна на прямую при вызовах vshard.router.call ?
Интересует скажем так best practice
2) Обращение к не шардированной функциональности B из любой ноды кластера делать через cartridge.rpc_call ?
3) При добавление новых нод в кластер (ноды запускаем на разных физически машинах), кодовую базу ролей нужно отдельно от катриджа разливать ?
4) Если ноды кластера находятся физически на разных машинах , то перед стартом катриджа эти ноды нужно предварительно поднять , т.е по верх катриджа нужен еще например ansible ?
5) Как разливать настройки ролей по кластеру аналогично веб морде или нужно использовать config_patch_clusterwide ?
Вводная:
У меня есть следующая топология реализованная тарантулами и мне нужно перейти на катридж:
1) Роутер
2) Репликасеты с функциональностью A отмасштабированные
3) Репликасет с функциональностью B
Вопросы:
1) как мне строить взаимодействие с репликасетами группы A через роутер, я правильно понимаю что это делается как то так :
local router_role = cartridge.service_get('vshard-router')
local default_router = router_role.get()
Или все таки можно написать обращение к роли с вычисленным bucket_id , что то на подобие cartridge.rpc_call ?
Оформление роли всегда предполагает помещение функции роли в таблицу return или я просто расшарю свою таблицу , которая будет доступна на прямую при вызовах vshard.router.call ?
Интересует скажем так best practice
2) Обращение к не шардированной функциональности B из любой ноды кластера делать через cartridge.rpc_call ?
3) При добавление новых нод в кластер (ноды запускаем на разных физически машинах), кодовую базу ролей нужно отдельно от катриджа разливать ?
4) Если ноды кластера находятся физически на разных машинах , то перед стартом катриджа эти ноды нужно предварительно поднять , т.е по верх катриджа нужен еще например ansible ?
5) Как разливать настройки ролей по кластеру аналогично веб морде или нужно использовать config_patch_clusterwide ?
привет!
> через роутер, я правильно понимаю что это делается как то так
да, правильно
> Оформление роли всегда предполагает помещение функции роли в таблицу return или я просто расшарю свою таблицу , которая будет доступна на прямую при вызовах
можно и так и так, в саму роль функцию добавлять необходимо только для rpc_call
>Обращение к не шардированной функциональности B из любой ноды кластера делать через cartridge.rpc_call
да
> При добавление новых нод в кластер (ноды запускаем на разных физически машинах), кодовую базу ролей нужно отдельно от катриджа разливать ?
нет, они разливаются единым пакетом, со все и собранными зависимостями
> Если ноды кластера находятся физически на разных машинах , то перед стартом катриджа эти ноды нужно предварительно поднять , т.е по верх катриджа нужен еще например ansible ?
да
> Как разливать настройки ролей по кластеру аналогично веб морде или нужно использовать config_patch_clusterwide ?
Да, аналогично веб-морде. но бывает и через patch_clustterwide - если для смены конфига пишется какой-то кастомный апи (пример можно посомтреть в sharded-queue например)
> через роутер, я правильно понимаю что это делается как то так
да, правильно
> Оформление роли всегда предполагает помещение функции роли в таблицу return или я просто расшарю свою таблицу , которая будет доступна на прямую при вызовах
можно и так и так, в саму роль функцию добавлять необходимо только для rpc_call
>Обращение к не шардированной функциональности B из любой ноды кластера делать через cartridge.rpc_call
да
> При добавление новых нод в кластер (ноды запускаем на разных физически машинах), кодовую базу ролей нужно отдельно от катриджа разливать ?
нет, они разливаются единым пакетом, со все и собранными зависимостями
> Если ноды кластера находятся физически на разных машинах , то перед стартом катриджа эти ноды нужно предварительно поднять , т.е по верх катриджа нужен еще например ansible ?
да
> Как разливать настройки ролей по кластеру аналогично веб морде или нужно использовать config_patch_clusterwide ?
Да, аналогично веб-морде. но бывает и через patch_clustterwide - если для смены конфига пишется какой-то кастомный апи (пример можно посомтреть в sharded-queue например)
Т
привет!
> через роутер, я правильно понимаю что это делается как то так
да, правильно
> Оформление роли всегда предполагает помещение функции роли в таблицу return или я просто расшарю свою таблицу , которая будет доступна на прямую при вызовах
можно и так и так, в саму роль функцию добавлять необходимо только для rpc_call
>Обращение к не шардированной функциональности B из любой ноды кластера делать через cartridge.rpc_call
да
> При добавление новых нод в кластер (ноды запускаем на разных физически машинах), кодовую базу ролей нужно отдельно от катриджа разливать ?
нет, они разливаются единым пакетом, со все и собранными зависимостями
> Если ноды кластера находятся физически на разных машинах , то перед стартом катриджа эти ноды нужно предварительно поднять , т.е по верх катриджа нужен еще например ansible ?
да
> Как разливать настройки ролей по кластеру аналогично веб морде или нужно использовать config_patch_clusterwide ?
Да, аналогично веб-морде. но бывает и через patch_clustterwide - если для смены конфига пишется какой-то кастомный апи (пример можно посомтреть в sharded-queue например)
> через роутер, я правильно понимаю что это делается как то так
да, правильно
> Оформление роли всегда предполагает помещение функции роли в таблицу return или я просто расшарю свою таблицу , которая будет доступна на прямую при вызовах
можно и так и так, в саму роль функцию добавлять необходимо только для rpc_call
>Обращение к не шардированной функциональности B из любой ноды кластера делать через cartridge.rpc_call
да
> При добавление новых нод в кластер (ноды запускаем на разных физически машинах), кодовую базу ролей нужно отдельно от катриджа разливать ?
нет, они разливаются единым пакетом, со все и собранными зависимостями
> Если ноды кластера находятся физически на разных машинах , то перед стартом катриджа эти ноды нужно предварительно поднять , т.е по верх катриджа нужен еще например ansible ?
да
> Как разливать настройки ролей по кластеру аналогично веб морде или нужно использовать config_patch_clusterwide ?
Да, аналогично веб-морде. но бывает и через patch_clustterwide - если для смены конфига пишется какой-то кастомный апи (пример можно посомтреть в sharded-queue например)
>нет, они разливаются единым пакетом, со все и собранными зависимостями
если мне нужно обновить кодовую базу , допустим одну роль ?
>Да, аналогично веб-морде. но бывает и через patch_clustterwide - если для смены конфига пишется какой-то кастомный апи (пример можно посомтреть в sharded-queue например)
чем заменить веб морду при разливке конфига , есть ли пример ?
если мне нужно обновить кодовую базу , допустим одну роль ?
>Да, аналогично веб-морде. но бывает и через patch_clustterwide - если для смены конфига пишется какой-то кастомный апи (пример можно посомтреть в sharded-queue например)
чем заменить веб морду при разливке конфига , есть ли пример ?
DS
>нет, они разливаются единым пакетом, со все и собранными зависимостями
если мне нужно обновить кодовую базу , допустим одну роль ?
>Да, аналогично веб-морде. но бывает и через patch_clustterwide - если для смены конфига пишется какой-то кастомный апи (пример можно посомтреть в sharded-queue например)
чем заменить веб морду при разливке конфига , есть ли пример ?
если мне нужно обновить кодовую базу , допустим одну роль ?
>Да, аналогично веб-морде. но бывает и через patch_clustterwide - если для смены конфига пишется какой-то кастомный апи (пример можно посомтреть в sharded-queue например)
чем заменить веб морду при разливке конфига , есть ли пример ?
> если мне нужно обновить кодовую базу , допустим одну роль ?
да, все равно. есть альтернатива - куски кода можно грузить через конфиг (он может включать луа-файлы). тогда их можно будет обновлять через обновление конфига - но обработку такого кода надо будет описать в роли.
а, и плюс теперь еще хотрелоад кода ролей есть - т е можно разлить обнову кода ролей и применить ее без рестартов
> чем заменить веб морду при разливке конфига , есть ли пример ?
есть просто хттп-ендпоинт /admin/config например. веб-морда его и использует, можно прямо в ней и подсмотреть (в консоли браузера). ансибл кажется использует луа-апи, но тут навскидку не помню, надо по сорцам смотреть
да, все равно. есть альтернатива - куски кода можно грузить через конфиг (он может включать луа-файлы). тогда их можно будет обновлять через обновление конфига - но обработку такого кода надо будет описать в роли.
а, и плюс теперь еще хотрелоад кода ролей есть - т е можно разлить обнову кода ролей и применить ее без рестартов
> чем заменить веб морду при разливке конфига , есть ли пример ?
есть просто хттп-ендпоинт /admin/config например. веб-морда его и использует, можно прямо в ней и подсмотреть (в консоли браузера). ансибл кажется использует луа-апи, но тут навскидку не помню, надо по сорцам смотреть
ЯШ
curl -XPUT --data-binary @<name>.yml http://server:port/admin/config
ЯШ
В ансибле в инвентори конфиг кладется в переменную: cartridge_app_config
2021 March 23
V
Всем доброе время суток.
Пишу приложение на в tarantool которое активно обращается к внешним http ресурсам, создается множество файберов.
Периодически стала появляться проблема: процесс tarantool грузит ядро на 100%,
Версия
Выполнил сбор показателей производительности:
Выполнил формирование читаемого отчета:
Из отчета вижу, что 99.9% процессора приходится сюда:
Подскажите следующие шаги для выяснения проблемной части кода
Пишу приложение на в tarantool которое активно обращается к внешним http ресурсам, создается множество файберов.
Периодически стала появляться проблема: процесс tarantool грузит ядро на 100%,
tarantoolctl enter не подключается. Вероятно где-то образовался бесконечный цикл...Версия
Tarantool 2.6.2-0-g34d504d7d
В документации нашел подходящий раздел: "Просмотр состояния сервера".Выполнил сбор показателей производительности:
perf record -g -p.Выполнил формирование читаемого отчета:
perf report -n -g --stdio
Но не понятно, какой файбер, какие инструкции съели процессор.Из отчета вижу, что 99.9% процессора приходится сюда:
71.85%--http_parse_header_lineК сожалению мне не понятно - куда копать дальше.
28.15%--luaT_httpc_request
Подскажите следующие шаги для выяснения проблемной части кода
MF
- сделать дамп процесса
- открыть через гдб
- догрузить расширение luajit-gdb.py
- посмотреть стектрейс
- открыть через гдб
- догрузить расширение luajit-gdb.py
- посмотреть стектрейс
V
- сделать дамп процесса
- открыть через гдб
- догрузить расширение luajit-gdb.py
- посмотреть стектрейс
- открыть через гдб
- догрузить расширение luajit-gdb.py
- посмотреть стектрейс
Версия tarantool с подробностями:
gdb ругнулся, что версия исходного файла старше и не уверен, что дамп корректный создался:
2) Предположительно, по содержимом трейс файла вижу, что идет обработка http ответа от моего устройства. В lua коде мне понятно место, где идет обработка этого ответа. Но прблем с lua кодом не видно. Возможно ли, что это проблема с http_client:request()?
Трейс прилагаю в следующем сообщении
tarantool -vВыполняю команду для создания дампа в каталоге с исходным кодом tarantool. git переключил на tag 2.6.2.
Tarantool 2.6.2-0-g34d504d7d
Target: Linux-x86_64-RelWithDebInfo
Build options: cmake . -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_BACKTRACE=ON
Compiler: /usr/bin/cc /usr/lib/ccache/g++
C_FLAGS:-g -O2 -fdebug-prefix-map=/build/tarantool-2.6.2.0=. -specs=/usr/share/dpkg/no-pie-compile.specs -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fexceptions -funwind-tables -fno-omit-frame-pointer -fno-stack-protector -fno-common -fopenmp -msse2 -std=c11 -Wall -Wextra -Wno-strict-aliasing -Wno-char-subscripts -Wno-format-truncation -Wno-gnu-alignof-expression -fno-gnu89-inline -Wno-cast-function-type
CXX_FLAGS:-g -O2 -fdebug-prefix-map=/build/tarantool-2.6.2.0=. -specs=/usr/share/dpkg/no-pie-compile.specs -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fexceptions -funwind-tables -fno-omit-frame-pointer -fno-stack-protector -fno-common -fopenmp -msse2 -std=c++11 -Wall -Wextra -Wno-strict-aliasing -Wno-char-subscripts -Wno-format-truncation -Wno-invalid-offsetof -Wno-gnu-alignof-expression -Wno-cast-function-type
gdb ругнулся, что версия исходного файла старше и не уверен, что дамп корректный создался:
# gdb -batch -ex "generate-core-file" -p 1169082Создание трейса тоже ругнулось на версию файла исходного кода:
[New LWP 1169095]
[New LWP 1169099]
[New LWP 1169100]
[New LWP 1169101]
[New LWP 1169103]
[New LWP 1203424]
[New LWP 1203430]
[New LWP 1203431]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
http_parse_header_line (prsr=prsr@entry=0x7f61a217fe60, bufp=bufp@entry=0x7f61a217fe58, end_buf=end_buf@entry=0x7f61a1778078 "e\":22.7,\"Humidity\":38.0,\"DewPoint\":7.7,\"Pressure\":992.3},\"MHZ19B\":{\"Model\":\"B\",\"CarbonDioxide\":400,\"Temperature\":25.0},\"PressureUnit\":\"hPa\",\"TempUnit\":\"C\"}}oad\r\nAccess-Control-Allow-Origin: *\r\nAccess-"..., max_hname_len=max_hname_len@entry=32) at ./src/lib/http_parser/http_parser.c:428
warning: Source file is more recent than executable.
428 return HTTP_PARSE_CONTINUE;
warning: Memory read failed for corefile section, 4096 bytes at 0xffffffffff600000.
Saved corefile core.1169082
[Inferior 1 (process 1169082) detached]
# gdb -se "tarantool" -ex "bt full" -ex "thread apply all bt" --batch -c core.1169082 > tarantool_trace.txt1) Подскажите, как подключить дополнение luajit-gdb.py? Виже его в git с исходным кодом tarantool, но как включить не понял.
warning: Source file is more recent than executable.
2) Предположительно, по содержимом трейс файла вижу, что идет обработка http ответа от моего устройства. В lua коде мне понятно место, где идет обработка этого ответа. Но прблем с lua кодом не видно. Возможно ли, что это проблема с http_client:request()?
Трейс прилагаю в следующем сообщении
V
MF
MF
вот это выполнять в запущенном gdb
AT
Dmitry Lukovkin
В общем не все так просто с установкой метрик на 8 центоси
В репе нет модуля tarantool-checks, вышел из положения скачав и установив модуль с репозитория 1.10 - tarantool-checks-3.0.1.2-1.el8.noarch.rpm с packagecloud.io. Все установилось после этого нормально.
Возникла теперь другая проблема - нет модуля http.server в репозиториях для 8 центоси(ни в вашем ни на packagecloud.io). Без него не могу настроить выгрузку в прометеус. Останавливается на
httpd = require('http.server').new('0.0.0.0', 8080)
- error: "[string \"httpd = require('http.server').new('0.0.0.0',...\"]:1: module
'http.server' not found:\n\tno field package.preload['http.server']\n\tno file
'/http/server.lua'
При попытке установки пишет
Нет соответствия аргументу: tarantool-http
В репе нет модуля tarantool-checks, вышел из положения скачав и установив модуль с репозитория 1.10 - tarantool-checks-3.0.1.2-1.el8.noarch.rpm с packagecloud.io. Все установилось после этого нормально.
Возникла теперь другая проблема - нет модуля http.server в репозиториях для 8 центоси(ни в вашем ни на packagecloud.io). Без него не могу настроить выгрузку в прометеус. Останавливается на
httpd = require('http.server').new('0.0.0.0', 8080)
- error: "[string \"httpd = require('http.server').new('0.0.0.0',...\"]:1: module
'http.server' not found:\n\tno field package.preload['http.server']\n\tno file
'/http/server.lua'
При попытке установки пишет
Нет соответствия аргументу: tarantool-http
Я попросил @avtikhon посмотреть. Спасибо.
V
вот это выполнять в запущенном gdb
Добавил строку
Похоже нормально подключается дополнение, в стектрейсе есть об этом инфа.
Визуально стектрейс особенно не изменился.
Оговорюсь - опыта отладки на таком уровне у меня нет. На данный момент больше догадки: по ощущениям тарантул бесконечно парсит http ответ.
Для проверки попробовал отключить сеть. То-есть фактически http запросы и ответы не могут уходить/приходить. Но поведение tarantool не меняется, продолжает писать в трейсе тоже самое.
Трейс прикладываю.
source ./third_party/luajit/src/luajit-gdb.py в файл .gdbinit.Похоже нормально подключается дополнение, в стектрейсе есть об этом инфа.
Визуально стектрейс особенно не изменился.
Оговорюсь - опыта отладки на таком уровне у меня нет. На данный момент больше догадки: по ощущениям тарантул бесконечно парсит http ответ.
Для проверки попробовал отключить сеть. То-есть фактически http запросы и ответы не могут уходить/приходить. Но поведение tarantool не меняется, продолжает писать в трейсе тоже самое.
Трейс прикладываю.
ОБ
http_parse_header_line Сходу вспоминается вот эта проблема - https://github.com/tarantool/tarantool/commit/462bd104a36f332d122a0579bf24d672f38fad68
ОБ
И, судя по всему, этого патча нет ещё в 2.6.2
MF
http_parse_header_line Сходу вспоминается вот эта проблема - https://github.com/tarantool/tarantool/commit/462bd104a36f332d122a0579bf24d672f38fad68
оно похоже могло зациклиться на парсинге