Медленная запись в регистры бухгалтерии после миграции с PostgreSQL 10 на PostgreSQL 16/17
1.
Volodya653
27.05.26 10:57
Сейчас в теме
Предыстория:
Старый сервер начал давать проблемы с RAID — решил перенести всё на новый сервер с NVMe дисками. Заодно решил обновить PostgreSQL с 10-й версии (которая уже очень старая) на актуальную, надеясь что производительность вырастет. По итогу получил обратный эффект.
Конфигурация:
Старый сервер:
Ubuntu 18.04, PostgreSQL 10.5-24.1C
ssd ~100 MB/s
~460 баз, платформа 8.3.24.1548
Новый сервер:
Ubuntu 22.04, PostgreSQL 16.12-1.1C / 17.8-1.1C (пробовали оба)
NVMe 1.5 GB/s, 53GB RAM, 30 ядер Xeon Silver 4208
Платформа 1С 8.3.24.1548
(платформа сервер приложений у меня на отдельном сервере к нему вопросов нет)
Проблема:
Проведение документов (реализация, бухгалтерские проводки) занимает 30-40 секунд вместо мгновенного на старом сервере. Разница в 200 раз!
Из логов PostgreSQL:
sqlINSERT INTO _AccRg12303 ... SELECT — 2500-3000ms
UPDATE _Document299 ... — 2000-2500ms
DELETE FROM _AccRg12303 — 2100ms
На PostgreSQL 10 те же запросы выполнялись быстрее 10ms.
Что проверили:
Железо не виновато — диск в 15 раз быстрее старого, CPU и IO почти не нагружены во время проведения, сеть 0.23ms
wait_event пустой — процесс активно работает без ожидания блокировок
Кэш прогрелся до 15GB при размере базы 8.9GB — скорость не изменилась
Что пробовали:
Перешли с PostgreSQL 17 на PostgreSQL 16 — результат тот же
Применяли все рекомендованные настройки: synchronous_commit=off, jit=off, max_parallel_workers=0, plantuner.fix_empty_table=on, online_analyze.enable=on
REINDEX CONCURRENTLY всех индексов
Реструктуризация базы через конфигуратор 1С
Перезапуск сервера приложений 1С
Прогрев кэша через pg_prewarm
Важное наблюдение:
При тестировании одной базы на PostgreSQL 16 без остальных — скорость отличная. При загрузке всех 460 баз — скорость та же что и на PostgreSQL 17. Т.е. проблема не в количестве баз.
Вопросы:
Какой PostgreSQL актуален для платформы 8.3.24.1548? Если нет решения тогда
Планируем обновить платформу до 8.3.27 — какой PostgreSQL выбрать для неё?
Почему PostgreSQL 10 работает быстро а 16/17 в 200 раз медленнее для INSERT в регистры бухгалтерии (_AccRg)?
Есть ли решение кроме обновления платформы?
Так же пробовал подобные решения применить что писали в соседних темах о медленной работе, в моем случае мало что помогло
конфиг по офису 400-500 баз
Соединений 150-300 одновременно
Старый сервер начал давать проблемы с RAID — решил перенести всё на новый сервер с NVMe дисками. Заодно решил обновить PostgreSQL с 10-й версии (которая уже очень старая) на актуальную, надеясь что производительность вырастет. По итогу получил обратный эффект.
Конфигурация:
Старый сервер:
Ubuntu 18.04, PostgreSQL 10.5-24.1C
ssd ~100 MB/s
~460 баз, платформа 8.3.24.1548
Новый сервер:
Ubuntu 22.04, PostgreSQL 16.12-1.1C / 17.8-1.1C (пробовали оба)
NVMe 1.5 GB/s, 53GB RAM, 30 ядер Xeon Silver 4208
Платформа 1С 8.3.24.1548
(платформа сервер приложений у меня на отдельном сервере к нему вопросов нет)
Проблема:
Проведение документов (реализация, бухгалтерские проводки) занимает 30-40 секунд вместо мгновенного на старом сервере. Разница в 200 раз!
Из логов PostgreSQL:
sqlINSERT INTO _AccRg12303 ... SELECT — 2500-3000ms
UPDATE _Document299 ... — 2000-2500ms
DELETE FROM _AccRg12303 — 2100ms
На PostgreSQL 10 те же запросы выполнялись быстрее 10ms.
Что проверили:
Железо не виновато — диск в 15 раз быстрее старого, CPU и IO почти не нагружены во время проведения, сеть 0.23ms
wait_event пустой — процесс активно работает без ожидания блокировок
Кэш прогрелся до 15GB при размере базы 8.9GB — скорость не изменилась
Что пробовали:
Перешли с PostgreSQL 17 на PostgreSQL 16 — результат тот же
Применяли все рекомендованные настройки: synchronous_commit=off, jit=off, max_parallel_workers=0, plantuner.fix_empty_table=on, online_analyze.enable=on
REINDEX CONCURRENTLY всех индексов
Реструктуризация базы через конфигуратор 1С
Перезапуск сервера приложений 1С
Прогрев кэша через pg_prewarm
Важное наблюдение:
При тестировании одной базы на PostgreSQL 16 без остальных — скорость отличная. При загрузке всех 460 баз — скорость та же что и на PostgreSQL 17. Т.е. проблема не в количестве баз.
Вопросы:
Какой PostgreSQL актуален для платформы 8.3.24.1548? Если нет решения тогда
Планируем обновить платформу до 8.3.27 — какой PostgreSQL выбрать для неё?
Почему PostgreSQL 10 работает быстро а 16/17 в 200 раз медленнее для INSERT в регистры бухгалтерии (_AccRg)?
Есть ли решение кроме обновления платформы?
Так же пробовал подобные решения применить что писали в соседних темах о медленной работе, в моем случае мало что помогло
конфиг по офису 400-500 баз
Соединений 150-300 одновременно
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
3.
Volodya653
27.05.26 13:25
Сейчас в теме
2)
План запроса SELECT на таблицу регистра бухгалтерии:
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM _AccRg12303 WHERE _Period > '2025-01-01' LIMIT 100;
Limit (cost=1.57..58.94 rows=100 width=464)
(actual time=35.878..36.209 rows=100 loops=1)
Buffers: shared hit=3494 read=24
-> Index Scan using _accrg12303_10 on _accrg12303
(cost=0.42..27251.54 rows=47497 width=464)
(actual time=35.875..36.196 rows=100 loops=1)
Index Cond: (_period > '2025-01-01 00:00:00')
Buffers: shared hit=3494 read=24
Planning Time: 2.616 ms
Execution Time: 36.314 ms
Данные в кэше (shared hit=3494, read=24 минимум) но Index Scan занимает 35ms. На PostgreSQL 10 этот запрос выполнялся менее 1ms. Что может быть причиной?
И в этом ли причина?
План запроса SELECT на таблицу регистра бухгалтерии:
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM _AccRg12303 WHERE _Period > '2025-01-01' LIMIT 100;
Limit (cost=1.57..58.94 rows=100 width=464)
(actual time=35.878..36.209 rows=100 loops=1)
Buffers: shared hit=3494 read=24
-> Index Scan using _accrg12303_10 on _accrg12303
(cost=0.42..27251.54 rows=47497 width=464)
(actual time=35.875..36.196 rows=100 loops=1)
Index Cond: (_period > '2025-01-01 00:00:00')
Buffers: shared hit=3494 read=24
Planning Time: 2.616 ms
Execution Time: 36.314 ms
Данные в кэше (shared hit=3494, read=24 минимум) но Index Scan занимает 35ms. На PostgreSQL 10 этот запрос выполнялся менее 1ms. Что может быть причиной?
И в этом ли причина?
7.
starik-2005
3272
27.05.26 14:54
Сейчас в теме
(3)
Данные в кэше (shared hit=3494, read=24 минимум) но Index Scan занимает 35ms. На PostgreSQL 10 этот запрос выполнялся менее 1ms. Что может быть причиной?
Главная причина: Shared Buffers Hit
Посмотрите на эту строку в плане:
Buffers: shared hit=3494 read=24
Что произошло: PostgreSQL прочитал 3518 страниц данных (3494 из кэша + 24 с диска).
Объем данных: Одна страница в Postgres равна 8 КБ. Суммарно запрос прочитал около 27.5 МБ данных.
В чем проблема: Чтобы выдать всего 100 строк, читать 27 МБ — это очень много. На чтение и обработку этих страниц в памяти ушло ~35 мс.
Почему планировщик ошибся (Cost vs Actual)
Оценка стоимости (cost=1.57..58.94): Планировщик считает, что строки в индексе расположены идеально последовательно. Он предположил, что для выдачи 100 строк ему понадобится прочитать буквально несколько страниц.
Реальность (actual time=35.875...): Порядок записей в индексе _accrg12303_10 не совпадает с физическим порядком строк в таблице. Либо нужные 100 строк были «размазаны» по всей таблице, либо первые тысячи проверенных строк не подошли под условия видимости (MVCC).
Другие частые причины для таблиц 1С
Мусорные строки (Dead Rows): Индекс мог ссылаться на старые, удаленные или обновленные версии строк. Postgres тратил время на их чтение, но отсекал, так как они невидимы для вашей транзакции.
Сканирование индекса вместо Index Only Scan: Запрос делает SELECT *. Из-за этого Postgres берет из индекса только ссылку, а за самими данными (всеми 464 байтами ширины строки) каждый раз идет в саму таблицу (Heap).
Посмотрите на эту строку в плане:
Buffers: shared hit=3494 read=24
Что произошло: PostgreSQL прочитал 3518 страниц данных (3494 из кэша + 24 с диска).
Объем данных: Одна страница в Postgres равна 8 КБ. Суммарно запрос прочитал около 27.5 МБ данных.
В чем проблема: Чтобы выдать всего 100 строк, читать 27 МБ — это очень много. На чтение и обработку этих страниц в памяти ушло ~35 мс.
Почему планировщик ошибся (Cost vs Actual)
Оценка стоимости (cost=1.57..58.94): Планировщик считает, что строки в индексе расположены идеально последовательно. Он предположил, что для выдачи 100 строк ему понадобится прочитать буквально несколько страниц.
Реальность (actual time=35.875...): Порядок записей в индексе _accrg12303_10 не совпадает с физическим порядком строк в таблице. Либо нужные 100 строк были «размазаны» по всей таблице, либо первые тысячи проверенных строк не подошли под условия видимости (MVCC).
Другие частые причины для таблиц 1С
Мусорные строки (Dead Rows): Индекс мог ссылаться на старые, удаленные или обновленные версии строк. Postgres тратил время на их чтение, но отсекал, так как они невидимы для вашей транзакции.
Сканирование индекса вместо Index Only Scan: Запрос делает SELECT *. Из-за этого Postgres берет из индекса только ссылку, а за самими данными (всеми 464 байтами ширины строки) каждый раз идет в саму таблицу (Heap).
(3)
Имея только словесное описание "фотографии" можно только гадать :)
Сделайте
И перепишите предикат, как
результат в студию.
И в этом ли причина?
Имея только словесное описание "фотографии" можно только гадать :)
Сделайте
vacuum _AccRg12303И перепишите предикат, как
SELECT * FROM _AccRg12303 WHERE _Period > '2025-01-01 00:00:00' LIMIT 100;результат в студию.
4.
starik-2005
3272
27.05.26 13:32
Сейчас в теме
При развертывании на постгресе через какие-то темные места статистика не обновляется и индексы перестают использоваться. Суть проблемы с записью в том, что поиск текущей записи в таблице для ее перезаписи сканит таблицу целиком.
Для исправления достаточно запустить реструктуризацию в конфигураторе ТиИ.
Для исправления достаточно запустить реструктуризацию в конфигураторе ТиИ.
5.
Volodya653
27.05.26 13:48
Сейчас в теме
(4)
Реструктуризацию через ТиИ делали результат не изменился скорость осталась та же
Реструктуризацию через ТиИ делали результат не изменился скорость осталась та же
6.
starik-2005
3272
27.05.26 14:45
Сейчас в теме
(5) Обычно это как раз помогало. Основной проблемой был скан вместо сика по таблице при записи объекта, хотя ссылка вообще в индексе. А т.к. при записи 1С обычно несколько раз читает данные, удаляет их и потом уже вставляет, то скан таблицы против поиска по индексу создает ну очень сильную деградацию в производительности.
Второй вариант - большая база с типовыми настройками в "postgres.conf", ибо по умолчанию там ну очень маленькие цифры под буфера и прочее.
Второй вариант - большая база с типовыми настройками в "postgres.conf", ибо по умолчанию там ну очень маленькие цифры под буфера и прочее.
(11)
Не, с Джимми беседовать не буду, лень :) :) :)
(11)
Ммм, я такое не утверждал, НО по сравнению с дисковыми операциями, "сгонять в память" - это считай бесплатно.
Ну и на старом серваке данная операция занимала 1 мс, кстати Volodya653 - приведите план с 1 мс.
Собственно ответ уже был дан:
(4)
Или
Если это не поможет, то надо ковыряться в настройках ОС, СУБД.
Джимми это скажи - он тебе предложит вариантов на вентилятор.
Не, с Джимми беседовать не буду, лень :) :) :)
(11)
И да, с чего ты решил, что сгонять в память - это бесплатная операция?
Ммм, я такое не утверждал, НО по сравнению с дисковыми операциями, "сгонять в память" - это считай бесплатно.
Ну и на старом серваке данная операция занимала 1 мс, кстати Volodya653 - приведите план с 1 мс.
Собственно ответ уже был дан:
(4)
При развертывании на постгресе через какие-то темные места статистика не обновляется и индексы перестают использоваться.
Или
vacuum _AccRg12303Если это не поможет, то надо ковыряться в настройках ОС, СУБД.
20.
Volodya653
28.05.26 10:03
Сейчас в теме
(19)
Для чистоты провожу одну и ту же реализацию с момента нажатия кнопки до проведения уходит 1.5-2 секунды
План со старого сервера PostgreSQL 10:
Limit (actual time=186.880..195.003 rows=100 loops=1)
Buffers: shared hit=1 read=3544
Index Scan using _accrg12303_1
Execution time: 195.256 ms
План с нового сервера PostgreSQL 16:
Limit (actual time=35.878..36.209 rows=100 loops=1)
Buffers: shared hit=3494 read=24
Index Scan using _accrg12303_10
Execution time: 36.314 ms
Здесь уже уходит на том же самом документе 37-40 секунд
Ну и на старом серваке данная операция занимала 1 мс, кстати Volodya653 - приведите план с 1 мс
Для чистоты провожу одну и ту же реализацию с момента нажатия кнопки до проведения уходит 1.5-2 секунды
План со старого сервера PostgreSQL 10:
Limit (actual time=186.880..195.003 rows=100 loops=1)
Buffers: shared hit=1 read=3544
Index Scan using _accrg12303_1
Execution time: 195.256 ms
План с нового сервера PostgreSQL 16:
Limit (actual time=35.878..36.209 rows=100 loops=1)
Buffers: shared hit=3494 read=24
Index Scan using _accrg12303_10
Execution time: 36.314 ms
Здесь уже уходит на том же самом документе 37-40 секунд
(20)
Первое.
ПГ 10 тратит 195 мс, ПГ 16 тратит 35 мс, те ПГ 16 в 6 раз быстрее выполняет, понятно, что из-за shared hit=3494. (как раз пример, что "сходить в память" на порядок быстрее "поднять с диска")
Второе.
ПГ 10 использует индекс _accrg12303_1, ПГ 16 использует другой индекс _accrg12303_10 - проверьте DDL определения индексов.
Если они тождественно равны , то тормоза не на этой табличке, сравнивайте планы других запросов (для начала Execution time).
Для чистоты провожу одну и ту же реализацию с момента нажатия кнопки до проведения уходит
Первое.
ПГ 10 тратит 195 мс, ПГ 16 тратит 35 мс, те ПГ 16 в 6 раз быстрее выполняет, понятно, что из-за shared hit=3494. (как раз пример, что "сходить в память" на порядок быстрее "поднять с диска")
Второе.
ПГ 10 использует индекс _accrg12303_1, ПГ 16 использует другой индекс _accrg12303_10 - проверьте DDL определения индексов.
Если они тождественно равны , то тормоза не на этой табличке, сравнивайте планы других запросов (для начала Execution time).
24.
Volodya653
28.05.26 11:02
Сейчас в теме
(21)
Проверил DDL индексов — они не тождественно равны:
Старый PG10 — кластерный индекс _accrg12303_1:
UNIQUE btree (_fld602, _period, _recordertref, _recorderrref, _lineno)
Новый PG16 — кластерный индекс _accrg12303_10:
UNIQUE btree (_fld602, _fld12309, _period, _recordertref, _recorderrref, _lineno)
При переносе базы через pg_dump/pg_restore кластеризация таблицы сохранилась на другой индекс. Выполнил:
sqlCLUSTER _AccRg12303 USING _accrg12303_1;
SELECT pg_prewarm('_accrg12303');
Визуально не дало ничего в 1с
Первое.
ПГ 10 тратит 195 мс, ПГ 16 тратит 35 мс, те ПГ 16 в 6 раз быстрее выполняет, понятно, что из-за shared hit=3494. (как раз пример, что "сходить в память" на порядок быстрее "поднять с диска")
Второе.
ПГ использует индекс _accrg12303_1, ПГ 16 использует другой индекс _accrg12303_10 - проверьте DDL определения индексов.
Если они тождественно равны , то тормоза не на этой табличке, сравнивайте планы других запросов (для начала Execution time).
ПГ 10 тратит 195 мс, ПГ 16 тратит 35 мс, те ПГ 16 в 6 раз быстрее выполняет, понятно, что из-за shared hit=3494. (как раз пример, что "сходить в память" на порядок быстрее "поднять с диска")
Второе.
ПГ использует индекс _accrg12303_1, ПГ 16 использует другой индекс _accrg12303_10 - проверьте DDL определения индексов.
Если они тождественно равны , то тормоза не на этой табличке, сравнивайте планы других запросов (для начала Execution time).
Проверил DDL индексов — они не тождественно равны:
Старый PG10 — кластерный индекс _accrg12303_1:
UNIQUE btree (_fld602, _period, _recordertref, _recorderrref, _lineno)
Новый PG16 — кластерный индекс _accrg12303_10:
UNIQUE btree (_fld602, _fld12309, _period, _recordertref, _recorderrref, _lineno)
При переносе базы через pg_dump/pg_restore кластеризация таблицы сохранилась на другой индекс. Выполнил:
sqlCLUSTER _AccRg12303 USING _accrg12303_1;
SELECT pg_prewarm('_accrg12303');
Визуально не дало ничего в 1с
(24)
1. Создайте индекс, что бы _period был лидирующим полем, для эксперимента можно напрямую руками UNIQUE btree (_period, _fld602, _fld12309, _recordertref, _recorderrref, _lineno).
2. Смотрите в ПГ 16 аномальные значения Execution time
Визуально не дало ничего в 1с
1. Создайте индекс, что бы _period был лидирующим полем, для эксперимента можно напрямую руками UNIQUE btree (_period, _fld602, _fld12309, _recordertref, _recorderrref, _lineno).
2. Смотрите в ПГ 16 аномальные значения Execution time
26.
Volodya653
28.05.26 11:21
Сейчас в теме
(25)
Проблема в том что база у меня не одна их под 400
и каждую сидеть ковырять довольно таки проблемно будет, зависания именно на обьемных базах даже если кеш прогрет, возможно здесь в каком то ином направление копнуть? Раз проблема не типичная, возможно я что то не так сделал при развертывание или с настройками постгерса
Создайте индекс, что бы _period был лидирующим полем, для эксперимента можно напрямую руками UNIQUE btree (_period, _fld602, _fld12309, _recordertref, _recorderrref, _lineno).
Проблема в том что база у меня не одна их под 400
и каждую сидеть ковырять довольно таки проблемно будет, зависания именно на обьемных базах даже если кеш прогрет, возможно здесь в каком то ином направление копнуть? Раз проблема не типичная, возможно я что то не так сделал при развертывание или с настройками постгерса
27.
Volodya653
28.05.26 11:30
Сейчас в теме
(25)
Нашли аномальные Execution time:
DELETE FROM _AccRg12330 — 2234ms
INSERT INTO _AccRg12303 — 3670ms
INSERT INTO _AccRg12330 — 2266ms
Все остальные запросы менее 1ms. Проблема именно в таблицах _AccRg12303 и _AccRg12330. Что делать дальше?
UPD:
Индекс создан результат не дало
Нашли аномальные Execution time:
DELETE FROM _AccRg12330 — 2234ms
INSERT INTO _AccRg12303 — 3670ms
INSERT INTO _AccRg12330 — 2266ms
Все остальные запросы менее 1ms. Проблема именно в таблицах _AccRg12303 и _AccRg12330. Что делать дальше?
UPD:
Индекс создан результат не дало
34.
starik-2005
3272
28.05.26 13:59
Сейчас в теме
(27)
DELETE FROM _AccRg12330 — 2234ms
INSERT INTO _AccRg12303 — 3670ms
INSERT INTO _AccRg12330 — 2266ms
Как вариант - пересчет итогов запустить.
INSERT INTO _AccRg12303 — 3670ms
INSERT INTO _AccRg12330 — 2266ms
22.
starik-2005
3272
28.05.26 10:45
Сейчас в теме
(20) Фактически этот план бесполезную информацию выдает, т.к. мало соотносится с тормозами. Старый сервак с неразогретым кешем все прочитал с диска, новый сервак все прочитал из памяти. Ниачом инфа.
(22)
Хм, на мой взгляд, наоборот, ... ПГ 10 с холодным кэшем откликается быстрее, чем ПГ 16 с прогретым, ... ТС пока ищет где светлее, а ни где тормоза, те тормозит на чём-то другом.
Фактически этот план бесполезную информацию выдает
Хм, на мой взгляд, наоборот, ... ПГ 10 с холодным кэшем откликается быстрее, чем ПГ 16 с прогретым, ... ТС пока ищет где светлее, а ни где тормоза, те тормозит на чём-то другом.
32.
starik-2005
3272
28.05.26 13:55
Сейчас в теме
(23)
ПГ 10 с холодным кэшем откликается быстрее, чем ПГ 16 с прогретым
С этим конкретным запросом - нет. Execution time: 195.256 ms vs Execution time: 36.314 ms.
(32)
Не-не-не, имел в виду, ПГ 10 с холодным кэшем выполняет ВСЕ операции 1С быстрее чем ПГ 16 с прогретым.
Что ТС пишет для ПГ 10
А это для ПГ 16
А с этим конкретным запросом - кто же спорит, на "прогретом" быстрее :) :) :)
С этим конкретным запросом - нет. Execution time: 195.256 ms vs Execution time: 36.314 ms.
Не-не-не, имел в виду, ПГ 10 с холодным кэшем выполняет ВСЕ операции 1С быстрее чем ПГ 16 с прогретым.
Что ТС пишет для ПГ 10
Для чистоты провожу одну и ту же реализацию с момента нажатия кнопки до проведения уходит 1.5-2 секунды
А это для ПГ 16
Здесь уже уходит на том же самом документе 37-40 секунд
А с этим конкретным запросом - кто же спорит, на "прогретом" быстрее :) :) :)
36.
starik-2005
3272
28.05.26 14:20
Сейчас в теме
(35)
Не-не-не, имел в виду, ...
Имел и ввел. Получилось такое себе )))
(36)
Повторю "слова" ТС.
Мой коммент относился к этим фразам.
:)
Имел и ввел. Получилось такое себе )))
Повторю "слова" ТС.
Для чистоты провожу одну и ту же реализацию с момента нажатия кнопки до проведения уходит 1.5-2 секунды
Здесь уже уходит на том же самом документе 37-40 секунд
Мой коммент относился к этим фразам.
:)
(38)
А что не так??
Для ПГ 10
ПГ 16
И ТС приводит планы, где ПГ 10 с холодным кэшем делает в 10 раз ПГ 16.
Или как вы "прочли" слова ТСа??
Ну-ну....
А что не так??
Для ПГ 10
Для чистоты провожу одну и ту же реализацию с момента нажатия кнопки до проведения уходит 1.5-2 секунды
ПГ 16
Здесь уже уходит на том же самом документе 37-40 секунд
И ТС приводит планы, где ПГ 10 с холодным кэшем делает в 10 раз ПГ 16.
Или как вы "прочли" слова ТСа??
40.
starik-2005
3272
28.05.26 15:50
Сейчас в теме
(39)
И ТС приводит планы, где ПГ 10 с холодным кэшем делает в 10 раз ПГ 16.
И ТС приводит планы совсем другие:
С этим конкретным запросом - нет. Execution time: 195.256 ms vs Execution time: 36.314 ms.
(7)
Нуу, ПГ физически прочитал 24 блока/страницы = 200К данных, остальные были уже в ОЗУ - это копейки.
(7)
По другому ни как, при условии, что _Period является левым/лидирующим полем индекса, иначе это не индекс.
(7)
Пожалуй только в MSSQL при кластерном индексе порядок индекса совпадает с данными.
Даже если 100 строк размазаны, то всё равно будет максимум считаны 100 страниц.
Неее, тут другое :)
Суммарно запрос прочитал около 27.5 МБ данных.
Нуу, ПГ физически прочитал 24 блока/страницы = 200К данных, остальные были уже в ОЗУ - это копейки.
(7)
Планировщик считает, что строки в индексе расположены идеально последовательно.
По другому ни как, при условии, что _Period является левым/лидирующим полем индекса, иначе это не индекс.
(7)
Реальность (actual time=35.875...): Порядок записей в индексе _accrg12303_10 не совпадает с физическим порядком строк в таблице. Либо нужные 100 строк были «размазаны» по всей таблице, либо первые тысячи проверенных строк не подошли под условия видимости (MVCC).
Пожалуй только в MSSQL при кластерном индексе порядок индекса совпадает с данными.
Даже если 100 строк размазаны, то всё равно будет максимум считаны 100 страниц.
Неее, тут другое :)
11.
starik-2005
3272
27.05.26 15:21
Сейчас в теме
(10)
И да, с чего ты решил, что сгонять в память - это бесплатная операция? 27 мб прочитать - это как раз для приличной программы в 10-30 мс выйдет, ибо гиг в сек - это вот вообще хорошо. Память 30 Гигабайт в сек отдает только при последовательном чтении, если у чела там два канала хотя бы. А если у него что-то старое китайское с одной планкой памяти - тут вообще все такое себе.
Неее, тут другое :)
Джимми это скажи - он тебе предложит вариантов на вентилятор.
И да, с чего ты решил, что сгонять в память - это бесплатная операция? 27 мб прочитать - это как раз для приличной программы в 10-30 мс выйдет, ибо гиг в сек - это вот вообще хорошо. Память 30 Гигабайт в сек отдает только при последовательном чтении, если у чела там два канала хотя бы. А если у него что-то старое китайское с одной планкой памяти - тут вообще все такое себе.
14.
Volodya653
27.05.26 20:24
Сейчас в теме
Базы переносил через pg_dump / pg_restore со старого сервера PostgreSQL 10 на новый PostgreSQL 16. После переноса делали VACUUM ANALYZE и реструктуризацию через ТиИ конфигуратора не помогло.
Возможно ли что при переносе с PG10 на PG16 через дамп есть какие-то особенности которые влияют на производительность? Например статистика, bloat, корреляция индексов?
VACUUM и CLUSTER сделал результат практически не изменился. 33ms вместо 36ms. Данные всё равно будто читают 3499 страниц для выдачи 100 строк. Проблема видимо не в физическом порядке. Что ещё можно попробовать?
Ну версию постгреса мы исключаем?
Так же версия платформы моей?
Возможно ли что при переносе с PG10 на PG16 через дамп есть какие-то особенности которые влияют на производительность? Например статистика, bloat, корреляция индексов?
VACUUM и CLUSTER сделал результат практически не изменился. 33ms вместо 36ms. Данные всё равно будто читают 3499 страниц для выдачи 100 строк. Проблема видимо не в физическом порядке. Что ещё можно попробовать?
Ну версию постгреса мы исключаем?
Так же версия платформы моей?
15.
Volodya653
27.05.26 20:33
Сейчас в теме
приложил параметры последние которые применил и не помогли данные параметры были на 10м постгресе старого сервера, это последнее до чего я смог додуматься и что то вычитать
Прикрепленные файлы:
pg16_full_settings.txt
16.
Volodya653
27.05.26 21:05
Сейчас в теме
8.3.27.1688 решил поставить новую платформу тоже ситуацию не спасла последнее что на нее грешил и несовместимость какую то
18.
Volodya653
28.05.26 07:43
Сейчас в теме
(17)
Ситуацию это не исправит, здесь же проблема иная а все анализы через ИИ я проводил это тоже предлагалось и безуспешно, тут нужен именно эксперт в области постгреса
Все что доступное в ии и на форуме было испытано
Ситуацию это не исправит, здесь же проблема иная а все анализы через ИИ я проводил это тоже предлагалось и безуспешно, тут нужен именно эксперт в области постгреса
Все что доступное в ии и на форуме было испытано
29.
Volodya653
28.05.26 11:45
Сейчас в теме
(28)
Filesystem volume name: <none>
Filesystem UUID: 2de378b2-8993-4181-8431-0aede017755d
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Filesystem state: clean
Filesystem OS type: Linux
Block size: 4096
Filesystem created: Tue Apr 9 16:23:52 2019
Старый
size|Filesystem"
Filesystem volume name: <none>
Filesystem UUID: 2de378b2-8993-4181-8431-0aede017755d
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Filesystem state: clean
Filesystem OS type: Linux
Block size: 4096
Filesystem created: Tue Apr 9 16:23:52 2019
Новый
Изначально это был клон системы, после все поднял с нуля UUID сохранился
Если тут уже к железу сразу глупый вопрос Hyper-V внутри которого линукс тоже не может же быть проблемой? старый у меня на esxi и внутри линукс, уже варианты не знаю какие использовать, скорей всего буду писать скрипт на перенос данных со 16пг обратно в 10й пг и сносить всю систему под ноль
Сравни файловые системы на старых дисках и на новых, в частности размер кластера.
Filesystem volume name: <none>
Filesystem UUID: 2de378b2-8993-4181-8431-0aede017755d
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Filesystem state: clean
Filesystem OS type: Linux
Block size: 4096
Filesystem created: Tue Apr 9 16:23:52 2019
Старый
size|Filesystem"
Filesystem volume name: <none>
Filesystem UUID: 2de378b2-8993-4181-8431-0aede017755d
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Filesystem state: clean
Filesystem OS type: Linux
Block size: 4096
Filesystem created: Tue Apr 9 16:23:52 2019
Новый
Изначально это был клон системы, после все поднял с нуля UUID сохранился
Если тут уже к железу сразу глупый вопрос Hyper-V внутри которого линукс тоже не может же быть проблемой? старый у меня на esxi и внутри линукс, уже варианты не знаю какие использовать, скорей всего буду писать скрипт на перенос данных со 16пг обратно в 10й пг и сносить всю систему под ноль
33.
starik-2005
3272
28.05.26 13:58
Сейчас в теме
(29)
Если тут уже к железу сразу глупый вопрос Hyper-V внутри которого линукс тоже не может же быть проблемой? старый у меня на esxi и внутри линукс
Легко, особенно если нет аппаратной виртуализации (вырублена в биосе, например). Но это, обычно, касается 1С сильнее, чем постгреса. У Гилева писали, что иногда разница на порядок.
41.
Volodya653
28.05.26 15:55
Сейчас в теме
(33)
виртуализация включена, все же верну данные обратно скриптом удалю со старого сервера базу и залью так же копирование через pipe на 16 пг уже достаточно новой инфы бухи в базы забили
после этого попробую удалить полностью виртуальную машину и уже поднять с нуля на 24 убунте
ковыряться с таблицами в моем случае это многовато делов будет а время идет
виртуализация включена, все же верну данные обратно скриптом удалю со старого сервера базу и залью так же копирование через pipe на 16 пг уже достаточно новой инфы бухи в базы забили
после этого попробую удалить полностью виртуальную машину и уже поднять с нуля на 24 убунте
ковыряться с таблицами в моем случае это многовато делов будет а время идет
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот