Примечание: я ищу любые подсказки о том, как отладить эту проблему, не обязательно прямой ответ на эту конкретную проблему.
Я измеряю производительность PipelineDB для использования в нашей системе.
Я определил несколько непрерывных представлений (подсчет сумм, top-K и т. Д.), Поступающих из одного потока (который содержит ~ 20 столбцов, некоторый текст, в основном целые и логические значения).
Тест написан на Python, и я использую функцию psycopg2 cursor.copy_from () для достижения максимальной производительности.
PipelineDB хорошо работает, когда работа, заданная непрерывными представлениями, не слишком сложна.
Однако, когда я прошу его вычислить много результатов top-K или много значений процентных_конт (), тест зависает со следующими симптомами:
- (один) процесс 'worker0' начинает использовать 100% CPU
- Процесс ввода показывает, что он выполняет команду COPY, никогда не изменяясь на IDLE (во время обычной работы он изменяется между COPY и IDLE).
- Тестовые зависания (т.е. вызов функции copy_from () не возвращает)
Ниже приведен вывод команды 'ps -ef', показывающий все процессы pipelinedb примерно через минуту или после запуска теста. Обратите внимание, что процесс worker0 потребляет 100% ЦП с начала теста. Он никогда не возобновляет нормальную работу («top» показывает, что он потребляет ровно 100% CPU)
Тестовые журналы показывают, что он работает нормально в течение первой ~ 1 секунды, вставляя ~ 30 000 событий (в пакетах по 100), а затем зависает, потому что вызов функции copy_from () не возвращает.
Когда я уменьшаю объем работы, выполняемой PipelineDB (удаляя некоторые из непрерывных представлений), тест работает нормально, обеспечивая до 20 000 вставок в секунду, поддерживаемых в течение не менее одной минуты.
Я хотел бы отметить, что все события имеют одинаковую отметку времени, и все представления имеют предложение «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 ~]$