Настройка PostgreSQL для работы в связке с 1С 8.х на платформе Windows Server 2012, объём БД более 200 Гб

Публикация № 554213 11.10.16

Администрирование БД - HighLoad оптимизация

postgre postgresql postgresql 1C postgresql.conf

Настройка бесплатной СУБД PostgreSQL для работы в связке с 1С 8.х на платформе Windows Server 2012 х64. Объём БД более 380 Гб для мощного сервака. Конфигурация КА 1.1.108.2, 50 пользователей. Более 1 млн. проводок при закрытии месяца. Время закрытия месяца сравнимо с MSSQL и составляет в среднем 2 часа. Время отмены закрытия месяца - всего 10 минут! Ликвидированы зависания PostgreSQL. Всё за счет настроек файла postgesql.conf.

PostgreeSQL может работать с большими базами данных, не уступая по скорости и надёжности MSSQL. Всё зависит от настроек этой СУБД в файле postgresql.conf . Единственный минус - скорость разворачивания большой БД через dt-шник (10 часов) и скорость создания копии БД (5 часов c помощью pgdump при работающих пользователях, но ПЛЮС - всего 1 час выгрузкой в  dt-шник из конфигуратора при неработающих пользователях).

У нас тяжёлая конфигурация 1С КА 1.1.108.2, 50 одновременно работающих пользователей. Более 1 млн. проводок при закрытии месяца. Время закрытия месяца сравнимо с MSSQL и составляет в среднем 2 часа. Время отмены закрытия месяца - всего 10 минут! Ликвидированы зависания PostgreSQL. Всё за счет настроек файла postgesql.conf.

# Оптимальные настройки для сервера PostgreeSQL сборки postgresql-9.4.2-1.1C с тяжелыми базами данных и тяжёлыми запросами (подробное описание)
# Процессоры: Intel (R) Xeon (R) E5620 2.4 GHz (2 процессора по 8 ядер каждый) х64
# ОЗУ: 48 ГБ 1068MHz
# Дисковый массив уровня RAID 10: 4 диска по 800 ГБ, сумарный объем дискового массива 1600 ГБ
# ОС: Windows Server 2012 R2 Standard х64
# База данных: 1С КА текущий объем 215 ГБ, суммарный объём всех планируемых баз данных 1500 ГБ
# Сервер 1С 8.3.8.2137 х64 запущен на этой же машине.

# Текущее распределение памяти в ОС смотрим в Диспетчере задач закладка Производительность-> Память:
# Используется:  Доступно:   Выделено:   КЭШИРОВАНО: Выгружаемый Пул: Невыгружаемый пул:
#     15,2 ГБ           30,7 ГБ       15,6/54,9 ГБ          30,5 ГБ               484 МБ             85,3 МБ

# Итак, необходимые настройки postgresql.conf 


effective_cache_size = 30GB # чуть меньше 2/3 от доступного объема памяти (=текущий размер кэша ОС см. КЭШИРОВАНО=30,5 ГБ в Диспетчере задач)

#PostgreSQL в своих планах запросов опирается на кэширование файлов, осуществляемое операционной системой. Этот параметр соответствует максимальному размеру объекта, который может поместиться в системный кэш. Это значение используется только для оценки. effective_cache_size можно установить в 1/2 - 2/3 от объёма имеющейся в наличии оперативной памяти, если вся она отдана в распоряжение PostgreSQL.
#Начиная с версии PostreSQL 8.2 изменена работа оптимизатора запросов. Теперь она существенно зависит от размера выделенной PostreSQL оперативной памяти.

#При использовании сборки PostgreSQL-9.4.2-1.1C при работе с 1С:Предприятием 8 рекомендуется увеличить значение параметра effective_cache_size в конфиргурационном файле postgresql.conf до предела.
# В нашем данном случае предельный размер определяется Кэшем ОС = 30,5 Гб после запуска службы сервера PostgreSQL. Значение параметра корректируем по мере уменьшения кэша ОС в процессе работы системы, а также уменьшение может потребоваться, если мы увеличим параметры, изменяющие распределение памяти ,например, shared_buffers.

shared_buffers = 6GB # 1/8 RAM или больше (но не более 1/4). В нашем случае сложные запросы, тяжелые транзакции, 48 ГБ ОЗУ, но такого объема пока хватает (можно как в рекомендации: от 1/8 RAM = 6GB до 1/4 RAM = 12GB). При большом количестве строк данных записываемых в одной транзакции объем буфера должен быть увеличен, иначе PostgreSQL вылетит по ошибке. К примеру, для 1С поводом увеличить буфер является запись свыше 5000-6000 строк в табличную часть одного документа с помощью обработки и последующая запись или проведение этого документа.

#На выделенных серверах полезным объемом будет значение от 8 МБ до 2 ГБ. Объем может быть выше, если у вас большие активные порции базы данных, сложные запросы, большое число одновременных соединений, длительные транзакции, вам доступен большой объем оперативной памяти или большее количество процессоров. И, конечно же, не забываем об остальных приложениях. Выделив слишком много памяти для базы данных, мы можем получить ухудшение производительности.
# Объём совместно используемой памяти, выделяемой PostgreSQL для кэширования данных, определяется числом страниц (shared_buffers) по 8 килобайт каждая. Следует учитывать, что операционная система сама кеширует данные, поэтому нет необходимости отводить под кэш всю наличную оперативную память. Размер shared_buffers зависит от многих факторов, для начала можно принять следующие значения:
#8–16 Мб  – Обычный настольный компьютер с 512 Мб и небольшой базой данных
#80–160 Мб – Небольшой > сервер, предназначенный для обслуживания базы данных с объёмом оперативной памяти 1 Гб и базой данных около 10 Гб.
#400 Мб – Сервер с несколькими процессорами, с объёмом памяти в 8 Гб и базой данных занимающей свыше 100 Гб обслуживающий несколько сотен активных соединений одновременно.
#Примеры:
#Laptop, Celeron processor, 384 МБ RAM, база данных 25 МБ: 12 МБ
#Athlon server, 1 ГБ RAM, база данных поддержки принятия решений 10 ГБ: 200 МБ
#Quad PIII server, 4 ГБ RAM, 40 ГБ, 150 соединений, «тяжелые» транзакции: 1 ГБ
#Quad Xeon server, 8 ГБ RAM, 200 ГБ, 300 соединений, «тяжелые» транзакции: 2 ГБ
#Intel Xeon server, 48 ГБ RAM, 800 ГБ, 100 соединений, «тяжелые» транзакции: 6 ГБ
#Если объём буфера недостаточен для хранения часто используемых рабочих данных, то они будут постоянно писаться и читаться из кэша ОС или с диска, что крайне отрицательно скажется на производительности.
#В то же время не следует устанавливать это значение слишком большим: это НЕ вся память, которая нужна для работы PostgreSQL, это только размер разделяемой между процессами PostgreSQL памяти, которая нужна для выполнения активных операций. Она должна занимать меньшую часть оперативной памяти вашего компьютера, так как PostgreSQL полагается на то, что операционная система кэширует файлы, и не старается дублировать эту работу. Кроме того, чем больше памяти будет отдано под буфер, тем меньше останется операционной системе и другим приложениям, что может привести к своппингу.
#К сожалению, чтобы знать точное число shared_buffers, нужно учесть количество оперативной памяти компьютера, размер базы данных, число соединений и сложность запросов, так что лучше воспользуемся несколькими простыми правилами настройки.
#Для тонкой настройки параметра установите для него большое значение и потестируйте базу при обычной нагрузке. Проверяйте использование разделяемой памяти при помощи ipcs или других утилит(например, free или vmstat). Рекомендуемое значение параметра будет примерно в 1,2 -2 раза больше, чем максимум использованной памяти. Обратите внимание, что память под буфер выделятся при запуске сервера, и её объём при работе не изменяется. Учтите также, что настройки ядра операционной системы могут не дать вам выделить большой объём памяти.

