26 ноября 2020, 11:52

Цитата дня:

UNIX прост. Но надо быть гением, чтобы понять его простоту. Деннис Ритчи


1c 8.3 + MS SQL + другие базы

Автор Oleg_Sviridov, 23 июля 2019, 22:37

« предыдущая тема - следующая тема »

0 Пользователей и 1 Гость просматривают эту тему.

Вниз

Oleg_Sviridov

23 июля 2019, 22:37 Последнее редактирование: 23 июля 2019, 22:50 от Oleg_Sviridov
добрый день.
Вопрос в целом не только про 1с. Подняли систему виртуализации Vmware на которой в числе прочих должны будут работать:

1.MS SQL сервер

И на нем:

- Базы 1с 8.3:
  Бухгалтерия (~4Гб, 4 пользователя), 7 баз складов (по 2-3 Гб каждая и по 1-2 пользователя в каждой), ЗиК (~5-6Гб, 7 пользователей). Точно сейчас размер баз не скажешь, все это пока работает на 1с7.7 файловой и будет переноситься).

- База ERP (пока 2Гб, 30 пользователей)

- База конструкторского документооборота (размер и нагрузку пока определить сложно, пользователей тоже под 30) + сам сервер

- Плюс еще одна база, ее задача в основном собирать данные в SQL и выдавать данные и аналитику (3 базы по 5-6 Гб.) Пользователи ее как таковые к ней 1-2 человека + сам сервер

Я понимаю что этой информации в целом недостаточно. Вопрос как это все лучше по виртуалкам распределить? 

1. Сделать одну виртуалку SQL сервера и все базы вешать на него, а сами сервера 1с, ERP и аналитики по отдельным виртуалкам?
Тут уйдет лицензия на один SQL standart + лицензии на каждую ОС серверов.
Ну сервер 1с расположу на одной ноде с SQL (на одном vswitch) чтобы было что то близкое к shared memory.  Остальные как получится.

2. Лицензировать под 1с свой SQL (или покупать их вместе) и ставить их на одну виртуалку. Пускай живут вместе + настоящий shared memory. От многих слышу что 1с не любит делить ресурсы SQL своих баз с другими. 
Покупаем еще один SQL и на него вешаем остальное - ERP + аналитику. Тут траты на два SQL.

Все идет к тому что в будущем надо будет корячить SRM систему, но это пока не определено. ПО кол-ву сотрудиков, работающих в базах, примерно везде вот такие цифры ~20-40 человек.

Как лучше поступить, кто что посоветует?



Oleg_Sviridov

забыл указать, в 1с планируется использовать для удаленщиков-кладовщиков web клиент

Уваров А.С.

Лицензировать под 1с свой SQL (или покупать их вместе) и ставить их на одну виртуалку. Пускай живут вместе + настоящий shared memory.
Именно так и делать. Берете  MS SQL Server Standard 2016 Runtime для пользователей 1С:Предприятие 8 и ставите вместе с 1С - получаете самую высокую производительность в этой связке.

От многих слышу что 1с не любит делить ресурсы SQL своих баз с другими.  
Оперативки выделить достаточно - и проблем не будет. Ну и не забыть ограничить аппетиты SQL-сервера.

Тут траты на два SQL
Стоимость MS SQL Server Standard 2016 Runtime - это копейки, куда дороже обойдутся лицензии клиентского доступа на SQL, которые требуются на каждое рабочее место вместе с клиентскими лицензиями 1С.


Уваров А.С.

забыл указать, в 1с планируется использовать для удаленщиков-кладовщиков web клиент
Веб-клиент в отдельную виртуалку.

Oleg_Sviridov

спасибо за ответы!

MS SQL Server Standard 2016 Runtime это какая то особая редакция?

Веб-клиент в отдельную виртуалку.
Учитывая кол-во пользователей через web обязательно отдельную виртуалку на одной системе с сервером и SQL не уживутся?  Обязательно серверную ОС использовать?

Уваров А.С.

MS SQL Server Standard 2016 Runtime это какая то особая редакция?
Это обычная редакция, которая ограничена только использованием исключительно совместно с 1С, любое другое использование будет считаться нарушением лицензии. Продается самой фирмой 1С, клиентские лицензии тоже специальные, с ограничением по использованию.


Учитывая кол-во пользователей через web обязательно отдельную виртуалку?  На одной системе с сервером и SQL не уживутся?  Обязательно серверную ОС использовать?
Мы обычно ставим Debian + Apache. Основная проблема в том, что при подключении через веб-клиент выделяется начиная от 1 ГБ на сеанс, которые не освобождаются по окончании сеанса (точнее сохраняется сам сеанс) в течении 20 минут, на случай повторного подключений клиента. Если в сеансе запускали что-то тяжелое - то памяти уйдет больше.

И еще - берите сразу сервер 1С на 64-бита, в последнее время даже в не очень больших базах ЗуП при формировании тяжелых отчетов сервер x32 может вылететь с нехваткой памяти. А с сентября, с отделением КОРП платформы будет практически невозможно нормально настроить количество баз и сеансов на рабочий процесс - что тоже будет приводить к нехватке памяти.

Oleg_Sviridov

#6
24 июля 2019, 10:17 Последнее редактирование: 24 июля 2019, 10:19 от Oleg_Sviridov
Это обычная редакция, которая ограничена только использованием исключительно совместно с 1С, любое другое использование будет считаться нарушением лицензии. Продается самой фирмой 1С, клиентские лицензии тоже специальные, с ограничением по использованию.
понял
Мы обычно ставим Debian + Apache. Основная проблема в том, что при подключении через веб-клиент выделяется начиная от 1 ГБ на сеанс, которые не освобождаются по окончании сеанса (точнее сохраняется сам сеанс) в течении 20 минут, на случай повторного подключений клиента. Если в сеансе запускали что-то тяжелое - то памяти уйдет больше.
От 1Гб оперативки на каждое подключение. Не хило...
Debian + Apache я думаю мне с ходу не осилить, нет опыта.
Тогда может заменить терминалом + remoteapp?

Уваров А.С.

А что там осиливать, поставить Дебиан, поставить Апач, настраивать ничего не надо. Поставить пакет веб-клиента 1С с зависимостями и опубликовать базу. Наружу высунуть 80 или 443 (лучше добавить SSL).

А на терминал надо лицензии, плюс замороки с принтерами, торговым оборудованием и т.д. и т.п.

Oleg_Sviridov

А что там осиливать, поставить Дебиан, поставить Апач, настраивать ничего не надо. Поставить пакет веб-клиента 1С с зависимостями и опубликовать базу. Наружу высунуть 80 или 443 (лучше добавить SSL).

А на терминал надо лицензии, плюс замороки с принтерами, торговым оборудованием и т.д. и т.п.
терминальный сервер уже есть. Доступ к 1с планирую через vpn. Выставлять все это наружу как то не очень.
Где-то на ифонстарте видел ваш комментарий что вполне себе успешно работает тонкий клиент через vpn.
Если это так то и все остальное городить нет смыла?

 
Веб-клиент в отдельную виртуалку.
имелся ввиду "веб-сервер" ?

Уваров А.С.

Где-то на ифонстарте видел ваш комментарий что вполне себе успешно работает тонкий клиент через vpn.
Если это так то и все остальное городить нет смыла?
Вполне себе работает. Даже через мобильный интернет, там есть специальная опция запуска - медленное соединение. Но для этого нужен доступ именно к серверу: 1540, 1540, 1560-1599 порты. Через веб-сервер можно работать тем же тонким клиентом, но через порт 80/443.

имелся ввиду "веб-сервер" ?
В данном случае имелась ввиду компонента 1С, которая работает в связке с сервером, для базы и сервера 1С она выступает именно клиентом.

Т.е. клиент (браузер или тонкий клиент) соединяются с веб-сервером, веб-сервер обращается к компоненте 1С (веб-клиенту), который уже создает соединение с базой и обрабатывает полученные данные.

ival

Я расскажу своё видение. Лучше брать полноценный sql с лицензированием на пользователей. Учитывая что у вас часть баз ( аналитика и crm) не будут иметь отношение к 1с, то runtime бессмысленно. Ставить лучше две машины одна 1с+IIS вторая чиста для sql. При использовании виртуального коммутатора скорость доступа будет приближена к shared memory. По поводу того что 1с базы конкурируют с другими, это не так. Просто 1с написана так что она не может нормально работать с sql, треть запросов уходят по такому плану запроса что вызывают ожидания и жрут потоки. С этим приходится мириться. Вопрос по аналитике это отдельная история, обычно аналитические базы достаточно большого размера, например у нас это 200 гб. Тут надо понимать опять же, в принципе такая база может спокойно жить с базами 1с при нескольких условиях: серверу хватает памяти и потоков, у сервера правильно организованна дисковая система и база аналитики разделена на несколько файлов по принципу (горячие и холодные данные) и разнесена по дискам (горячие на быстрых, холодные на медленных)

Oleg_Sviridov

Я расскажу своё видение. Лучше брать полноценный sql с лицензированием на пользователей. Учитывая что у вас часть баз ( аналитика и crm) не будут иметь отношение к 1с, то runtime бессмысленно.
Спасибо. Я тоже думаю что лучше купить полноценный SQL. Тем более что на runtime ничего кроме 1с запустить нельзя и CAL`ы у него тоже "свои". Вопрос пока только покупать ли для 1с отдельный SQL и ставить все компоненты на одну виртуалку.

Ставить лучше две машины одна 1с+IIS вторая чиста для sql. При использовании виртуального коммутатора скорость доступа будет приближена к shared memory. По поводу того что 1с базы конкурируют с другими, это не так. Просто 1с написана так что она не может нормально работать с sql, треть запросов уходят по такому плану запроса что вызывают ожидания и жрут потоки. С этим приходится мириться.
Я опасаюсь использовать для всех баз один SQL сервер как раз из-за такой работы 1с с ним.  Не приведёт ли это к тормозам в работе с остальными базами?

Ставить лучше две машины одна 1с+IIS вторая чиста для sql.
Если как писали выше  тонкий клиент нормально работает через VPN надо ли городить web доступ? Ну и учитывая то что доступ будет только через VPN.

Вопрос по аналитике это отдельная история, обычно аналитические базы достаточно большого размера, например у нас это 200 гб.
это не та аналитика. Софтина пишет круглосуточно параметры работы станков ЧПУ. Потом по запросу выдает статистику их работы, простои и т.п. Сейчас все это успешно работает на i5-4460/8Gb, SQL server express. При этом занято 4,5Gb памяти и процессор только при запросах к ней загружается на 15-20%.

Тут надо понимать опять же, в принципе такая база может спокойно жить с базами 1с при нескольких условиях: серверу хватает памяти и потоков, у сервера правильно организованна дисковая система и база аналитики разделена на несколько файлов по принципу (горячие и холодные данные) и разнесена по дискам (горячие на быстрых, холодные на медленных)
работать SQL будет на ноде с процами gold 5122/128Gb и ssd системой хранения.

Oleg_Sviridov

здравствуйте, уважаемые Уваров А.С. и Ival   ;)
после всех согласований и покупок наконец подошли к стадии установки.

У нас ожидается 30 пользователей. Базы УТ, ЗИК, Бухгалтерия. Все базы сейчас от 4 до 6 Гб размером.
Планирую что этот экземпляр MS SQL будет обслуживать только базы 1с. Не хочу складывать все в одну корзину. Платформа 1с8 последней версии.

Варианты такие:
1. поставить SQL 2017 + Сервер1с на одну виртуалку,  WEB сервер - на отдельную. Получаем shared memory.
2. как выше советовал Ival - SQL на отдельной, а Сервер1с и WEB сервер - на отдельной. Связь через виртуальный коммутатор.

Второе, 6 из 30 юзеров - удаленщики, только через VPN.

1. Так ли необходимо городить SSL на WEB  ?
2. Что лучше использовать в качестве web сервера под windows?  apache или IIS ?
3. Актуальна ли эта статья https://interface31.ru/tech_it/2015/05/nastraivaem-web-dostup-dlya-1c-v-faylovom-rezhime.html   в качестве руководства по настройке? По крайней мере про SSL там ничего.


Уваров А.С.

Я бы сделал две виртуалки для 1С и SQL, через виртуальный коммутатор скорость будет близка к shared memory, но будет возможность более гибко управлять разделением ресурсов.

Если нужен веб-доступ - то делаем отдельную виртуалку или контейнер с Linux + Apache: быстро, дешево и сердито. Ресурсов почти не жрет, если это не файловый режим, главное - обеспечить потребность в оперативке, что легко обеспечить динамической памятью.

SSL нужен всегда, если доступ выходит за рамки доверенных сетей.

В Windows - IIS, в Linux - Apache.

По настройке веб-доступа: https://interface31.ru/tech_it/2019/10/publikaciya-baz-dannyh-1spredpriyatie-83-na-veb-servere-apache-v-debian-ili-ubuntu.html

По настройке SSL смотрите здесь: https://interface31.ru/tech_it/2019/10/publikaciya-baz-dannyh-1spredpriyatie-83-na-veb-servere-apache-v-debian-ili-ubuntu.html

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

Поэтому более правильно будет использовать для внешних пользователей обратный прокси на NGINX, на котором уже поднять SSL. Кроме того это поможет решить вопрос одного внешнего порта 80/443 и нескольких веб-сервисов, которые может потребоваться опубликовать.

Oleg_Sviridov

Если нужен веб-доступ - то делаем отдельную виртуалку или контейнер с Linux + Apache: быстро, дешево и сердито. Ресурсов почти не жрет, если это не файловый режим, главное - обеспечить потребность в оперативке, что легко обеспечить динамической памятью.

ну как нужен... Надо подключать VPNщиков. Только терминал остается иначе.
Можно им поставить тонкий клиент, но как его потом обновлять у людей с ноутами черт знает где?
Да и тонкий клиент тоже публикуется через WEB. А прямая работа через него через VPN на мой взгляд не надежна, VPN все таки падает иногда, что будет при этом с клиентом и базой?

Еще третью виртуалку городить под WEB?  :-[


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


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

да общем в FQDN не вижу особой проблемы. А изнутри сети web доступ не нужен.


Уваров А.С.

Еще третью виртуалку городить под WEB?
А в чем проблема? Наоборот, сегодняшние технологии позволяют разнести сервисы по собственным системам максимально развязав их друг от друга.

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

А прямая работа через него через VPN на мой взгляд не надежна, VPN все таки падает иногда, что будет при этом с клиентом и базой?
Ничего не будет, пропадет то, что не успели сохранить. В рамках модели 1С клиент с данными в базе не работает, только сервер. На клиенте хранятся только данные форм и то, что пользователь успел туда ввести.

Оптимальный вариант для удаленщиков - это тонкий клиент через веб-сервер. При наличии SSL и нормальных паролей даже VPN не нужен, во всяком случае сама 1С в своем Фреш держит базы наружу просто через SSL.


ival

Я как и писал выше за вариант номер 2, отдельно sql отдельно 1с. По web'y я за iis на машине с 1с, но это только из-за того, что слинуксом я на ВЫ. Если у Вас таких проблем нет, то правильнее наверное как предложил Уваров - nginx+Apache. Публиковать на ружу 1с, ну не знаю, я бы не стал, но я старовер и не люблю публиковать что-то на ружу, если что-то нужно с внешки - есть vpn.

Уваров А.С.

По web'y я за iis на машине с 1с, но это только из-за того, что с линуксом я на ВЫ.
Там нет вообще ничего страшного, достаточно просто поставить пакеты, никаких настроек по факту не надо. Плюс Apache прост и надежен как табуретка, легко настраивается и диагностируется. IIS, конечно, тоже работает, но местами он подобен черному ящику, где не понятно что он делает, зачем и почему.

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

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

Oleg_Sviridov

обратный прокси у нас есть на шлюзе, не используем. Надо только к нему валидный сертификат прикрутить.
А если использовать Apache на windows вместо IIS ?

А вообще demo версия web интерфейса базы у них на сайте http://demo.1c.ru/ выглядит не плохо.

Уваров А.С.

обратный прокси у нас есть на шлюзе, не используем. Надо только к нему валидный сертификат прикрутить.
А если использовать Apache на windows вместо IIS ?
Апач на Windows ведет себя, на мой взгляд, не очень, хотя работает. И какой смысл?

А вообще demo версия web интерфейса базы у них на сайте http://demo.1c.ru/ выглядит не плохо.
Веб-интерфейс 1С полностью повторяет интерфейс настольного клиента.

Oleg_Sviridov

#20
23 декабря 2019, 22:11 Последнее редактирование: 23 декабря 2019, 22:14 от Oleg_Sviridov
доброго дня.
Развернул SQL server 2016 и сервер 1с х64 (8.3.16.1063) каждый на своей виртуалке windows server 2016.

Базы на SQL пока не в работе. Есть пустые конфигурации, есть с перенесенными остатками из 1с 7.7. Конфигурации типовые, ничего не меняно. Отключил C1E и прочие режиме у процов ноды. Тест Гилева выдает 33 попугая.

Но, сейчас при старте что толстого что тонкого базы процесс rphost даже при запуске одного клиента грузит процессор виртуалки на 30-55%. При чем загрузка эта волнами именно при старте базы или при переходе по меню. Если ничего не делать - нагрузка около 0.

Полный старт базы занимает секунд 15-18. Затыки при первом открытии пунктов меню.

Это нормально так у 1с или я что-то не допилил?




Уваров А.С.

Тест Гилева выдает 33 попугая.
Ну это нормально.

Но, сейчас при старте что толстого что тонкого базы процесс rphost даже при запуске одного клиента грузит процессор виртуалки на 30-55%. При чем загрузка эта волнами именно при старте базы или при переходе по меню. Если ничего не делать - нагрузка около 0.

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

Это нормально так у 1с или я что-то не допилил?
Трудно сказать не зная размер баз и количество записей в базах.

ival

Вообще сам rphost для меня не особо понятно работает, то жрет проц без нагрузки на 40%, то под нагрузкой выдает 5-10%

Самое простое и понятное для меня начать со стороны MS SQL. Смотрите permon стандартные параметры:

На сервере 1с:
общая загрузка ЦП
загрука ЦП по ядрам

На сервере MS SQL
общая загрузка ЦП
загрука ЦП по ядрам
дисковая очередь
параметры MS SQL
SQL Statistics\Batch Requests/sec
SQL Statistics\SQL Compilations/sec
Memory Manager\Memory Grants Pending
Buffer Manager\Page life expectancy
SQL Statistics\SQL re-Compilations/sec

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

Уваров А.С.

#23
24 декабря 2019, 17:36 Последнее редактирование: 24 декабря 2019, 17:45 от Уваров А.С.
Вообще сам rphost для меня не особо понятно работает, то жрет проц без нагрузки на 40%, то под нагрузкой выдает 5-10%
Просто сервер 1С выполняет не только явные пользовательские запросы, но и фоновые и регламентные задания, это хорошо видно если открыть консоль управления сервером 1С и посмотреть текущие сеансы.

Смотрите permon стандартные параметры:

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

Oleg_Sviridov

#24
24 декабря 2019, 22:00 Последнее редактирование: 24 декабря 2019, 22:06 от Oleg_Sviridov
добавил виртуалке с 1с сервервером еще 2 vCPU. Стало 4 вместо двух. Загрузка проца снизилась до 20-25% и также рывками при запуске и при переходе по меню.
Процы в ноде intel gold 5122, 4-ех ядерные.

Да, постоянная загрузка проца rphost`ом это явно регламентные задания. Я их поотключал у всех баз.

