Уважаемые коллеги, в процессе настройки postgresql.conf (вернее, наведения глянца :-) возник вопрос, связанный с автовакуумом. Есть два параметра:
#autovacuum_vacuum_threshold
#autovacuum_analyze_threshold
Значения этих параметров по умолчанию - 50. Как я понял, это сделано, чтобы гарантированно убирался мусор в небольших таблицах. Многие спецы рекомендуют увеличить их до 1800, а иногда и более.
Хорошо, увеличиваем. Прирост производительности по тесту Гилева - в пределах погрешности. Увеличим еще, на порядок - до 18000. Все равно в сущности никакого улучшения. Следовательно, оставить как есть? Или я что-то упускаю?
Заранее большое спасибо!

http://goldhous.com/ru/OpenSource/2011/06/28/postgresql-dlya-1c.html
"autovacuum_vacuum_threshold — Порог на число удалённых и изменённых записей в любой таблице по превышению которого происходит сборка мусора (VACUUM)"

Это понятно. Т.е. если есть небольшая таблица, где этих самых записей всего пару сотен, то при 18000 автовакуум до нее доберется только когда в ней наберется 18000 измененных/удаленных записей, так? Т.е. когда она раздуется в 100 с лишним раз. А если таких таблиц много, то и база раздуется до огромной величины. Что не есть гут. Значит, надо ставить минимальные значения, правильно?

Пост Джоша Беркуса вот здесь:
https://groups.google.com/forum/?fromgroups=#!topic/pgsql.performance/l1FQt1NvqFg

А если больших таблиц тоже немало(размером по нескольку гигабайт) и записи в них тоже регулярно изменяются/удаляются?
Можно, в принципе, отключить автовакуум(хотя и не рекомендуют) и запускать раз в сутки, в период наименьшей пользовательской активности, vacuumdb в cron-е.
Универсального рецепта нет, скорее всего. Может поставить какое-то усредненное значение, чтобы и маленькие таблицы не сильно разрастались и большие таблицы не слишком часто обрабатывались автовакуумом.

В том-то вся и проблема :-) Отключение автовакуума, конечно, тоже вариант, но обычно это использую только при первоначальной загрузке БД или больших обновлениях (много баз, типовые конфигурации, базы сами по себе сравнительно небольшие). У меня, в сущности, два postgresql.conf - один для текущей работы, другой для загрузок.
Спасибо, сам прихожу постепенно к тому же мнению.
Сделал так. Взял несколько баз и запросом
SELECT relname, relpages*8192, reltuples FROM pg_class WHERE NOT relname LIKE 'pg_%' ORDER BY relpages DESC;
увидел, что самые большие таблицы содержат порядка 100 тыс. reltuples (строк). А таблиц с количеством строк более 10 тыс. всего 15-20 из 6-8 и более тыс. Следовательно, основная масса базы состоит из мелких и очень мелких таблиц. Потому минимальные значения autovacuum_vacuum_threshold (пусть не 50, конечно, но 100-200-500) вполне оправданы.
Как считаете, разумно?

Да, вполне. Можно при разных значениях понаблюдать как ведут себя разные таблицы(кол-во строк, размер таблицы) и выбрать более подходящее. Хотя при небольших базах, 5-10 ГБ, эта проблема существенной роли не играет, мне так кажется. При не слишком большой интенсивности операций изменения/удаления, разумеется.

Отлично, спасибо большое!
Пока сделал так:

autovacuum_max_workers = 5
autovacuum_naptime = 30s
autovacuum_vacuum_threshold = 100
autovacuum_vacuum_scale_factor = 0.1
autovacuum_analyze_threshold = 50
autovacuum_analyze_scale_factor = 0.05

Остальное, относящееся к автовакууму, по умолчанию.
Завтра народ день поработает, и тогда можно будет по косвенным признакам (прежде всего, использование cpu, I/O, RAM и  т.п.) посмотреть, насколько такие параметры лучше.
Утром крон запустит iostat, iotop, sar, а вечером поизучаю логи.
Сейчас при указанных выше параметрах субъективно (подчеркну - только субъективно) базы заработали быстрее и как-то более гладко. Мелкие подтормаживания при построении ОСВ или других такого типа отчетов ушли полностью, ощущение работы с файловой базой. Похоже, время отклика (или как правильно?) стало меньше. Утверждать ничего не буду, но ощущения именно такие. Если это так, то удалось именно то, что и хотелось.
Удачи, и еще раз большое спасибо!