max_connections = 100 # максимальное число клиентских подключений, которые могут подсоединяться к базе данных одновременно (взято с запасом)

# не может быть бесконечным. Каждое подсоединение порождает ещё один процесс postmaster, что, естественно, требует ресурсов. Средней «паршивости» современный однопроцессорный компьютер со стандартным наполнении без особых проблем может обслуживать 100-200 соединений, но, например, 600 активных соединений будут уже явной проблемой. Любая попытка подсоединиться сверх указанного лимита приведёт к отказу от обслуживания. Плохо написанная программа в цикле открывающая, но не закрывающая за собой соединения, легко создаст проблему. Если число клиентов жёстко ограничено, то имеет смысл уменьшить этот параметр до минимально возможного значения.

maintenance_work_mem = 2024MB # увеличить до рекомендуемого размера не позволяет сам сервер PostgreSQL, при увеличении служба сервера не стартует!!! (рекомендуемый размер 1/4 RAM = 12GB)

# Эта память используется для выполнения операций по сбору статистики (ANALYZE), сборке мусора (VACUUM), создания индексов (CREATE INDEX) и для добавления внешних ключей (FOREGIN KEY). Размер выделяемой под эти операции памяти должен быть сравним с физическим размером самого большого индекса на диске. Как и в случае work_mem эта переменная может быть установлена прямо во время выполнения запроса.

work_mem = 2024MB # увеличить до рекомендуемого размера не позволяет сам сервер PostgreSQL, при увеличении служба сервера не стартует!!! (рекомендуемый размер 1/20 RAM = 2,4GB)

# Под каждый запрос можно выделить личный ограниченный объём памяти для работы. Этот объём может использоваться для сортировки, объединения и других подобных операций. При превышении этого объёма сервер начинает использовать временные файлы на диске, что может существенно замедлить скорость обработки запросов. Предел для work_mem можно вычислить, разделив объём доступной памяти (физическая память минус объём занятый под другие программы и под совместно используемые страницы shared_buffers) на максимальное число одновременно используемых активных соединений. При необходимости, например, выполнения очень объёмных операций, допустимый лимит можно изменять прямо во время выполнения запроса. Поэтому нет нужды изначально задавать теоретический предел.

temp_buffers = 2024MB # увеличить до рекомендуемого размера не позволяет сам сервер PostgreSQL, при увеличении служба сервера не стартует!!! (рекомендуемый размер 1/20 RAM = 2,4GB)

# Буфер под временные объекты, в основном для временных таблиц.

wal_sync_method = open_datasync # наилучший по тесту для Windows (для Линукс = fdatasync)

# На производительность PostgreSQL оказывает существенное влияние производительность дисковой системы. В конфигурационном файле postgresql.conf есть несколько параметров, значения которых могут оказать существенное влияние на производительность:
#fsync
#По умолчанию, параметр fsync включен. Это означает, что при выполнении операции COMMIT данные сразу переписываются из кеша операционной системы на диск, тем самым гарантируется консистентность при возможном аппаратном сбое. Обратной стороной этого является снижение производительности операций записи на диск, поскольку при этом не используются возможности отложенной записи данных операционной системы.
#Отрицательное влияние включенного fsync можно уменьшить, отключив его, положившись на надежность вашего оборудования, или правильно подобрав параметр wal_sync_method - метод, который используется для принудительной записи данных на диск.
#Возможные значения:
#open_datasync – запись данных методом open() с параметром O_DSYNC,
#fdatasync – вызов метода fdatasync() после каждого commit,
#fsync_writethrough – вызывать fsync() после каждого commit игнорирую паралельные процессы,
#fsync – вызов fsync() после каждого commit,
#open_sync – запись данных методом open() с параметром O_SYNC.
#Не все методы доступны на определенных платформах. Выбор метода зависит от операционной системы под управлением, которой работает PostgreSQL.
#В состав PostgreSQL входит утилита pg_test_fsync, с помощью которой можно определить оптимальное значение параметра wal_sync_method.
#Она выполняет серию дисковых тестов с использованием различных методов синхронизации. В результате этого теста получаются оценки производительности #дисковой системы, по которым можно определить оптимальный метод синхронизации для данной опереционной системы

checkpoint_segments = 24 #можно до 32 - подбирается экспериментально

#Журнал транзакций PostgreSQL работает следующим образом: все изменения в файлах данных (в которых находятся таблицы и индексы) производятся только после того, как они были занесены в журнал транзакций, при этом записи в журнале должны быть гарантированно записаны на диск.
#В этом случае нет необходимости сбрасывать на диск изменения данных при каждом успешном завершении транзакции: в случае сбоя БД может быть восстановлена по записям в журнале. Таким образом, данные из буферов сбрасываются на диск при проходе контрольной точки: либо при заполнении нескольких (параметр checkpoint_segments, по умолчанию 3) сегментов журнала транзакций, либо через определённый интервал времени (параметр checkpoint_timeout, измеряется в секундах, по умолчанию 300).
#Изменение этих параметров прямо не повлияет на скорость чтения, но может принести большую пользу, если данные в базе активно изменяются.
#1 Уменьшение количества контрольных точек: checkpoint_segments
#Если в базу заносятся большие объёмы данных, то контрольные точки могут происходить слишком часто2. При этом производительность упадёт из-за постоянного сбрасывания на диск данных из буфера.
#Для увеличения интервала между контрольными точками нужно увеличить количество сегментов журнала транзакций (checkpoint_segments). Данный параметр определяет количество сегментов (каждый по 16 МБ) лога транзакций между контрольными точками. Этот параметр не имеет особого значения для базы данных, предназначенной преимущественно для чтения, но для баз данных со множеством транзакций увеличение этого параметра может оказаться жизненно необходимым. В зависимости от объема данных установите этот параметр в диапазоне от 12 до 256 сегментов и, если в логе появляются предупреждения (warning) о том, что контрольные точки происходят слишком часто, постепенно увеличивайте его. Место, требуемое на диске, вычисляется по формуле (checkpoint_segments * 2 + 1) * 16 МБ, так что убедитесь, что у вас достаточно свободного места. Например, если вы выставите значение 32, вам потребуется больше 1 ГБ дискового пространства.
#Следует также отметить, что чем больше интервал между контрольными точками, тем дольше будут восстанавливаться данные по журналу транзакций после сбоя.

checkpoint_completion_target = 0.9 # рекомендуемое максимальное значение

# Чтобы избежать "завала" большим количеством системных операций дискового ввода/вывода из-за взрывного количества операций записи страниц, запись заполненных буферов во время контрольной точки "размазывается" на определённый период времени. Этот период управляется параметром checkpoint_completion_target, который задаётся как часть интервала контрольной точки. Количество данных ввода/вывода согласуется так, чтобы контрольная точка завершалась, когда данная часть checkpoint_segments сегментов WAL будет израсходована с момента старта контрольной точки или когда заданная часть checkpoint_timeout секунд истечёт, смотря какое событие из вышеуказанных наступит быстрее. С значением 0.5, заданным по умолчанию, PostgreSQL может ожидать завершения каждой контрольной точки примерно половину времени перед стартом следующей контрольной точки. На системах, которые очень близки к максимальному потоку данных ввода/вывода во время обычного функционирования, вы возможно захотите увеличить checkpoint_completion_target, чтобы снизить загрузку по вводу/выводу, возникающую из-за контрольных точек. Недостаток такого подхода состоит в том, что пролонгированные контрольные точки влияют на время восстановления, потому что при восстановлении нужно будет использовать большее количество сегментов WAL. Хотя значение checkpoint_completion_target может быть установлено столь высоким как 1.0, лучше оставить его поменьше (по крайней мере, предположительно, меньше 0.9), так как контрольные точки включают некоторые другие операции, помимо записи заполненных буферов. Установка значения 1.0 вполне вероятно приведёт к тому, что контрольные точки не будут завершаться вовремя, что приведёт к потере производительности из-за неожиданного изменения количества необходимых сегментов WAL.

