От переводчика: Для этой статьи, вероятно, подошел бы заголовок "Незнание значений по умолчанию не освобождает от ответственности". Перед нами классический пример "эффекта швейцарского сыра", когда несколько мелочей приводят к сбоям, интересным и долгим расследованиям и героическому преодолению трудностей.

Сайт мониторинга ситуации по коронавирусу Соединенного Королевства - основной сервис отчетности во время пандемии COVID-19 для всей страны. Он испытывает нагрузку порядка 45–50 миллионов запросов в день и относится к национальным сервисам критической важности.

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

Есть только одно исключение - наша база данных. Сервис работает с использованием специальной версии PostgreSQL: Hyperscale Citus. Тот факт, что наша база данных не соответствует архитектуре active-active — это не следствие того, что мы не знаем, как делать реплики для чтения, скорее - результат логистических проблем, обсуждение которых выходит за рамки этой статьи.

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

Замечательное обновление

СУБД PostgreSQL 14 была официально выпущена 30 сентября 2021 года. Помимо всего остального, новая версия предлагала расширенную модель безопасности и прирост производительности запросов к сегментированным таблицам.

Мы очень радовались этому факту, хотя, в силу того, что у нас был полностью облачный сервис СУБД, мы думали, что мы не сможем обновить нашу БД до весны 2022 года, самое раннее.

Но благодаря отличной работе команды Azure Postgres, наши ощущения оказались ложными и новое обновление стало доступным для облачных СУБД в Azure в течение 24 часов.

Это было огромное достижение команды Azure Postgres - новая веха в поддержке облачных сервисов баз данных. И это обновление оказалось даже лучше, чем мы ожидали, потому что оно также предлагало новую версию модуля Citus 10. В этой версии было исправлено несколько багов, которые мы нашли в предыдущем релизе.

Вместе с командой Azure Postgres (Citus), мы развернули новую версию нашего окружения для разработки вечером в среду, 13 октября 2021. Все прошло очень гладко, мы наблюдали за всем в течение 48 часов и сделали несколько нагрузочных тестов перед тем, как запустить развертывание на промышленное окружение в полночь субботы, 16 октября, 2021. Процесс развертывания закончился около 11 утра в субботу без проблем.

Все было прекрасно и пахло розами.

Что ещё произошло?  

На следующей после обновления неделе мы сделали несколько изменений в сервисе:

Второе обновление было нацелено на:

  • уменьшение зависимости от БД;

  • уменьшение времени ответа во время пиковой нагрузки;

  • использование Redis для дорогостоящих запросов;

  • использование решения из нашего ETL для предварительного заполнения кэша

Неделя перед судной ночью

До конца недели мне в Твиттере написали несколько человек и сообщили, о росте количества ошибок в запросах ко второй версии API (APIv2).

Самое странное, что они говорили, это то, что было невозможно скачать новые данные через API после релиза, т. е. в 4 вечера.

Первое, что я делаю в таких случаях - проверяю сервис API и наши экземпляры PGBouncer, чтобы убедится, что с ними все в порядке. Затем я обычно очищаю кэш данных для APIv2, и это обычно решает проблему.

Количество жалоб ко мне в Твиттере увеличилось. Люди теперь жаловались на увеличивающиеся задержки при использовании нашего GenericAPI. Это беспокоило меня, потому что, в отличие от APIv2, который мы активно замедляем и который предназначен для загрузок очень больших объемов данных, Generic API был написан на Go и использует сильно оптимизированные запросы для быстрого ответа. В то время, как загрузка данных через APIv2 может занять 3 или 4 минуты, средняя задержка ответа для GenericAPI – 30–50 миллисекунд.

Я ещё раз проверил инфраструктуру и даже откатил несколько изменений Generic API, чтобы убедиться, что это ошибка не из-за этих недавних, хотя и небольших, изменений. Но нет.

Катастрофический выходной 

В воскресенье, 31 октября 2021 года, у нас случился критический отказ: все наши ETL процессы завершались с ошибкой, мы не могли загрузить новые данные в базу. Причина? Ошибка соединения или невозможность поддержки соединения с базой данных.

Я подчеркивал ранее, что все соединения с БД происходят через пул соединений (PGBouncer), который развернут на двух мощных виртуальных машинах с 64 Гб памяти и 16 процессорными ядрами (Standard D16 v4), которые управлялись с использованием Azure VM Scale Set.

Почему мы используем PGBouncer?

По сути, база данных предоставляет ограниченное число одновременных соединений. Можно поменять или увеличить это число, но тут есть издержки. Чем больше соединений, тем больше памяти расходуется. В Postgres каждое соединение использует примерно 10 Мб памяти. Это также означает, что можно запустить больше одновременно работающих процессов, что, в свою очередь, требует ещё больше ресурсов для выполнения.

В большинстве случаев соединения с БД не нужно поддерживать, они нужны только на время выборки данных и ожидания ответа. Однако, приложения стремятся забирать соединения навсегда.

PGBouncer, да и в целом пулы соединений, смягчают ситуацию тем, что они постоянно поддерживают фиксированное число соединений к БД (986 в нашем случае) и предоставляют короткоживущие соединения их клиентским приложениям, а затем возвращают результат запроса клиенту. Короче говоря, 986 соединений превращаются в 5000.

Как долго поддерживается соединение между клиентом и PGBouncer? Это зависит от настроек, но в нашем случае оно поддерживается для одной транзакции.

Я только недавно включил ускоренное сетевое соединение для экземпляров PGBouncer, так что у них не было причины падать, но, тем не менее они показывались как “сбойные”

Проверка состояния для PGBouncer сделана в виде пинга Postgres. Это означает, что (помимо исчерпания ресурсов процессора или памяти), есть только одна причина для того, чтобы они сбоили: проблема с СУБД.

Естественно, следующий шаг, который я сделал - проверка базы данных. И вот что я увидел:

Все было в порядке ???? !

Но так не могло быть, и нужно было копать глубже. Единственной проблемой было то, что сейчас 12:45, середина дня, а мы ещё не загрузили данные. Время было на исходе...

Затем я проверил количество соединений:

ОК, тут все было нормально... за исключением пиков, отмеченных красными стрелками. Они коррелировали с нашими попытками загрузки данных. Это было странно, потому что нам никогда не требовалось 150 соединений для загрузки. Обычно было достаточно 30 или 40.

Затем я проверил процессор... и вот тогда я понял настоящий смысл Хэллоуина ???? :

Это не могло произойти. Не на этом сервере. Но это произошло!

Я оповестил команду Azure Postgres, но они, в основном, находились в США и это все происходило в воскресенье. И не просто в воскресенье, а в Хэллоуин ???? . Напоминаю, что это не служба поддержки Azure, это команда разработчиков этого сервиса, и ребята, которых я знаю, не должны быть на связи 24/7.

У меня не было времени что-то предпринять в тот момент, было уже 14:50, все что я знал - нужно было, очевидно, уменьшить нагрузку на БД, чтобы иметь возможность загрузить данные. Всё, о чем я мог думать - принудительно уменьшить количество соединений к БД, так что я выключил 70% наших серверов. Это сработало, и мы смогли завершить загрузку первой порции данных в 15:08. Мы еле-еле успели загрузить все к 15:58, я включил все серверы, и мы опубликовали данные в 16:01.

Но всё было далеко от завершения 

А потом мы испытали значительное ухудшение работы APIv1. Эта проблема стала очень критичной. APIv1 это наш интерфейс Open Data. Это то, с помощью чего мы показываем данные на нашем вебсайте и этот API интенсивно используется разными организациями от местных служб до министерства здравоохранения, кабинета премьер-министра, ВОЗ и университета Хопкинса. Проблемы с API стали заметными к 16:30, в воскресенье, 31 октября 2021 года.

Важно рассмотреть это в перспективе. Большинство сообщений, которые я получал, были о проблемах во время публикации данных. Затем, после публикации мы испытали моментальный взлет количества запросов. Вот как выглядел трафик во время релиза:

Это означает, что возможны редкие ошибки то тут, то там, но не для 50% запросов, как это было 31 октября:

Была ещё одна интересная закономерность. Посмотрите на участок графика, отмеченный серой стрелкой. Это тот момент, когда 70% серверов было выключено и количество необслуженных запросов уменьшилось! Но этого не может быть. У нас большое количество доступных соединений, у нас они просто не могли закончиться. Хорошо, это не было пиковой загрузкой, и мы все равно не использовали все серверы. Но все равно, как могло упасть количество ошибок, если мы уменьшили вычислительные мощности на 70%?

Почему уменьшилось количество ошибок?  

И тут все стало ещё сложнее.

После напряженного расследования и замеров производительности оказалось, что наши запросы стали выполняться гораздо медленнее.  