(6) Еще вдогонку: поскольку
http://doxygen.postgresql.org/vacuumlazy_8c.html#a0441510cbcfe4becd1583106624bb626
получается, что ставить maintennance_work_mem более 1ГБ попросту бессмысленно, все равно максимум - 1 ГБ, т.к. параметр MaxAllocSize жестко задан в  memutils_8h на уровне 1ГБ. Странно, что в пользовательской документации нет никаких упоминаний об этом.
Видимо, в реальности нужно гораздо меньше, т.к. maintennance_work_mem должен быть лишь несколько больше самого большого индекса в БД.
ОК, вот запрос:
SELECT nspname || '.' || relname AS "relation",
   pg_size_pretty(pg_relation_size(C.oid)) AS "size"
 FROM pg_class C
 LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
 WHERE nspname NOT IN ('pg_catalog', 'information_schema')
 ORDER BY pg_relation_size(C.oid) DESC
 LIMIT 20;
Взято отсюда: http://www.quantprinciple.com/invest/index.php/docs/tipsandtricks/postgres_commands/tablesize/

На одной из баз максимум - 350 МБ, остальные существенно меньше - 15-18 МБ.
Следовательно, более правильно поставить maintennance_work_mem, скажем, 500 МБ, но увеличить количество autovacuum_max_workers до 5 или даже 10?

(8)Пробовать все надо.
Тут товарищ MaxAllocSize менял и смотрел на время выполнения своих операций
http://postgresql.1045698.n5.nabble.com/using-a-lot-of-maintenance-work-mem-td3384577.html
По ходу, это "пережиток прошлого" http://postgresql.1045698.n5.nabble.com/GENERAL-maintenance-work-mem-upper-limit-1gb-td1844099.html

ОК, спасибо большое за ссылки, натолкнули на отличную идею :-) Согласен, видимо, это ограничение сделано для 32-битных систем, где 4ГБ ОЗУ - потолок. У х64, особенно серверных систем где и 196 ГБ не предел, такое ограничение глупо и бессмысленно. Пока что сижу на 9.0.3, обновляться буду сразу на 9.2 или даже 9.3, там много чего полезного добавили. Можно будет сделать тестовую сборку с измененным этим и еще кучкой параметров.
Впрочем, итог всех игр с настройками: средний балл теста Гилева увеличился с 21,4 до 35,9, это в рабочее время, когда все пользователи на месте! Вечером доходит до 41, причем fsync=on и вообще все рекомендации по безопасности соблюдены.
Очень сильный эффект (не ожидал, честно) дали:
default_statistics_target (300 вместо 100) и перечисленные в (7), + maintennance_work_mem=1GB.
Полагаю, дала эффект именно совокупность параметров, т.к. каждый по отдельности влиял не существенно.
Думаю, можно еще 2-4 балла выжать, но уже нет возможности играться.
Спасибо большущее Вам еще раз, очень помогли.

Пожалуйста.
На sql.ru сегодня наткнулся на тему http://www.sql.ru/forum/actualthread.aspx?tid=965853,
а в ней на эту ссылку http://www.pgexperts.com/documents.html
Посмотрите, может что и окажется полезным.

Спасибо, это все уже читано-перечитано :-) Сейчас вот надвигается проект на 200 пользователей, УПП, похоже, придется брать 9.3, накатывать патчи 1С и вносить некоторые свои правки. Похоже, будет весело :-)
Удачи!

(12) С таким количеством пользаков надо уже fsync=off, а на деньги, сэкономленные на лицензиях MS-SQL, купить какой-нить контроллер с батарейкой...

(13) и  ssd

