pg_dump. Занимает всю оперативную память и весь swap / PostgreSQL

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / pg_dump. Занимает всю оперативную память и весь swap

25 сообщений из 30, страница 1 из 2

все

pg_dump. Занимает всю оперативную память и весь swap

#39559997

Visermoz

Гость

Здравствуйте. Столкнулся с проблемой при снятии копии БД.
Postgresql 9.6.7, ubuntu 16.04. При снятии копии утилитой pg_dump

Код: plsql

pg_dump -U postgres -hlocalhost -d mybase -Fc -b -EUTF8 -v -f /mnt/pgdata/bkp/mybase.pgdmp 2> /mnt/pgdata/bkp/mybase.log

при настройках БД

Код: plsql

1.
2.
3.
4.
5.
6.
7.

Размер БД~ 70GB
shared_buffers =512MB
temp_buffers = 50MB
work_mem = 5MB
maintenance_work_mem = 10MB
autovacuum_work_mem = 300MB
effective_cache_size = 1GB

сначала заполняется вся оперативная память(12гб), после этого и весь swap(8гб) и снятие копии падает.
В логе в это время пишется о чтении информации о БД. в pg_stat_activity мелькают запросы по представлениям вида

Код: plsql

SELECT pg_catalog.pg_get_ruledef('65571296'::pg_catalog.oid) AS definition

Подскажите пожалуйста по какой причине может возникать подобная проблема, можно ли решить ее правильной настройкой postgresql.conf

...

Рейтинг:

0 / 0

27.11.2017, 14:17

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560010

mefman

Участник

Сообщения: 1 562

Рейтинг: 0 / 0

Visermoz

Код: plsql

1.
2.
3.
4.
5.
6.
7.

Размер БД~ 70GB
shared_buffers =512MB
temp_buffers = 50MB
work_mem = 5MB
maintenance_work_mem = 10MB
autovacuum_work_mem = 300MB
effective_cache_size = 1GB

Слабоваты настройки для такого размера. Параметры машины можно увидеть?

...

Рейтинг:

0 / 0

27.11.2017, 14:33

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560013

mefman

Участник

Сообщения: 1 562

Рейтинг: 0 / 0

Попробовать что-то вроде этого:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.

shared_buffers = 3GB
effective_cache_size = 9GB
work_mem = 15728kB
maintenance_work_mem = 768MB
min_wal_size = 1GB
max_wal_size = 2GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100

для начала

...

Рейтинг:

0 / 0

27.11.2017, 14:36

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560014

mefman

Участник

Сообщения: 1 562

Рейтинг: 0 / 0

хорошая отправная точка для настроек ПЖ

...

Рейтинг:

0 / 0

27.11.2017, 14:37

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560266

Visermoz

Гость

mefman,

meminfo

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.

MemTotal:       12293092 kB
MemFree:          276564 kB
MemAvailable:    9365556 kB
Buffers:          337856 kB
Cached:          9196592 kB
SwapCached:        65740 kB
Active:          7040000 kB
Inactive:        4103004 kB
Active(anon):    1318896 kB
Inactive(anon):   925712 kB
Active(file):    5721104 kB
Inactive(file):  3177292 kB
Unevictable:       15340 kB
Mlocked:           15340 kB
SwapTotal:       8388604 kB
SwapFree:        7005544 kB
Dirty:               364 kB
Writeback:             0 kB
AnonPages:       1572520 kB
Mapped:           662536 kB
Shmem:            632536 kB
Slab:             642532 kB
SReclaimable:     575008 kB
SUnreclaim:        67524 kB
KernelStack:        8272 kB
PageTables:       102396 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    14535148 kB
Committed_AS:    5834888 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
AnonHugePages:    854016 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       55232 kB
DirectMap2M:    12527616 kB

Процессор Intel(R) Xeon(R) CPU E5620 @ 2.40GHz

Операционная система: Linux 4.4.0-83-generic #106~14.04.1-Ubuntu SMP Mon Jun 26 18:10:19 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Информация по дискам:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

