DeeK
09.01.23 — 12:29
8.3.20.2180
обновление бух 3.0 с 3.0.123.26 на 3.0.127.49
postgre 10
53100:error: could not extend file «base/52185646/95696157»: no space left on device HINT: check free disk space
размер базы около 20Гб
свободного места на тот момент было 7ГБ
загрузили бэкап, все ок
админ и руководство хотят узнать есть ли методы анализа требуемого места для предстоящего обновления
я не знаю таких методов, помогите найти вразумительные слова для них, или может предложите решение
Builder
1 — 09.01.23 — 12:33
(0) Жесть, экономить место на диске? Вы серьезно? 7 гигов свободно????
ИМХО на диске должно быть хотя бы в 2-3 раза больше места чем размер базы.
DeeK
2 — 09.01.23 — 12:34
(1) это само собой, я сразу это сказал, налейте места и забудем на ближайшие несколько лет
но им хочется анализ
PLUT
3 — 09.01.23 — 12:34
если перекладывать из одних таблиц в другие при реструктуризации базы, логично предположить, что свободного места должно быть не меньше текущего размера базы + логи транзакций?
если база 20 Гектар, то и места должно быть не меньше 20 Га?
Ryzeman
4 — 09.01.23 — 12:39
>>есть ли методы анализа требуемого места для предстоящего обновления
Не думаю, если при обновлении не написано ничего в подсказках, но если
>>размер базы около 20Гб
>>свободного места на тот момент было 7ГБ
тут ИМХО и так более чем очевидно. Если у вас там не раритетные суперскоростные скази-диски или не оптаны лимитированной серии, то смысл крохоборить?…
PLUT
5 — 09.01.23 — 12:40
(4) ну как вариант арендовать SSD диск на время обновления, после обновления базу вернуть взад
DeeK
6 — 09.01.23 — 12:42
то есть метод анализа примерно такой как (3)?
минимум размер базы плюс подушка какая-то
Trimax
7 — 09.01.23 — 12:43
(2) Дык анализ уже произведен средствами 1С: Нет места на жестком диске….
Aleksey
8 — 09.01.23 — 12:43
(6) За анализом им к психологу, он им поставит анализ.
Или анализ чего им нужно?
DeeK
9 — 09.01.23 — 12:44
(8) требуемого свободного места на диске для корректного завершения обновления
DeeK
10 — 09.01.23 — 12:44
(7) они хотят перед обновлением оценивать — хватит места или нет
Ryzeman
11 — 09.01.23 — 12:45
(8) Ну автор нормальный вопрос задал, просто читать всю ветку надо) Типа предварительный анализ перед обновлением — хватит ли места.
PLUT
12 — 09.01.23 — 12:45
(7) особенно «анализ» обновления типовой ERP (соблюдайте спокойствие. поезд скоро отправится. обновление в зависимости от количества данных займет от нескольких минут до нескольких дней)
и костыли в виде запуска в параллель нескольких фоновых заданий и галочка производительности обновления или работы пользователей.
а еще обновление через копию базы забыл
Trimax
13 — 09.01.23 — 12:47
(9) Это вопрос должен быть адресован админу. Железо — его головняк. Он должен обеспечить работоспособность программы.
Ryzeman
14 — 09.01.23 — 12:48
(6) я бы заморачивался если бы речь шла на терабайты. Но «жалкие» (по нынешним дням) ~50 гигов держать свободными уж точно можно…
PLUT
15 — 09.01.23 — 12:48
(10)
п.1 бэкап базы.
п.2 обновление — > no space left on device HINT: check free disk space
БИНГО! предварительный анализ — недостаточно места! <- вы находитесь здесь
п.4 загружаем из бэкапа базу
п.5 пишем на форум, читаем, много думаем…
Asmody
16 — 09.01.23 — 12:51
(0) если кратко, то примерно так:
1. через сравнение-объединение определяешь объекты с изменившейся структурой
2. смотришь объем таблиц этих объектов вместе с индексами + объем таблиц Config
3. умножаешь на 2, но лучше сразу на π
вот тебе будет оценка
PLUT
17 — 09.01.23 — 12:52
(16) кстати да, и неделю времени на анализ (это ж сколько денег можно заработать, если франь)
DeeK
18 — 09.01.23 — 12:53
(16) спасибо за конкретику
(17) тоже об этом подумал
я думаю мой конспект из этой темы их удовлетворит, всем спасибо, можно закрывать
ViSo76
19 — 09.01.23 — 13:14
Есть шанс что ошибки на диске
Aleksey
20 — 09.01.23 — 13:53
(11) так кроме эмпирического пути других методов нет, даже (размер базы умножь на 2) и то иногда не спасает, тем более когда модель восстановления стоит FULL а не простая.
Так что только делать обновление на копии и смотреть сколько заняло место
bolobol
21 — 09.01.23 — 16:25
(20) И как же это посмотреть? После обновления база занимает +/- столько же, сколько и до
bolobol
22 — 09.01.23 — 16:28
А по сути вопроса, если грубо, то: — да ну вас нахрен, даже голову напрягать не стоит из-за 50 гигабайтов…
Новый1сник2
23 — 09.01.23 — 16:30
(0) обновлял на днях бух корп (размер не смотрел), места на диске было 10г свободных, при обновлении глюкануло что не достаточно места. пришлось чистить немного и повторно обновлять
Новый1сник2
24 — 09.01.23 — 16:33
(О) размер диска какой? столкнулся с тем что под пользователем, которым обновлял. в темпах пользователя накопился кэш от обновлений, примерно 50 г. можно почистить
Aleksey
25 — 09.01.23 — 16:35
(21) запустить стандартный виндовый счетчик свободного место на время обновления и смотреть минимальное значение?
bolobol
26 — 09.01.23 — 16:37
(25) Спасибо, не знал что такое вообще есть стандартное в винде
Aleksey
27 — 09.01.23 — 16:44
Счетчики производительности для дисковой подсистемы
%Free Space — Объем свободного дискового пространства на выбранном логическом диске, в процентах.
https://windowsnotes.ru/other/schetchiki-proizvoditelnosti-dlya-diskovoj-podsistemy/
Ну или по 1С-совски
Мониторинг свободного места на диске с помощью OneScript
https://infostart.ru/1c/articles/1450352/
Kassern
28 — 09.01.23 — 16:58
(27) Все же можно проще, без всяких OneScript
Только что на коленке собрал
FSO=Новый COMОбъект(«Scripting.FileSystemObject»);
Для каждого ТекДиск Из FSO.Drives Цикл
Если ТекДиск.DriveType=2 Тогда
СвободныйОбъем = Окр(fso.GetDrive(ТекДиск.DriveLetter).FreeSpace/1048576,1);
Сообщить(«Диск «+ТекДиск.DriveLetter+» свободно «+СвободныйОбъем+» Мб.»);
КонецЕсли;
КонецЦикла;
Kassern
29 — 09.01.23 — 16:59
Aleksey
30 — 09.01.23 — 17:06
(28) там вроде как ограничения типа с сетевыми дискми не работает. или в виртуалки чудит, короче тестить надо
bolobol
31 — 09.01.23 — 17:07
(28) В (25) говорят, что всё уже написано до Вас
Kassern
32 — 09.01.23 — 17:17
(30) Все же есть)
DriveType
Возвращаемое значение: число — определяет тип ресурса. Возможные значения:
0 — неизвестное устройство.
1 — устройство со сменным носителем.
2 — жёсткий диск.
3 — сетевой диск.
4 — CD-ROM.
5 — RAM-диск.
I’m running a query that duplicates a very large table (92 million rows) on PostgreSQL. After a 3 iterations I got this error message:
The query was:
CREATE TABLE table_name
AS SELECT * FROM big_table
The issue isn’t due to lack of space in the database cluster: at 0.3% of max possible storage at the time of running the query, table size is about 0.01% of max storage including all replicas. I also checked temporary files and it’s not that.
Laurenz Albe
190k17 gold badges175 silver badges229 bronze badges
asked Nov 9, 2020 at 14:32
3
You are definitely running out of file system resources.
Make sure you got the size right:
SELECT pg_table_size('big_table');
Don’t forget that the files backing the new table are deleted after the error, so it is no surprise that you have lots of free space after the statement has failed.
One possibility is that you are not running out of disk space, but of free i-nodes. How to examine the free resources differs from file system to file system; for ext4 on Linux it would be
sudo dumpe2fs -h /dev/... | grep Free
answered Nov 9, 2020 at 17:55
Laurenz AlbeLaurenz Albe
190k17 gold badges175 silver badges229 bronze badges
I keep running into this error on Windows Postgresql running a large query:
[53100] ERROR: could not write block 21991344 of temporary file: No space left on device
The only problem is that I actually have a huge amount of space left on all of my partitions (including 171gb on the partition holding the data directory and 448gb on my only other partition).
It seems like some sort of internal setting preventing the creation of the temp file that I am unfamiliar with. I looked through the configuration file and tweaked a couple of settings to do with temp tables with no help.
I was able to run the query before, not much has been changed in the database aside from a couple of tables.
asked Sep 24, 2019 at 20:21
0
21991344 blocks is 168GB. That is pretty close to the space you say you have free. There could be some other smaller temp file also in use making up the differences (or it could be a difference in definition of GB, 10^9 or 2^30).
answered Sep 24, 2019 at 20:59
jjanesjjanes
33.8k5 gold badges27 silver badges32 bronze badges
1
I keep running into this error on Windows Postgresql running a large query:
[53100] ERROR: could not write block 21991344 of temporary file: No space left on device
The only problem is that I actually have a huge amount of space left on all of my partitions (including 171gb on the partition holding the data directory and 448gb on my only other partition).
It seems like some sort of internal setting preventing the creation of the temp file that I am unfamiliar with. I looked through the configuration file and tweaked a couple of settings to do with temp tables with no help.
I was able to run the query before, not much has been changed in the database aside from a couple of tables.
asked Sep 24, 2019 at 20:21
0
21991344 blocks is 168GB. That is pretty close to the space you say you have free. There could be some other smaller temp file also in use making up the differences (or it could be a difference in definition of GB, 10^9 or 2^30).
answered Sep 24, 2019 at 20:59
jjanesjjanes
33.8k5 gold badges27 silver badges32 bronze badges
1
Я продолжаю сталкиваться с этой ошибкой в Windows Postgresql, выполняющей большой запрос:
[53100] ERROR: could not write block 21991344 of temporary file: No space left on device
Единственная проблема заключается в том, что у меня на самом деле есть огромное количество места, оставленного на всех моих разделах (в том числе 171 ГБ на раздел, содержащий каталог данных и 448 ГБ в моем единственном другом разделу).
Похоже, что какая-то внутренняя настройка предотвращает создание временного файла, с которым я не знаком. Я просмотрел файл конфигурации и без посторонней помощи изменил пару настроек для работы с временными таблицами.
Я смог запустить запрос раньше, не сильно изменился в базе данных от пары таблиц.
1 ответ
Лучший ответ
21991344 блока — 168 ГБ. Это довольно близко к тому месту, которое, по вашему мнению, у вас есть бесплатно. Также может использоваться какой-то другой временный файл меньшего размера, составляющий различия (или это может быть разница в определении ГБ, 10 ^ 9 или 2 ^ 30).
4
jjanes
24 Сен 2019 в 23:59
DeeK
09.01.23 — 12:29
8.3.20.2180
обновление бух 3.0 с 3.0.123.26 на 3.0.127.49
postgre 10
53100:error: could not extend file «base/52185646/95696157»: no space left on device HINT: check free disk space
размер базы около 20Гб
свободного места на тот момент было 7ГБ
загрузили бэкап, все ок
админ и руководство хотят узнать есть ли методы анализа требуемого места для предстоящего обновления
я не знаю таких методов, помогите найти вразумительные слова для них, или может предложите решение
Builder
1 — 09.01.23 — 12:33
(0) Жесть, экономить место на диске? Вы серьезно? 7 гигов свободно????
ИМХО на диске должно быть хотя бы в 2-3 раза больше места чем размер базы.
DeeK
2 — 09.01.23 — 12:34
(1) это само собой, я сразу это сказал, налейте места и забудем на ближайшие несколько лет
но им хочется анализ
PLUT
3 — 09.01.23 — 12:34
если перекладывать из одних таблиц в другие при реструктуризации базы, логично предположить, что свободного места должно быть не меньше текущего размера базы + логи транзакций?
если база 20 Гектар, то и места должно быть не меньше 20 Га?
Ryzeman
4 — 09.01.23 — 12:39
>>есть ли методы анализа требуемого места для предстоящего обновления
Не думаю, если при обновлении не написано ничего в подсказках, но если
>>размер базы около 20Гб
>>свободного места на тот момент было 7ГБ
тут ИМХО и так более чем очевидно. Если у вас там не раритетные суперскоростные скази-диски или не оптаны лимитированной серии, то смысл крохоборить?…
PLUT
5 — 09.01.23 — 12:40
(4) ну как вариант арендовать SSD диск на время обновления, после обновления базу вернуть взад
DeeK
6 — 09.01.23 — 12:42
то есть метод анализа примерно такой как (3)?
минимум размер базы плюс подушка какая-то
Trimax
7 — 09.01.23 — 12:43
(2) Дык анализ уже произведен средствами 1С: Нет места на жестком диске….
Aleksey
8 — 09.01.23 — 12:43
(6) За анализом им к психологу, он им поставит анализ.
Или анализ чего им нужно?
DeeK
9 — 09.01.23 — 12:44
(8) требуемого свободного места на диске для корректного завершения обновления
DeeK
10 — 09.01.23 — 12:44
(7) они хотят перед обновлением оценивать — хватит места или нет
Ryzeman
11 — 09.01.23 — 12:45
(8) Ну автор нормальный вопрос задал, просто читать всю ветку надо) Типа предварительный анализ перед обновлением — хватит ли места.
PLUT
12 — 09.01.23 — 12:45
(7) особенно «анализ» обновления типовой ERP (соблюдайте спокойствие. поезд скоро отправится. обновление в зависимости от количества данных займет от нескольких минут до нескольких дней)
и костыли в виде запуска в параллель нескольких фоновых заданий и галочка производительности обновления или работы пользователей.
а еще обновление через копию базы забыл
Trimax
13 — 09.01.23 — 12:47
(9) Это вопрос должен быть адресован админу. Железо — его головняк. Он должен обеспечить работоспособность программы.
Ryzeman
14 — 09.01.23 — 12:48
(6) я бы заморачивался если бы речь шла на терабайты. Но «жалкие» (по нынешним дням) ~50 гигов держать свободными уж точно можно…
PLUT
15 — 09.01.23 — 12:48
(10)
п.1 бэкап базы.
п.2 обновление — > no space left on device HINT: check free disk space
БИНГО! предварительный анализ — недостаточно места! <- вы находитесь здесь
п.4 загружаем из бэкапа базу
п.5 пишем на форум, читаем, много думаем…
Asmody
16 — 09.01.23 — 12:51
(0) если кратко, то примерно так:
1. через сравнение-объединение определяешь объекты с изменившейся структурой
2. смотришь объем таблиц этих объектов вместе с индексами + объем таблиц Config
3. умножаешь на 2, но лучше сразу на π
вот тебе будет оценка
PLUT
17 — 09.01.23 — 12:52
(16) кстати да, и неделю времени на анализ (это ж сколько денег можно заработать, если франь)
DeeK
18 — 09.01.23 — 12:53
(16) спасибо за конкретику
(17) тоже об этом подумал
я думаю мой конспект из этой темы их удовлетворит, всем спасибо, можно закрывать
ViSo76
19 — 09.01.23 — 13:14
Есть шанс что ошибки на диске
Aleksey
20 — 09.01.23 — 13:53
(11) так кроме эмпирического пути других методов нет, даже (размер базы умножь на 2) и то иногда не спасает, тем более когда модель восстановления стоит FULL а не простая.
Так что только делать обновление на копии и смотреть сколько заняло место
bolobol
21 — 09.01.23 — 16:25
(20) И как же это посмотреть? После обновления база занимает +/- столько же, сколько и до
bolobol
22 — 09.01.23 — 16:28
А по сути вопроса, если грубо, то: — да ну вас нахрен, даже голову напрягать не стоит из-за 50 гигабайтов…
Новый1сник2
23 — 09.01.23 — 16:30
(0) обновлял на днях бух корп (размер не смотрел), места на диске было 10г свободных, при обновлении глюкануло что не достаточно места. пришлось чистить немного и повторно обновлять
Новый1сник2
24 — 09.01.23 — 16:33
(О) размер диска какой? столкнулся с тем что под пользователем, которым обновлял. в темпах пользователя накопился кэш от обновлений, примерно 50 г. можно почистить
Aleksey
25 — 09.01.23 — 16:35
(21) запустить стандартный виндовый счетчик свободного место на время обновления и смотреть минимальное значение?
bolobol
26 — 09.01.23 — 16:37
(25) Спасибо, не знал что такое вообще есть стандартное в винде
Aleksey
27 — 09.01.23 — 16:44
Счетчики производительности для дисковой подсистемы
%Free Space — Объем свободного дискового пространства на выбранном логическом диске, в процентах.
https://windowsnotes.ru/other/schetchiki-proizvoditelnosti-dlya-diskovoj-podsistemy/
Ну или по 1С-совски
Мониторинг свободного места на диске с помощью OneScript
https://infostart.ru/1c/articles/1450352/
Kassern
28 — 09.01.23 — 16:58
(27) Все же можно проще, без всяких OneScript
Только что на коленке собрал
FSO=Новый COMОбъект(«Scripting.FileSystemObject»);
Для каждого ТекДиск Из FSO.Drives Цикл
Если ТекДиск.DriveType=2 Тогда
СвободныйОбъем = Окр(fso.GetDrive(ТекДиск.DriveLetter).FreeSpace/1048576,1);
Сообщить(«Диск «+ТекДиск.DriveLetter+» свободно «+СвободныйОбъем+» Мб.»);
КонецЕсли;
КонецЦикла;
Kassern
29 — 09.01.23 — 16:59
Aleksey
30 — 09.01.23 — 17:06
(28) там вроде как ограничения типа с сетевыми дискми не работает. или в виртуалки чудит, короче тестить надо
bolobol
31 — 09.01.23 — 17:07
(28) В (25) говорят, что всё уже написано до Вас
Kassern
32 — 09.01.23 — 17:17
(30) Все же есть)
DriveType
Возвращаемое значение: число — определяет тип ресурса. Возможные значения:
0 — неизвестное устройство.
1 — устройство со сменным носителем.
2 — жёсткий диск.
3 — сетевой диск.
4 — CD-ROM.
5 — RAM-диск.
-
Доброго времени суток. Извините если пишу не туда и не по теме.
Вчера случилось несколько ситуевин, на которые в интернете просто не было однозначных ответов, что делать? Дабы помочь коллегам и форумчанам опишу решение двух ошибок связанных в моем случаи вместе.
Описание оборудования:
Сервер HP 590161
Centos 6.2×64 + Pgsql +1C 8.2×32
На сервер лицензии:
Серверная лицензия 1С 32бт 1 шт + 5 зверей +20зверей + 10 зверей — все программные лицензии!
И так:Как обычно в выходной у пользователей вылетает ошибка:
————————————————————————————————————————
Ошибка СУБД:
ERROR: cold not extend file :base/329490/16669873″: wrote only 4096 of 8192 bytes at block 18
HINT: Check free disk space.
CONTEXT: COPY tt4, line 1331————————————————————————————————————————
Ну тут вроде все ясно, залезаем через SSH и смотрим, что у нас со свободным местом.
Оказалось, что разросся лог pgsql до 10ти ГБ, обнуляем:
команда для проверки своюбодного места:df
команда для проверки самого обемного файла в pgsql:
du -sh /var/lib/pgsql/*
обнуляем лог:
cat /dev/null/ >имялога
На этом с вышеописанной ошибкой баста.
Ну конечно нужно задуматься о том, что все-таки маловато места на HDD.
Далее, первую ошибку исправили, запускаем 1С но всего могут зайти на сервер 2 пользователя. Остальным при входе выскакивет надпись:——————————————————————————————————————
«Отсутствует серверная лицензия»
В папке home/user**/1C не найдена серверная лицензия.
Файл программной лицензии не предусматривает возможность запуска сервера 1С:Предприятия: file: путь к файлу…………………………——————————————————————————————————————
Получается, что до этого была лицензия, а сейчас ее нет 0_0.
Кстати в интернете специалисты (в ковычках) так и говорят мол, а чего не понятного? даже не пытаясь вникнуть в простую суть вопроса. В топку таких.. в итоге туда сюда, а сами не знают не фига.
И так решаем проблему:
— мы точно знаем, что серверная лицензия у нас есть.
— мы точно знаем, что лицензия не работает если изменить конфигурацию сервера.
— мы точно знаем, что не меняли конфигурацию сервера.
— мы точно знаем, что ранее у нас была ошибка связанная со свободным местом.
Решаем возникшее недоразумение:Берем лицензию (бумажный носитель с кодами, выдают при покупки, их всего ТРИ) и начинаем обновление, тут нам пригодится ранее созданный файл (при первой настройки сервера) LicData.txt при регистрации программной лицензии т.к. информация об организации должны быть точно введена правильно как в прошлый раз.
Сервер заработал.
Обратился в ТП о произошедшем.
Ответа из ТП так вразумительного и не пришло.
Единственное утишает, что остался последний ключ.
Уважаемые форумчане, если у Вас есть ответ о причинах произошедшего с лицензией прошу Вас его озвучить. Спасибо. -
Offline
shurikvz
Модераторы
Команда форума
Модератор
- Регистрация:
- 1 окт 2009
- Сообщения:
- 8.547
- Симпатии:
- 344
- Баллы:
- 104
Скажите, а версия платформы 1С (полная) какая — ?
Да, кстати, насколько я понимаю (с программными лицензиями сам не сталкивался), но даже после того как вы израсходуете 3 пинкода — можно запросить дополнительный, отправив письмо на [email protected] (несколько неудобно конечно, но тем не менее не катастрофа).
-
По поводу пин кода Вы полностью правы, особенно учитывая, что в выходные никто не ответит.
Версия 1С: 8.2.15.319 -
Offline
shurikvz
Модераторы
Команда форума
Модератор
- Регистрация:
- 1 окт 2009
- Сообщения:
- 8.547
- Симпатии:
- 344
- Баллы:
- 104
Идей почему так могло произойти нет. В текущем списке зарегистрированных ошибок платформы чего-то подобного не увидел.
Единственно такой момент:
Одни из параметров учитываемых при получении программной лицензии:
Ну как бы сетевой имя компьютера вы вряд ли меняли я так понимаю, а вот что имеет ввиду 1С под «список жестких дисков и их параметры» я честно говоря не знаю. Если свободное место — то бред конечно, согласен. -
Изменения в системе не производились вовсе. До сих пор не могу найти причину.
-
Offline
uza
1С, VBA (EXCEL), VB (.NET + WEB)
- Регистрация:
- 10 июл 2007
- Сообщения:
- 1.845
- Симпатии:
- 1
- Баллы:
- 29
Параметры диска, если я не ошибаюсь — это серийники (UUIDы) дисков. Но помимо этого 1С контролирует и другие параметры сервера. Окружение программное и аппаратное.
Слышал о случаях, когда лицензия слетала после применения сервис паков. Но подтвердить достоверность не смогу.
Я впервые работаю с собственным выделенным сервером, и у меня возникает проблема, когда я пытаюсь перенести большой (10 ГБ, миллионы строк) файл резервной копии postgresql в новую таблицу. Запуск ubuntu 18.04 LTS.
Я установил postgresql с помощью apt-get, затем вошел в систему как root и создал базу данных.
Затем я запустил
sudo -u postgres psql mytable в / root
appart из-за ошибки отсутствующей роли он начал работать до тех пор, пока я не начал получать такие ошибки, как:
ERROR: could not extend file "base/16384/16472.4": wrote only 4096 of
8192 bytes at block 635129
HINT: Check free disk space.
CONTEXT: COPY stock_prices, line 28568936
ERROR: could not extend file "base/16384/16480": No space left on device
HINT: Check free disk space.
CONTEXT: COPY stocks, line 99
он продолжал работать «нормально» после этого:
...
setval
---------
1864218
(1 row)
setval
---------
1356711
(1 row)
setval
--------
478761
(1 row)
...
, пока не превратился в набор:
ERROR: could not create temporary file "base/pgsql_tmp/pgsql_tmp3458.0": No such file or directory
ERROR: could not extend file "base/16384/16503": No space left on device
my файловая система выглядит так:
Filesystem Size Used Avail Use% Mounted on
udev 16G 0 16G 0% /dev
tmpfs 3.2G 1000K 3.2G 1% /run
/dev/md2 20G 12G 6.2G 67% /
tmpfs 16G 8.0K 16G 1% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 16G 0 16G 0% /sys/fs/cgroup
/dev/md3 420G 9.3G 390G 3% /home
/dev/md1 487M 146M 312M 32% /boot
tmpfs 3.2G 0 3.2G 0% /run/user/0
Прочитав несколько связанных вопросов, некоторые люди говорят, что существует проблема в разделах сервера здесь , другие говорят, что нужно увеличить размер корневого раздела, кроме того, что это может быть проблема только с временной памятью, необходимой во время импорта и для изменения файла конфигурации psql.
Я немного растерялся, на сервере нет ничего, кроме базовой конфигурации безопасности и PSQL + файла резервной копии, поэтому, если нужно внести изменения в размер раздела, сейчас самое подходящее время, но я не знаю, что происходит в моем случае и не хочу все испортить, если это ничего не исправит.
1
postgresql ubuntu-18.04 import
задан
2 July 2019 в 10:00
Ссылка
2 ответа
Итак, я выполнил этот учебник , чтобы переместить каталог данных в / home / postgresql /, и он работает.
ответ дан
4 December 2019 в 10:57
Ссылка
ответ дан
4 December 2019 в 10:57
Ссылка
Теги
postgresql ubuntu-18.04 import
Похожие вопросы
-
385
Каково имя пользователя/пароль суперпользователя по умолчанию для пост-ГРЭС после новой установки? - 21 September 2017 17:21
-
154
Как я загружаю sql.gz файл в свою базу данных? (импорт) - 14 April 2015 13:10
-
101
Как видеть активные соединения и “текущее действие” в PostgreSQL 8.4 - 1 April 2010 02:06
-
99
Postgresql предлагает настроить tzdata при установке во время сборки образа докера [дубликат] - 21 January 2019 04:46
-
89
ПРЕДОСТАВЬТЕ ВЫБОР всем таблицам в postgresql - 13 April 2017 15:14
-
82
Пост-ГРЭС, эквивалентная G MySQL? - 2 July 2009 00:54
-
69
Существует ли эквивалент ВЫСТАВОЧНОГО CREATE TABLE MySQL в Пост-ГРЭС? - 29 October 2019 23:55
-
66
pg_dump и pg_restore: входной файл, кажется, не допустимый архив - 14 June 2010 19:15
-
65
Каковы недостатки запуска базы данных внутри виртуальной машины? Как мне их преодолеть? [closed] - 7 September 2011 18:02
-
60
Postgresql: что действительно ДОПУСКАЕТ, что ВСЕ ПОЛНОМОЧИЯ НА БАЗЕ ДАННЫХ делают? - 4 November 2010 05:13
-
49
Как установить libpq-dev на Centos 5.5 - 29 September 2011 09:03
-
45
Репликация PostgreSQL - 22 May 2009 09:22
-
39
Экспортировать и импортировать базу данных PostgreSQL с другим именем? - 29 January 2011 17:59
-
31
bzip2 слишком медленно. Возможно использование нескольких ядер - 25 July 2018 14:38
-
29
как защитить открытый порт PostgreSQL - 28 January 2016 14:37
-
09-22-2014, 03:57 PM
#1
Junior Member
Раздулась база
Раздулась База в ХМ2. Пишет общий вес 193Гб. Хотя на самом деле она весит не больше 20Гб. Как-то такая фигня уже случалась. И у меня получилось исправить этот глюк, сделав Вакуум и Реиндексацию.
Но сейчас при попытке сделать Вакуум базы(FULL+Analyze) вылезает вот такая ошибка:[SPOILER]ИНФОРМАЦИЯ: очистка «public.handhistories» ОШИБКА: не удалось увеличить файл «base/16392/169717551.9»: No space left on device HINT: Проверьте, есть ли место на диске. ОШИБКА: не удалось увеличить файл «base/16392/169717551.9»: No space left on device HINT: Проверьте, есть ли место на диске.[/SPOILER]
Таким образом объем базы не уменьшается. И продолжает весить ОЧЕНЬ много.
Подскажите, пожалуйста, что можно предпринять?Пользуюсь НотеКадди. Как раз после очередного блока нотсов база и раздулась.
П.С. Всё обслуживание базы делал с помощью PGAdmin III, не в самом ХМ2.
Пользуюсь PostgreSQL 9.0Создавал тему на форуме Покерстратеджи. Советы не помогли.
http://ru.pokerstrategy.com/forum/th…readid=1013696Сейчас появились новые особенности. Около двух недель импорт и последущая запись нотсов проходила нормально в стандартном режиме. Но сегодня опять сожрало всё оставшееся свободное место(Более 10Гб).
В поисках этих самых файлов, которые занимают всё место наткнулся на такую картину:И вот таких файлов с одним и тем же именем только в этом случае набралось 173 шт. Также существуют менее объемные файлы, которых набралось 22 шт. с одним именем.
Можно ли что-нибудь сделать? Кроме сноса базы?
Спасибо.
-
09-22-2014, 05:25 PM
#2
Senior Member
Тут много причин может быть, их подробно разбирали в разделе ноуткедди, плюс есть куча мануалов по постгре. Для начала попробуй следующий сценарий:
1. Полный бекап базы из хм2.
2. Полное удаление существующей базы в хм2.
3. Отключение всех видов логов в конфиге постгре. А еще лучше обновить постгре плюс прописать в конфиг все рекомендуемые оптимизации.
4. Пообновлять все что можно из софта, включая виндовс и все системное.
5. Создать новую базу в хм2 из бекапа.
6. Сделать полный ресет нотсов в ноуткедди.Если номер 1 не получится, значит база порченная, но это еще не приговор, есть сценарии лечения и для этого случая.
Кроме того, что бы полный вакуум постгре в принципе мог произойти, на разделе с базой должно быть свободного места столько же, сколько вся база сама весит, или хотя бы не намного меньше (а лучше больше, что бы знать что косяк точно не сдесь). Иначе полный вакуум произойти не сможет, а частичный вакуум может и не помочь вовсе.
-
09-23-2014, 03:05 AM
#3
Holdem Manager Support
A) Вот это «1 048…» есть максимальный размер файла, разрешенного в Postgres. Потому их и столько с одинаковым именем, что в один не поместилось.
А там внутри — почти наверняка именно нотсы Caddy.B) Кроме того, сообщение о нехватке места на диске — скорее всего, относится к диску системному.
Потому что вакумирование и прочие процедуры активно используют папку TEMP профиля юзера Виндовс. А она, как правило, на системном диске находится.Кстати, функция HM backup тоже будет класть промежуточные результаты работы (а их много образуется, пока процесс не завершится) в ту же TEMP — так что вполне возможно, что и бекап-то не доделается.
Общее правило: для работы HM backup места в папке TEMP должно быть раза в четыре больше, чем размер БД.Можно попробовать ее перенести на другой диск — Гугл даст полмиллиона ссылок на (одинаковые) инструкции, как это делается. Там просто.
Раздулась база
Я продолжаю сталкиваться с этой ошибкой в Windows Postgresql, выполняющей большой запрос:
[53100] ERROR: could not write block 21991344 of temporary file: No space left on device
Единственная проблема заключается в том, что у меня на самом деле есть огромное количество места, оставленного на всех моих разделах (в том числе 171 ГБ на раздел, содержащий каталог данных и 448 ГБ в моем единственном другом разделу).
Похоже, что какая-то внутренняя настройка предотвращает создание временного файла, с которым я не знаком. Я просмотрел файл конфигурации и без посторонней помощи изменил пару настроек для работы с временными таблицами.
Я смог запустить запрос раньше, не сильно изменился в базе данных от пары таблиц.
1 ответ
Лучший ответ
21991344 блока — 168 ГБ. Это довольно близко к тому месту, которое, по вашему мнению, у вас есть бесплатно. Также может использоваться какой-то другой временный файл меньшего размера, составляющий различия (или это может быть разница в определении ГБ, 10 ^ 9 или 2 ^ 30).
4
jjanes
24 Сен 2019 в 23:59
I’m running a query that duplicates a very large table (92 million rows) on PostgreSQL. After a 3 iterations I got this error message:
The query was:
CREATE TABLE table_name
AS SELECT * FROM big_table
The issue isn’t due to lack of space in the database cluster: at 0.3% of max possible storage at the time of running the query, table size is about 0.01% of max storage including all replicas. I also checked temporary files and it’s not that.
Laurenz Albe
203k17 gold badges193 silver badges250 bronze badges
asked Nov 9, 2020 at 14:32
3
You are definitely running out of file system resources.
Make sure you got the size right:
SELECT pg_table_size('big_table');
Don’t forget that the files backing the new table are deleted after the error, so it is no surprise that you have lots of free space after the statement has failed.
One possibility is that you are not running out of disk space, but of free i-nodes. How to examine the free resources differs from file system to file system; for ext4 on Linux it would be
sudo dumpe2fs -h /dev/... | grep Free
answered Nov 9, 2020 at 17:55
Laurenz AlbeLaurenz Albe
203k17 gold badges193 silver badges250 bronze badges