Читаю документацию и разные форумы - везде пишут про слабые сервера с 4Гб оперативной памяти и тд...
Но ведь прогресс не стоит на месте! Сейчас по БД использую сервер с восьмью ядрами 2Ггц и 24Гб RAM. На больших запросах postgres тормозит, пока пытаюсь решить проблему - решил спросить у сообщества отредактированный postgresql.conf для сервера сходной конфигурации.
Документации я прочитал уйму и продолжаю это делать.
Хотелось бы именно реальных примеров. Что-то вроде - 50 пользователей УПП, настройки такие-то, были проблемы с тем-то, изменил вот эти параметры, помогло...
В первую очередь надо посмотреть при выполнении каких операций "тормозит" сервер.
Это может быть как и неправильный код в 1С, так и "оптимизатор" постгреса построил не оптимальный запрос, ориентируюсь на свои, неведомые простым смертным, механизмы.
Отследите - при каких условиях база тормозит (здесь нажали это, а тут это).
А потом, если хотите - напишите мне, проконсультирую.
Я понимаю, но конфигурация закрыта для изменений административными решениями (дабы не было проблем из-за смен программистов). Поэтому остается только тюнить БД и разгонять сервера. У вас postgres? Можете поделиться конфигурационным файлом?
Посмотрите мой вариант для этих целей. Вроде работает неплохо у многих моих клиентов: https://github.com/kozhin/pgsql-1c
Если сможете подсказать по дальнейшей оптимизации, буду только рад! Единственное, это конфиг под PostgreSQL, работающий на Windows Server 2008 R2.
Виртуальная машина с Windows Server 2008 R2, 2-мя вирт. процессорами (Intel X5660), 4 Гбайтами памяти и разделом на SAS-диске. Есть машина с 6 Гбайтами. Есть с 4-мя вирт. процессорами и 8 Гбайтами памяти. Количество пользователей варьируется от 10 до 20. Одновременно работают 8-18.
посмотрел ваш конфиг, у вас там
fsync = off
synchronous_commit = off
это конечно увеличивает скорость, но дает риск коррупции данных (1) и риск потери закоммиченных транзакций (2) в случае отказа по питанию. на критичных сервисах это совершенно недопустимо.
Да, забыл отметить, что у меня все данных хранятся на двухконтроллерной СХД с RAID10 массивом, которая стоит в очень хорошем дата-центре, имеющем многократное резервирование по питанию. Также всё моё оборудование подключено к собственным упсам, помимо упсов дата-центра.
Уже 6 лет полет нормальный. Когда стоял в другом дата-центре, отключали электричество "внезапно" - работа останавливалась штатно, ничего не терялось.
Но безусловно для работы на обычном "офисном" сервере fsync и synchronous_commit лучше включить.
М-да... Как ни крутил настройки, особых изменений не заметил. В итоге остановился на настройках по pgtune pgtune.leopard.in.ua для профиля Desktop Application. Обновление postgresql до 9.2 вроде дало некоторое ускорение, но проверял только в монопольном режиме, как оно будет с кучей пользователей - надо выяснять.
@nikweter значит, с точки зрения postgresql конфигурация оптимальная. Т.е. дальше нужно сначала рассматривать вариант с оптимизацией запросов (особенно если конфигурация дописывалась), а затем думать про апгрейд железа.
Нет, конфа стандартная. Диски почти не нагружены, а вот одно ядро и postgresql и 1С грузят на 100% практически постоянно. Буду думать о замене процессора на более быстрый.
