Оптимизация работы Postgres

1. hell_vs 14.05.19 17:13 Сейчас в теме
Здравствуйте, дамы и господа, гуру и знатоки!

Обрисую для начала ситуацию, а потом пару вопросов.

Стоит сервак (Xeon E5-2630 v4 2.2ГГц, 128 Гб ОЗУ), на нем крутятся 2 вирт.машины:
1. Win Serv 2012 (80 Гб ОЗУ, 1,0 Тб HDD) - Терм. сервер
2. Связка CentOS 7 + PostgreSQL 9.6 (40 Гб ОЗУ, 600 Гб HDD) - Сервер 1С + база

Настройки сервера 1С приведены на скриншоте.

На PSQL крутиться база, её размер 35 Гб + временные файлы к ней 450 Гб
+ еще пара мелких баз суммарно на 10 Гб

Так вот вопрос:
что еще можно сделать, потому как при формировании карточки счета за год возникает ситуация, приведенная на втором скриншоте. Либо 1С пишет, что недостаточно памяти.

Ткните носом.

Заранее спасибо.


P.S.: Может не хватает места для самой базы? И если так, то возможно на HyperV расширить HDD или надо новую вирт. машину создавать?
Прикрепленные файлы:
По теме из базы знаний
Найденные решения
18. hell_vs 17.06.19 18:30 Сейчас в теме
Добрый вечер.

Проблему свою решил. Отпишусь, может кому поможет.

Изначально, когда описывал условие вопроса, то был не совсем корректен в описании 2-ой виртуалки (на которой крутятся Сервер 1С и база на PostgreSQL).
Когда потом полез, то выяснилось, что там два диска: на 50 Гб и 500 Гб (sda и sdb, соответственно).
Базы крутятся на sdb, а обработка всех запросов идет там, где стоит сервер 1С, т.е. на sda.
На котором места как оказалось очень мало - используется 45 из 50 Гб.
Изначально я увеличивал место на sdb: думал там база крутится, соответственно там и места не хватает и увеличил с 500 Гб до 1,2 Тб.
А в итоге оказалось, что необходимо было увеличивать sda, что я и сделал (увеличил на 100 Гб).

В итоге все заработало, postgre теперь жует многокилометровые запросы от 1С как и раньше.

Всем спасибо кто помогал: п.п. 9. 13. 16. Вашими подсказками тоже воспользовался.
Остальные ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
3. lefthander 15.05.19 12:24 Сейчас в теме
(1)Смотрите запрос, где то в результатах очень много записей. Проверить можно сформируйте за квартал или 6 месяцев. Если все нормально, то скорее всего в запросе есть не оптимальность.
2. a.doroshkevich 1423 15.05.19 12:22 Сейчас в теме
4. hell_vs 16.05.19 18:29 Сейчас в теме
Сервер х64.
Сам запрос, как я понимаю, стандартный.
С октября организация начала оч. активно прирастать филиалами и, соответственно, база начала пухнуть.
Т.е. с января по сентябрь я могу сформировать (и то, только помесячно), октябрь уже формируется, если почищу место, а о ноябре с декабрем и мечтать не приходится. При формировании падает. Чаще всего пишет "Недостаточно памяти".
На просторах Всемирной все пишут, что речь идет об оперативке, но у меня её более чем достаточно.
Сейчас решил просто попробовать увеличить объем диска где база лежит.
5. hell_vs 16.05.19 22:06 Сейчас в теме
Отредактировать пост не дали.
Читал, что в psql есть процедура вакуумирования базы, т.е. аналог шринкования.
В pgadmin'е можно сделать, но по-таблично. С учетом того, что таблиц там более чем достаточно, возможно эту процедуру применить ко всей базе?
И в принципе стоит ли делать или проще увеличить вирт.хард?
с psql столкнулся впервые
6. acanta 16.05.19 22:44 Сейчас в теме
Поскольку речь идёт о стандартном бухгалтерском отчёте, то об оптимизации речь не идёт. Технологический журнал подключали.?
7. hell_vs 17.05.19 01:51 Сейчас в теме
Журнал подключен.
Вот что пишет:
Прикрепленные файлы:
10. a.doroshkevich 1423 17.05.19 12:35 Сейчас в теме
(7)В момент ошибки какой объём памяти занимает rphost, на котором выполняется операция?
Сколько в этот момент свободной памяти в ОС?
8. hell_vs 17.05.19 05:43 Сейчас в теме
P.S.: Увеличил объем харда с базой до 1,2 Тб.
Эффект тот же...
9. a.doroshkevich 1423 17.05.19 11:25 Сейчас в теме
Покажите настройки PG