Базы с перенесенными остатками по 400Мб весом.
Ни память, ни процессор на виртуалке SQL ничем не нагружены особо во время работы. Диски виртуалок лежат на SSD хранилище. 

Подскажите, лицензия ПРОФ сильно хуже в плане если удаленщики работают в 1с с базой через тонкого клиента? 
Тем что им клиентов тоже надо обновлять, а также обновлять клиентов в локалке.
Юзеров в базе около 30. 

Уваров А.С.

добавил виртуалке с 1с сервервером еще 2 vCPU. Стало 4 вместо двух. Загрузка проца снизилась до 20-25% и также рывками при запуске и при переходе по меню
Это только видимость. 2 ядра, одно загружено на 100%, общая загрузка 50%, 4 ядра, загружено также одно - но общая уже 25%.

Да, постоянная загрузка проца rphost`ом это явно регламентные задания. Я их поотключал у всех баз.
Это вы зря. Выключать их не нужно, а вот настроить грамотно расписание - самое то. Почитайте здесь: https://interface31.ru/tech_it/2016/04/pochemu-tormozit-1s-reglamentnye-zadaniya.html

Подскажите, лицензия ПРОФ сильно хуже в плане если удаленщики работают в 1с с базой через тонкого клиента? 
Она не лучше и не хуже, а объективная реальность с которой нам предстоит жить. Просто если вы решите купить КОРП на 30 пользователей - вас не поймут.

В локалке нет проблем, если есть домен - то через AD, если нет, то через "административную установку": https://interface31.ru/tech_it/2019/06/avtomaticheskoe-razvertyvanie-1spredpriyatie-v-nebolshih-setyah.html

У нас в одной сети из 6 магазинов такая схема работает через VPN, каналы везде достаточно широкие и установка новой версии занимает не более 10-15 минут. Персонал предупреждается об обновлении и запускает 1С сразу по приходу на работу.

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

В принципе подобная схема применима и к удаленщикам.

ival

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

Это только видимость. 2 ядра, одно загружено на 100%, общая загрузка 50%, 4 ядра, загружено также одно - но общая уже 25%.
Загрузка одного ядра, а простой остальных будет как раз свидетельствовать о проблемах которые нужно решать. Вот пример скриншота (прикреплен) с сервера 1с. Если на нем проблемы? Как по мне то нет. Загрузка по ВП ложится относительно ровным фоном и распределяется примерно одинаково между всеми службами и процессами системы. И тут не играет роли что 1с забирает только один ВП. Вот если было бы одно ядро в космосе а все остальные 5-10 % то это означало бы только то, что системе и сторонним службам ресурсов за глаза, а 1с не хватает, то есть получалось бы что 1с забирало бы ресурсов больше чем вся система, что в свою очередь являлось бы показателем проблем в производительности именно на стороне сервиса 1с.


Уваров А.С.

#27
25 декабря 2019, 11:42 Последнее редактирование: 25 декабря 2019, 11:59 от Уваров А.С.
Загрузка одного ядра, а простой остальных будет как раз свидетельствовать о проблемах которые нужно решать.
Абсолютно нет. Если у нас сидит 10 менеджеров и каждый из них вбивает накладные, то небольшая нагрузка равномерно размажется по ядрам. Но если кто-то запустит закрытие месяца и в его рамках восстановление последовательности - то будет высокая загрузка одного ядра, так как восстановление месяца - задача однопоточная и это абсолютно нормальная ситуация.

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

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

В этом плане показательно запустить тест Гилева (он как раз однопоточный)  и посмотреть характер нагрузки на процессор внутри виртуальной машины и на гипревизоре. Это как раз будет эталон тяжелых операций.

Еще раз повторюсь, что это не архитектурная проблема 1С и не техническая, это методические ограничения, ряд учетных операций и их достаточно много можно выполнять только однопоточно в строгой последовательности.

то это означало бы только то, что системе и сторонним службам ресурсов за глаза, а 1с не хватает, то есть получалось бы что 1с забирало бы ресурсов больше чем вся система, что в свою очередь являлось бы показателем проблем в производительности именно на стороне сервиса 1с.
Либо покажет ситуацию с неправильным подбором железа. Еще раз ситуация выше - вбивают накладные - ресурсов всем хватает, нагрузка 10-15% равномерно размазанная. Тут главбух Марья Ивановна начинает закрывать год и на восстановлении последовательности одно ядро уходит на 2 часа в 100%. Проблемы в производительности? Да? На стороне 1С? Нет.

Это типичная ситуация когда возникает недопонимание между 1Сниками и "классическими" админами, которая порождает множество конфликтов. Потому как с точки зрения последних с железом все ОК и проблема на стороне сервиса 1С. Первые же будут утверждать, что железо никуда не годится и в качестве аргумента будут приводить количество попугаев по Гилеву.

И крайними в этой ситуации окажутся именно классические админы. Потому как когда Марья Ивановна придет к шефу и скажет, что работать невозможно, месяц по часу закрывается, то сразу дернут админов, те покажут графики и скажут, что проблема на стороне 1С, дернут 1Сника, то скажет, что конфигурация типовая. И приплыли...

ival

#28
25 декабря 2019, 14:51 Последнее редактирование: 25 декабря 2019, 15:08 от ival
Но если кто-то запустит закрытие месяца и в его рамках восстановление последовательности - то будет высокая загрузка одного ядра, так как восстановление месяца - задача однопоточная и это абсолютно нормальная ситуация.
Сриншот ниже. Запущена операция закрытия месяца. Как видно из скриншота, при увеличилась нагрузка на один ВП свободные ВП сразу отреагировали на это. При этом падения по этим трем ВП будут только тогда когда разгрузится первый ВП по окончании операции. Я не говорю что они всегда будут идти в ровень с первым ВП, но 70% времени ОС будет пытаться разгрузить занятое ядро максимально, снимая нагрузку которую можно снять.

И тут же мгновенно отреагировали ВП SQL на операцию, а через какое-то время и диски когда данные начали писаться (хотя тут может и не из-за этого, я не знаю что происходит при закрытии писятся, пишется ли большой объем в ldf и mdf или нет)


Oleg_Sviridov

Сриншот ниже. Запущена операция закрытия месяца. Как видно из скриншота, при увеличилась нагрузка на один ВП свободные ВП сразу отреагировали на это. При этом падения по этим трем ВП будут только тогда когда разгрузится первый ВП по окончании операции. Я не говорю что они всегда будут идти в ровень с первым ВП, но 70% времени ОС будет пытаться разгрузить занятое ядро максимально, снимая нагрузку которую можно снять.

И тут же мгновенно отреагировали ВП SQL на операцию, а через какое-то время и диски когда данные начали писаться (хотя тут может и не из-за этого, я не знаю что происходит при закрытии писятся, пишется ли большой объем в ldf и mdf или нет)
это у вас на какой винде стоит 1с сервер и какая версия платформы?

ival

это у вас на какой винде стоит 1с сервер и какая версия платформы?
2016 и 8.3.13.1513

Вверх