Пример: хорошо оптимизированный, протестированный запрос из нашего Generic API, который при нормальных условиях должен выполняться 1.5 миллисекунды:

SELECT
   area_code    AS "areaCode",
   area_name    AS "areaName",
   ar.area_type AS "areaType"
FROM covid19.area_reference AS ar
WHERE LOWER(area_type) = LOWER('region')
  AND area_name ILIKE 'London'
LIMIT 1 OFFSET 0;

Я запустил анализ запроса:

EXPLAIN (ANALYZE, BUFFERS)
SELECT
   area_code    AS "areaCode",
   area_name    AS "areaName",
   ar.area_type AS "areaType"
FROM covid19.area_reference AS ar
WHERE LOWER(area_type) = LOWER('region')
  AND area_name ILIKE 'London'
LIMIT 1 OFFSET 0;

И результат был:

...
  Buffers: shared hit=5
Planning Time: 0.119 ms
Execution Time: 57.190 ms

Это заняло ~57 миллисекунд! Как это возможно? Падение производительности примерно в 40 раз.

Затем я проверил активности в БД и посмотрел, какие запросы выполняются и как долго:

SELECT usename, 
       state, 
       query, 
       state_change - query_start AS time_lapsed 
FROM pg_stat_activity;

Нашлось 140 запросов, но больше половины из них содержали это:

WITH RECURSIVE typeinfo_tree(
    oid, ns, name, kind, basetype, elemtype, elemdelim,
    range_subtype, attrtypoids, attrnames, depth)