В pgadmin'е можно сделать, но по-таблично. С учетом того, что таблиц там более чем достаточно, возможно эту процедуру применить ко всей базе? - правой кнопкой по базе и там Обслуживание
11. hell_vs 17.05.19 14:09 Сейчас в теме
настройки PG:

max_connections = 1000
ssl = off
shared_buffers = 10240MB
work_mem = 8MB
maintenance_work_mem = 1024MB
dynamic_shared_memory_type = posix
shared_preload_libraries = 'online_analyze, plantuner'
bgwriter_delay = 20ms
synchronous_commit = off
wal_buffers = -1
join_collapse_limit = 20
log_destination = 'stderr'
logging_collector = on
log_directory = 'pg_log'
log_filename = 'postgresql-%a.log'
log_truncate_on_rotation = on
log_rotation_age = 1d
log_rotation_size = 0
log_line_prefix = '< %m >'
log_timezone = 'W-SU'
autovacuum = on
autovacuum_max_workers = 4
datestyle = 'iso, dmy'
timezone = 'W-SU'
lc_messages = 'ru_RU.UTF-8'
lc_monetary = 'ru_RU.UTF-8'
lc_numeric = 'ru_RU.UTF-8'
lc_time = 'ru_RU.UTF-8'
default_text_search_config = 'pg_catalog.russian'
max_locks_per_transaction = 256
backslash_quote = on
escape_string_warning = off
standard_conforming_strings = off
online_analyze.threshold = 50
online_analyze.scale_factor = 0.1
online_analyze.enable = off
online_analyze.verbose = off
online_analyze.local_tracking = on
online_analyze.min_interval = 10000
online_analyze.table_type = 'temporary'


Самые основные должны быть такими?

max_connections = 100
shared_buffers = 10GB
effective_cache_size = 30GB
maintenance_work_mem = 2GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 500
random_page_cost = 4
effective_io_concurrency = 2
work_mem = 52428kB
min_wal_size = 4GB
max_wal_size = 8GB

спасибо за подсказку про pgadmin'а
16. a.doroshkevich 1423 27.05.19 05:24 Сейчас в теме
(11)
Поменяйте настройки:
shared_buffers = 7GB
work_mem = 256MB
join_collapse_limit = 8
online_analyze.enable = on
effective_cache_size = 20GB
default_statistics_target = 100

autovacuum_vacuum_scale_factor = 0.01
autovacuum_analyze_scale_factor = 0.005

рестарт PG
12. hell_vs 18.05.19 09:04 Сейчас в теме
по поводу объема памяти
Прикрепленные файлы:
13. Noob001 18.05.19 16:59 Сейчас в теме
(12) А точно сервер 1С то 64x?
Слишком мало памяти что то он ест.
В /opt/1C/v8.3/

Какой каталог?
14. hell_vs 18.05.19 18:56 Сейчас в теме
был неправ, х32.
стоит i386
15. hell_vs 24.05.19 18:06 Сейчас в теме
Снес 32-битную версию, поставил х64
1С-ка по-прежнему при формировании отчета вылетает.

Прихожу к мысли, что надо тюнить posgresql.
Наткнулся сегодня статью о распараллеливании в posgre запросов на несколько ядер.
17. a.doroshkevich 1423 27.05.19 05:26 Сейчас в теме
(15)Судя по ошибке - виноват сервер 1С, ему не хватает оперативы.
PG нужно подтюнить, от этого скорее всего будет выбран другой план запроса, но на память сервера 1С это не повлияет, зато благотворно повлияет на систему в целом.
В итоге, скорее всего придётся смотреть сам код и его править.
18. hell_vs 17.06.19 18:30 Сейчас в теме
Добрый вечер.

Проблему свою решил. Отпишусь, может кому поможет.

Изначально, когда описывал условие вопроса, то был не совсем корректен в описании 2-ой виртуалки (на которой крутятся Сервер 1С и база на PostgreSQL).
Когда потом полез, то выяснилось, что там два диска: на 50 Гб и 500 Гб (sda и sdb, соответственно).
Базы крутятся на sdb, а обработка всех запросов идет там, где стоит сервер 1С, т.е. на sda.
На котором места как оказалось очень мало - используется 45 из 50 Гб.
Изначально я увеличивал место на sdb: думал там база крутится, соответственно там и места не хватает и увеличил с 500 Гб до 1,2 Тб.
А в итоге оказалось, что необходимо было увеличивать sda, что я и сделал (увеличил на 100 Гб).

В итоге все заработало, postgre теперь жует многокилометровые запросы от 1С как и раньше.

Всем спасибо кто помогал: п.п. 9. 13. 16. Вашими подсказками тоже воспользовался.
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот