АЛ
в однопольз режиме в другое место пишет?
grep -E 'WARNING|ERROR|FATAL|PANIC' postgresql-$(date +%Y-%m-%d).log | sed -rn '/WARNING:|ERROR:|FATAL:|PANIC:/{s/^.*(((WARNING|ERROR|FATAL|PANIC): [^:]*).*$)/\2/;p}' | sort | uniq -c | sort -nr | headSize: a a a
2020 May 25
VY
перейдите в тот каталог и выполните:
АЛ
45544 WARNING: there is no transaction in progress
38636 ERROR: database is not accepting commands to avoid wraparound data loss in database "DB"
4394 ERROR: database is not accepting commands to avoid wraparound data loss in database "DB" at character 59
2258 ERROR: database is not accepting commands to avoid wraparound data loss in database "DB" at character 58
256 ERROR: database is not accepting commands to avoid wraparound data loss in database "DB" at character 57
20 FATAL: database is not accepting commands to avoid wraparound data loss in database "DB"
4 WARNING: database "DB" must be vacuumed within 1523703 transactions
4 WARNING: database "DB" must be vacuumed within 1519688 transactions
4 WARNING: database "DB" must be vacuumed within 1518542 transactions
4 WARNING: database "DB" must be vacuumed within 1517834 transactions
38636 ERROR: database is not accepting commands to avoid wraparound data loss in database "DB"
4394 ERROR: database is not accepting commands to avoid wraparound data loss in database "DB" at character 59
2258 ERROR: database is not accepting commands to avoid wraparound data loss in database "DB" at character 58
256 ERROR: database is not accepting commands to avoid wraparound data loss in database "DB" at character 57
20 FATAL: database is not accepting commands to avoid wraparound data loss in database "DB"
4 WARNING: database "DB" must be vacuumed within 1523703 transactions
4 WARNING: database "DB" must be vacuumed within 1519688 transactions
4 WARNING: database "DB" must be vacuumed within 1518542 transactions
4 WARNING: database "DB" must be vacuumed within 1517834 transactions
VY
вакуум завершается без ошибок, когда вы его запускаете?
какая версия базы?
какая версия базы?
SELECT version();АЛ
база 9.6
VY
база 9.6
а можно полную версию?
ПЕ
backend> select oid, relname, age(relfrozenxid) from pg_class order by age(relfrozenxid) desc limit 5;
1: oid (typeid = 26, len = 4, typmod = -1, byval = t)
2: relname (typeid = 19, len = 64, typmod = -1, byval = f)
3: age (typeid = 23, len = 4, typmod = -1, byval = t)
----
1: oid = "11654" (typeid = 26, len = 4, typmod = -1, byval = t)
2: relname = "pg_roles" (typeid = 19, len = 64, typmod = -1, byval = f)
3: age = "2147483647" (typeid = 23, len = 4, typmod = -1, byval = t)
----
1: oid = "11718" (typeid = 26, len = 4, typmod = -1, byval = t)
2: relname = "pg_settings" (typeid = 19, len = 64, typmod = -1, byval = f)
3: age = "2147483647" (typeid = 23, len = 4, typmod = -1, byval = t)
----
1: oid = "11723" (typeid = 26, len = 4, typmod = -1, byval = t)
2: relname = "pg_file_settings" (typeid = 19, len = 64, typmod = -1, byval = f)
3: age = "2147483647" (typeid = 23, len = 4, typmod = -1, byval = t)
----
1: oid = "11732" (typeid = 26, len = 4, typmod = -1, byval = t)
2: relname = "pg_config" (typeid = 19, len = 64, typmod = -1, byval = f)
3: age = "2147483647" (typeid = 23, len = 4, typmod = -1, byval = t)
----
1: oid = "11658" (typeid = 26, len = 4, typmod = -1, byval = t)
2: relname = "pg_shadow" (typeid = 19, len = 64, typmod = -1, byval = f)
3: age = "2147483647" (typeid = 23, len = 4, typmod = -1, byval = t)
----
1: oid (typeid = 26, len = 4, typmod = -1, byval = t)
2: relname (typeid = 19, len = 64, typmod = -1, byval = f)
3: age (typeid = 23, len = 4, typmod = -1, byval = t)
----
1: oid = "11654" (typeid = 26, len = 4, typmod = -1, byval = t)
2: relname = "pg_roles" (typeid = 19, len = 64, typmod = -1, byval = f)
3: age = "2147483647" (typeid = 23, len = 4, typmod = -1, byval = t)
----
1: oid = "11718" (typeid = 26, len = 4, typmod = -1, byval = t)
2: relname = "pg_settings" (typeid = 19, len = 64, typmod = -1, byval = f)
3: age = "2147483647" (typeid = 23, len = 4, typmod = -1, byval = t)
----
1: oid = "11723" (typeid = 26, len = 4, typmod = -1, byval = t)
2: relname = "pg_file_settings" (typeid = 19, len = 64, typmod = -1, byval = f)
3: age = "2147483647" (typeid = 23, len = 4, typmod = -1, byval = t)
----
1: oid = "11732" (typeid = 26, len = 4, typmod = -1, byval = t)
2: relname = "pg_config" (typeid = 19, len = 64, typmod = -1, byval = f)
3: age = "2147483647" (typeid = 23, len = 4, typmod = -1, byval = t)
----
1: oid = "11658" (typeid = 26, len = 4, typmod = -1, byval = t)
2: relname = "pg_shadow" (typeid = 19, len = 64, typmod = -1, byval = f)
3: age = "2147483647" (typeid = 23, len = 4, typmod = -1, byval = t)
----
Пофризьте таблицы в pg_catalog
АЛ
а можно полную версию?
PostgreSQL 9.6.6 on x86_64-pc-linux-gnu
РЖ
Пофризьте таблицы в pg_catalog
В 12-ой версии попытка вакуума заканчивается так:
backend> vacuum pg_roles;
2020-05-25 12:17:08.343 +07 [28214] WARNING: skipping "pg_roles" --- cannot vacuum non-tables or special system tables
2020-05-25 12:17:08.343 +07 [28214] LOG: duration: 0.838 ms statement: vacuum pg_roles;VY
PostgreSQL 9.6.6 on x86_64-pc-linux-gnu
ставим 9.6.18, чтобы получить багфиксы за 3 года. повторяем упражнение
АЛ
нет возможности поднять версию. только до 9.6.7 могу
АЛ
у меня дистр для 1С
AB
у меня дистр для 1С
откуда брали?
VY
https://why-upgrade.depesz.com/show?from=9.6.6&to=9.6.18&keywords=vacuum
в 9.6.7 тоже были закрыты баги по вакууму. но лучше найти возможность до актуальной 9.6.18 прыгнуть
в 9.6.7 тоже были закрыты баги по вакууму. но лучше найти возможность до актуальной 9.6.18 прыгнуть
AK
Подскажите, а если БД PostgreSQL маленького размера(20-25MB)
Есть смысл делать какие-либо "тюнинги" типо размер кеша и т.д. для увеличения скорости работы ?
Есть смысл делать какие-либо "тюнинги" типо размер кеша и т.д. для увеличения скорости работы ?
АЛ
Andrew Bille
откуда брали?
с releases на 1с
AB
с releases на 1с
так вроде у них есть более свежие 9.6
АЛ
далее 10 версия уже
ДЛ
Подскажите, а если БД PostgreSQL маленького размера(20-25MB)
Есть смысл делать какие-либо "тюнинги" типо размер кеша и т.д. для увеличения скорости работы ?
Есть смысл делать какие-либо "тюнинги" типо размер кеша и т.д. для увеличения скорости работы ?
Ну, очевидно то, что размер кэша более этих 25 МБ никогда не будет заполнен...
Опять же, не один размер определяет нагрузку на БД. Если с этими 25 МБ работают 1000 юзеров, то она может быть довольно нагруженной..
Опять же, не один размер определяет нагрузку на БД. Если с этими 25 МБ работают 1000 юзеров, то она может быть довольно нагруженной..
Б
кто работает на Access?