Segfault when using Prometheus metrics

[Ivelok]

Привет!

Мы собрали Odyssey с Master ветки, настроили и включили Prometheus метрики параметром
log_route_stats_prom yes

Однако при использовании этого параметра Odyssey периодически падает с ошибкой Segmentation fault

[ilya-maltsev]

@Ivelok
Привет!
Очень интересно, а конфиг свой можете предоставить?

[Ivelok]

@ilya-maltsev Вот.
config.txt

У нас были подозрение на большой объём файла, но пока сократить его не получилось :)
Пробовали увеличить coroutine_stack_size до 32, меняли количество worker, но это всё не помогло :(

[ilya-maltsev]

@Ivelok
с такого конфига трудно не уйти в Segmentation fault :)
Попробуйте отловить ошибку на дебаг-сборке, которую можно создать выполнив команду make build_asan

[Ivelok]

@ilya-maltsev Я правильно понимаю, что после сборки build_asan нужно собрать CoreDump при падении и через gdb посмотреть его содержимое?

[ilya-maltsev]

@Ivelok
Примерно так и есть.

[Ivelok]

@ilya-maltsev По какой-то причине в asan сборке не делается coredump :(

В обычной сборке работало.

[ilya-maltsev]

@Ivelok
Coredump можно и с обычного бинарника собрать, но и также интересно было бы посмотреть выхлоп AddressSanitizer (ASan) в момент сбоя

[Ivelok]

@ilya-maltsev А он ничего не писал в момент сбоя. Просто контейнер перезапускался с кодом 139 и всё :(

Выхлоп bt full могу прислать.

[ilya-maltsev]

@Ivelok
можно попробовать указать в конфиге:
log_debug yes
и, конечно, не стесняясь, присылайте все, что есть по данной проблеме :)

[ilya-maltsev]

@Ivelok
указанный в приложенном дампе сбой возник при запуске odyssey или произошел спустя некоторое время после запуска?

[Ivelok]

@ilya-maltsev
Это спустя некоторое время, не помню точно сколько, но около 5-15 минут.

P.s. спасибо :)

[ilya-maltsev]

@Ivelok
попробуйте установить значение параметра log_stats no

try change value of param log_stats from yes to no
it seems that log_stats and log_general_stats_prom/log_route_stats_prom cannot be enabled at the same time because prometheus library output cannot be placed into plain logger

[Ivelok]

@ilya-maltsev Если указать log_stats no, то метрик вообще нет :)

[ilya-maltsev]

@Ivelok
в stdout метрик prometheus не будет, они будут доступны через http-порт 9127:
curl 'localhost:9127/metrics'

[Ivelok]

Именно там я их и смотрю, в других местах они мне не интересны :)

# HELP process_max_fds Maximum number of open file descriptors.
# TYPE process_max_fds gauge
process_max_fds 1048576

# HELP process_virtual_memory_max_bytes Maximum amount of virtual memory available in bytes.
# TYPE process_virtual_memory_max_bytes gauge
process_virtual_memory_max_bytes -1

# HELP process_cpu_seconds_total Total user and system CPU time spent in seconds.
# TYPE process_cpu_seconds_total gauge
process_cpu_seconds_total 0

# HELP process_virtual_memory_bytes Virtual memory size in bytes.
# TYPE process_virtual_memory_bytes gauge
process_virtual_memory_bytes 715890688

# HELP process_start_time_seconds Start time of the process since unix epoch in seconds.
# TYPE process_start_time_seconds gauge
process_start_time_seconds 189206829

# HELP process_open_fds Number of open file descriptors.
# TYPE process_open_fds gauge
process_open_fds 112

# HELP database_len Total databases count
# TYPE database_len gauge

# HELP server_pool_active Active servers count
# TYPE server_pool_active gauge

# HELP sever_pool_idle Idle servers count
# TYPE sever_pool_idle gauge

# HELP user_len Total users count
# TYPE user_len gauge

# HELP msg_allocated Messages allocated
# TYPE msg_allocated gauge

# HELP msg_cache_count Messages cached
# TYPE msg_cache_count gauge

# HELP msg_cache_gc_count Messages freed
# TYPE msg_cache_gc_count gauge

# HELP msg_cache_size Messages cache size
# TYPE msg_cache_size gauge

# HELP count_coroutine Coroutines running
# TYPE count_coroutine gauge

# HELP count_coroutine_cache Coroutines cached
# TYPE count_coroutine_cache gauge

# HELP clients_processed Number of processed clients
# TYPE clients_processed gauge

# HELP client_pool_total Total database clients count
# TYPE client_pool_total gauge

# HELP avg_tx_count Average transactions count per second
# TYPE avg_tx_count gauge

# HELP avg_tx_time Average transaction time in usec
# TYPE avg_tx_time gauge

# HELP avg_query_count Average query count per second
# TYPE avg_query_count gauge

# HELP avg_query_time Average query time in usec
# TYPE avg_query_time gauge

# HELP avg_recv_client Average in bytes/sec
# TYPE avg_recv_client gauge

# HELP avg_recv_server Average out bytes/sec
# TYPE avg_recv_server gauge

[ilya-maltsev]

@Ivelok
в таком случае самым простым будет выпилить функционал логирования метрик prometheus в stdout (который расположен тут и тут)

[Ivelok]

Прощу прощения, я тут немного упал в работу и забыл отписать.

По итогу нам помогло увеличение coroutine_stack_size до 1024 :)

[ilya-maltsev]

@Ivelok
если не затруднит - покажите график утилизации памяти через неделю) когда она кончится :)

[Ivelok]

Выглядит хорошо :)

[ilya-maltsev]

@Ivelok
Выглядит, как будто нет нагрузки, но всеравно спасибо!

[ramili4]

У меня такая же проблема но с одиссеем в контейнере. Есть другие идеи?)

[Ivelok]

@ramili4 Привет!

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

[ramili4]

Спасибо, попробуем. А нет решения утечки памяти?

[Ivelok]

У меня нет. Вероятно это особенность реализации пром-метрик.

[ramili4]

@ramili4 Привет!

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

Поднял до 2048. минут на 5 хватило) снова вылетает с ошибкой 139

[ramili4]

Еще вопрос возник - у меня периодически количество метрик меняется. Может связано с библиотеками prom и promhttp? Я уже и компилировал Prometheus client и оттуда из доставал, и так скачивал, и все равно количество метрик разное каждый раз)