![]() |
|
1С:Предприятие
:: 1С:Предприятие 8 общая
|
|
| ||
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) Не думай о нехорошем ) |
|
Список тем форума |