Pipelinedb зависает при высокой нагрузке, рабочий процесс ест 100% CPU, ничего не делая

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

Я измеряю производительность PipelineDB для использования в нашей системе. Я определил несколько непрерывных представлений (вычисление сумм, top-K и т. Д.), Подачу из одного потока (который содержит ~20 столбцов, некоторый текст, в основном целые и логические значения). Тест написан на Python, и я использую функцию psycopg2 cursor.copy_from() для достижения максимальной производительности. PipelineDB хорошо работает, когда работа, заданная непрерывными представлениями, не слишком сложна. Однако, когда я прошу его вычислить много результатов top-K или много значений процентных_контрантов (), тест зависает со следующими симптомами:

  • Процесс (single) 'worker0' начинает потреблять 100% ЦП
  • Процесс ввода показывает, что он выполняет команду COPY, никогда не изменяясь на IDLE (во время обычной работы он изменяется между COPY и IDLE).
  • Тестовые зависания (т.е. вызов функции copy_from () не возвращается)

Ниже приведен вывод команды 'ps -ef', показывающий все процессы pipelinedb примерно через минуту или после запуска теста. Обратите внимание, что процесс worker0 потребляет 100% ЦП с начала теста. Он никогда не возобновляет нормальную работу ("top" показывает, что он потребляет ровно 100% CPU)

Журналы испытаний показывают, что он работает нормально в течение первой ~1 секунды, вставляя ~30000 событий (в пакетах по 100), а затем зависает, потому что вызов функции copy_from () не возвращается.

Когда я сокращаю объем работы, выполняемой PipelineDB (удаляя некоторые из непрерывных представлений), тест работает нормально, обеспечивая до 20000 вставок в секунду при продолжительности не менее одной минуты.

Я хотел бы отметить, что все события имеют одну и ту же отметку времени, и все представления имеют предложение "GROUP BY minute", поэтому в каждом непрерывном представлении во время теста должна быть создана / обновлена ​​одна строка.

Я поиграл с некоторыми параметрами конфигурации, в частности с параметрами, относящимися к размеру буфера памяти, методам синхронизации, временным интервалам, max_wait и т. Д., Количеству рабочих, и не смог найти ни одной комбинации, которая позволила бы избежать проблемы.

Я не знаю, сталкиваюсь ли я с проблемой PipelineDB или с проблемой PostgreSQL. Конечно, это не ожидаемое поведение, и его нельзя допустить в реальном приложении. Любые намеки, догадки, интуиция и т. Д. Приветствуются.

[orens@rd10 ~]$ps -ef | grep pipelinedb 
UID   PID  PPID  C STIME TTY    TIME   CMD
orens 3005 3004  0 11:17 ?    00:00:00 pipelinedb: logger process    
orens 3007 3004  0 11:17 ?    00:00:00 pipelinedb: checkpointer process    
orens 3008 3004  0 11:17 ?    00:00:00 pipelinedb: writer process    
orens 3009 3004  0 11:17 ?    00:00:00 pipelinedb: wal writer process    
orens 3010 3004  0 11:17 ?    00:00:00 pipelinedb: autovacuum launcher process    
orens 3011 3004  0 11:17 ?    00:00:00 pipelinedb: stats collector process    
orens 3012 3004  0 11:17 ?    00:00:00 pipelinedb: pipelinedb scheduler process    
orens 3014 3004  0 11:17 ?    00:00:00 pipelinedb: bgworker: reaper0 [pipeline]    
orens 3015 3004  0 11:17 ?    00:00:00 pipelinedb: bgworker: queue0 [pipeline]    
orens 3016 3004  0 11:17 ?    00:00:00 pipelinedb: bgworker: combiner1 [pipeline]    
orens 3017 3004  0 11:17 ?    00:00:00 pipelinedb: bgworker: combiner0 [pipeline]   
orens 3018 3004  0 11:17 ?    00:00:00 pipelinedb: bgworker: worker0 [pipeline]    
orens 3046 3004  0 11:17 ?    00:00:00 pipelinedb: bgworker: reaper0 [db1]    
orens 3050 3004  0 11:17 ?    00:00:00 pipelinedb: bgworker: queue0 [db1]      
orens 3052 3004  0 11:17 ?    00:00:00 pipelinedb: bgworker: combiner0 [db1]
orens 3056 3004 90 11:17 ?    00:01:06 pipelinedb: bgworker: worker0 [db1]    
orens 3132 3004  1 11:17 ?    00:00:01 pipelinedb: ut_user db1 ::1(58830) COPY
[orens@rd10 ~]$

0 ответов

Другие вопросы по тегам