Korolev Leonid

108
Рейтинг

leonidkorolev



  •   Регистрация: 22.08.2012 (11 лет назад)

  •   Был(а) на сайте: 13.05.2024

Друзья
  • Стас Стас
  • O_L_E_G
  • Алексей Плотников
Подписчики 6
Группы

Профессиональный разработчик

IE 2012 Online

Рейтинг 108

Упрощенное производство в ERP 2.0 на пальцах. Часть 2. (ОПР)
+28 –

Статья Бухгалтер Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бухгалтерский учет Windows Бесплатно (free) Нет файла Производство готовой продукции (работ, услуг)

Данная статья является продолжением статьи: Упрощенное производство в ERP 2.0 на пальцах (http://infostart.ru/public/384762/). Это будет усложнение ранее продемонстрированного пример. В данном примере попробуем добавить общепроизводственные затраты (далее ОПР).

08.08.2015    47806    leonidkorolev    8       

28

Упрощенное производство в 1C:ERP 2.0 на пальцах
+80 –

Статья Бухгалтер Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бухгалтерский учет Windows Бесплатно (free) Нет файла Производство готовой продукции (работ, услуг)

Под упрощенным производством в 1C:ERP 2.0 (далее ERP) я подразумеваю полный цикл производства без использования какого-либо планирования и заказов. Т.е. это производственный учет как бы глазами бухгалтера, только факт и никаких заказов, и планов. Данная статья главным образом ориентирована для бухгалтеров или консультантов, которым необходимо получить общее представление о реализации упрощенного учета в ERP.

30.07.2015    42029    leonidkorolev    24       

80
Смотреть все

Комментарии

HighLoad › Долгий запуск базы Бухгалтерии 3 и ЗУП 3 › #54 06.03.24 9:56
У меня тоже запуск первой базы долго происходит, затем остальные быстро запускаются. Платформа 8.3.23.2040. При первом запуске сильно грузит ресурсы сервер 1С. Как будто сервер грузить конфигурацию в кэш для дальнейшего использования. Если учитывать что в базе всегда кто-то есть, то приняли для себя что ничего страшного.
Учет › 1С-ЭДО: внутренний и внешний документооборот в типовых учетных решениях 1С › #2 18.05.23 9:50
С юридической точки зрения этот внутренний ЭДО имеет какую-то силу? Вроде должен быть сторонний сертефицированный удостоверяющий центр? А то мы ведь у себя в базе что захотим то и сделаем.
HighLoad › В консоли показывает утечку памяти, при этом в диспетчере всё ровно › #3 28.12.22 11:56
(2)
"Уверены, что это прям утечка?"
Не правильно выразился. Консоль показывает большое потребление памяти, а диспетчер не показывает большое потребление памяти.

"Сколько серверу памяти выделено?"
Вся память. Он никак не ограничен.

"shared memory включен?"
Да, на SQL сервере включено, и в настройках базы lpc:

"Какая-то проблема возникает, или просто число большое, страшно?"
Ну страшновато. Такие дурные цифры на проде. И есть ощущение что фоновые задания тормозят.

"Порядка 1 млрд в консоле там число видел на фоновом задании"
Т.е. это такой типичный глюк консоли. Не обращать внимание?
HighLoad › В консоли показывает утечку памяти, при этом в диспетчере всё ровно › #1 28.12.22 10:18
На скрине видно что показатели по памяти в консоли не соотв. показателям в диспетчере.
Что это? Ктонить сталкивался?

Прикрепленные файлы:

Память.png
HighLoad › Оптимизатор стабильно ошибается в подсчете строк и подставляет непонятные предикаты › #3 30.11.22 13:33
Вроде разобрался. Проблему локализовал. Теперь буду думать как дальше жить с этим.
Ноги растут отсюда
http://www.queryprocessor.ru/rowgoal-on-non-uniform-distribution/
HighLoad › Оптимизатор стабильно ошибается в подсчете строк и подставляет непонятные предикаты › #1 30.11.22 11:13
На сколько я понял, из-за этого Index Seek запрос тормозит.
Что это за соединение Nested Loops c константами? Где эти константы посмотреть.
Не могу найти их фактические значения. В Computer Scalar в поле Defined values пусто.

У меня только один предикат на меньше. А больше оптимизатор сам поставил. Почему и зачем?

Статистика свежая. Есть индекс по предикату. Оптимизатор должен чётко подсчитать количество строк.
Но сильно ошибается. Там действительно примерно 82000 строк.

Чем отличается Estimated rows от Estimated rows to be Read.

В Estimated rows to be Read более правильно значение. И если бы он так подсчитал, то скорей всего был бы другой план и соотв. не тормозил.

Прикрепленные файлы:

Screenshot_1.png
HighLoad › При соединении hash match сильно ошибается в оценке › #11 30.11.22 9:39
Вообщем это было соединение со срезом последних. Вынес в отдельную временную таблицу срез последних и проблема решилась но осталось для меня загадкой. Думаю оптимизатор не смог просчитать. Как подсказали выше у меня старый оптимизатор.
HighLoad › При соединении hash match сильно ошибается в оценке › #10 30.11.22 9:36
(7) На рабочей не буду менять. А на копии генерится другой план (там другое окружение. Железо, ПО и т.д.) и без повышения уровня. Вообщем этот запрос остался для меня очередной загадкой.
HighLoad › При соединении hash match сильно ошибается в оценке › #9 30.11.22 9:33
(8) Статистика свежая. Делается с fullscan.
Выполняется вот так каждый день
Код
...
set @command = N'update statistics ' + @s2 + ' with fullscan , maxdop = 64 ';
print @command
exec(@command);
...
HighLoad › При соединении hash match сильно ошибается в оценке › #6 21.11.22 17:52
(5) SQL Server 2008 (100)