(13) Да куда же без этого? Даже на 20 юзеров и то ставим LSI-based RAID (типа Intel RS2BL080), с BBU, винты WD 10krpm, 4 шт. RAID 10 - база, 2 шт. RAID 1 - система, 2 шт. RAID 1 - pg_xlog. И fsync = on в любом случае - сохранность информации дороже. А если 200 - так тут вообще не дай бог чего - всех же потом собак повесят, там за час столько успевают набивать, что за фразу "есть вчерашний бэкап" могут реально как с тем бегемотом на картинке http://habrahabr.ru/post/132768/
Аппаратная часть просто будет весьма серьезная, минимум 16 SAS 15k под БД и RAM 192 ГБ. Эта машинка только под СУБД, 1с на другой, попроще. Ладно, тьфу*3, пока только планируем бюджет и подбираем железо.
//(мечтательно: хорошо бы 16 ядер!)
А насчет ssd - страшновато их пока на боевые проекты ставить. SAS 15k - наше все :-)

PS Вот если бы кто поделился опытом по кластерам 1С на Linux+PostgreSQL для тяжелых проектов (скажем, 300 и более лицензий) - вот бы интересно было.

(15) fsync реально тормозит, и в случае выхода из строя оборудования - ничем этот fsync не поможет.
Если сервак на UPS, плюс контроллер с батарейкой - имхо этого вполне достаточно, что бы отключить fsync, да и сами разработчики пишут: "...using fsync results in a performance penalty", "If you trust your operating system, your hardware, and your utility company (or your battery backup), you can consider disabling fsync."

(16) Это понятно, с fsync=off прирост производительности ощутимый, но. У сервака должно быть минимум 2 БП, один резервный (в большинстве случаев этого нет!).
Да и вот еще соображение. У нас был случай, когда в серверной меняли сплит и один из ишаков-работяг ухитрился выбить провод из работающего сервера 1С: просто "удачно" сверзился с лестницы. Включил сервак обратно, проверил, все было нормально, кроме некоторого количества записей типа autovacuum: found orphan temp table "pg_temp_3"."tt21" in database "test1"  в логах. Руками убрал эти ненужные таблицы и ВСЕ. Даунтайм - менее 5 минут. А вот если бы fsync был выключен - думаю, объяснять далее не надо.
Фактор уборщицы, знаете ли :-)
Поэтому пусть даже он съедает 30% производительности, не так уж велика цена за спокойствие. ИМХО, конечно.

И вдогонку: был еще случай, когда один "забытый" сервачок - ну, работал себе, чего трогать? - вдруг стал притормаживать. Не сразу и поняли, какой именно. Решили, массив развалился (хотя hot spare были) - дык нет, живой, и не пищит. Оказалось, насмерть сдохла батарея BBU, контроллер переключился в режим write-through (было write-back with bbu). Кто бы и знал! Так что батарейкам тоже особого доверия нет.

Ну не знаю, лучше принять меры, что бы посторонний персонал в серверной не появлялся, да мониторинг за оборудованием организовать что бы вовремя батарейки и умирающие винты менялись. Системный администратор за это и получает деньги, а не за то, что пасивно наблюдает как его оборудование ногами таджики пинают. А fsync - помимо существенной потери производительности - это еще и постоянная дрочь винчестера, имхо - это лишнее...

Естественно, в идеале все так и должно быть. Сейчас, конечно, набив шишек, многие косяки устранены. И мониторинг, и уведомления админу, и еще много чего. Насчет посторонних в серверной - мне вот только еще самому сплиты менять не хватает :-) Бывает, ясное дело. Сплит именно там, где он менее всего доступен, стойку не передвинешь - в ней железа набито и витой пары - хвост в две руки толщиной. Учли и этот момент, все кабло убрали в гофрошланги, и сзади спрятали в пластиковые закругленные кожухи.
Второстепенные сервера сейчас активно переводим на виртуалки, регламенты ТО утверждены, все как надо.
Просто всего не предусмотришь. А мне вполне достаточно слов Грегори Смита: если вам не нужны ваши данные, отключайте fsync.
Насчет дерганья винта - ничего, пусть подергается. Не сдохнет. Его работа такая. На pg_xlog он (они, вернее, т.к. массив) работает только на запись. И дергается он не так уж и часто, спасибо контроллеру.

(20) Кстати, а как бэкапить базы планируете? Пг-дампа, как я понимаю, тут уже недостаточно будет, раньше давно еще были какие-то полудохлые проекты для репликации данных, а чем можно сейчас делать архивы у постгри?