AS (
    SELECT
        ti.oid, ti.ns, ti.name, ti.kind, ti.basetype,
        ti.elemtype, ti.elemdelim, ti.range_subtype,
        ti.attrtypoids, ti.attrnames, 0
    FROM
            (...

Эти запросы показывались как IDLE, и величина параметра time_lapsed между запуском запроса и изменением состояния была достаточно значительной.

Последующее расследование показало, что этот запрос выполнялся asyncpg, API драйвера, который мы используем в нашем Python коде для выполнения асинхронных операций с Postgres.

В ходе дальнейших исследований выяснилось, что эта проблема уже была замечена в сообществе:

В процессе обсуждении тикета оказалось, что проблема связана с настройкой, которая включала JIT (Just-In-Time compilation) и она была включена по умолчанию для Postgres 14, когда СУБД была скомпилирована с использованием LLVM.

Я нашел это примерно в 23:40 в понедельник, 1 ноября после обсуждений, которые у меня были ранее, примерно в 21:30 с командой Azure Postgres (Citus), где JIT упоминался как возможная причина.

Я все ещё не верил в то, что причина найдена, но затем получил сообщение команды Citus, в котором говорилось, что после тщательного расследования было установлено, что проблема именно во включенном JIT. Самое интересное, что мне прислали ссылку на то же обсуждение в GitHub.

У нас была гипотеза и, очевидно, нужно было ее проверить. Они выслали мне довольно объемный запрос, который нужно было запустить и проверить результат:

Planning Time: 3.283 ms
JIT:
  Functions: 147
  Options: Inlining true, Optimization true, Expressions true, Deforming true
  Timing: Generation 17.460 ms, Inlining 15.796 ms, Optimization 525.188 ms, Emission 350.897 ms, Total 909.340 ms
Execution Time: 911.799 ms

Отлично, теперь у нас есть тест производительности. Но посмотрите ещё раз, у нас также была проблема, которая показала себя:

JIT:
  Functions: 147
  Options: Inlining true, Optimization true, Expressions true, Deforming true
  Timing: Generation 17.460 ms, Inlining 15.796 ms, Optimization 525.188 ms, Emission 350.897ms, Total 909.340 ms
  

JIT оптимизация выполнялась 909.340 миллисекунд !

Время выключить JIT - сейчас 00:20, это отличное время для эксперимента:

В 00:22 мы запустили запрос снова и вот что увидели:

Planning Time: 3.159 ms
Execution Time: 0.409 ms

И вот так вот просто время выполнения уменьшилось в 2,229 раз?

На следующий день мы увидели значительное уменьшение потребления процессора в Postgres. Вертикальная линия на графике отмечает время 00:22, точку, когда мы выключили JIT.

Проблема решена! ????

Итоговые соображения 

Проблемы вроде этой достаточно сложно идентифицировать, потому что они проявляются как каскад ошибок, по следам которых надо пройти. И даже тогда необходимо поработать детективом и исследователем, чтобы дойти до сути.

JIT в Postgres 

JIT компиляция - полезная вещь, вопросов нет. Однако, это не та функциональность, которая должна быть включена по умолчанию. JIT компиляция должна использоваться только в сценариях, подобных этим:

  • Процессы, которые выполняют аналитические вычисления или работают по столбцам таблицы - и для всей таблицы.

  • Запросы, которые долго выполняются без JIT, и:

  • Запросы, которые не вызываются постоянно

Это работает так же, как и JIT компиляторы в Python или .NET, которые оптимизируют код для более быстрого исполнения. Они исключительно полезны для приложений, которые работают в течение продолжительного времени. Компиляторы уменьшают стоимость исполнения приложений, а пользователи ждут ответа меньше.

В этом случае преимущества значительны, потому что дополнительные накладные расходы незаметны после фазы старта приложения, во время которой JIT процесс выполняет компиляцию.

Однако, это не годится для случая, когда мы выполняем короткие, хорошо оптимизированные запросы к БД десятки, если не сотни раз в секунду - особенно, если мы делаем компиляцию каждый раз, когда нам приходит этот запрос. Это не создало бы никаких проблем, если бы скомпилированные запросы кэшировались, но на текущий момент это не так.

Кэш таких запросов мог бы хранить бинарные данные и в качестве ключа использовать хэш от строки запроса. Время жизни (TTL) кэша можно было бы сделать настраиваемым с длительностью по умолчанию что-то вроде 5 минут. Однако, нужно признать, что в команде разработчиков ядра PostgreSQL работают весьма умные и компетентные инженеры, которые знают, что они делают и которые наверняка подумали о кэшировании скомпилированных запросов. Так что я остаюсь с верой в то, что этот подход не был реализован по каким-то причинам, о которых мы не догадываемся.

Пороги срабатывания

Игра с порогами срабатывания JIT на основе стоимости транзакций, по-моему, окажет не слишком большое воздействие - не в том случае, когда у вас есть огромная, но адекватно индексированная БД.

Обратное давление 

Ещё одна проблема здесь - давление событий. Когда оптимизированный запрос, который должен выполняться 1 миллисекунду, выполняется 5 секунд - возможно из-за того, что в нем есть рекурсивное выражение общей таблицы (common table expression, CTE) - процессор БД остается загруженным. JIT компиляция потребляет много процессорного времени, и процессор не может обработать большое количество таких запросов.

Это значит, что другие запросы, возможно, даже идентичные этим (счет которых может идти на сотни), остановлены и ожидают своей очереди на выполнение, пополняя список отложенных задач.

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

  • Что приводит к увеличению времени ответа

  • Что может привести к срабатыванию порога таймаута в клиентском приложении

  • Что приводит к ошибкам в запросах

  • Что приводит к тому, что экземпляр приложения рапортует, что он сломан

  • Что приводит к созданию нового экземпляра и запуску процесса масштабирования

  • Что приводит к увеличению количества соединений к БД

  • Что добавляет давления на БД

...и дальше вы уже все видели.

Как мы узнаем, что JIT полезен?

Нет эталонного процесса, которому надо следовать, это сильно зависит от приложения. Хороший способ определения полезности, тем не менее, остается включение JIT для определенных транзакций и проведение тестов производительности:

BEGIN;
SET LOCAL jit = ON;

EXPLAIN (BUFFERS, ANALYSE) 
-- The query
;

COMMIT;

Нужно заметить, что наш запрос слишком простой и попадает в категорию ниже порога срабатывания `jit_above_cost` и процесс может не запуститься. Можно временно уменьшить порог, чтобы это предотвратить.

Давайте потестируем запрос к нашей БД в качестве примера.

Без JIT:

EXPLAIN (BUFFERS, ANALYSE)
SELECT metric,
       area_code,
       MAX(area_name) AS area_name,
       percentile_cont(.25) WITHIN GROUP (ORDER BY (ts.payload ->> 'value')::FLOAT) AS first_quantile,
       percentile_cont(.5)  WITHIN GROUP (ORDER BY (ts.payload ->> 'value')::FLOAT) AS median,
       percentile_cont(.75) WITHIN GROUP (ORDER BY (ts.payload ->> 'value')::FLOAT) AS third_quantile
FROM covid19.time_series AS ts
  JOIN covid19.area_reference   AS ar ON ar.id = ts.area_id
  JOIN covid19.metric_reference AS mr ON mr.id = ts.metric_id
WHERE ts.date BETWEEN '2021-08-05' AND '2021-11-05'
  AND ts.partition_id = '2021_11_10|ltla'
  AND NOT (metric ILIKE '%direction%' OR metric ILIKE '%demog%')
GROUP BY metric, area_code
ORDER BY median DESC;
QUERY PLAN
Planning:
  Buffers: shared hit=29
Planning Time: 2.163 ms
Execution Time: 13024.737 ms

А теперь с JIT:

BEGIN;

SET LOCAL jit = ON;
SET LOCAL jit_above_cost = 10;

EXPLAIN (BUFFERS, ANALYSE)
SELECT metric,
       area_code,
       MAX(area_name) AS area_name,
       percentile_cont(.25) WITHIN GROUP (ORDER BY (ts.payload ->> 'value')::FLOAT) AS first_quantile,
       percentile_cont(.5)  WITHIN GROUP (ORDER BY (ts.payload ->> 'value')::FLOAT) AS median,
       percentile_cont(.75) WITHIN GROUP (ORDER BY (ts.payload ->> 'value')::FLOAT) AS third_quantile
FROM covid19.time_series AS ts
  JOIN covid19.area_reference   AS ar ON ar.id = ts.area_id
  JOIN covid19.metric_reference AS mr ON mr.id = ts.metric_id
WHERE ts.date BETWEEN '2021-08-05' AND '2021-11-05'
  AND ts.partition_id = '2021_11_10|ltla'
  AND NOT (metric ILIKE '%direction%' OR metric ILIKE '%demog%')
GROUP BY metric, area_code
ORDER BY median DESC;

COMMIT;
QUERY PLAN
Planning:
  Buffers: shared hit=29
Planning Time: 2.090 ms
JIT:
  Functions: 8
  Options: Inlining false, Optimization false, Expressions true, Deforming true
  Timing: Generation 1.471 ms, Inlining 0.000 ms, Optimization 0.485 ms, Emission 6.421 ms, Total 8.377 ms
Execution Time: 12750.490 ms

Как можно видеть, несмотря на накладные расходы, время выполнения меньше, хотя и ненамного.

Простого ответа нет

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

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

В результате вышеописанного инцидента команда Postgres из Microsoft Azure приняла решение изменить настройки по умолчанию для Posgtres 14 и выключить JIT для новых экземпляров сервиса.

Благодарности

В конце я хочу поблагодарить команду Azure Postgres (Hyperscale) за их вовлеченность, самоотдачу и поддержку днем, ночью и глубокой ночью!

(От переводчика) P.S. Когда речь идет о разработке программного обеспечения для создания корпоративного ПО, значения по умолчанию - важная часть продукта. Парадокс: пользователь ничего не делает и даже может не знать о существовании настройки, ее может не быть в конфигурационных файлах, а она внезапно меняется в новой версии и все перестает работать. Поэтому упоминание изменения значения параметра по умолчанию в новой версии - важная часть release notes, а миграция на новую версию должна это учитывать и создавать явные конфигурации с предыдущим значением параметра. В Jmix всегда так делаем :-)

Комментарии (14)


  1. RekGRpth
    18.11.2021 12:06
    +5

    Хоть авторы и не увидят, но есть подозрение, что jit не кэшировался из-за баунсера


    1. a_belyaev Автор
      18.11.2021 12:18
      +1

      Вот тут (правда, всего лишь 2019 год) на 7 слайде говорится, что можно кэшировать вручную: http://ivannikov-ws.org/2019/docs/Buchatskiy.pdf

      И дальше интересно:

      With minor modifications to PostgreSQL query plan data structures we can save a pointer to generated machine code and reuse it together with prepared GENERIC plan. But this is not enough as absolute addresses of run-time data structures that we use during code generation change on every query execution. At the run-time the execution control flows from JIT to PostgreSQL functions and vice versa. => Need to update obsolete addresses in generated machine code before it can be used again.


  1. BeMySlaveDarlin
    18.11.2021 13:22
    -3

    Простите душнилу, но не могли бы мд разметку переделать под хабр, совсем чуть чуть глаз режет при чтении)


    1. a_belyaev Автор
      18.11.2021 15:43

      Пользовался стандартным WYSIWYG редактором хабра, вставлял текст, потом отмечал его как код. Ничего другого тут не предусмотрено, к сожалению. Старый редактор умеет MD разметку, но он что-то не захотел работать с длинным текстом. Поэтому решил попробовать новый редактор и получилось то, что получилось.


    1. a_belyaev Автор
      18.11.2021 16:16

      А кривые ссылки поправил, да


  1. vitaly_il1
    18.11.2021 20:21
    +7

    Спасибо за перевод, очень интересно!
    В целом я не понимаю людей которые обновляют major version на проде через две недели после выхода и на след. день после релиза облачного провайдера. Другое поколение. Можно обозвать меня бумером - так оно и есть.
    И да, если погонять нагрузку в staging подольше, то вероятность обнаружения ошибки увеличивается.


    1. a_belyaev Автор
      18.11.2021 21:17
      +2

      А ещё я не очень понимаю, как там мониторинг был настроен. Почему задержки с ответами не были пойман раньше.

      Жаль, что автор не написал, какие ещё были сделаны изменения.


      1. vitaly_il1
        18.11.2021 21:45
        +2

        Я просмотрел комменты на dev.to. Про мониторинг не очень понятно.
        Но в целом мне кажется что система у них неоправданно сложная и большая - он упоминает "we have ~8 billion records in the DB". Это примерно 120 записей на каждого британца. Зачем? Почему нет агрегации за прошлые месяцы?


        1. a_belyaev Автор
          18.11.2021 22:40

          Мне кажется, надо пойти в комменты и накомментировать там ???? Может, займусь...


        1. speshuric
          19.11.2021 09:39
          +5

          Да тут вся картина говорит о каком-то лютом бардаке. "Почему мы не смогли увернуться от пуль, когда стреляли себе в ногу из пулемёта".


      1. vanxant
        18.11.2021 23:29
        +4

        Вот да, латентность не мониторят, проц не мониторят... А что они тогда мониторят? Ну и банально же интересно посмотреть, как изменится ситуация после мажорного обновления.


        1. a_belyaev Автор
          19.11.2021 14:09
          +1

          Вот ответ автора: https://dev.to/xenatisch/comment/1jokg Там много и логично, как мне кажется, объяснено.


    1. AMDmi3
      19.11.2021 19:45
      +1

      В целом я не понимаю людей которые обновляют major version на проде через две недели после выхода и на след. день после релиза облачного провайдера. Другое поколение. Можно обозвать меня бумером - так оно и есть.

      А что вы предлагаете, ждать и надеяться что кто-то наступит на тот же баг что случится у вас, его зарепортят и починят? Сколько именно нужно ждать? Придерживаться ли ритуалов вроде "никогда не ставить x.0"? Какие это даст гарантии? Может вообще не обновляться?

      И да, если погонять нагрузку в staging подольше, то вероятность обнаружения ошибки увеличивается.

      Вот же правильный ответ, только на stg можно гонять следующий релиз задолго до собственно релиза. А если на stg под рабочей нагрузкой идеально работает хоть альфа, что мешает выкатить хоть альфу в прод если от этого будет профит? Тем более что можно выкатить на 10% кластера и мгновенно откатить?

      В прошлом веке не было инструментов позволяющих одной кнопкой сделать копию прода, выкатить туда любую версию любого сервиса, и убедиться что всё это ожидаемо работает, а в случае проблем безболезненно откатиться. Поэтому ждали "стабилизации" и всё равно тряслись при каждом мажорном обновлении. Сейчас это бессмысленно - при современном подходе к разработке и деплою можно хоть из git всё собирать с минимальным риском.


  1. AMDmi3
    19.11.2021 20:07
    +2

    Это, возможно, только верхушка проблем с JIT. С год назад я чинил в 13.0 устойчивое падение бэкенда в llvmjit на FreeBSD. В двух словах, там оказалось что LLVM не умеет инлайнить функции с обращениями к thread local storage, а под FreeBSD в TLS хранятся параметры локали, которые используются из функций типа isspace(). isspace(), в свою очередь, используется много где в коде PostgreSQL, в частности при конвертации типов (чтобы пропустить не значащие пробелы), например при конвертации текста/json в bool (boolin()), где оно, собственно и падало. В Linux, видимо, isspace() устроена по другому, поэтому там это так сильно не стреляло.

    Так вот, оказалось что testsuite постгреса не прогонялся с JIT вообще (он даже не собирался с поддержкой JIT; ЕМНИП там код должен был собираться два раза - по классике для обычных вызовов и в объектный код LLVM для JIT). Не знаю, может быть с тех пор это починили, но непокрытую тестами фичу я бы на месте авторов постгреса не стал выкатывать.