Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

1С заставляет PostgreSQL генерить огромные логи

1С заставляет PostgreSQL генерить огромные логи
Я
   linuxmaster
 
24.03.21 - 12:34
Что делать?
Обновили голову до 8.3.18.1208. Сначала было всё хорошо. А вот уже последний месяц - вот такое:

< 2021-03-24 05:23:23.266 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt12')
< 2021-03-24 05:23:23.267 EDT >LOG:  fast-truncating relation pg_temp.tt11
< 2021-03-24 05:23:23.267 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt11')
< 2021-03-24 05:23:23.268 EDT >LOG:  fast-truncating relation pg_temp.tt10
< 2021-03-24 05:23:23.268 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt10')
< 2021-03-24 05:23:24.668 EDT >LOG:  fast-truncating relation pg_temp.tt1
< 2021-03-24 05:23:24.668 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt1')
< 2021-03-24 05:23:34.291 EDT >LOG:  fast-truncating relation pg_temp.tt246
< 2021-03-24 05:23:34.291 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt246')
< 2021-03-24 05:23:34.326 EDT >LOG:  fast-truncating relation pg_temp.tt245
< 2021-03-24 05:23:34.326 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt245')
< 2021-03-24 05:23:34.328 EDT >LOG:  fast-truncating relation pg_temp.tt247
< 2021-03-24 05:23:34.328 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt247')
< 2021-03-24 05:23:34.330 EDT >LOG:  fast-truncating relation pg_temp.tt232
< 2021-03-24 05:23:34.330 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt232')
< 2021-03-24 05:23:34.332 EDT >LOG:  fast-truncating relation pg_temp.tt248
< 2021-03-24 05:23:34.332 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt248')
< 2021-03-24 05:23:34.334 EDT >LOG:  fast-truncating relation pg_temp.tt249
< 2021-03-24 05:23:34.334 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt249')
< 2021-03-24 05:23:34.447 EDT >LOG:  fast-truncating relation pg_temp.tt250
< 2021-03-24 05:23:34.447 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt250')
< 2021-03-24 05:23:34.448 EDT >LOG:  fast-truncating relation pg_temp.tt251
< 2021-03-24 05:23:34.448 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt251')
< 2021-03-24 05:23:34.449 EDT >LOG:  fast-truncating relation pg_temp.tt252
< 2021-03-24 05:23:34.449 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt252')
< 2021-03-24 05:23:34.449 EDT >LOG:  fast-truncating relation pg_temp.tt253
< 2021-03-24 05:23:34.449 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt253')
< 2021-03-24 05:23:37.132 EDT >LOG:  fast-truncating relation pg_temp.tt49
< 2021-03-24 05:23:37.132 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt49')
< 2021-03-24 05:23:42.275 EDT >LOG:  fast-truncating relation pg_temp.tt244
< 2021-03-24 05:23:42.275 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt244')

Просто очень много в лог идёт. Это что-то сломано или как? Или можно просто отключить логирование этой проблемы?
   piter3
 
1 - 24.03.21 - 12:35
Вбей в поиск 8.3.18.1208
   rphosts
 
2 - 24.03.21 - 12:36
(0) место на иске быстро заканчивается или в чём проблема?
Не слишком агрессивно автовакуум настроен?
   rphosts
 
3 - 24.03.21 - 12:38
или кто-то шринкует временную таблицу (подозреваю что платформа)
   dmrjan
 
4 - 24.03.21 - 12:38
Сервер 1С 32 bit?
   dmrjan
 
5 - 24.03.21 - 12:41
Модуль fasttrun предоставляет транзакционно-небезопасную функцию для усечения временных таблиц, предотвращающую разрастание каталога pg_class.

https://postgrespro.ru/docs/postgrespro/9.6/fasttrun
   linuxmaster
 
6 - 24.03.21 - 12:54
dmrjan нет, 1C сервер x86_64. Версия PostgreSQL: 96-9.6.7-1.1C. Да я читал про этот модуль fasttrun (да, там всё красиво написано, но можно как-то без него?)
rphosts да, очень агрессивно, напрягает, диски изнашиваются, процессор напрягается... Может можно обойтись без этого адского логгирования? Или вообще отключить этот fasttrun и всё будет работать? Тогда как?
piter3 а это мысль... Пойду смотреть release notes...
   arsik
 
7 - 24.03.21 - 13:01
на 12 посгре переходите
   ansh15
 
8 - 24.03.21 - 13:04
Здесь тоже жалуются - https://www.linux.org.ru/forum/admin/15400910
   ansh15
 
9 - 24.03.21 - 13:05
И уйти с 1208 на последние.
   ansh15
 
10 - 24.03.21 - 15:05
Если log_statement установить в none, то эти сообщения записываться в лог не будут. Впрочем, и другие тоже.
А fasttrun выключить проблематично, его специально для 1С писали, без него работать не будет.
Можно написать в 1С, чтобы они там пореже запускали его, так и сказать - диск изнашивается.
   linuxmaster
 
11 - 24.03.21 - 16:14
Снизил уровень логгирования до ошибок в postgresql.conf:
client_min_messages = error
log_min_messages = error

Это решило проблему спама в лог! Но... а как же таблицы pg_temp - они создаются на диске или в оперативной памяти? Стоит о них переживать? Может что-то надо делать в конфигурации 1С (УТ11)?
   linuxmaster
 
12 - 24.03.21 - 16:16
Соврал, опять полезло...
   linuxmaster
 
13 - 24.03.21 - 16:17
Буду делать раздел в оперативной памяти под эту пертрушку...
   Фрэнки
 
14 - 24.03.21 - 16:17
(11) тебе надо повысить релиз постгри. Платформа не рассчитывалась на то, чтоб использовался постгри давних релизов.
   linuxmaster
 
15 - 24.03.21 - 16:19
ansh15 log_statement = 'none' там в конфиге так и есть! А statementы есть всё равно.
   linuxmaster
 
16 - 24.03.21 - 16:19
@Френки вот 100%, да?
   linuxmaster
 
17 - 24.03.21 - 16:20
Пока меня спасёт tmpfs, а там посмотрим ^__^
   mistеr
 
18 - 24.03.21 - 17:14
(11) Временные таблицы (если это они) создаются и удаляются практически в каждом нетривиальном запросе в типовых. Это норма. (C)
   ansh15
 
19 - 24.03.21 - 17:29
(16) Прямого указания на то, что 8.3.18 тестировалась с PostgreSQL ниже 12-й редакции и дало 100% правильные результаты, обнаружить не удавалось.
1С пишет, что "Поддержка этой версии в 1С:Предприятии 8.3 реализована в версии 8.3.18 и старше.
Нагрузочное тестирование проводилось на версиях 1С:Предприятия 8.3.18". Интерпретация смысла этого сообщения может быть для разных людей различной. Лично я считаю, что для 8.3.18 лучше использовать 12.5-12.6.
   Asmody
 
20 - 24.03.21 - 18:15
А буквы EDT в логе — это то, о чем я думаю, или что-то другое?
   vis_tmp
 
21 - 24.03.21 - 18:27
(20) Не думай о нехорошем )


Список тем форума
Рекламное место пустует  Рекламное место пустует
Основная теорема систематики: Новые системы плодят новые проблемы.
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.