default_statistics_target = 300 # количество записей, просматриваемых при сборе статистики по таблицам. По умолчанию - 100, 1С рекомендует от 1000 до 10000 при зависании запросов к БД

#Этот параметр задаёт объём статистики, собираемой командой ANALYZE. Увеличение параметра заставит эту команду работать дольше, но может позволить оптимизатору строить более быстрые планы запросов, используя полученные дополнительные данные. Объём статистики для конкретного поля может быть задан командой ALTER TABLE ...SET STATISTICS.

constraint_exclusion = partition # включаем партиционирование таблиц только для партиционированных таблиц

#Начиная с 8.4 версии PostgreSQL «constraint_exclusion» может быть «on», «off» и «partition». По умолчанию (и рекомендуется) ставить «constraint_exclusion» не «on», и не «off», а «partition», который будет проверять «CHECK» только на партиционированых таблицах.

#ну и 1С-специфические настройки:
escape_string_warning = off #чтобы лог не засорялся соответствующими предупреждениями по \
standard_conforming_strings = off # отключение \ как спецсимвола

#Следующие ниже настройки используются, если база начала подвисать:

join_collapse_limit = 6 # по умолчанию 8 . Внимание!!! Для 1С не стоит устанавливать значение этого параметра равным 1, как в рекомендациях фирмы 1С. Иначе сложные запросы с большим количеством соединений и источников данных станут надолго зависать. Примером для КА являются: документ Инвентаризационная опись основных средств, Отчет по временным разницам и т.п., поскольку данные отчеты используют множество соединений с таблицами регистров сведений.

#Задаёт максимальное количество элементов в списке FROM, до достижения которого планировщик будет сносить в него явные конструкции JOIN (за исключением FULL JOIN). При меньших значениях сокращается время планирования, но план запроса может стать менее эффективным.
#По умолчанию эта переменная имеет то же значение, что и from_collapse_limit, и это приемлемо в большинстве случаев. При значении, равном 1, предложения JOIN переставляться не будут, так что явно заданный в запросе порядок соединений определит фактический порядок, в котором будут соединяться отношения. Так как планировщик не всегда выбирает оптимальный порядок соединений, опытные пользователи могут временно задать для этой переменной значение 1, а затем явно определить желаемый порядок.

seq_page_cost = 0.1 # стоимость последовательного чтения страниц
#Задаёт приблизительную стоимость чтения одной страницы с диска, которое выполняется в серии последовательных чтений. Значение по умолчанию равно 1.0. Это значение можно переопределить для таблиц и индексов в определённом табличном пространстве, установив одноимённый параметр табличного пространства (см. ALTER TABLESPACE).

random_page_cost = 0.4 # стоимость случайного чтения страниц

#Задаёт приблизительную стоимость чтения одной произвольной страницы с диска. Значение по умолчанию равно 4.0. Это значение можно переопределить для таблиц и индексов в определённом табличном пространстве, установив одноимённый параметр табличного пространства (см. ALTER TABLESPACE).

cpu_operator_cost = 0.00025 # стоимость одного оператора запроса
#Задаёт приблизительную стоимость обработки оператора или функции при выполнении запроса. Значение по умолчанию — 0.0025

max_locks_per_transaction = 248  # 64 по умолчанию. Пришлось увеличить этот параметр одновременно с shared_buffers из-за записи более 5000 строк  в табличной части одного документа 1С. При заданном по умолчанию параметре PostgreSQL вылетала по ошибке.

#Общая таблица блокировок отслеживает блокировки для max_locks_per_transaction * (max_connections + max_prepared_transactions) объектов (например, таблиц); таким образом, в любой момент времени может быть заблокировано не больше этого числа различных объектов. Этот параметр управляет средним числом блокировок объектов, выделяемым для каждой транзакции; отдельные транзакции могут заблокировать и больше объектов, если все они умещаются в таблице блокировок. Заметьте, что это не число строк, которое может быть заблокировано; их количество не ограничено. Значение по умолчанию, 64, как показала практика, вполне приемлемо, но может возникнуть потребность его увеличить, если запросы обращаются ко множеству различных таблиц в одной транзакции, как например, запрос к родительской таблице со многими потомками. Этот параметр можно задать только при запуске сервера.

Остальные настройки пока по умолчанию.  Об их влиянии на работу 1С буду писать по мере появления свободного времени. Также будет обновляться файл postgresql.conf c оптимальными настройками начального уровня для работы на мощных серверах с большими объемами баз данных. Надеюсь, что это сэкономит время программистам и деньги предприятиям, внедряющим 1С, ибо использование MSSQL дороговато ;)

Статья в ближайшее время будет доработана. А пока выкладываю настройки для версии  выкладываю файл postgresql.conf для версии PostgreSQL 9.6 и выше для объема ОЗУ 48 Гб. Пояснения дам чуть позже. Пока на это времени нет.

Источники: 

Решение проблемы с зависанием PostgreSQL 

Документация на русском по всем версиям PostgreSQL

Скачать файлы

Наименование Файл Версия Размер
postgresql.conf

.conf 19,47Kb
66
.conf 19,47Kb 66 Скачать
postgresql.conf для PostgreSQL 9.6 для 48 Гб ОЗУ

.conf 3,08Kb
20
.conf 3,08Kb 20 Скачать

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Kopman 22 12.10.16 04:47 Сейчас в теме
Денег на память(ОЗУ) жалко?
2. zabaluev 455 12.10.16 07:13 Сейчас в теме
(1) Kopman, Сервер памятью не испортишь, а лицензия MS SQL намного дороже.
3. Pasha1st 672 12.10.16 07:42 Сейчас в теме
Настройки AUTOVACUUM не трогали?
10. vsasav 529 12.10.16 12:43 Сейчас в теме
(3) Pasha1st, avtovacuum пока не трогали, настройки по умолчанию
4. headMade 144 12.10.16 07:52 Сейчас в теме
А какой точный Релиз 1с у вас используется?
8. vsasav 529 12.10.16 11:53 Сейчас в теме
(4) headMade, 8.3.8.2137 стоит, 8.3.9 пока боимся ставить
5. asved.ru 36 12.10.16 08:17 Сейчас в теме
>> текущий объем 215 ГБ
Степень bloat проверяли? Используется ли антиблотер, например pgcompacttable? Каков размер после пересчета итогов и последующего vacuum full?

>> work_mem = 2024MB
Совсем озверели.

>> checkpoint_completion_target = 0.9
Очередь и IOPS покажите.

Не увидел режима коммита и wal_level.

В общем, система работает, потому что объем оперативки превышает текущие потребности.
Ну и выбор платформы Windows сомнителен.
9. vsasav 529 12.10.16 12:06 Сейчас в теме
(5) asved.ru, Остальные настройки - пока по умолчанию, размер базы не зависит от VACUUM FULL и от пересчета итогов, проверяли до и после, полный вакуум идёт неприемлемо долгое время - 10 ч
12. asved.ru 36 13.10.16 06:31 Сейчас в теме
(9)
размер базы не зависит от VACUUM FULL и от пересчета итогов


Не верю. Вы что-то делаете не так.
13. vsasav 529 13.10.16 08:30 Сейчас в теме
(12) asved.ru, сам удивился, видимо автовакуум вовремя срабатывает
6. dour-dead 257 12.10.16 08:34 Сейчас в теме
>>Сервер 1С 8.3 х64 запущен на этой же машине.
У нас когда база подходила к 300гб, начались тормоза и зависания, процессора (Intel ® Xeon ® E5650 2.4 GHz ) не хватало (в пики постоянная загрузка 98-100%, при 200 активных соединений ), что бы одновременно обрабатывать запросы сервера и 1с и СУБД.

Пришлось основной кластер 1с (всего 3 сервера 1с) и субд, разделить на 2 машины, сейчас БД ~ 600gb полет нормальный в пики видим загрузку процессора субд и 1с только на 50-60%
Danil.Potapov; +1 Ответить
17. vsasav 529 14.10.16 13:26 Сейчас в теме
(6) dour-dead, В дальнейшем, вероятно, так и сделаем, разнесем PostgreSQL и 1C 8.3 сервер по разным серверам, но пока нагрузка в среднем 10% на процы, пики редкие до 90%. Настроил сервер 1С 8.3 на не более 20 соединений на рабочий процесс и отдельные процессы для каждой БД. В итоге крутится в среднем 3 рабочих процесса, сервер 1С не зависает целиком, если какой-то пользователь вдруг запустил "невозможный" отчет миллионов на 100 проводок по 20 счету. Спасибо за совет.
18. kofr1c 16.10.16 17:06 Сейчас в теме
(6) dour-dead, а какая ОС и база данных?
7. Pasha1st 672 12.10.16 09:51 Сейчас в теме
И ещё. Может быть оправданным вынесение WAL и tmp_tablespace на отдельные диски. На тех серверах на 2xE5*** которые я видел даже на 1U было место и порты где можно было бы разместить пару 2.5" дисков. Мы ставили два SSD в зеркало и размещали там WAL, temp_tablespace + дисковый кэш (на Linux и FreeBSD).
11. vsasav 529 12.10.16 12:48 Сейчас в теме
(7) Pasha1st, да, не помешало бы, ограничены только бюджетом, все выжимаем из сервака пятилетней давности
14. vj_still 13 13.10.16 17:18 Сейчас в теме
Интересно было бы посмотреть тест Гилёва, а именно Нагрузочный тест TPC-1C. У меня почти такая же конфигурация но собранная на Centos выдаёт максимум 10 баллов.
15. belovo3000 41 14.10.16 06:15 Сейчас в теме
Что(14) vj_still, Что-то мне подсказывает что тест Гилава покажет еще ниже при таких настройках. Во всяком случае после этих рекомендаций у меня с 20 упало до 4. Хотя тест Гилева не панацея, он однопоточный и не всегда показывает актуальные данные. А вот реальная база стала работать быстрее. Во всяком случае проведение и удаление объектов
19. vj_still 13 17.10.16 09:00 Сейчас в теме
(15) belovo3000, Можешь конфигом поделиться, подсмотреть =) Нифига понять не могу 2 разных сервера, один намного мощнее другого, но на тесте выдают одинаковое количество баллов. Уже 3 недели пытаюсь врубиться в чём трабл, нифига понять не могу...
16. vsasav 529 14.10.16 11:48 Сейчас в теме
(14) vj_still, Тест Гилева 9,62, однако реальная база работает быстрее. Ещё бы как-то заставить оптимизатор запросов Postgree выбирать правильные планы запроса без включения/отключения параметра
#enable_nestloop = off, цены бы не было такой настройке
устанавливал
default_statistics_target = 5000, Запускал ANALIZE, как советуют в документации - не помогает,
для некоторых запросов всё равно строится неоптимальный план (к примеру, при заполнении документа Инвентаризация ОС с большим числом позиций помогало только временное отключение плана со вложенными запросами enable_nestloop = off)
отключенный же enable_nestloop = off отрицательно влияет на время расшифровки обороток по 20,23 счетам)
20. frkbvfnjh 702 17.10.16 12:04 Сейчас в теме
я всегда делаю enable_nestloop = off, т.к. иначе никак, видимо с 1С-ными сложными запросами постгри не в силах построить адекватный план запроса.
21. frkbvfnjh 702 17.10.16 12:14 Сейчас в теме
Кстати статья с ИТС про enable_nestloop кому интересно:

Решение проблемы с зависанием PostgreSQL

При выполнения некоторых регламентных операций (Закрытие месяца, Расчет себестоимости и т.п), где используются сложные запросы с большим количеством соединений больших таблиц, возможно существенное увеличение времени выполнения операции. В основном, эти проблемы связаны с работой оптимизатора PostgreSQL и отсутствием актуальной статистики по таблицам, учавствующим в запросе.

Варианты решения проблемы:

Увеличить количество записей, просматриваемых при сборе статистики по таблицам. Большие значения могут повысить время выполения команды ANALYZE, но улучшат построение плана запроса:
Файл postgresql.conf - default_statistics_target = 1000 -10000.
Отключение оптимизатору возможности использования NESTED LOOP при выборе плана выполнения запроса в конфигурации PostgreSQL:
Файл postgresql.conf - enable_nestloop=off.
Отрицательным эффектом этого способа является возможное замедление некоторых запросов, поскольку при их выполении будут использоваться другие, более затратные, методы соединения (HASH JOIN).
Отключение оптимизатору возможности изменения порядка соединений таблиц в запросе:
Файл postgresql.conf - join_collapse_limit=1.
Следует использовать этот метод, если вы уверены в правильности порядка соединений таблиц в проблемном запросе.
Изменение параметров настройки оптимизатора:
Файл postgresql.conf:
seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025
Использование версии PostgreSQL 9.1.2-1.1.C, в которой реализован независимый от AUTOVACUUM сбор статистики, на основе информации об изменении данных в таблице. По умолчанию включен сбор статистики только для временных таблиц и во многих ситуациях этого достаточно. При возникновении проблем с производительностью выполнения регламентных операций можно включить сбор статистики для всех или отдельных проблемных таблиц изменив значение параметра конфигурации PostgreSQL( файл postgresql.conf) online_analyze.table_type = "temporary" на online_analyze.table_type = "all".
После изменнеия этих параметров, следует оценить возможное влияние этих изменений на работу системы и выбрать наиболее приемлимый выриант для ваших задач.
22. vsasav 529 17.10.16 13:11 Сейчас в теме
(21) Именно этой статьёй: Решение проблемы с зависанием Postgree и описанием Postgree Документация на русском по всем версиям PostgreSQL пользовался при настройках, однако полностью проблем с подвисанием запросов она не решает
23. vj_still 13 17.10.16 16:17 Сейчас в теме
Есть ещё и видосы с PG DAY 16 по настройке... Но чёт как-то... 10, периодически 13 =)... Подкрадываются сомнения в стабильности самого железа...
https://www.youtube.com/watch?v=BixjT3TaJqE
https://www.youtube.com/watch?v=A8JWZJGHpbU
dour-dead; +1 Ответить
24. ture 596 21.11.16 09:18 Сейчас в теме
На сервак все равно придется отвалить много. Для тех, кто не мог без линуха, это была тема. А теперь MS SQL легко идет на линухе. Следующая тема - Oracle.
26. RealEscander 493 22.11.16 13:33 Сейчас в теме
(24) ture, оракла халявного не бывает!
25. RealEscander 493 22.11.16 13:33 Сейчас в теме
Тема автовакуума не раскрыта, эффективкэшсайз обычно рекомендуют в половину физической памяти... а так норм конфиг.
27. Andry.Boris 58 22.11.16 23:44 Сейчас в теме
28. bulas 208 23.11.16 08:18 Сейчас в теме
У автора предложения при использовании сборки (версии) PostgreSQL-9.4.2-1.1С, а решение проблемы с зависанием PostgreSQL, от Андрея Лукина, приводится с использованием версии PostgreSQL 9.1.2-1.1.C - при выполнении некоторых регламентных операций (Закрытие месяца, Расчет себестоимости и т.п), где используются сложные запросы с большим количеством соединений больших таблиц, возможно существенное увеличение времени выполнения операции. Насколько эти версии отличаются друг от друга? И подойдут предложения для 9.1.2-1.1С к 9.4.2-1.1С.
29. vsasav 529 23.11.16 15:52 Сейчас в теме
(28) bulas,
seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025

установка этих параметров сильно уменьшает время выполнения длительных запросов и для версии 9.4.2-1.1С

enable_nestloop = off - используется в исключительных случаях в запросах по регистрам, связанным с Основными средствами, отключение этого параметра в КА 1.1 замедляет формирование расшифровок обороток по 20-м счетам и поэтому не рекомендуется
30. vsasav 529 23.11.16 15:56 Сейчас в теме
(28) bulas, При замедлении работы базы ANALIZE по всем таблицам, и далее - полет нормальный
31. xmolex 12 19.06.18 17:46 Сейчас в теме
Хотел бы немного упомянуть про очень интересный параметр, если у вас диск в рейд0: effective_io_concurrency. Очень хорошо влияет на производительность.
33. vsasav 529 20.06.18 09:57 Сейчас в теме
(31) RAID 5 у нас, этот параметр пробовал выставлять, PG перестает грузиться
35. xmolex 12 20.06.18 11:44 Сейчас в теме
(33) Это естественно, т.к. RAID5 - это не просто несколько дисков, чтобы pg мог кидать на них порции данных, это постоянный расчет контрольных сумм. Вообще, как по мне, RAID5 и highload несовместимые понятия.
32. a.doroshkevich 20.06.18 07:43 Сейчас в теме
К автору публикации: можете полный конфиг выложить?
Так как у Вас настроен PG, так настраивать нельзя. Особенно seq_page_cost = 0.1 и enable_nestloop=off.

P.S. Тест Гилёва на клиент-серверных базах не показатель впринципе, бороться там за попугаев не имеет никакого смысла. Есть стандартный нагрузочный тест от Фирмы 1С - это гораздо более приближенно к реальной нагрузке.
34. vsasav 529 20.06.18 10:05 Сейчас в теме
(32) Выше (28), я писал, для чего используется этот режим. Это крайняк, когда расчет себестоимости зависает.
enable_nestloop=off - категорически НЕ РЕКОМЕНДУЕТСЯ
36. user885088 13.03.19 08:02 Сейчас в теме
Всем доброго времени суток!
Если я правильно понял, вышеперечисленные настройки применимы к одной базе, а как быть если их 24?, 2 основные размером 27Гб и 8Гб, а остальные от 1Гб до 11Гб. и крутится все это не на Windows Server а на CentOs 7?.
Подскажите пожалуйста, как мне оптимизировать быстродействие PostgreSQL?.
37. vsasav 529 18.03.19 10:35 Сейчас в теме
(36) Я не Линуксоид, но думаю, что PostgreSQL неплохо справляется с обработкой множества баз в одном кластере в любой ОС, тем более на LINUX. На Windows Server у меня сейчас 40 !!! баз крутится в одном кластере, и все немаленького размера. Так что все описанное здесь справедливо для множества баз.
38. shard 265 01.04.19 15:11 Сейчас в теме
для ускорения pg_dump, pg_restore стОит обратить внимание на параметр --jobs
39. vsasav 529 01.04.19 18:58 Сейчас в теме
(38) Это тема другой публикации:
41. пользователь 12.02.20 10:38
Сообщение было скрыто модератором.
...
42. xKEEPERx 16.04.20 00:30 Сейчас в теме
Здравствуйте, Коллеги! Подскажите пожалуйста куда копать в устранении проблемы? У нас периодически падает база postgressql. Мониторинг перед падением показывает перегруз оперативной памяти. В нормальном состоянии база сервера postgresql потребляет 4-6 ГБ оперативной памяти, при падении базы потребление оперативки подскакивает до максимума в 24 ГБ.

Параметры сервера:

Windows server 2016, 8 CPU, 24ГБ RAM.

PostgreSQL Database Server 10.3-2.1C(x64)

Платформа стоит на другой машине.

Конфигурация Документооборот 8 КОРП, редакция 2.1 (2.1.12.2)
43. D_astana 14.05.20 09:41 Сейчас в теме
(42) effective_cache_size сколько? Потребление памяти в кластере 1с замеряли? Там тоже потребление скачет или только слоник жрет память? Что в логаг PG? Настройки логирования длительных запросов делали? У меня такое было, только проц уходил в потолок. Нашли запрос на стороне 1с зацикленный в расчетах.
Как предположение можно посмотреть maintenance_work_mem и autovacuum_max_workers. Если удаляется много данных и запускается много процессов очистки и подсчета статистики, то выделяется память maintenance_work_mem * autovacuum_max_workers. Но я не знаю, ограничивается ли это выделение параметром effective_cache_size. Это предположение, мало информации. Ни размера базы, ни количества пользователей, ни среднего количества операций в ед времени, ни проводимые обслуживания в тех окно.
44. xKEEPERx 21.05.20 00:03 Сейчас в теме
(43)
effective_cache_size сколько?

effective_cache_size = 16500MB
maintenance_work_mem = 1GB
autovacuum_max_workers = 4
Потребление памяти в кластере 1с замеряли?

В кластере память в норме...
Что в логаг PG?

Логи к сожалению отключены, пока не разобрался как их настроить. При включении отнимают много системных ресурсов.

Причину нашёл, но как её побороть на стороне постгресса пока не знаю.
Причина оказалось в том, что у некоторых пользователей для поиска добавлены столбцы доп реквизитов внутренних документов 1С ДО.
При динамическом поиске при вводе символов типа "До" постгресс создаёт один процесс который занимает около 800мб памяти и 15% процессора
При вводе символов типа "Договор №365 от" система создаёт 5 процессов postgresql и каждый из них занимает 1.4ГБ памяти и 15% процессора.
В итоге потребление взлетает до 100% и максимально возможной памяти, что в последствии вешает сервер базы данных.

Пока убрал у пользователей функцию динамического поиска.
Может быть кто то подскажет, как это можно побороть на стороне базы данных?
45. ansh15 21.05.20 09:05 Сейчас в теме
(42) Встречалось похожее поведение
Попробуйте 11.5-19.1C или тестовую 11.7-5.1C(на днях выложили).
Желательно учесть, при этом, что для 11-й редакции PostgreSQL
Текущая версия PostgreSQL предназначена для использования с версией технологической платформы 1С:Предприятие 8 не ниже 8.3.14.1565

Что с более ранними версиями работать совсем не будет, нигде не утверждается, но и обратного тоже.
Впрочем, и 10.12-3.1C тоже есть тестовая, можно и ее попробовать, но для нее тоже
не ниже 8.3.14.1565

10.3-2.1C уже очень старая.
46. ansh15 25.05.20 16:18 Сейчас в теме
(45)
тестовую 11.7-5.1C(на днях выложили)

Уже актуальная.
47. KOMES 01.07.20 13:38 Сейчас в теме
Добрый день возникла проблема с ошибкой 53100 при этом места на диски с BD есть. Ошибка вываливается при обновление и удаление.
База весит 29 Gb диск 278Gb свободна 249Gb Reid 1 диски sas. Куда копать не пойму. Можете подсказать в чем проблема postgresql прикрепил.