Filesystem      Size  Used Avail Use% Mounted on
udev            5,9G  8,0K  5,9G   1% /dev
tmpfs           1,2G   18M  1,2G   2% /run
/dev/dm-0        32G  4,6G   25G  16% /
none            4,0K     0  4,0K   0% /sys/fs/cgroup
none            5,0M     0  5,0M   0% /run/lock
none            5,9G  4,0K  5,9G   1% /run/shm
none            100M     0  100M   0% /run/user
/dev/sdb1       1,5T  717G  685G  52% /mnt/data
/dev/sdc1      1008G  201G  757G  21% /mnt/pgdata
/dev/sda1       236M  108M  117M  48% /boot

iostat

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

Linux 4.4.0-83-generic (vr-pg-proud)    28.11.2017      _x86_64_        (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8,40    0,00    0,89    0,70    0,00   90,01

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sdb              19,99      1041,70       935,85 2325539373 2089242712
sda              21,10        39,48       725,03   88143356 1618585694
sdc               3,41       158,29       115,22  353368441  257220048
dm-0             20,24        22,09       631,46   49324965 1409697216
dm-1             27,74        17,38        93,57   38799080  208888464

Спасибо вам за советы. я попробую сегодня с параметрами, которые вы указали

...

Рейтинг:

0 / 0

28.11.2017, 05:22

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560345

mefman

Участник

Сообщения: 1 562

Рейтинг: 0 / 0

iostat ни о чем. Такую инфу нужно приводить в динамике. Графики заббикса например.

...

Рейтинг:

0 / 0

28.11.2017, 09:58

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560449

Visermoz

Гость

mefman,
к сожалению zabbix на сервере не стоит.
в момент разрастания памяти в логе pg_dump последнее

Код: plsql

1.
2.
3.
4.
5.

pg_dump: чтение больших объектов
pg_dump: чтение данных о зависимостях
pg_dump: сохранение кодировки (UTF8)
pg_dump: сохранение standard_conforming_strings (on)
pg_dump: сохранение определения базы данных

я выгрузил результат vmstat -SM 3

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 4  0   2194   3080     32   3976    0    0   156   220    1    1  9  1 90  1  0
 3  0   2194   2945     32   3980    0    0  4339    75  538 1466 32  2 66  1  0
 4  0   2194   2810     32   3986    0    0  3721   112  629 1785 35  2 62  1  0
 2  0   2194   2680     32   3990    0    0  4797     4  424 1732 39  3 58  1  0
 2  0   2194   2561     32   3985    0    0  3471   552  489 2102 24  3 72  0  0
 3  0   2194   2435     32   3986    0    0  3745    17  256 2186 23  2 73  2  0
 1  0   2194   2308     32   3993    0    0  4984    40  405 1476 24  2 73  2  0
 3  0   2194   2186     32   3992    0    0  3811    24  423 1428 20  2 78  1  0
 2  0   2194   2067     32   3998    0    0  3733    17  305 1391 21  2 76  1  0
 3  0   2194   1944     32   3999    0    0  3901     8  488 1570 21  2 77  0  0
 2  0   2194   1811     32   3999    0    0  2973    29  500 1690 28  2 70  1  0
 4  0   2194   1704     32   3997    0    0  4085     0  380 2244 39  3 56  2  0
 3  0   2194   1571     32   3998    0    0  4889    29  756 2246 32  3 64  1  0
 3  0   2194   1431     32   4007    0    0  4453    32  799 2000 38  2 59  1  0
 3  0   2194   1284     32   4016    0    0  4536   101  836 2103 26  2 71  0  0
 1  0   2194   1146     32   4016    0    0  3413    33 1326 3036 20  2 78  1  0
 1  0   2194   1074     32   4007    0    0  4077    93 1297 2984 18  2 80  0  0
 2  1   2193    968     32   4008    0    0  3805    37 1652 3795 24  3 72  1  0
 2  0   2193    885     32   4003    0    0  3747    56  296 1263 25  3 70  3  0
 3  0   2193    774     32   4005    0    0  3604    40  292 1147 22  2 76  1  0
 2  0   2193    645     32   4010    0    0  4560    16  463 1854 26  3 69  1  0
 5  0   2193    502     32   4014    0    0  4341    24  680 2314 42  4 54  0  0
 3  0   2193    358     32   4014    0    0  3240    89  677 2070 31  2 66  0  0
 3  0   2193    243     32   4019    0    0  4680     0  584 2195 29  2 66  3  0
 1  1   2193    159     32   3980    0    0  4480   547  271 1154 28  1 69  1  0
 2  0   2193    160     32   3863    0    0  4416    11 1109 1542 26  2 70  1  0
 2  0   2193    172     32   3739    0    0  4128    15  318 1440 22  2 75  1  0
 2  0   2193    164     32   3594    0    0  3589    47  319 1319 20  2 78  0  0
 2  0   2193    145     30   3529    0    0  4179    13  365 2201 23  5 66  6  0
 2  0   2193    166     25   3439    0    0  5579    65 1393 2495 32  6 57  5  0
 0  1   2257    179     24   3344    0   21  5209 21768  502 1458 19  8 70  3  0
 2  0   2275    152     24   3294    0    6  4965  6591  885 1380 24  2 71  3  0
 3  0   2336    144     24   3198    4   24  8173 24364 2031 2104 34  6 55  4  0
 4  1   2388    155     24   3126    4   21  8560 22172 2824 1799 36  7 53  5  0
 1  1   2445    138     25   3022    1   20  5513 20511 1067 1640 29  3 64  4  0
 1  1   2463    163     25   2972    1    7  4517  6916  508 2243 13  2 76  8  0
 1  3   2495    173      5   2913    2   12  5792 12797  572 1629 20  4 66 10  0
 3  1   2537    159      7   2884    8   22 13603 22497 4669 2362 21  8 53 18  0
 1  4   2598    153      7   2848    2   22  8831 22535 3295 2157 24  8 44 25  0
 3  4   2590    143      8   2883   20   17 24000 17444 1342 2718 11  5 49 35  0
 1  3   2639    149      8   2893    7   22 11751 22881  929 2380 22  5 42 30  0
 1  4   2673    156      8   2900   16   27 20700 27764 1162 2615 12  5 47 35  0
 2  4   2695    148      8   2918   13   20 16227 21052  885 2286 17  5 44 34  0
 3  1   2741    147     11   2913    7   22 10912 22572  911 2462 26  6 41 27  0
 3  2   2783    157     15   2909    9   22 12545 22981 1078 2274 21  4 49 26  0
 4  0   2808    150     16   2911   17   23 20064 24235 1223 3407 20  5 49 26  0
 2  1   2855    147     16   2908    7   22  9779 22659 2114 2234 25  5 49 22  0
 2  2   2924    145      7   2883   16   38 19911 39103 3678 2936 36  8 44 12  0
 2  1   2967    154      6   2906   13   29 16729 29552 1526 2502 20  5 56 19  0
 2  1   3015    156      4   2886    1   16  3889 17043  369 1282 17  4 70  9  0
 1  0   3042    160      4   2883    1    9  3128  9597  409 1337 12  2 76 10  0
 1  1   3065    157      4   2892    5   10  6717 10637  741 2169 11  2 77 10  0
 1  1   3063    147      4   2894    1    0  2157    29  406 1463  8  2 78 13  0
 1  2   3093    171      6   2922   16   24 17497 25073 2079 2678 13  5 60 22  0
 3  1   3109    151      7   2935    7   11  8979 11409  629 2017 21  4 60 15  0
 1  3   3153    155      6   2966   13   26 15355 26943 1680 2388 29  6 43 22  0
 2  2   3180    159      8   2993   10   18 12863 18424 2782 2125 27  5 46 22  0

iostat -m 3 10

Код: plsql

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8,57    0,00    0,90    0,71    0,00   89,81

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sdb              20,24         1,02         0,90    2308209    2041854
sda              22,99         0,04         0,72      91084    1615490
sdc               3,47         0,16         0,11     352140     251466
dm-0             21,94         0,02         0,62      50196    1395824
dm-1             29,56         0,02         0,10      40869     219666

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          13,28    0,00    3,43    9,24    0,00   74,05

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sdb              48,33         1,77         0,00          5          0
sda             429,00         0,65        15,86          1         47
sdc               1,33         0,00         0,01          0          0
dm-0              5,00         0,04         0,03          0          0
dm-1           4485,67         0,60        16,92          1         50

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          21,67    0,00    2,29   10,25    0,00   65,79

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sdb             110,00         1,76         0,00          5          0
sda             188,00         0,88         1,49          2          4
sdc               3,33         0,05         0,02          0          0
dm-0             54,67         0,21         0,04          0          0
dm-1            262,33         0,67         0,36          2          1

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10,79    0,00    3,39   27,76    0,00   58,07

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sdb             117,67         1,48         0,00          4          0
sda             565,33         3,29        18,42          9         55
sdc              12,67         0,08         0,01          0          0
dm-0            231,33         2,22         0,05          6          0
dm-1           4987,00         1,11        18,37          3         55

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18,69    0,00    5,23   26,38    0,00   49,71

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sdb              49,67         0,69         0,00          2          0
sda            1140,33         3,07        15,83          9         47
sdc             194,00         0,76         0,00          2          0
dm-0            341,33         2,45         0,03          7          0
dm-1           4203,33         0,62        15,80          1         47

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          35,94    0,00    3,01   16,76    0,00   44,30

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sdb             201,00         2,02         0,00          6          0
sda             188,67         1,60         1,41          4          4
sdc              56,33         0,25         0,02          0          0
dm-0            138,67         1,25         0,08          3          0
dm-1            424,33         0,32         1,34          0          4

...

Рейтинг:

0 / 0

28.11.2017, 12:04

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560543

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

VisermozЗдравствуйте. Столкнулся с проблемой при снятии копии БД.
Postgresql 9.6.7, ubuntu 16.04. При снятии копии утилитой pg_dump

Код: plsql

pg_dump -U postgres -hlocalhost -d mybase -Fc -b -EUTF8 -v -f /mnt/pgdata/bkp/mybase.pgdmp 2> /mnt/pgdata/bkp/mybase.log

при настройках БД

Код: plsql

1.
2.
3.
4.
5.
6.
7.

Размер БД~ 70GB
shared_buffers =512MB
temp_buffers = 50MB
work_mem = 5MB
maintenance_work_mem = 10MB
autovacuum_work_mem = 300MB
effective_cache_size = 1GB

Код: plsql

SELECT pg_catalog.pg_get_ruledef('65571296'::pg_catalog.oid) AS definition

Подскажите пожалуйста по какой причине может возникать подобная проблема, можно ли решить ее правильной настройкой postgresql.conf

Рекомендую попробовать сначала сделать pg_dump с другого сервера и проверить где закончится память. На базе или на сервере где Pg_dump работает. Тогда станет понятнее куда собственно копать.

...

Рейтинг:

0 / 0

28.11.2017, 13:43

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560563

Visermoz

Гость

Maxim Boguk,
проверил с другого сервера. Память занимает, постоянно увеличиваясь, именно процесс на сервере:

...

Рейтинг:

0 / 0

28.11.2017, 14:18

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560570

Visermoz

Гость

Чуть позже

...

Рейтинг:

0 / 0

28.11.2017, 14:24

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560581

Vadim Lejnin

Участник

Сообщения: 7 675

Рейтинг: 0 / 0

mefmaniostat ни о чем. Такую инфу нужно приводить в динамике. Графики заббикса например.

Практически во всех современных Linux, при установке sysstat, автоматом добавляется сбор статистики.
Можно попробовать вытащить статистику:
sar -d -f /var/log/sa/saXX
Где XX - нужный день

...

Рейтинг:

0 / 0

28.11.2017, 14:40

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560588

mefman

Участник

Сообщения: 1 562

Рейтинг: 0 / 0

Vadim Lejninmefmaniostat ни о чем. Такую инфу нужно приводить в динамике. Графики заббикса например.

Практически во всех современных Linux, при установке sysstat, автоматом добавляется сбор статистики.
Можно попробовать вытащить статистику:
sar -d -f /var/log/sa/saXX
Где XX - нужный день
на убунту по-моему нет. Но не уверен.

...

Рейтинг:

0 / 0

28.11.2017, 14:50

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560990

Visermoz

Гость

Vadim Lejnin, спасибо за совет.
сбор статистики в системе был отключен. прописал true в /etc/default/sysstat и перезапустил службу sysstat .
Теперь сбор появился. сегодня буду пробовать снять копию базы снова и посмотрю что будет в файле статистики.

...

Рейтинг:

0 / 0

29.11.2017, 05:36

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560992

Visermoz

Гость

После включения статистики воспроизвел проблему и в sar получил такое:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

Linux 4.4.0-83-generic (pgserver)    29.11.2017      _x86_64_        (8 CPU)

08:34:49          LINUX RESTART

08:35:01          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
08:45:04      dev8-16    247,74  32337,32      0,50    130,53      2,01      8,10      1,98     48,98
08:45:04       dev8-0    151,78   2554,74  13325,07    104,62      1,85     12,16      2,17     32,96
08:45:04      dev8-32     29,51    266,53     48,79     10,69      0,55     18,79      2,79      8,22
08:45:04     dev252-0     48,15    850,68    105,33     19,85      0,89     18,49      3,50     16,85
08:45:04     dev252-1   1865,52   1704,45  13219,74      8,00     41,45     22,22      0,12     22,22
Average:      dev8-16    247,74  32337,32      0,50    130,53      2,01      8,10      1,98     48,98
Average:       dev8-0    151,78   2554,74  13325,07    104,62      1,85     12,16      2,17     32,96
Average:      dev8-32     29,51    266,53     48,79     10,69      0,55     18,79      2,79      8,22
Average:     dev252-0     48,15    850,68    105,33     19,85      0,89     18,49      3,50     16,85
Average:     dev252-1   1865,52   1704,45  13219,74      8,00     41,45     22,22      0,12     22,22

...

Рейтинг:

0 / 0

29.11.2017, 05:53

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560996

Visermoz

Гость

Особенность базы в том что в ней 30 схем. в каждой схеме примерно по 1000 представлений.
и как раз снятие дампа падает на выгрузке определений этих представлений. Хочу попробовать вариант- сохранить SQL всех представлений, удалить их и снять без них.

Мне интересно- это всё-таки дело в настройках Postgresql или такое количество представлений как-то влияет.
Интересно понять причину почему такое происходит.

...

Рейтинг:

0 / 0

29.11.2017, 06:11

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560998

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

VisermozОсобенность базы в том что в ней 30 схем. в каждой схеме примерно по 1000 представлений.
и как раз снятие дампа падает на выгрузке определений этих представлений. Хочу попробовать вариант- сохранить SQL всех представлений, удалить их и снять без них.

Мне интересно- это всё-таки дело в настройках Postgresql или такое количество представлений как-то влияет.
Интересно понять причину почему такое происходит.

Количество представлений влияет. Настройки не причем. Попробуйте на сервере с 32Gb памяти сделать для интереса, если не помогает - напишите сюда я bug report подготовлю.

PS: а pg_dump -F p -s имя_базы работает или тоже по ООМ валится?

...

Рейтинг:

0 / 0

29.11.2017, 06:26

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39560999

Visermoz

Гость

Maxim Boguk, спасибо за совет.
я попробовал снять копию с параметрами -F p -s, но ошибка также произошла на выгрузке представлений.

После этого попробовал просто получить список представлений в psql:
(system_schema.schema_list - таблица с именами схем с данными и представлениями)

Код: plsql

1.
2.
3.
4.

create table system_schema.d_bkp_view_def as
select v.table_schema,table_name,view_definition
	from information_schema.views v
		join system_schema.schema_list p on v.table_schema=lower(p.schema);

С памятью произошла такая же проблема- начинает забиваться оперативная память и растет swap. А после полного заполнения процесс падает.
План запроса:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

Hash Join  (cost=7.50..8637.18 rows=1783 width=136)
  Output: (nc.nspname)::information_schema.sql_identifier, (c.relname)::information_schema.sql_identifier, (CASE WHEN pg_has_role(c.relowner, 'USAGE'::text) THEN pg_get_viewdef(c.oid) ELSE NULL::text END)::information_schema.character_data
  Hash Cond: (c.relnamespace = nc.oid)
  ->  Seq Scan on pg_catalog.pg_class c  (cost=0.00..8528.82 rows=17387 width=76)
        Output: c.relname, c.relowner, c.oid, c.relnamespace
        Filter: ((c.relkind = 'v'::"char") AND (pg_has_role(c.relowner, 'USAGE'::text) OR has_table_privilege(c.oid, 'SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER'::text) OR has_any_column_privilege(c.oid, 'SELECT, INSERT, UPDATE, REFERENCES'::text)))
  ->  Hash  (cost=7.30..7.30 rows=16 width=68)
        Output: nc.nspname, nc.oid
        ->  Hash Join  (cost=1.54..7.30 rows=16 width=68)
              Output: nc.nspname, nc.oid
              Hash Cond: (((nc.nspname)::information_schema.sql_identifier)::text = lower((p.scheme)::text))
              ->  Seq Scan on pg_catalog.pg_namespace nc  (cost=0.00..4.95 rows=104 width=68)
                    Output: nc.nspname, nc.oid
                    Filter: (NOT pg_is_other_temp_schema(nc.oid))
              ->  Hash  (cost=1.24..1.24 rows=24 width=12)
                    Output: p.schema
                    ->  Seq Scan on system_schema.schema_list p  (cost=0.00..1.24 rows=24 width=12)
                          Output: p.schema

В представлении information_schema.views как раз присутствует функция pg_get_viewdef.

К сожалению сейчас нет сервера с бОльшим количеством памяти чтобы проверить ваш вариант.
Прошу прощения- в самом первом сообщении указал неправильную версию Postgresql - сейчас используется 9.5.7, а я написал 9.6.7.
Как вы считаете, стоит ли обновиться на 9.6 чтобы проверить вариант с ошибками в текущем релизе 9.5.7?

...

Рейтинг:

0 / 0

29.11.2017, 07:02

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39561001

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

Visermoz,

Вам стоит обновится на 9.5.10 в начале (на последний стабильный релиз 9.5 ветки).
Может там эта проблема уже исправлена.
Если нет - я попробую bug report написать но вам стоит более подробно вашу схему описать.
Сколько у вас всего views/схем/насколько каждый view в среднем длинный и тд.

...

Рейтинг:

0 / 0

29.11.2017, 07:14

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39561002

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

Maxim BogukVisermoz,

Вам стоит обновится на 9.5.10 в начале (на последний стабильный релиз 9.5 ветки).
Может там эта проблема уже исправлена.
Если нет - я попробую bug report написать но вам стоит более подробно вашу схему описать.
Сколько у вас всего views/схем/насколько каждый view в среднем длинный и тд.

И на всякий случай проверьте а запрос вида

select (CASE WHEN pg_has_role(c.relowner, 'USAGE'::text) THEN pg_get_viewdef(c.oid) ELSE NULL::text END) as view_src from pg_class c where (c.relkind = 'v'::"char");

отрабатывает или тоже роняет сервер в OOM

если роняет то проверьте запрос

select pg_get_viewdef(c.oid) as view_src from pg_class c where (c.relkind = 'v'::"char");

...

Рейтинг:

0 / 0

29.11.2017, 07:18

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39561040

Visermoz

Гость

Maxim Boguk,
попробую сегодня обновить версию до 9.5.10.

Интересно, что запрос

Код: plsql

select (CASE WHEN pg_has_role(c.relowner, 'USAGE'::text) THEN pg_get_viewdef(c.oid) ELSE NULL::text END) as view_src from pg_class c where (c.relkind = 'v'::"char");

всё-таки выполнился за 1 час. при его выполнении память процесса была 12 Гб и 3 гб в свопе.

Сейчас в базе 22 схемы и в каждой около 1000 представлений:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.

имя схемы         количество представлений
---------------------------------------------------
prj_schema1:	1058
prj_schema2:	1060
prj_schema3:	1060
prj_schema4:	1060
prj_schema5:	1060
prj_schema6:	1060
prj_schema7:	1065
prj_schema8:	1057
prj_schema9:	1060
prj_schema10:	1060
prj_schema11:	1225
prj_schema12:	1060
prj_schema13:	1060
prj_schema14:	1060
prj_schema15:	1071
prj_schema16:	1060
prj_schema17:	1065
prj_schema18:	1058
prj_schema19:	1060
prj_schema20:	1060
prj_schema21:	1067
prj_schema22:	1058

в среднем по проекту длина SQL представления 1900 символов.
В каждом SQL минимум 3 таблицы и минимум 10 полей.

...

Рейтинг:

0 / 0

29.11.2017, 09:26

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39561058

mefman

Участник

Сообщения: 1 562

Рейтинг: 0 / 0

Maxim BogukКоличество представлений влияет.

Вы имееtе в виду, что при дампе проводится select * из каждого? Или он на метадате затыкается?

...

Рейтинг:

0 / 0

29.11.2017, 09:56

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39561100

Visermoz

Гость

mefman,
падает на метаданных: идет огромное количество(как я понимаю по количеству представлений) запросов вида:

Код: plsql

SELECT pg_catalog.pg_get_ruledef('65571296'::pg_catalog.oid) AS definition

...

Рейтинг:

0 / 0

29.11.2017, 10:43

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39561121

mefman

Участник

Сообщения: 1 562

Рейтинг: 0 / 0

Странно конечно. 30000 доп объектов - не так много. Тем более сервак хоть не супер мощный, но для базы в 70Г вполне подойдет.
Попробуйте, действительно обновиться до последней 9.5. если есть возможность потестируйте где-нибудь 9.6.

...

Рейтинг:

0 / 0

29.11.2017, 11:07

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39561138

Visermoz

Гость

Обновил версию до 9.5.10 , но ошибка также воспроизвелась.

Попробую на выходных обновиться до 9.6 и на этой версии снять копию

...

Рейтинг:

0 / 0

29.11.2017, 11:36

| Ответить | Цитировать | Написать

pg_dump. Занимает всю оперативную память и весь swap

#39561171

Visermoz

Гость

Пока остановился на таком решении:
буду снимать копии с помощью Pg_dump не базы целиком, а за несколько приходов. в pg_dump с ключом -n указываю первые 7 схем, следующий запуск с указанием других схем и т.д.
Проверил такой вариант- работает и память так сильно не расходуется.

Конечно, было бы интересно понять причину такой ошибки.

Всем большое спасибо за советы и подсказки

...

Рейтинг:

0 / 0

29.11.2017, 12:12

| Ответить | Цитировать | Написать

25 сообщений из 30, страница 1 из 2

все

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / pg_dump. Занимает всю оперативную память и весь swap

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=53&fpage=62&tid=1996059]:	0ms
get settings:	10ms
get forum list:	15ms
check forum access:	4ms
check topic access:	4ms
track hit:	37ms
get topic data:	13ms
get forum data:	3ms
get page messages:	93ms
get tp. blocked users:	1ms
others:	293ms

total:	473ms