Помогите разобраться с оптимизацией производительности работы 1С
Сервер 2 х процессорный Е5-2620v 4. 128 озу всего.
На этом физическом сервере установлен сервер 1с и postgres SQL 10.5-24.1C.
Также в hyper-v поднят терминальный сервер со статическим резервом озу 64 гб и числом виртуальных процессоров 10.
Конфигурация 1С:Управление микрофинансовой организацией и кредитным потребительским кооперативом КОРП, редакция 3.0 (на базе БП 3.0)
Размер базы 1С порядка 50 ГБ
Платформа 1С:Предприятие 8.3 (8.3.13.1644)
Пользователи подключаются к 1С через терминальный сервер (тонкий клиент)
Не устраивает работа 1С, запускается по 5 мин, зависает, долго проводятся документы, формируются отчеты, может просто напрочь зависнуть в режиме бездействия и тд Долго архивируется через postgres...
Не могу понять куда копать... Всю голову сломала...
Тест Гилева показывает 9.33
Картинки с тестом и параметрами ПК прикрепляю + конфиг
конфиг постгри
скидываю строки, которые не по дефолту:
------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------
# - Connection Settings -
listen_addresses = '*' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost'; use '*' for all
# (change requires restart)
port = 5432 # (change requires restart)
max_connections = 500 # (change requires restart)
ssl = off
#wal_level = replica # minimal, replica, or logical
# (change requires restart)
fsync = on # flush data to disk for crash safety
# (turning this off can cause
# unrecoverable data corruption)
synchronous_commit = off # synchronization level;
# off, local, remote_write, remote_apply, or on
wal_sync_method = open_datasync # the default is the first option
# supported by the operating system:
commit_delay = 1000 # range 0-100000, in microseconds
commit_siblings = 5 # range 1-1000
seq_page_cost = 0.1 # measured on an arbitrary scale
random_page_cost = 0.4 # same scale as above
#cpu_tuple_cost = 0.01 # same scale as above
#cpu_index_tuple_cost = 0.005 # same scale as above
cpu_operator_cost = 0.0025 # same scale as above
#parallel_tuple_cost = 0.1 # same scale as above
#parallel_setup_cost = 1000.0 # same scale as above
#min_parallel_table_scan_size = 8MB
#min_parallel_index_scan_size = 512kB
effective_cache_size = 38GB
# - Other Planner Options -
default_statistics_target = 5000 # range 1-10000
constraint_exclusion = partition # on, off, or partition
#cursor_tuple_fraction = 0.1 # range 0.0-1.0
from_collapse_limit = 20
join_collapse_limit = 6 # 1 disables collapsing of explicit
# JOIN clauses
#force_parallel_mode = off
autovacuum = on # Enable autovacuum subprocess? 'on'
# requires track_counts to also be on.
#log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and
# their durations, > 0 logs only
# actions running at least this number
# of milliseconds.
autovacuum_max_workers = 5 # max number of autovacuum subprocesses
# (change requires restart)
autovacuum_naptime = 20s # time between autovacuum runs
#autovacuum_vacuum_threshold = 50 # min number of row updates before
# vacuum
#autovacuum_analyze_threshold = 50 # min number of row updates before
# analyze
#autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum
#autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze
#autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum
# (change requires restart)
#autovacuum_multixact_freeze_max_age = 400000000 # maximum multixact age
# before forced vacuum
# (change requires restart)
#autovacuum_vacuum_cost_delay = 20ms # default vacuum cost delay for
# autovacuum, in milliseconds;
# -1 means use vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for
# autovacuum, -1 means use
# vacuum_cost_limit
Процессоры в контексте 1С очень плохие. Просто ужасные.
Если говорить про 1С, то например, один единственный E3-1280V6 в разы уделает сразу два Е5-2620.
Электропитание хотя бы настроено на высокую производительность?
по диспетчеру задач нагрузка на ЦП от 5 до 20% максимум
Вы оцениваете нагрузку как "сумма загруженности всех ядер" / "сумма мощностей всех ядер". Это неправильно.
У вас показывается процент нагрузки на все потоки обоих процессоров. А в 1С, обычно невозможно "размазать" операцию больше, чем на 2-3 потока.
Соответственно, у вас несколько потоков реально загружены, а остальные простаивают попусту.
У нас, в 1С, быстродействие процессора в первую очередь определяется тактовой частотой процессора, а не количеством ядер.
Если не верите мне, то полистайте результаты тестов Гилёва. Они появляются сразу внизу, как только заканчивается тест. Там вы очень быстро найдёте подтверждение моим словам. Чем больше частота, тем больше попугаев.
Вот тест у одного из клиентов на сравнительно дешёвом E3-1280 V5:
(15) согласна, но на вашем примере файловая база, а у нас клиент-серверная. К сожалению, поменять проц и в целом сервер сейчас нет возможности. Есть ли какие-то мысли как можно оптимизировать работу 1С без замены сервера/процессора?
(26) Действительно. Вот серверная на том же процессоре. Правда, не постгри, а mssql.
Ну а по делу сказать ничего не могу. Думаю, вы и так уже выжали максимум из этого сервера.
29.
a.doroshkevich
152609.08.19 13:22 Сейчас в теме
(26) Юлия, перевод PG на Linux и настройка pg под 1с даст в среднем ускорение работы в 5-10 раз в вашем случае (не путать с результатами тестов Гилева)
вряд ли вы добьетесь большего, плюс минус пару попугаев и значит около 13 всего, что очень мало.
при "hyper-v", "Размер базы 1С порядка 50 ГБ " процессоры НИ О ЧЕМ.
в рамках ликбеза, на простой офисной машине с частотой больше 3.5 поставить сервер 1С + постгри с той же cfg и можете проверить тесты.
сервак на свалку или под апгрейд.
(11) К сожалению, поменять проц и в целом сервер сейчас нет возможности. Есть ли какие-то мысли как можно оптимизировать работу 1С без замены сервера/процессора?
не моё, но согласен...
"Raid контроллер, весьма продвинутый только и сможет управлять тримом.
И такой контроллер в целом бессмысленно делать.
Для системы рейд, отдельный физический диск, внутренняя организация рейда от системы полностью скрыта.
И каждому участнику рейда система не может указать, что же уже не нужно из данных.
На SDD в целом бессмысленно делать классический Rаid. Ни какого плюса он не дает.
Внутри всех SSD и так организован рейд, для распределения нагрузки между микросхемами.
По этому для SSD более эффективна обычная система резервирования, которую и так необходимо сделать, есть ли RAID или нет."
Не перекладывайте свою работу на других. Зачем мне искать информацию, на которую опираетесь вы?
Вот вы погуглите и выложите здесь уже готовое пояснение.
(20)
Я написал 19 сообщение ещё до того, как вы отредактировали 18 и добавили туда эту копипасту.
И уж не знаю, что там автор имел в виду, говоря про "классический" raid. Пропущу эту чепуху мимо ушей.
А так, в в этой статье написано, что RAID-контроллер не нужен для равномерного износа SSD.
Я с этим полностью согласен. Но надо быть круглым дураком, чтобы ждать от RAID-контроллера этого и только этого.
RAID-контроллер в первую очередь придуман для того, чтобы создавать RAID-массивы.
В частности, RAID-1 служит для ускорения чтения и удвоения надёжности. Как раз такой массив и есть у автора.
Что из этих двух вещей не нужно или мешает автору?
Хоть SSD, хоть HDD, хоть floppy.
Если говорить про RAID-1, то выход одного диска из строя не выводит из строя всю систему.
Сервер работает и дальше, давая время спокойно поменять диск. В этом и удвоение надёжности.
Этого, разумеется, не будет без массива.
И ещё кое-что. Чтобы иметь право использовать такой менторный тон ("глупое упрямство", "подумайте), вы должны на 200% разбираться вопросе.
Этого не видно. Даже наоборот, вы демонстрируете то, что в вопросе плаваете.
Не надо заставлять меня гуглить, думать, читать книжки или узнавать у соседей. Просто обосновывайте собственные же слова самостоятельно, иначе ваши слова - фуфло.
давая время спокойно поменять диск. В этом и удвоение надёжности.
Этого, разумеется, не будет без массива.
И ещё кое-что. Чтобы иметь право использовать такой менторный тон ("глупое упрямство", "подумайте), вы должны на 200% разбираться вопросе.
Этого не видно. Даже наоборот, вы демонстрируете то, что в вопросе плаваете.
Не надо заставлять меня гуглить, думать, читать книжки или узнавать у соседей
От этих рейдов один вред, особенно на SSD.
Рейд собирают на специализированных SSD полках и отдельных категорий высокопроизводительных серверов с контроллерами HPE Smart Array P408i-p (2 GB кэш чтение/запись) и выше.
На всяких зиромемори контроллерах - райд собирают для хранения видео.
Вечно эти админы сорбирают г**норейды и мучайся потом. Нахрена систему резервировать, если система не работает $-)
(32)
Давайте отложим вопрос про то, как надо.
Ответьте лучше на вопрос, с которого начался спор и от которого мой грубоватый оппонент старательно уклонялся:
Что плохого в массивах на ssd?
(23), обычно ssd умирают после определенного количества чтения-записи. В случае raid оба диска будут работать одновременно и скорее всего умрут в один день. Поэтому для себя я не вижу смысла в raid на ssd для надежности.
(69) серверные диски - это до ПТБ записей, поэтому даже с базой размером в 1ТБ записать ее придется 1к раз целиком, чтобы добиться износа диска. Но реально пишется может быть 20-30 Гб в сутки, так что это на 50к суток - мы не доживем))))
А что ssd не может умереть физически??? плата там же из радиодеталей или мы чего не знаем??? А программный raid на linux тоже плохо? куда катится мир.....
Для начала
1. Скиньте на стандартные настройки postgres
2. Купите SSD диск Samsung 860 pro. Если у вас хорошие диски переходим к пункту 3.
Настройте ее на ОСь и файл подкачки.
Данные храните на SAS Диске. (Посгри ставите на диск C, данные отдельный нэймспэйс. Тем самым временные и системмные таблы будут работать на SSD.)
3. Убейте это ничтожество Майкрософт Hyper-V. Либо терминалу прям на ту же ОСь ставьте либо осваивайте VmWare. Но с вашим железом смысла нет
4 Приструнить Антивирус
5. Сносите эти все рэйды с SSD - безхорошего аппаратного контроллера - все это во вред.
6. Отключите гипертрейдинг в Биосе.
7. Включите турбобуст в биосе.
8. Настройки питания - максимальная производительность!
Настройками postgres нет смысла играться, если база меньше 100 гигов
У меня на ноуте с i5-8250U файловый тест Гилева показывает 72-81 балл, что говорит о том, что серверный будет показывать в районе 35. При этом стоковая частота проца 1,6 Ггц, а турбо - 3.4 Ггц. Таким образом он коррелирует по однопоточному тесту Гилева с моим Rizen 1600 (84-89 в файловом тесте Гилева).
Что может быть не так?
1. Тест Гилева на графике показывает скорость работы одного процесса, поэтому для него (теста) важна частота.
2. Частота современного процессора имеет две части - обычная и турбо-частота. Если в BIOS не разрешен турбо-буст, то процессор будет работать на низкой частоте и тест Гилева покажет ниочем. Например, если у меня на ноуте выключить турбо-буст, то тест гилева показывает 21 балл. А если выключить схему высокой производительности, но не выключать турбо-буст, то примерно 66. Сам не понимаю, почему так: частота вроде в 2 раза всего, а скорость в три-четыре раза выше. Видимо проц половину времени без турбо-буста висит на частотах ближе к 800 Мгц.
3. Также для 1С важна частота памяти, т.к. все то, с чем оперирует 1С, в кеш процессора точно не влезает.
В итоге простой совет:
1. Включить в BIOS турбо-буст.
2. Включить схему высокой производительности.
Этого уже должно хватить, чтобы получить что-то в районе 30-33 в тесте Гилева на SQL и в районе 70 в файловой базе.
Спасибо добрый человек, но не совсем понимаю почему shared_buffers = 512MB и max_connections = 50 . у нас бывает одновременно до 80 пользователей + фоновые задания
В документации к PostgreSQL пишут, что для Windows это оптимальный вариант.
Количество соединений указывается столько, сколько необходимо для конкретной задачи, с небольшим запасом.
(37) из документации
"Если вы используете выделенный сервер с объёмом ОЗУ 1 ГБ и более, разумным начальным значением shared_buffers будет 25% от объёма памяти. Существуют варианты нагрузки, при которых эффективны будут и ещё большие значения shared_buffers, но так как PostgreSQL использует и кеш операционной системы, выделять для shared_buffers более 40% ОЗУ вряд ли будет полезно. При увеличении shared_buffers обычно требуется соответственно увеличить max_wal_size, чтобы растянуть процесс записи большого объёма новых или изменённых данных на более продолжительное время."
или я не там читаю?
Кроме того, большие значения shared_buffers не так эффективны в Windows. Возможно, вы получите лучшие результаты, если оставите это значение относительно небольшим и будете больше полагаться на кеш операционной системы. Оптимальные значения shared_buffers для Windows обычно лежат в интервале от 64 до 512 мегабайт.
Почему-то из 10-й редакции PostgreSQL это дополнение убрали. Не думаю, что в работе с памятью в Windows что-то существенно поменялось. Хотя может что-то и изменилось...
(39) default_statistics_target = 100 ? везде пишут, что для разгона 1С нужно поставить от 1000 это значение...
random_page_cost = 1.1 аналогично советуют для 1С устанавливать 0,4
41.
a.doroshkevich
152610.08.19 05:48 Сейчас в теме
(40) Основная причина тормозов в вашем случае это ошибка работы с файлом статистики.
Да, pg настроен тоже некорректно во многом, но без решения вопроса со статистикой (переходом на linux) настойка pg будет давать эффект только между полными зависаниями БД.
А после переноса на Linux настройки будут нужны другие, так как там уже и сервера 1С не будет на одной ОС с БД и объемы оперативки поменяются...
42.
a.doroshkevich
152610.08.19 05:53 Сейчас в теме
(40) Отдельно про default_statistics_target = 100
Это нужно тестировать, на разных системах по разному пока себя ведёт эта настройка, где-то становится лучше немного где-то сильно хуже.
Поэтому пока 100 - оптимальный вариант
отключать HyperThreading. - сделали
также рекомендуется отключать Energy Saving, - тоже
Включить в BIOS турбо-буст.
Все это сделали ничего не поменялось
(34)
(54) гипертрейдинг и smt не влияют на скорость в тесте Гилева по крайней мере у меня.
Если бы включили турбо-буст, то в мониторе ресурсов производительность процессора должна скакать от 110% до 150% (2.1 ГГц÷> 3.0 ГГц). Если в мониторе ресурсов производительностт ниже 100%, то турбобуст не работает.
Если это какая-то старая венда, то она может просто не понимать, что у процессора есть s-state выше 100% производительности - тот самый турбо-буст.
(61) сисадмин может пипипи все что угодно. Заходите в монитор ресурсов и видите, что производительность выше 100%. Если этого нет, то сисадмина на кол.
Почему вы решили что у вас проблема именно в PostgreSQL? С учётом того что вы написали что средняя загрузка сервера находится 5-20%, то у вас происходит "затык" в каком-то другом месте. Что показывает мониторинг производительности?
p.s. А так как у вас 128Гб памяти, то вся ваша база 50Гб легко помещается в ОЗУ и вопросы производительности PGSQL вторичны. Что-то другое вам мешает. Без доступа к системе сложно сделать диагностику. Повторюсь - вам нужно мониторить дисковый обмен, сетевую нагрузку.
Пользователи терминального сервера работают через RemoteDesktop или RemoteApp?
(46) тогда тем более (я уже подумал что на 80 сотрудников выделяются полноценные сессии с рабочим столом и тогда можно было бы предположить нехватку памяти для терминального сервера). Вы не ответили - почему вы считаете что причина в SQL-сервере?
Может быть раньше стоял MSSQL и проблем не было?
Когда начались проблемы? (замена SQL, апргейд софта/железа)
(47) до этого жили на виртуальном сервере работали через веб клиент стоял postgres - конфигурация была другая совсем и win сервер 2012. Купили свой сервер как переехали так и начались проблемы. Я ищу причину со своей стороны (1С) одновременно сисадмин смотрит со своей стороны
(52) При переезде изменилась версия PGSQL? Версия платформы 1С?
Почему решили не использовать конфигурацию постгреса установленного на виртуальном сервере?
Насколько стабильна(повторяема) ситуация с низкой производительностью? Бывают ли моменты когда производительность вырастает сама по себе и всё работает без замечаний? Появляется ли в логах pgsql сообщения об ошибках/предупреждениях?
(57) версия та же, постоянные зависания особенно в пики активности пользователей, производительность не вырастает, логи - 1 раз ошибка со статистикой, про размер wal, но я увеличила, ежедневные - checkpoints are occurring too frequently (26 seconds apart), logical replication launcher (PID 4724) exited with exit code 1, canceling statement due to user request, there is no transaction in progress
(62) checkpoints - это не ошибка, это "совет" от сервера, что стоит увеличить время, так запись в файл происходит чаще. После изменения параметров wal - это сообщение стало реже появляться?
canceling statement ... - это тоже не ошибка, просто пользовательский сеанс отвалился и запрос не отработал полностью. Для вашей распределенной структуры пользователей это нормально.
У вас постгрес работает в "одиночестве" или есть второй сервер, на который отправляются реплики для дублирования? Если он единственный параметр wal_level можно установить minimal, а max_wal_senders установить в 0.
Далее - есть ли второй/резервный сервер на котором можно проводить эксперименты по настройке и проверке? Или вы всё вживую на единственном сервере делаете? Будет неправильно давать какие-то советы без качественной диагностики. Единственное что я могу предложить - это при наличие свободных ресурсов на сервере - поднять виртуальную машину и там развернуть PostgresPro Standard (ознакомительную версию):
http://repo.postgrespro.ru/pgpro-11/win/PostgresPro_11.5.1_64bit_Setup.exe и на этом тестовом сервере развернуть копию базы и проверять разные настройки постгреса не мешая работе остальных пользователей.
(63) это вам предлагают сделать ВПН от каждого клиента до сервера. Не слушайте)) - вариант с ремотеапп самый подходящий для вас, ещё можно через веб-доступ сделать, но там тоже есть свои подводные камни.
p.s. Если нужна помощь в удаленной диагностике и настройке то можете обратиться через л/с, для обсуждения деталей.
"После изменения параметров wal - это сообщение стало реже появляться? " - кол-во секунд через которые происходит чекпоинт поменялось стало 26. Сервер один, а почему советуете PostgresPro Standard?
у нас уже был и веб и впн не удобно обслуживать такое кол-во ПК в плане обновления платформы и пр. проблем с впн например. Кстати, сама работаю через впн и рдп - впн периодически меня выкидывает)))
(58) а как? Территориально в разных городах работаем все пользователи. Я работаю через рдп прямо на сервере, но я в основном вечером и работа связана с конфигурированием...
Ну тогда может вам показалось, про ускорение. Пока не будет стоять режим совместимости 8.3.15, многие плюшки не заработают.
Скорость должна быть в районе 14 платформы.