Параметры сервера:
Windows server 2012 R2, 20 CPU, 64 ГБ RAM
PostgreSQL Database Server 10.5-24.1C(x64)

Платформа стоит на другой машине.

При выполнение процесса нагрузки на сервер почти нет.
postgresql вроде выполнен также ток с учетом ттх сервера.
Прикрепленные файлы:
postgresql.conf
49. rokhin 131 18.05.21 09:12 Сейчас в теме
48. rokhin 131 18.05.21 09:11 Сейчас в теме
Оставьте свое сообщение

См. также

Обслуживание баз данных 1C на Postgresql под Astra Linux Промо

Администрирование СУБД Инструменты администратора БД Linux v8 Абонемент ($m)

Эта публикация для тех специалистов 1С, которые развернули сервер 1С и сервер PostgreSQL под Astra Linux и которым не интересно работать в командной строке, выполняя «шаманские» скрипты для автоматического сохранения и восстановления баз. Возможно вам тоже будет удобно обслуживать базы данных PostgreSQL решением на платформе 1С.

1 стартмани

14.06.2022    1653    4    alfanika    9    

Подсистема оповещений об изменении объектов

Инструменты администратора БД v8 1cv8.cf Абонемент ($m)

Подсистема предназначена для оповещения пользователей по электронной почте об изменении объектов (справочников/документов). Письмо содержит информацию о том, кто, когда и что изменил в отслеживаемых объектах.

1 стартмани

27.07.2022    1932    11    Sirruf    15    

Решение проблем подвисания 1С “в онлайне”. Инструмент - консоль управления блокировками и процессами 1С и SQL

HighLoad оптимизация Администрирование СУБД v8 v8::УФ 8.3.14 1cv8.cf Абонемент ($m)

Обработка-консоль, улучшенная версия консоли администрирования 1С для решения проблем с производительностью, поиска и устранения блокировок и длительных запросов. Тестировалось на платформе 8.3.14, 8.3.17, 8.3.20 УФ.

1 стартмани

04.07.2022    2317    31    victor_goodwill    6    

Консоль запросов SQL (управляемые формы)

Инструменты администратора БД Инструментарий разработчика Внешние источники данных Запросы v8 1cv8.cf Абонемент ($m)

Иногда требуется подключиться к другим базам данных для обменов, например: MySQL (сайты, интернет магазины), MS SQL, PostgreSQL (базы данных такие как 1С, WMS, других приложений) и т.д. Данная консоль поможет настроить и проверить подключение, выполнить любые запросы на языке SQL, а также если подключить обработку в конфигуратор использовать для обменов между базами данных с помощью языка SQL.

2 стартмани

04.05.2022    2976    21    nikolasx    6    

Оптимизация размера изображений из присоединенных файлов УТ 11.4 Промо

Инструменты администратора БД Обработка справочников v8 УТ11 Россия Абонемент ($m)

У нас часто возникала ситуация, когда необходимо настроить обмен с сайтом или с внешней системой, но выгружаемые изображения слишком сильно увеличивали объем сообщений обмена, обмен происходил медленно. Да и для самой базы, операции с не оптимизированными изображениями требуют большего количество ресурсов и места на диске. Потому мы собрали свои наработки в одно расширение.

5 стартмани

10.07.2020    12795    20    Neti    5    

Изыскания на тему записи в регистр сведений

HighLoad оптимизация v8 Платформа 1C v8.2 1cv8.cf Абонемент ($m)

Уважаемые коллеги, здравствуйте! Сегодня хочу поделиться с Вами своими изысканиями на тему записи в регистр сведений в контексте оптимизации одной операции. Однажды мы столкнулись со следующей проблемой: поступили жалобы от разработчиков сайта, что наш веб-сервис очень медленно реагирует, точней, обработка запроса не укладывается в таймаут 5 секунд, и сайт получает ошибку 500. Стали разбираться, и вот что выяснили.

1 стартмани

21.09.2021    8539    0    METAL    57    

Просмотр файлов технологических журналов 1С (WinAPI)

HighLoad оптимизация Технологический журнал v8 Россия Абонемент ($m)

Программа просмотра файлов технологических журналов 1С (WinAPI). Работает с большими файлами. Минимальное потребление памяти при индексировании данных, просмотре. Анализ управляемых взаимоблокировок, таймаутов, ожиданий. Фильтры по событиям, периоду, пользователям, соединениям, сеансам.

1 стартмани

24.08.2021    4176    16    sdf1979    17    

Универсальная выгрузка, загрузка и резервное копирование настроек программы

Универсальные обработки Инструменты администратора БД v8 1cv8.cf Абонемент ($m)

Универсальная обработка позволяет выгрузить настройки практически любой современной конфигурации на базе БСП в файл, а при загрузке из файла сравнить с текущими значениями в информационной базе.

1 стартмани

23.08.2021    4684    22    Nicholas    11    

Запуск 1С под любым пользователем (без необходимости указания пароля) Промо

Пароли Инструменты администратора БД Инструментарий разработчика v8 v8::Права 1cv8.cf Абонемент ($m)

Предназначается для запуска сеанса другого пользователя из своего сеанса 1С (если пароль вам неизвестен).

1 стартмани

02.07.2019    34732    381    sapervodichka    0    

Доп. панель Alt+Z

Инструменты администратора БД v8 1cv8.cf Абонемент ($m)

Панель, вызываемая для объекта комбинацией клавиш Alt+Z (для документа, справочника, плана вида характеристик, плана счетов и т.д.). Возможности: Редактор всех реквизитов, таблиц и движений, Анализ прав к объекту, Поиск ссылок на объект с фильтрами, Сторно движений документа, Выгрузка/загрузка текущего объекта между базами. Подключается как Расширение.

2 стартмани

24.06.2021    12576    141    sapervodichka    63    

Мастер создания копии информационной базы для отчетности

HighLoad оптимизация Администрирование СУБД v8 1cv8.cf Абонемент ($m)

Прототип инструмента для подготовки реплики в режиме только для чтения к использованию. Позволяет использовать "read-only" реплики как обычные информационные базы 1С.

10 стартмани

28.08.2020    12588    12    YPermitin    13    

Настройка PostgreSQL 11.5 и 1C: Предприятие 8.3.16 на Windows Server 2008R2

Администрирование СУБД v8 1cv8.cf Россия Абонемент ($m)

Под «Окнами» «Слона» водили… Когда файловая БД 1С вырастает и начинает тормозить, встает вопрос по переводу базы на SQL, безусловно, лидеры и самые используемые при настройке SQL баз на 1С это ПО Microsoft SQL Server и PostgerSQL, (прочие IBM DB2 и Oracle Datebase), но жирный плюс в сторону PostgerSQL, что она условно бесплатная, в отличие от цены на MSSQL.

1 стартмани

22.01.2020    101488    ClickUp    54    

DroidRAC2 - консоль администрирования кластера серверов 1С:Предприятие 8.3 под Android Промо

Инструменты администратора БД v8 1cv8.cf Абонемент ($m)

DroidRAC2 - клиент для RAS-сервиса кластера серверов платформы 1С:Предприятие 8.3 под Android.

1 стартмани

24.02.2017    31055    13    user700211_a.straltsou    20    

Транслятор запросов 1С в SQL

HighLoad оптимизация Администрирование СУБД Запросы v8 v8::Запросы 1cv8.cf Абонемент ($m)

Инструмент для трансляции запросов платформы 1С в SQL, а также их диагностики.

10 стартмани

07.01.2020    35639    304    YPermitin    89    

Быстрая реструктуризация базы данных

