|
pg_dump. Занимает всю оперативную память и весь swap
|
|||
---|---|---|---|
#18+
mefmanMaxim BogukКоличество представлений влияет. Вы имееtе в виду, что при дампе проводится select * из каждого? Или он на метадате затыкается? Я бы предположил что там где то память течет. Попробую bug report написать сегодня. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2017, 12:56 |
|
pg_dump. Занимает всю оперативную память и весь swap
|
|||
---|---|---|---|
#18+
VisermozПока остановился на таком решении: буду снимать копии с помощью Pg_dump не базы целиком, а за несколько приходов. в pg_dump с ключом -n указываю первые 7 схем, следующий запуск с указанием других схем и т.д. Проверил такой вариант- работает и память так сильно не расходуется. Конечно, было бы интересно понять причину такой ошибки. Всем большое спасибо за советы и подсказки А каждая схема по структуре похожа на другие? Если да - сделайте dump одной схемы и пришлите или сюда в виде файла или мне лично на maxim.boguk@gmail.com я попробую test case сделать у себя и посмотреть что там такое творится. PS: у вас именно обычный postgres? не линтер/pg-pro/enterprise-db форки? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2017, 13:09 |
|
pg_dump. Занимает всю оперативную память и весь swap
|
|||
---|---|---|---|
#18+
VisermozКонечно, было бы интересно понять причину такой ошибки. поскольку вью -- не самое удобная часть пж, то редко кто додумывается ими злоупотре, в таком убойном количестве. вы что, доступом рулите через вью ? зачем их стока--то ? это ж садо--мазо какое-то. если их хотя бы раз в год альтерить. ну вот никто и не натыкался на ... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2017, 14:16 |
|
pg_dump. Занимает всю оперативную память и весь swap
|
|||
---|---|---|---|
#18+
Maxim Boguk, да, используется обычная версия. Спасибо, я подготовлю файл и отправлю вам.Схемы примерно одинаковые по структуре. qwwq, вьюшки используются как тематические выборки из основных данных. Вероятно, не самое удачное решение было использовать для этого именно представления в БД, возможно просто достаточно было хранить текст запроса, а приложении его бы исполняло в нужной ситуации. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 10:00 |
|
pg_dump. Занимает всю оперативную память и весь swap
|
|||
---|---|---|---|
#18+
Проблему удалось решить увеличением swap-раздела до 20Гб. точно не измерял насколько он используется(копии снимаются ночью), но всё прошло без ошибок. Как говорил Maxim Boguk , увеличение памяти на сервере тоже бы помогло. Примерно смоделировал структуру базы на которой воспроизводилась ошибка таким скриптом-реальную схему руководство не разрешило отправлять .(40 схем с 2000 представлений с SQL по длине как в реальной системе): Код: 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. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 05:52 |
|
|
start [/forum/topic.php?fid=53&startmsg=39561211&tid=1996059]: |
0ms |
get settings: |
11ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
80ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
others: | 299ms |
total: | 458ms |
0 / 0 |