Здравствуйте, дамы и господа, гуру и знатоки!
Обрисую для начала ситуацию, а потом пару вопросов.
Стоит сервак (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 или надо новую вирт. машину создавать?
Обрисую для начала ситуацию, а потом пару вопросов.
Стоит сервак (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 или надо новую вирт. машину создавать?
Прикрепленные файлы:
По теме из базы знаний
- Инструкция. Устанавливаем выделенный сервер для 1С:Предприятия и PostgreSQL 8.4 на Ubuntu Server 10.04.3 i386
- Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах
- Несколько слов про платформенный механизм оптимизации RLS
- Новое в 14-й и 15-й версиях Postgres
- Опыт оптимизации 1С на PostgreSQL
Найденные решения
Добрый вечер.
Проблему свою решил. Отпишусь, может кому поможет.
Изначально, когда описывал условие вопроса, то был не совсем корректен в описании 2-ой виртуалки (на которой крутятся Сервер 1С и база на PostgreSQL).
Когда потом полез, то выяснилось, что там два диска: на 50 Гб и 500 Гб (sda и sdb, соответственно).
Базы крутятся на sdb, а обработка всех запросов идет там, где стоит сервер 1С, т.е. на sda.
На котором места как оказалось очень мало - используется 45 из 50 Гб.
Изначально я увеличивал место на sdb: думал там база крутится, соответственно там и места не хватает и увеличил с 500 Гб до 1,2 Тб.
А в итоге оказалось, что необходимо было увеличивать sda, что я и сделал (увеличил на 100 Гб).
В итоге все заработало, postgre теперь жует многокилометровые запросы от 1С как и раньше.
Всем спасибо кто помогал: п.п. 9. 13. 16. Вашими подсказками тоже воспользовался.
Проблему свою решил. Отпишусь, может кому поможет.
Изначально, когда описывал условие вопроса, то был не совсем корректен в описании 2-ой виртуалки (на которой крутятся Сервер 1С и база на PostgreSQL).
Когда потом полез, то выяснилось, что там два диска: на 50 Гб и 500 Гб (sda и sdb, соответственно).
Базы крутятся на sdb, а обработка всех запросов идет там, где стоит сервер 1С, т.е. на sda.
На котором места как оказалось очень мало - используется 45 из 50 Гб.
Изначально я увеличивал место на sdb: думал там база крутится, соответственно там и места не хватает и увеличил с 500 Гб до 1,2 Тб.
А в итоге оказалось, что необходимо было увеличивать sda, что я и сделал (увеличил на 100 Гб).
В итоге все заработало, postgre теперь жует многокилометровые запросы от 1С как и раньше.
Всем спасибо кто помогал: п.п. 9. 13. 16. Вашими подсказками тоже воспользовался.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Сервер х64.
Сам запрос, как я понимаю, стандартный.
С октября организация начала оч. активно прирастать филиалами и, соответственно, база начала пухнуть.
Т.е. с января по сентябрь я могу сформировать (и то, только помесячно), октябрь уже формируется, если почищу место, а о ноябре с декабрем и мечтать не приходится. При формировании падает. Чаще всего пишет "Недостаточно памяти".
На просторах Всемирной все пишут, что речь идет об оперативке, но у меня её более чем достаточно.
Сейчас решил просто попробовать увеличить объем диска где база лежит.
Сам запрос, как я понимаю, стандартный.
С октября организация начала оч. активно прирастать филиалами и, соответственно, база начала пухнуть.
Т.е. с января по сентябрь я могу сформировать (и то, только помесячно), октябрь уже формируется, если почищу место, а о ноябре с декабрем и мечтать не приходится. При формировании падает. Чаще всего пишет "Недостаточно памяти".
На просторах Всемирной все пишут, что речь идет об оперативке, но у меня её более чем достаточно.
Сейчас решил просто попробовать увеличить объем диска где база лежит.
Отредактировать пост не дали.
Читал, что в psql есть процедура вакуумирования базы, т.е. аналог шринкования.
В pgadmin'е можно сделать, но по-таблично. С учетом того, что таблиц там более чем достаточно, возможно эту процедуру применить ко всей базе?
И в принципе стоит ли делать или проще увеличить вирт.хард?
с psql столкнулся впервые
Читал, что в psql есть процедура вакуумирования базы, т.е. аналог шринкования.
В pgadmin'е можно сделать, но по-таблично. С учетом того, что таблиц там более чем достаточно, возможно эту процедуру применить ко всей базе?
И в принципе стоит ли делать или проще увеличить вирт.хард?
с psql столкнулся впервые
настройки 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'а
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'а
(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
Поменяйте настройки:
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
(15)Судя по ошибке - виноват сервер 1С, ему не хватает оперативы.
PG нужно подтюнить, от этого скорее всего будет выбран другой план запроса, но на память сервера 1С это не повлияет, зато благотворно повлияет на систему в целом.
В итоге, скорее всего придётся смотреть сам код и его править.
PG нужно подтюнить, от этого скорее всего будет выбран другой план запроса, но на память сервера 1С это не повлияет, зато благотворно повлияет на систему в целом.
В итоге, скорее всего придётся смотреть сам код и его править.
Добрый вечер.
Проблему свою решил. Отпишусь, может кому поможет.
Изначально, когда описывал условие вопроса, то был не совсем корректен в описании 2-ой виртуалки (на которой крутятся Сервер 1С и база на PostgreSQL).
Когда потом полез, то выяснилось, что там два диска: на 50 Гб и 500 Гб (sda и sdb, соответственно).
Базы крутятся на sdb, а обработка всех запросов идет там, где стоит сервер 1С, т.е. на sda.
На котором места как оказалось очень мало - используется 45 из 50 Гб.
Изначально я увеличивал место на sdb: думал там база крутится, соответственно там и места не хватает и увеличил с 500 Гб до 1,2 Тб.
А в итоге оказалось, что необходимо было увеличивать sda, что я и сделал (увеличил на 100 Гб).
В итоге все заработало, postgre теперь жует многокилометровые запросы от 1С как и раньше.
Всем спасибо кто помогал: п.п. 9. 13. 16. Вашими подсказками тоже воспользовался.
Проблему свою решил. Отпишусь, может кому поможет.
Изначально, когда описывал условие вопроса, то был не совсем корректен в описании 2-ой виртуалки (на которой крутятся Сервер 1С и база на PostgreSQL).
Когда потом полез, то выяснилось, что там два диска: на 50 Гб и 500 Гб (sda и sdb, соответственно).
Базы крутятся на sdb, а обработка всех запросов идет там, где стоит сервер 1С, т.е. на sda.
На котором места как оказалось очень мало - используется 45 из 50 Гб.
Изначально я увеличивал место на sdb: думал там база крутится, соответственно там и места не хватает и увеличил с 500 Гб до 1,2 Тб.
А в итоге оказалось, что необходимо было увеличивать sda, что я и сделал (увеличил на 100 Гб).
В итоге все заработало, postgre теперь жует многокилометровые запросы от 1С как и раньше.
Всем спасибо кто помогал: п.п. 9. 13. 16. Вашими подсказками тоже воспользовался.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот