Почему postgresql выдает ошибку «возможно, не хватает места на диске», когда на диске достаточно места?

Я запускаю этот запрос в postgresql на Ubuntu 12.0.4:

SELECT t2.p AS prop, t2.o AS obj, COUNT(t2.o) AS num 
FROM "class_Event" AS t1, 
  ((SELECT s,p,o FROM "prop_sliceHasAnomaly")  
   UNION (SELECT s,p,o FROM "prop_eventHasDuration")  
   UNION (SELECT s,p,o FROM "prop_sliceHasEndEvent")  
   UNION (SELECT s,p,o FROM "prop_eventPrecedeInCPU")  
   UNION (SELECT s,p,o FROM "prop_eventFollowInTask")  
   UNION (SELECT s,p,o FROM "prop_topObjectProperty")  
   UNION (SELECT s,p,o FROM "prop_eventDetails")  
   UNION (SELECT s,p,o FROM "prop_switchTo")  
   UNION (SELECT s,p,o FROM "prop_eventIsExecutedOn")  
   UNION (SELECT s,p,o FROM "prop_runningAction")  
   UNION (SELECT s,p,o FROM "prop_anomalyHasSlice")  
   UNION (SELECT s,p,o FROM "prop_eventPrecedeInTrace")  
   UNION (SELECT s,p,o FROM "prop_sliceHasStartEvent")  
   UNION (SELECT s,p,o FROM "prop_eventHasActiveDuration")  
   UNION (SELECT s,p,o FROM "prop_eventFollowInTrace")  
   UNION (SELECT s,p,o FROM "prop_runningTask")  
   UNION (SELECT s,p,o FROM "prop_eventOrdering")  
   UNION (SELECT s,p,o FROM "prop_domain")  
   UNION (SELECT s,p,o FROM "prop_sliceHasFunctionality")  
   UNION (SELECT s,p,o FROM "prop_traceContainsEvent")  
   UNION (SELECT s,p,o FROM "prop_eventHasDurationFromPreviousOccurrence")  
   UNION (SELECT s,p,o FROM "prop_eventPrecedeOccurrence")  
   UNION (SELECT s,p,o FROM "prop_eventPrecedeinTask")  
   UNION (SELECT s,p,o FROM "prop_switchFrom")  
   UNION (SELECT s,p,o FROM "prop_eventEndAt")  
   UNION (SELECT s,p,o FROM "prop_subPropertyOf")  
   UNION (SELECT s,p,o FROM "prop_eventFollowOccurrence")  
   UNION (SELECT s,p,o FROM "prop_eventFollowInCPU")  
   UNION (SELECT s,p,o FROM "prop_subClassOf")  
   UNION (SELECT s,p,o FROM "prop_eventHasDurationToNextOccurrence")  
   UNION (SELECT s,p,o FROM "prop_requestComponent")  
   UNION (SELECT s,p,o FROM "prop_eventStartAt")  
   UNION (SELECT s,p,o FROM "prop_range")  
   UNION (SELECT s,p,o FROM "prop_functionalityHasSlice") ) AS t2 
WHERE t1.s = t2.s 
GROUP BY t2.p, t2.o 
HAVING (COUNT(t2.o) > 1) 

Но я вышел с этой ошибкой из posgresql:

ERROR:  could not write block 713 of temporary file: Aucun espace disponible sur le périphérique
HINT:  Perhaps out of disk space?

********** Erreur **********

ERROR: could not write block 713 of temporary file: Aucun espace disponible sur le périphérique
État SQL :53100
Astuce : Perhaps out of disk space?

Я проверил достаточно ли места на диске с помощью команды df -h

df -h
df: «/var/lib/lightdm/.gvfs»: Permission non accordée
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sda5           37G     35G   46M 100% /
udev                16G    4,0K   16G   1% /dev
tmpfs              6,3G    984K  6,3G   1% /run
none               5,0M       0  5,0M   0% /run/lock
none                16G    216K   16G   1% /run/shm
/dev/sda6           37G    411M   35G   2% /opt
/dev/sda9          499G    435G   40G  92% /home
/dev/sda7           37G    4,7G   30G  14% /usr
/dev/sda8           37G    5,1G   30G  15% /usr/local

и кажется, что на диске /home есть свободное место 40GB. Вот мне и интересно, что заставляет эту ошибку поднимать? есть ли параметр ограничения дискового пространства, который можно установить в конфигурации postgresql?

у кого-то есть идея по этому поводу?


person Fopa Léon Constantin    schedule 04.02.2014    source источник
comment
Если вы не знаете, что ваш tempdir находится в /home, ваш раздел / заполнен на 100%, и именно там находится /tmp...   -  person Charles    schedule 04.02.2014
comment
@Charles Pg на самом деле не будет использовать /tmp для временных файлов по умолчанию, отчасти потому, что он очень расстраивается, когда ОС удаляет их из-под себя, пока она все еще их использует. Он использует temp_tablespaces, который в большинстве систем оказывается в основном каталоге данных PostgreSQL в /var по умолчанию.   -  person Craig Ringer    schedule 04.02.2014


Ответы (1)


Пишет временный файл. Они записываются в temp_tablespaces, для чего:

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

это означает, что он будет записывать временные файлы в ваш data_directory. Чтобы увидеть, где это, запустите SHOW data_directory. Я ожидаю, что вы получите результат вроде /var/lib/pgsql/9.3/data/, указывающий, что данные PostgreSQL находятся в /var.

(Обязательно проверьте это; если ваше временное табличное пространство находится на tempfs, то это в основном виртуальный диск, и вы должны переместить его в другое место, потому что это плохо для производительности, а также является проблемой для больших временных файлов.)

В вашей системе /var является частью файловой системы /, которая заполнена. Таким образом, раздел, содержащий ваши данные PostgreSQL, заполнен, и PostgreSQL правильно сообщает об этом как об ошибке.

Варианты свободного места включают в себя:

  • Убедитесь, что старые временные файлы в /tmp удаляются

  • Удаление старых файлов журнала из /var/log

  • Удаление старых журналов PostgreSQL. Их расположение несколько варьируется в зависимости от ОС/дистрибутива, о чем вы не упомянули; они обычно будут в /var/log/postgresql/ или /var/lib/pgsql/9.3/data/pg_log. Важно: не удаляйте ничего в каталоге данных PostgreSQL; в частности, pg_xlog и pg_clog являются жизненно важными частями системы базы данных и не должны удаляться, перемещаться или изменяться каким-либо образом.

  • Удаление или TRUNCATEing таблиц в PostgreSQL (безвозвратно уничтожает данные)

  • DROPping нежелательные индексы в PostgreSQL

  • Удаление программ

  • ...

но лучший вариант:

  • Возьмите диск большего размера.
person Craig Ringer    schedule 04.02.2014
comment
Большое спасибо за эти подробности. Я бегу на Lunix ubuntu 2.0.4 - person Fopa Léon Constantin; 04.02.2014
comment
эта ошибка возникает после того, как запрос уже выполнен или раньше. Потому что на самом деле у меня нет прав на очистку пространства в /var и меня интересует производительность запросов. Таким образом, могу ли я считать время, фактически возвращенное pgadmin3, временем выполнения запроса, даже если я еще не получил результат? - person Fopa Léon Constantin; 04.02.2014
comment
Даже не тратьте свое время на изучение производительности, когда у вас так мало места на диске. Вам нужно свободное место на диске, чтобы получить хорошую производительность. Очень полные файловые системы работают плохо. И нет, вы не можете считать время, сообщаемое PgAdmin, временем выполнения запроса, это просто время до ошибки. Вы не знаете, как далеко вы продвинулись в выполнении запроса. Серьезно, получите диск большего размера или иным образом устраните проблемы с хранилищем. Вы не можете с пользой делать что-либо еще, пока не исправите это. - person Craig Ringer; 04.02.2014