Под Windows 10, Ubuntu 20.04 был установлен под виртуальным ящиком Oracle. Postgresql 12.2 был установлен под Ubuntu. Когда я пытаюсь создать таблицу со случайными данными (данные за 31 день с примерно 5 миллионами строк в один день), файл журнала Python показывает завершение (медленно с 24 дня). Но в таблице есть только частичные данные.
Я погуглил и не обнаружил подобной проблемы раньше ...
Информация о разделе диска (835 ГБ из 891 ГБ свободно смонтированы в / var):
user@user-VirtualBox:~$ df -H
Filesystem Size Used Avail Use% Mounted on
udev 34G 0 34G 0% /dev
tmpfs 6.8G 3.1M 6.8G 1% /run
/dev/sda5 100G 8.7G 86G 10% /
tmpfs 34G 8.2k 34G 1% /dev/shm
tmpfs 5.3M 4.1k 5.3M 1% /run/lock
tmpfs 34G 0 34G 0% /sys/fs/cgroup
/dev/sda6 9.0G 3.5G 5.0G 41% /home
/dev/sda7 891G 11G 835G 2% /var
/dev/loop2 253M 253M 0 100% /snap/gnome-3-34-1804/24
Журнал Python показывает медленное начало загрузки данных за 24-й день:
[I 200525 16:10:38 startpoint:22] Start loading 2019-01-01 data...
[I 200525 16:11:25 startpoint:22] Start loading 2019-01-02 data...
[I 200525 16:12:10 startpoint:22] Start loading 2019-01-03 data...
[I 200525 16:12:56 startpoint:22] Start loading 2019-01-04 data...
[I 200525 16:13:45 startpoint:22] Start loading 2019-01-05 data...
[I 200525 16:14:31 startpoint:22] Start loading 2019-01-06 data...
[I 200525 16:15:19 startpoint:22] Start loading 2019-01-07 data...
[I 200525 16:16:04 startpoint:22] Start loading 2019-01-08 data...
[I 200525 16:16:50 startpoint:22] Start loading 2019-01-09 data...
[I 200525 16:17:37 startpoint:22] Start loading 2019-01-10 data...
[I 200525 16:18:24 startpoint:22] Start loading 2019-01-11 data...
[I 200525 16:19:10 startpoint:22] Start loading 2019-01-12 data...
[I 200525 16:19:58 startpoint:22] Start loading 2019-01-13 data...
[I 200525 16:20:44 startpoint:22] Start loading 2019-01-14 data...
[I 200525 16:21:29 startpoint:22] Start loading 2019-01-15 data...
[I 200525 16:22:16 startpoint:22] Start loading 2019-01-16 data...
[I 200525 16:23:02 startpoint:22] Start loading 2019-01-17 data...
[I 200525 16:23:48 startpoint:22] Start loading 2019-01-18 data...
[I 200525 16:24:33 startpoint:22] Start loading 2019-01-19 data...
[I 200525 16:25:23 startpoint:22] Start loading 2019-01-20 data...
[I 200525 16:26:09 startpoint:22] Start loading 2019-01-21 data...
[I 200525 16:26:59 startpoint:22] Start loading 2019-01-22 data...
[I 200525 16:27:47 startpoint:22] Start loading 2019-01-23 data...
[I 200525 16:31:38 startpoint:22] Start loading 2019-01-24 data...
[I 200525 16:38:48 startpoint:22] Start loading 2019-01-25 data...
[I 200525 16:51:38 startpoint:22] Start loading 2019-01-26 data...
[I 200525 17:02:07 startpoint:22] Start loading 2019-01-27 data...
[I 200525 17:14:26 startpoint:22] Start loading 2019-01-28 data...
[I 200525 17:28:36 startpoint:22] Start loading 2019-01-29 data...
[I 200525 17:44:28 startpoint:22] Start loading 2019-01-30 data...
[I 200525 18:09:19 startpoint:22] Start loading 2019-01-31 data...
[I 200525 18:28:45 startpoint:43] end python code
Результирующие записи в созданной таблице:
dbhuge=> select substr(tid::text,1,6) as dt, count(*) from tbl_huge group by 1 order by 1;
dt | count
--------+---------
190107 | 2769655
190108 | 5624951
190109 | 3533726
190121 | 91628
190123 | 3733923
190124 | 5863851
190125 | 5777633
190126 | 5759523
190127 | 5764017
190128 | 5694689
190129 | 5745608
190130 | 5759871
190131 | 5746663
(13 rows)
dbhuge=>
Окончательный размер таблицы составляет всего 5 ГБ:
dbhuge=> SELECT pg_size_pretty( pg_total_relation_size('tbl_huge') );
pg_size_pretty
----------------
4984 MB
(1 row)
dbhuge=>
Любые предложения приветствуются!
Спасибо за предложение @pifor. Часть файла журнала показана ниже. По сравнению с приведенным выше журналом Python, при обычном запуске в журнал печатаются строки подсказки «max_wal_size». Во время странного поведения 16: 31-18: 28 вообще никакой записи в журнале.
2020-05-25 16:27:32.946 PDT [145406] LOG: checkpoints are occurring too frequently (27 seconds apart)
2020-05-25 16:27:32.946 PDT [145406] HINT: Consider increasing the configuration parameter "max_wal_size".
2020-05-25 16:28:00.243 PDT [145406] LOG: checkpoints are occurring too frequently (28 seconds apart)
2020-05-25 16:28:00.243 PDT [145406] HINT: Consider increasing the configuration parameter "max_wal_size".
2020-05-25 19:31:31.650 PDT [234294] sinnud@dbhuge ERROR: relation "tbl_huge" does not exist at character 51
Закройте его сейчас.
Спасибо за предложение моего коллеги. Я начал повторный запуск, и на этот раз все выглядит нормально:
[I 200526 19:09:10 startpoint:22] Start loading 2019-01-01 data...
[I 200526 19:10:58 startpoint:22] Start loading 2019-01-02 data...
[I 200526 19:14:51 startpoint:22] Start loading 2019-01-03 data...
[I 200526 19:23:51 startpoint:22] Start loading 2019-01-04 data...
[I 200526 19:31:47 startpoint:22] Start loading 2019-01-05 data...
[I 200526 19:41:21 startpoint:22] Start loading 2019-01-06 data...
[I 200526 19:52:35 startpoint:22] Start loading 2019-01-07 data...
[I 200526 20:06:06 startpoint:22] Start loading 2019-01-08 data...
[I 200526 20:21:23 startpoint:22] Start loading 2019-01-09 data...
[I 200526 20:38:54 startpoint:22] Start loading 2019-01-10 data...
[I 200526 21:01:23 startpoint:22] Start loading 2019-01-11 data...
[I 200526 21:21:10 startpoint:22] Start loading 2019-01-12 data...
[I 200526 21:43:05 startpoint:22] Start loading 2019-01-13 data...
[I 200526 22:07:12 startpoint:22] Start loading 2019-01-14 data...
[I 200526 22:37:34 startpoint:22] Start loading 2019-01-15 data...
[I 200526 23:05:16 startpoint:22] Start loading 2019-01-16 data...
[I 200526 23:44:49 startpoint:22] Start loading 2019-01-17 data...
[I 200527 00:16:11 startpoint:22] Start loading 2019-01-18 data...
[I 200527 00:49:24 startpoint:22] Start loading 2019-01-19 data...
[I 200527 01:24:27 startpoint:22] Start loading 2019-01-20 data...
[I 200527 02:07:36 startpoint:22] Start loading 2019-01-21 data...
[I 200527 02:46:30 startpoint:22] Start loading 2019-01-22 data...
[I 200527 03:27:16 startpoint:22] Start loading 2019-01-23 data...
[I 200527 04:10:05 startpoint:22] Start loading 2019-01-24 data...
[I 200527 04:53:41 startpoint:22] Start loading 2019-01-25 data...
[I 200527 05:38:31 startpoint:22] Start loading 2019-01-26 data...
[I 200527 06:25:08 startpoint:22] Start loading 2019-01-27 data...
[I 200527 07:13:25 startpoint:22] Start loading 2019-01-28 data...
[I 200527 08:03:33 startpoint:22] Start loading 2019-01-29 data...
[I 200527 08:55:29 startpoint:22] Start loading 2019-01-30 data...
[I 200527 09:50:47 startpoint:22] Start loading 2019-01-31 data...
[I 200527 10:47:08 startpoint:43] end python code startpoint.py.
Теперь у меня есть:
df -H
Filesystem Size Used Avail Use% Mounted on
udev 34G 0 34G 0% /dev
tmpfs 6.8G 3.1M 6.8G 1% /run
/dev/sda5 100G 8.7G 86G 10% /
tmpfs 34G 8.2k 34G 1% /dev/shm
tmpfs 5.3M 4.1k 5.3M 1% /run/lock
tmpfs 34G 0 34G 0% /sys/fs/cgroup
/dev/sda6 9.0G 3.5G 5.0G 41% /home
/dev/sda7 891G 21G 826G 3% /var
/dev/loop2 253M 253M 0 100% /snap/gnome-3-34-1804/24
и
SELECT pg_size_pretty( pg_total_relation_size('tbl_huge') );
pg_size_pretty
----------------
14 GB
(1 row)
Это было медленно, потому что ВМ нужно запросить 14 ГБ пространства у хоста (Windows 10). Я думаю, что первый запуск sh не завершился успешно, потому что конфигурация postgresql имела проблемы, когда я пытался открыть порт 5432. Это было исправлено вчера. Этот прогон прошлой ночью выглядит неплохо.
Спасибо всем за вклад!