psql, кажется, истекает тайм-аутом с длинными запросами

Я выполняю массовое копирование в postgres с объемом данных около 80 ГБ.

\copy my_table FROM '/path/csv_file.csv' csv DELIMITER ','

Перед тем, как транзакция будет совершена, я получаю следующую ошибку.

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

В логах PostgreSQL:

LOG:server process (PID 21122) was terminated by signal 9: Killed
LOG:terminating any other active server processes
WARNING:terminating connection because of crash of another server process
DETAIL:The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and repeat your command.

postgresql psql postgresql-9.2
person Matt E    schedule 07.05.2013    source источник
comment
Копия выполняется на локальном хосте или через удаленное соединение? Я бы сказал, что вы лично видите сбой бэкэнда. Подробности смотрите в журналах ошибок PostgreSQL. Если у вас очень высокие work_mem или maintenance_work_mem, возможно, вам не хватает памяти? Или, может быть, вам не хватает места на диске, хотя обычно это должно привести к лучшей ошибке. Также какая точная версия PostgreSQL?   -  person Craig Ringer    schedule 07.05.2013
comment
Версия 8.4.11. Я запускаю его на удаленной машине. Я вошел в коробку по ssh, но использую «экран». Я вижу это в журналах. Попробуйте увеличить параметр конфигурации checkpoint_segments.   -  person Matt E    schedule 07.05.2013
comment
просто чтобы уточнить, psql работает на той же машине, что и база данных? Неважно, удалена ли она для вас, только удалена она для клиента psql или нет; если вы используете psql для связи с базой данных на localhost, это не будет проблемой сети.   -  person Craig Ringer    schedule 07.05.2013
comment
Ищите точку отключения клиента в логах; поиск сообщений уровня FATAL или PANIC.   -  person Craig Ringer    schedule 07.05.2013
comment
LOG: серверный процесс (PID 21122) был прерван сигналом 9: Killed LOG: завершение любых других активных серверных процессов WARNING: завершение соединения из-за сбоя другого серверного процесса DETAIL: администратор почты приказал этому серверному процессу откатить текущую транзакцию и выйти из-за использования другого серверного процесса, который завершил работу ненормально и, возможно, повредил разделяемую память. СОВЕТ: Через мгновение вы сможете повторно подключиться к базе данных и повторить свою команду.   -  person Matt E    schedule 07.05.2013

Ответы (1)


arrow_upward
13
arrow_downward

Ваш внутренний процесс получает сигнал 9 (SIGKILL). Это может произойти, если:

  • Кто-то отправляет kill -9 вручную;
  • Задание cron настроено на отправку kill -9 при некоторых обстоятельствах (очень небезопасно, не делайте этого); или
  • убийца нехватки памяти (OOM) Linux запускает и завершает процесс.

В последнем случае вы увидите отчеты об активности OOM killer в выводе ядра dmesg. Я ожидаю, что это то, что вы увидите в своем случае.

Серверы PostgreSQL должны быть настроены без перераспределения виртуальной памяти, чтобы убийца OOM не запускался, а PostgreSQL мог самостоятельно обрабатывать условия нехватки памяти. См. документацию PostgreSQL по избыточному выделению памяти в Linux.

Отдельный вопрос "почему это использует так много памяти" остается. Ответ на этот вопрос требует дополнительных знаний о вашей настройке: сколько оперативной памяти у сервера, какая ее часть свободна, каковы ваши настройки work_mem и maintenance_work_mem и т. д. Это не очень интересная проблема, пока вы не обновите ее. к текущему выпуску исправлений PostgreSQL 8.4, чтобы убедиться, что проблема не исправлена.

person Craig Ringer    schedule 08.05.2013
comment
Обновление до postgres 9.1 помогло, похоже на проблему 8.4. Еще раз спасибо за помощь, Крейг. - person Matt E; 09.05.2013
comment
@MattE Или проблема с выпуском старых исправлений 8.4. Как правило, вы должны стараться не отставать от патчей, например, на самом деле должна была работать версия 8.4.17, а не 8.4.11. Это важно для безопасности, производительности, надежности и т. д. - person Craig Ringer; 09.05.2013