(16)(17) fsync=on, наверное, можно и оставить. Погонял тест при включенном и выключенном fsync, результат одинаковый, 42-43 балла. Вот если включить synchronous_commit, то результат теста уменьшается до 8-и баллов, запись на диск происходит все время с небольшой скоростью в 1-1.5 Мбайт/с.
При fsync=on и synchronous_commit=off запись на диск происходит со скоростью 4-5 МБайт/с и периодически порциями 45-60 МБайт/с, а при fsync=off только порциями со скоростью 110-130 МБайт/с.

(21) Хороший вопрос. Если не будет возможности для экспериментов, то pg_dump. Возможно, каждый час. А хотелось бы довести до ума вот это http://www.postgresql.org/docs/9.0/static/continuous-archiving.html
Именно по причине трудностей PITR и нужно уменьшить вероятность всяких неприятностей.

(22) Тут согласен. Отключение этого параметра вроде бы не должно привести ни к каким катастрофическим последствиям при, скажем, внезапном выключении питания. Другое дело, что записи в wal будут идти с задержкой, равной wal_writer_delay, умноженной на 3. При дефолтных настройках это получается 600 мсек. Т.е. в худшем случае транзакции за последние 0,6 сек не попадут в wal, т.е. их как бы не было. Но БД все равно останется структурно неповрежденной. Разумный компромисс.
НО. Если используется аппаратный RAID-контроллер с приличной дисковой системой, то влияние этого параметра практически исчезающее. У меня, например, с synchronous_commit=on получилось 38,17, а с off - 39,30. В пределах погрешности, по сути. Поэтому смею предположить, что если отключение этого параметра дает столь серьезный эффект, возможно, следует повышать производительность I/O.  ИМХО, конечно же.
У меня получается, что слабое место - процессор, поэтому 8 или 16 ядер вместо 4 дали бы гораздо более высокую оценку по тесту Гилева. Но тут еще приходится учитывать, что каждые три минуты на 60 базах запускаются регламенты, автовакуум по кольцу, так что сколько-то баллов отъедается уже этими факторами.

(21) Вдогонку: вот еще посмотрите http://www.mkyong.com/database/postgresql-point-in-time-recovery-incremental-backup/

(23)>>Поэтому смею предположить, что если отключение этого параметра дает столь серьезный эффект, возможно, следует повышать производительность I/O.  ИМХО, конечно же.

Нет, все правильно. Это тестировалось на рабочей машине с обычным sata диском и чипсете H67, поэтому ничего удивительного. На контроллере с 512 MB cache будет совсем другой результат.
Сравнивая разные процессоры(на этом же тесте), получается, что и тактовая частота и кэш имеют значение. Чем больше и то и другое, тем лучше. "Идеальный" вариант (из тех, что есть на рынке) - Xeon E5-2680/87/90, правда денег они стоят... Многие сервера за такую сумму покупают. Про E7-4870 не говорю даже. Зато 60 баз будут чувствовать себя спокойно и уютно.

(25) Да, именно такие ксеоны и нужны. 8 ядер, да парочка - то, что надо. Даже 2665 полностью устроит, несмотря на 2.4ГГц тактовой. Мы планируем именно на них и собирать систему под 200 лицензий (ксеоны вообще сильно лучше подходят для больших вычислений, чем i5/i7 даже с большей ТЧ). Заказчик понимающий, так что с этим проблем не возникает.
Материнка, кстати, http://www.nix.ru/autocatalog/motherboards_supermicro/SuperMicro_X9DR3F_Dual_LGA2011_C606_3xPCIE_2xGbLAN_SATA_SAS_RAID_EATX_16DDRIII_134635.html вот эта.
E7 вживую пока не видел, ценник, думаю, будет совсем заоблачный. Лучше уж 2 близнеца на 2х2680 в кластер.
Кстати, интересно, может, у кого-то есть опыт использования "бытовухи" - АМД FX-8120. 8 ядер, теоретически до 50 пользователей с 32 ГБ РАМ должно потянуть.

http://www.opennet.ru/opennews/art.shtml?num=34794
9.2 вышел.
Выглядит многообещающе, особенно про масштабируемость и репликации. Как скоро 1С отреагирует...

Ага, видел. Думаю, еще долго никак не будут реагировать. Вариант есть - пристально посмотреть патчи для 9.1.2 и попытаться перетянуть их на 9.2. Но в продакшн такое ставить страшновато.

