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ГБ
загрузили бэкап, все ок
админ и руководство хотят узнать есть ли методы анализа требуемого места для предстоящего обновления
я не знаю таких методов, помогите найти вразумительные слова для них, или может предложите решение
1 — 09.01.23 — 12:33
(0) Жесть, экономить место на диске? Вы серьезно? 7 гигов свободно????
ИМХО на диске должно быть хотя бы в 2-3 раза больше места чем размер базы.
2 — 09.01.23 — 12:34
(1) это само собой, я сразу это сказал, налейте места и забудем на ближайшие несколько лет
но им хочется анализ
3 — 09.01.23 — 12:34
если перекладывать из одних таблиц в другие при реструктуризации базы, логично предположить, что свободного места должно быть не меньше текущего размера базы + логи транзакций?
если база 20 Гектар, то и места должно быть не меньше 20 Га?
4 — 09.01.23 — 12:39
>>есть ли методы анализа требуемого места для предстоящего обновления
Не думаю, если при обновлении не написано ничего в подсказках, но если
>>размер базы около 20Гб
>>свободного места на тот момент было 7ГБ
тут ИМХО и так более чем очевидно. Если у вас там не раритетные суперскоростные скази-диски или не оптаны лимитированной серии, то смысл крохоборить?…
5 — 09.01.23 — 12:40
(4) ну как вариант арендовать SSD диск на время обновления, после обновления базу вернуть взад
6 — 09.01.23 — 12:42
то есть метод анализа примерно такой как (3)?
минимум размер базы плюс подушка какая-то
7 — 09.01.23 — 12:43
(2) Дык анализ уже произведен средствами 1С: Нет места на жестком диске….
8 — 09.01.23 — 12:43
(6) За анализом им к психологу, он им поставит анализ.
Или анализ чего им нужно?
9 — 09.01.23 — 12:44
(8) требуемого свободного места на диске для корректного завершения обновления
10 — 09.01.23 — 12:44
(7) они хотят перед обновлением оценивать — хватит места или нет
11 — 09.01.23 — 12:45
(8) Ну автор нормальный вопрос задал, просто читать всю ветку надо) Типа предварительный анализ перед обновлением — хватит ли места.
12 — 09.01.23 — 12:45
(7) особенно «анализ» обновления типовой ERP (соблюдайте спокойствие. поезд скоро отправится. обновление в зависимости от количества данных займет от нескольких минут до нескольких дней)
и костыли в виде запуска в параллель нескольких фоновых заданий и галочка производительности обновления или работы пользователей.
а еще обновление через копию базы забыл 🙂
13 — 09.01.23 — 12:47
(9) Это вопрос должен быть адресован админу. Железо — его головняк. Он должен обеспечить работоспособность программы.
14 — 09.01.23 — 12:48
(6) я бы заморачивался если бы речь шла на терабайты. Но «жалкие» (по нынешним дням) ~50 гигов держать свободными уж точно можно…
15 — 09.01.23 — 12:48
(10)
п.1 бэкап базы.
п.2 обновление — > no space left on device HINT: check free disk space
БИНГО! предварительный анализ — недостаточно места! <- вы находитесь здесь
п.4 загружаем из бэкапа базу
п.5 пишем на форум, читаем, много думаем…
16 — 09.01.23 — 12:51
(0) если кратко, то примерно так:
1. через сравнение-объединение определяешь объекты с изменившейся структурой
2. смотришь объем таблиц этих объектов вместе с индексами + объем таблиц Config
3. умножаешь на 2, но лучше сразу на π
вот тебе будет оценка
17 — 09.01.23 — 12:52
(16) кстати да, и неделю времени на анализ (это ж сколько денег можно заработать, если франь)
18 — 09.01.23 — 12:53
(16) спасибо за конкретику
(17) тоже об этом подумал
я думаю мой конспект из этой темы их удовлетворит, всем спасибо, можно закрывать
19 — 09.01.23 — 13:14
Есть шанс что ошибки на диске
20 — 09.01.23 — 13:53
(11) так кроме эмпирического пути других методов нет, даже (размер базы умножь на 2) и то иногда не спасает, тем более когда модель восстановления стоит FULL а не простая.
Так что только делать обновление на копии и смотреть сколько заняло место
21 — 09.01.23 — 16:25
(20) И как же это посмотреть? После обновления база занимает +/- столько же, сколько и до
22 — 09.01.23 — 16:28
А по сути вопроса, если грубо, то: — да ну вас нахрен, даже голову напрягать не стоит из-за 50 гигабайтов…
23 — 09.01.23 — 16:30
(0) обновлял на днях бух корп (размер не смотрел), места на диске было 10г свободных, при обновлении глюкануло что не достаточно места. пришлось чистить немного и повторно обновлять
24 — 09.01.23 — 16:33
(О) размер диска какой? столкнулся с тем что под пользователем, которым обновлял. в темпах пользователя накопился кэш от обновлений, примерно 50 г. можно почистить
25 — 09.01.23 — 16:35
(21) запустить стандартный виндовый счетчик свободного место на время обновления и смотреть минимальное значение?
26 — 09.01.23 — 16:37
(25) Спасибо, не знал что такое вообще есть стандартное в винде
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/
28 — 09.01.23 — 16:58
(27) Все же можно проще, без всяких OneScript
Только что на коленке собрал
FSO=Новый COMОбъект(«Scripting.FileSystemObject»);
Для каждого ТекДиск Из FSO.Drives Цикл
Если ТекДиск.DriveType=2 Тогда
СвободныйОбъем = Окр(fso.GetDrive(ТекДиск.DriveLetter).FreeSpace/1048576,1);
Сообщить(«Диск «+ТекДиск.DriveLetter+» свободно «+СвободныйОбъем+» Мб.»);
КонецЕсли;
КонецЦикла;
29 — 09.01.23 — 16:59
30 — 09.01.23 — 17:06
(28) там вроде как ограничения типа с сетевыми дискми не работает. или в виртуалки чудит, короче тестить надо
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