HighLoad оптимизация v8 v8::УФ 1cv8.cf Россия Абонемент ($m)

Внешняя обработка для быстрой реструктуризации клиент-серверной базы данных. Способ ускорения реструктуризации - замена таблиц большого объема пустыми копиями перед проведением обновления БД и возврат к исходным таблицам после обновления с предварительной корректировкой их структуры. Полностью автоматизировано создание и выполнение всех требуемых скриптов SQL. Представлены версии обработки для обычных форм (1С:Предприятие 8.2 (8.2.19.130)) и управляемого приложения (1С:Предприятие 8.3 (8.3.9.1818)).

1 стартмани

05.11.2019    29426    134    dmitrydemenew    39    

Набор скриптов для знакомства с PostgreSQL

Администрирование СУБД Бесплатно (free)

Немного скриптов для PostgreSQL, позволяющих познакомиться с состоянием сервера.

04.11.2019    21549    YPermitin    18    

Многопоточная обработка данных Промо

HighLoad оптимизация Инструменты администратора БД v8 v8::УФ 1cv8.cf Абонемент ($m)

Конфигурация "Универсальные механизмы: пакеты данных". Набор инструментов для быстрой организации отказоустойчивой многопоточной обработки данных.

1 стартмани

23.11.2018    36290    145    _ASZ_    18    

Конфигурация для администраторов "Центр управления базами" для 8.3 УФ

Инструменты администратора БД БСП (Библиотека стандартных подсистем) v8 v8::УФ 1cv8.cf Абонемент ($m)

Конфигурация предназначена для централизованного управления информационными базами предприятия. Разработана на БСП версии 2.4.4.76. В работе использует COM-соединение.

3 стартмани

09.10.2019    14131    49    WhiteOwl    17    

Обновление конфигурации 1С из cf по расписанию

Инструменты администратора БД v8 1cv8.cf Абонемент ($m)

Часто в процессе внедрения или активной разработки конфигурации возникает необходимость ежедневного обновления конфигурации базы данных.

1 стартмани

09.09.2019    6399    3    sivin-alexey    2    

Кто уложил 1С, или мониторинг загрузки кластера в разрезе пользователей с помощью Grafana

Инструменты администратора БД v8 1cv8.cf Россия Абонемент ($m)

Мониторингом различных параметров работы кластера 1С в zabbix сейчас уже никого не удивишь. Собственно потребление памяти, процов и места на серверах обычно настраивают первыми. Потом идет мониторинг в разрезе rphost'ов и различные метрики функционирования SQL сервера. Но вот когда уже все это есть, то временами возникает вопрос - какой же конкретно нехороший человек пытается съесть все (ну не все, но много) ресурсы сервера? Можно смотреть в консоль кластера и ловить редиску там. Можно анализировать журнал регистраций, включать технологический журнал или накапливать статистку в специализированных базах 1С. Но, "настоящим" сисадминам проще как-то с внешними скриптами, базами данных и, например, Grafana. Расскажу что у нас получилось.

1 стартмани

02.09.2019    18968    47    DonAlPatino    31    

Отключение доступа уволенным пользователям Промо

Информационная безопасность Обработка справочников Инструменты администратора БД v8 v8::Права БП2.0 УПП1 Абонемент ($m)

Давно хотели навести порядок в пользователях? Надоело, что в списке мешаются давно уволенные сотрудники? Тогда эта обработка для Вас!

3 стартмани

15.10.2013    59302    112    VBod    17    

Установка 1C на Ubuntu 19.04

Инструменты администратора БД v8 1cv8.cf Россия Абонемент ($m)

Установка платформы на примере (8.3.15.1565) на Ubuntu 19.04

1 стартмани

28.08.2019    20799    8    gubar    33    

Удаленный доступ к 1С используя SSH Тунель

Инструменты администратора БД v8 1cv8.cf Абонемент ($m)

Предлагаемая обработка открывает удаленный доступ к серверу 1С или клиентской машине через SSH-тунель.

1 стартмани

04.08.2019    13811    6    Sedaiko    7    

Service Desk. Конфигурация для администрирования баз 1С и техподдержки IT-отдела.

Инструменты администратора БД v8 Россия Абонемент ($m)

Простенькая конфигурация по обслуживанию баз 1С и IT-структуры организации для системных администраторов, программистов, IT отдела.

2 стартмани

15.07.2019    13980    92    SanchoD    19    

Инструкция по установке и настройке SQL Server и 1С Промо

Инструменты администратора БД v8 Россия Абонемент ($m)

Данный мануал позволит практически каждому пользователю пошагово установить и произвести первоначальную настройку SQL Server и 1С (клиент-серверный вариант). Основой для данной инструкции послужил SQL Server 2014 и 1С Предприятие 8.3, также данная инструкция может работать и для других версий SQL Server и 1С Предприятия.

1 стартмани

06.04.2016    98292    1132    LastSoldier    48    

Конфигурация: IT Unit

Инструменты администратора БД v8 1cv8.cf Абонемент ($m)

В помощь системным администраторам, занятым обслуживанием малого и среднего бизнеса. Конфигурация по учету оборудования, сервисов, сроков действия, записная книжка контактов, паролей и другое.

1 стартмани

03.07.2019    13711    78    riposte    15    

LicDataDecoder - расшифровка файла программной лицензии 1С

Инструменты администратора БД v8 1cv8.cf Россия Абонемент ($m)

Представляю вашему вниманию утилиту, предназначенную для работы с файлами программных лицензий 1С (*.lic).

1 стартмани

10.02.2019    60294    515    GeraltSnow    74    

Решение проблемы быстродействия в ERP на рабочем примере

HighLoad оптимизация v8 ERP2 Абонемент ($m)

Рассмотрим практический пример оптимизации, определим последовательность действий и воспользуемся специализированными инструментами.

3 стартмани

18.12.2018    30263    248    ivanov660    24    

Обработка для управления подключениями пользователей и создание бэкапа КЛИЕНТ-СЕРВЕРНОЙ базы данных 1С 8.2-8.3 (управляемое приложение,"такси") Промо

Архивирование (backup) Инструменты администратора БД v8 v8::УФ 1cv8.cf Абонемент ($m)

(©ТопчийДЮ) Данная обработка позволяет легко и быстро отключить от любой БД одного или несколько пользователей одновременно, установить блокировку сеансов, что необходимо при регламентных операциях с БД, создать резервную копию базы, удалить "дубли" сеансов. Обработка отключает соединения и сеансы указанных пользователей, даже если сеанс или соединение были "повисшими". Возможна интеграция в любую конфигурацию! (Обновление от 11.03.2016, версия 3.0)

2 стартмани

06.11.2012    64135    620    hakerxp    44    

1С в Windows docker контейнерах

Инструменты администратора БД DevOps и автоматизация разработки v8 Абонемент ($m)

Создаем Docker-контейнер для windows-версии 1C. Контейнеры позволяют подготовить рабочую среду на любой актуальной версии windows. Благодаря данной технологии можно беспрепятственно запускать требуемую версию сервера 1С или несколько серверов различных версий на одном сервере.

1 стартмани

02.10.2018    37481    43    lishniy    42    

Веб приложение для управления сервером 1С в Linux.

Инструменты администратора БД v8 Казахстан Абонемент ($m)

Статья о том как комфортно администрировать сервер 1С:Предприятие 8.3 используя Linux. А именно дистрибутив ClearOS.

1 стартмани

25.08.2018    16803    24    held88    84    

Установка/снятие блокировки регламентных заданий (клиент-серверный вариант)

Инструменты администратора БД v8 1cv8.cf Абонемент ($m)

