Maxim BogukkamakamaMaxim Boguk,

При стандартной работе AV получается так, что он отследит изменения в таблицах autovacuum_vacuum_threshold (например) = 10000 (это произойдет через секунд 30 после начала работы с партицией), и потом начнет ее оптимизировать. На партицию уходит по 30 минут времени в среднем. А в это время ее все равно продолжают пользовать другие вычислители и довольно активно (расчет не кончен). Получается рост нагрузки, который заметно тормозит сам процесс расчетов. Вот я и пытаюсь подобрать наиболее оптимальный режим. Думаю над autovacuum_vacuum_scale_factor, поставить его в 0.5, что бы максимально снизить влияние на работу вычислителей. Или воспользоваться идеей п.3 в асинхронном режиме для каждой партиции.

Вообще чем меньше scale factor тем меньше будет влияние 1 отработки autovacuum. Это вообще распостраненное заблуждение что подняв scale factor вы сделаете autovacuum более легким... да он будет запускаться реже но будет куда тяжелее для базы при отработке.

Про рост нагрузки по подробнее, рост какой нагрузки CPU? IO utilization? Графики CPU и io utlization (и задно writes/s reads/s) есть?
Может у вас просто ресурсов на сервере под ваши задачи не хватает? C вашими задачами я бы смотрел в сторону расширения памяти чтобы все или большая часть всего нужного влезала в память (и без виртуалок всяких они мешают локализовывать узкие места).
Т.е. я пока вижу утверждения не подтвержденные ни цифрами ни графиками ни даже хотя бы обьяснением что именно тормозит
(" тормозит сам процесс расчетов" - это не описание проблемы ни разу).
1) autovacuum_vacuum_scale_factor = 0.1 Это понятно, что если при равномерной загрузке сервера чем чаще запускать, тем быстрее будет работать. У меня же штука в том, что загрузка не равномерна
2) С подтверждением сложнее, сейчас тащим на физическую машину с выделенными под clog и xlog дисками на 15000 rpm и на ней проводим испытания. Хотя первые результаты есть. Загрузка IO минимальна, основные нагрузки ложатся на CPU (держит только 32 потока). Так что будем оптимизировать запросы

tadmin,

Не волнуйтесь, за один:) Не все так плохо. Чисто технологически текст хранится не целиком, а по предложениям, но все маркеры в рамках предложения пишутся за один UPDATE. Типа такого:
update split_article set word = ' Именно из-за этих угроз в этом году в <#188,301#>Багдаде</#188,301#> были отменены различные мероприятия, связанные с празднованием <#0,72231932#>Рождества</#0,72231932#>.' where id_article = 242182 and id = 9432163;

tadmin,

И еще - маркировки в тексте используются СУГУБО для отображения в клиентском софте, ни в каких расчетах они участия не принимают. Вообще, моя точка зрения такова, что все плюшки, которые связаны с подготовкой информации к отображению, должны быть отработаны самой системой отображения или клиентом(ну, кроме хранения метаописаний). Но в этом конкретном случае получается, что клиентов 2 - один тот, который считает, другой тот, который показывает. И получается, что второй клиент пересчитывал бы это у себя КАЖДЫЙ раз, когда обращался бы к тексту, в то время как первый клиент может сделать это ОДИН раз за проход.

tadmin,

Еще раз подчеркиваю, что разметка текста (генерация строки запроса см. выше) выполняется в вычислителе, PG пишет только результат (собственно, выполняет указанный запрос). То есть на самом деле Вы говорите, что самая дорогая операция UPDATE. Это логично, поэтому сейчас я думаю, как это подправить. Возможно, сделаю через балансировку нагрузки, возможно, через запись в UNLOGGED и дальнейшую синхронизацию. Если будут интересные результаты, то напишу

tadmin,

Для вакуума да, а вот с IO сложнее. Сейчас IO wait time меньше процента, основная нагрузка на CPU 80-85%.

В перерыве между другими делами. В принципе, жестко настроенный автовакуум не сильно подтормаживает (3-5% от CPU, хотя субъективно заметно). Есть некоторая проблема с производительностью (40-48 исполнителей, одновременно пишущих результаты сильно грузят CPU, очереди на харды нет). Была проблема с блокировками таблиц результатов при записи (исполнители конкурировали друг с другом жестко) , но ее успешно решили балансировкой нагрузки по партициям (если интересно кому, то расскажу как). Собственно, все получилось, единственное, что 4 ядра маловато, но это уже общие проблемы. Всем спасибо за ответы