А что, может, попробуем все вместе собрать 9.2.1-1С?
Модули online_analyze и plantuner разработал Teodor Sigaev, и у него на sigaev.ru в git выложены последние версии для 9.2, их элементарно встроить в ванильный код.
Патчи 1С вроде бы вполне накладываются в ручном режиме.
Сегодня-завтра попробую все это наложить и скомпилировать.
Не знаю только, какие условия распространения их у 1С-ников, можно ли их публиковать. Во всяком случае, последние патчи в свободном доступе мне не попадались, только на ИТС.

v8: Postgresql 8.4.13 Patch 1C, автору темы на sql.ru, по ходу, так никто пока и не ответил.
Даже если   все наложится  и соберется, кто его знает, как вести себя будет. Так, поиграться... Не в промэксплуатацию ставить же. Непонятно, насколько патчи будут соответствовать.
После 8.3.8 они не стали публиковать открыто, только на users.v8.1c.ru

Можно еще связаться с Олегом Бартуновым. Может он подскажет сроки выхода тестового PostgreSQL?

(30) 9.1.2 хоть как пришлось пересобирать, в т.ч. и по причинам, которые описывал выше в этой теме.
Проблема с Centos 6.3, ИМХО, не слишком интересна народу, ибо, нет объективных причин использовать 8-ю версию Postgres. Что касается 9.2, цель пока что - действительно поиграться: сравнить производительность 9.0 и 9.2. Если разница существенная, пилить дальше.

(31) Знаете, как-то совестно такого Человека дергать из-за всякой ерунды. Тем более, что, опять-таки, стабильной 9.2 станет в лучшем случае не ранее выхода 9.3 или 9.4.

Ладно, пока в отпуске, поиграюсь.
Спасибо!

(21) К вопросу о бэкапе баз PostgreSQL: есть такое решение, написанное ребятами из 2nd Quadrant (думаю, в представлении не нуждаются), называется Barman. http://www.pgbarman.org/
Это набор скриптов на питоне. Рекомендую посмотреть. Сейчас разворачиваем в тестовом режиме, думаю, там нужно будет кое-что допилить, но, возможно, все заработает из коробки. Если кому интересно, давайте пробовать и делиться опытом :-)

Пишут, не все так радужно на первых порах http://www.sql.ru/forum/actualthread.aspx?tid=973589
Придется, видимо, подождать.

ОК, спасибо большое!

Ну вот и дождались :-) Тестовая PostgreSQL 9.2.1-1.1C выложена на ИТС. Завтра на запасном серваке попробую.

Очень хорошо. Не затягивают. Значит, интерес в применении PostgreSQL  у 1С имеется.

Так удалось собрать 9.2.1-1.1С на Centos 6.3?
Хорошо бы где то выложить мысли и особенности пересборки. Если такие были.

(38)Да. Собирается так же, как и предыдущие версии, ничего особенного нет.

Так а заявленное увеличение скорости 9.2 так же отсутствует или присутствует?

На рабочей машине( описание в (25) ) не ощущается. Надо будет попробовать на нормальном сервере с более-менее приличной дисковой подсистемой.

А случаем ни кто не пробовал в деле online_analyze и plantuner? А то вроде эти патчи существуют с 9.1 версии. Только в стандартном конфиге они явно не включены.

(30) Подтверждаю - тишина как в танке)
http://www.sql.ru/forum/actualthread.aspx?tid=970792
(32) На Ubuntu 10.04 та же фигня - проблема с самим Postgreslq 8.4.13.
Вот еще одна ссылка.
http://www.linux.org.ru/forum/admin/8186256
Там и объективные причины использовать именно 8 версию)

Postgresql 8.4.13 с патчами от 1С у меня в итоге собрался - все проверки прошел, но в продакш пока не ставил. Поставил весь postgresql в exclude в yum.conf, чтобы не мешал обновлению.

(40) Вот мне тоже интересно по сравнению с 8.4. Пока складывается мнение что разница в скорости в пределах погрешности, потому и смысла переходить на 9.х пока не вижу.

У меня с начала года крутились ветки 9.1. Собирал из исходников 1С с наложенными патчами под Centos 6.x. Инструкция по сборке в общих чертах есть у "Админа маньяка". Сам postgres всегда работал стабильно.