Небольшая обработка для программного изменения свойств текущей информационной базы (клиент-сервер), в частности свойства ScheduledJobsDenied - признака блокировки выполнения регламентных заданий информационной базы. Тестировал в 8.3.10.2667 (OS Windows, MS SQL 2008).

1 стартмани

13.03.2018    13600    35    jwslavin    6    

Запуск любой внешней обработки по расписанию Промо

Инструменты администратора БД v8 1cv8.cf Россия Абонемент ($m)

Часто хочется запустить внешнюю обработку по расписанию, но непонятно как бы это сделать не коцая конфигурацию, а оставив ее типовой. Теперь это больше не проблема.

1 стартмани

15.03.2012    97048    368    Skimen    60    

Оптимизация настроек планировщика запросов в PostgreSQL

Инструменты администратора БД v8 Абонемент ($m)

Хочу сказать несколько слов о своем опыте настройки PostgreSQL для работы с 1С. А поскольку в сети уже достаточно много хороших мануалов о настройке Postgres, ограничусь тем, как я поборол неоптимальное использование плана nestloop.

1 стартмани

30.01.2018    19733    5    Gorus    8    

Вывод в windows-проводнике названия баз в каталоге кластера 1С и каталогах локального кэша и настроек пользователя

Инструменты администратора БД v8 1cv8.cf Абонемент ($m)

Вывод в windows-проводнике названия баз в каталоге кластера 1С и каталогов локального кэша и настроек пользователя. Используется создание файла desktop.ini, который автоматически размещается в подкаталогах кластера 1С. Теперь станет немного проще определить прямо в windows-проводнике, что, к примеру, каталог fd531400-428c-41c0-954f-b910bb5cc552 это именно база ERP.

1 стартмани

15.11.2017    17461    53    Alias    23    

Скрипт сбора параметров текущих сеансов 1С с отправкой в Elastic search

Инструменты администратора БД v8 Абонемент ($m)

Вы мониторите количество подключений к вашей базе 1С не открывая Конфигуратор, Консоль или Предприятие? Если нет и хотите начать, то удобно вызывать периодически внешний скрит и складывать полученные данные в удобный визуализатор.

1 стартмани

30.10.2017    18997    27    sergey.novikov    47    

Контролируемые механизмы Промо

Инструменты администратора БД v8 1cv8.cf Абонемент ($m)

Автоматический запрет запуска в копиях рабочих баз механизмов, оказывающих внешнее воздействие

1 стартмани

20.05.2014    15660    2    rtnm    7    

Многопоточные фоновые задания

Инструменты администратора БД v8 Абонемент ($m)

Подсистема Менеджер фоновых заданий предназначена для планирования, запуска и контроля выполнения произвольного кода в фоновых заданиях с многопоточной обработкой. Ведется логирование работы фоновых, перезапуск в случае ошибки, ограничение по общему количеству потоков и по количеству потоков конкретного задания. Для контроля работы предусмотрен монитор фоновых заданий, в который выводятся статусы выполнения.

1 стартмани

02.08.2017    18708    20    m-rv    12    

Установка подключения к MySQL через ODBC connector

Инструменты администратора БД v8 1cv8.cf Абонемент ($m)

Руководство, облегчающее жизнь при очередной настройке подключения MySQL к 1С через ODBC connector (driver). Оставлю это хотя бы для себя на память :)

1 стартмани

21.07.2017    33449    8    primara    2    

Автоматическое отключение неактивных веб-клиентов

Инструменты администратора БД v8 1cv8.cf Абонемент ($m)

У вас организован доступ в базу через веб-клиент для посторонних лиц (веб-портал, веб-витрина, и т.д.), и вы испытываете проблему нехватки лицензий 1С из-за того, что пользователи оставляют открытыми вкладки с 1С, не работая в них? Есть решение!

1 стартмани

20.07.2017    24944    32    VitaliyCeban    18    

Монитор журнала регистрации Промо

Журнал регистрации Инструменты администратора БД WEB v8 1cv8.cf Абонемент ($m)

Позволяет в режиме реального времени отслеживать активность пользователей, накапливать и оповещать о возникновении ошибок, которые попадают в журнал регистрации

2 стартмани

29.06.2015    47082    159    andy23    51    

COM соединения с базами 1С на различных версиях платформы "Без перерегистрации и СМС"

Инструменты администратора БД v8 1cv8.cf Абонемент ($m)

Описание способа подключения к базам 1С с помощью ComConnector, на различных версиях платформы.

1 стартмани

16.04.2017    126182    376    WizaXxX    73    

Просмотр заблокированных строк в 1С

HighLoad оптимизация v8 1cv8.cf Абонемент ($m)

Ввиду своей деятельности, мне часто приходится рассказывать про различные аспекты оптимизации и в том числе про блокировки. Очень часто слушатели задают следующие вопросы: Как посмотреть в реальном времени, какие именно данные сейчас заблокированы? Как понять, что сейчас заблокировано в терминах 1С? Если гранулярность блокировки страница, как увидеть, какие данные в ней находятся? Раньше приходилось отвечать, что инструмента, который показывает все вышеописанное, сейчас просто нет. Но потом мне это надоело, и я решил сделать собственный инструмент, который позволяет ответить на все вышеописанные вопросы.

1 стартмани

25.10.2016    51665    944    Andreynikus    70    

Блокировка повторного запуска комплексного процесса в 1С: Документооборот 2

Инструменты администратора БД Документооборот и делопроизводство v8 ДО Абонемент ($m)

Острой проблемой при работе документооборота стал повторный запуск комплексного процесса. Пользователи несколько раз  запускали один и тот же комплексный процесс по документу, не убедившись, что этот же процесс уже запущен. В результате наступил хаос, все возмущались и недоумевали, почему один и тот же документ приходил на согласование и исполнение несколько раз. 

2 стартмани

04.10.2016    32412    108    zabaluev    25    

Менеджер удаленных рабочих столов Промо

Инструменты администратора БД v8 1cv8.cf Россия Абонемент ($m)

Запуск удаленного стола из 1С

1 стартмани

11.08.2015    26774    27    spec8s    16    

Настройка регламентных работ на SQL сервере + (сбор данных по работе SQL и т.д)

Инструменты администратора БД v8 Абонемент ($m)

Тема не новая, вариантов найти можно массу. Последнее время появляются статьи с очень подробным описанием, что-то из этого не встречал за всю практику работы с 1С. Фактически эта публикация как памятка основной части 1С-ников, что не имеют глубоких знаний по SQL и 1С. Это готовая инструкция по настройке обслуживания БД на сервере ля большинства мелких и средних компаний\баз. Но бывают случаи поломок баз данных, поэтому приложен материал и для таких случаев, например, восстановление БД после обновления не очень удачного, и некоторые другие плюшки.

1 стартмани

12.09.2016    28069    27    izidakg    19    

Инструменты: v81_82_83: об./упр. формы. Отключение пользователей: файловый, кл-сервер. Запуск/Вход под другим польз-м. Поиск ссылок на объект СКД. Консоль запр. Отладка ВПФ и ОЗТЧ. Гр.печать, Перепровед-е немоноп-е и др.(Один архив)

Поиск данных Инструменты администратора БД v8 v8::УФ v8::СКД 1cv8.cf Россия Абонемент ($m)

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

1 стартмани

06.09.2016    24458    106    Светлый ум    138    

Версионирование объектов. Сжатие регистра "ВерсииОбъектов" Промо

HighLoad оптимизация v8 1cv8.cf Абонемент ($m)

Cжимаем версии объектов в регистре сведений "ВерсииОбъектов". Экономия занимаемого версиями объектов объема более 50% !!!

1 стартмани

30.12.2014    32178    44    ZLENKO    14