Все-таки хотелось бы услышать(увидеть) реальное сравнение Postgresql различный версий (8.4, 9.0, 9.1, 9.2) в плане производительности в 1С.

(26)На такой комплектации, как в вашем посте, именно на этой плате, с двумя E5-2680 и 128 GB  памяти, тест Гилева показывает 53.5-54 балла. Это на платформе 8.3 и PostgreSQL 9.1.2. С 9.2.1 получается на 1-2 балла меньше. Весьма годная машинка.
Занятно работает технология TurboBoost. При отсутствии нагрузки наготове(3.4-3.5 GHz) держится 1-2 ядра, остальные ядра "отдыхают". По мере повышения нагрузки, частота увеличивается на остальных ядрах, но не до максимальной. Чем больше ядер задействовано, тем ниже частота разгона. Греется все это хозяйство не слабо.

Хрень какая-то.

В логах обнаружил ошибку:

ERROR: syntax error at or near "application" at character 24
STATEMENT: lock table pg_class in application share mode

Раньше такого не замечал.

(46) А как вы собираете Postgress. У меня похоже что-то плохо собралось 9.2.1-1.1С на Centos 6.3

(48) Как обычно, вроде. Патчи, потом
./configure --with-perl --with-tcl --disable-integer-datetimes
make; make install; cd ./contrib; make; make install
Примерно так. Первые два флага для разных опытов, для 1С они не нужны.
http://pg1c.ru/?page_id=91
Пишут, что ошибка не страшная, только глаза мозолит. Хотя у себя я не наблюдал.

Давайте ка поподробнее. Пожалуйста.
Делаю уже не первый раз по такому методу.
http://www.alsigned.ru/?p=1756

Т.е. беру исходники src.rpm от самого 1С.

изменяю в /usr/lib/rpm/macros
%_default_patch_fuzz    2

Далее собираю
rpmbuild -bb --define 'runselftest 0' ~/rpmbuild/SPECS/postgresql-9.2.1-1C.spec

Ну это по правильному :), чтобы не нарушать строгую идеологию построения дистрибутива.
Я больше по старинке, в /usr/local/pgsql. Разархивируется куда-нибудь postgresql-9.2.1.tar.bz2, туда же кладутся патчи
и скрипт, типа такого
> cat makepgsql.sh
#!/bin/sh

patch -p 1 <1c_FULL_92-0.22
patch -p 1 <applock-1c-9.2.patch
patch -p 1 <online_analyze.patch
patch -p 1 <plantuner.patch
patch -p 1 <postgresql-1c-9.2.patch

./configure --disable-integer-datetimes
make; make install
cd ./contrib; make; make install
cd ..

Все.

Меня больше сборка rpm интересует. Ибо ставлю не на том ПК, где собираю пакеты.

(36)
Как прошли ваши опыты с 9.2.1?
Я все же откатился на 9.1.2, т.к. мне не удалось избавиться от ошибок в логе. И возможно базы работали неверно.

Может кому интересно будет - http://postgresql.leopard.in.ua/
Учтены последние версии.

Здравствуйте, друзья, долго не появлялся, работой подзавалили :-)
(46) Несмотря на то, что система в итоге вышла чуть другой, вышли примерно на эти цифры. С разбросом 5-6 баллов, правда. 8.2.16.362, постгрес 9.1.2. Жалко, к серверу уже не имею доступа, стоит у клиента, но люди довольны. 9.2.1 хотели поставить, но клиент уперся (вернее, его представитель). Дисковая система не такая, как хотелось, в ней и затык. Думаю, можно было бы выдавить больше.
(53) Да нормально. Особых проблем не обнаружил. Боюсь ошибиться, но ошибка ERROR: syntax error at or near "application" at character 24 - вроде как не существенна, кажется у 1С на сайте мелькало, что "типа забейте". О, вот нашел http://distrib.itrf.ru/1C/1cv81/1cv81/AddDoc/RU/V8Update.htm
Попробуйте платформу 8.2.17, она сегодня как раз стала стабильной.
Впрочем, у меня в логах этого нет.
9.2.1 в сравнении с предыдущей - почти то же самое, никакой разницы в стабильности или производительности не заметил. Тест Гилева тоже.
(54) Спасибо большое, интересно!

(42)Попробовал  включить online_analyze, результат теста снизился баллов на 5-6.