Улучшение пооперационного планирования в 1С:ERP 2.4 внешними средствами

Публикация № 1203840

Администрирование - Производительность и оптимизация (HighLoad)

Задача построения оптимального производственного расписания требует сравнения тысяч и десятков тысяч вариантов. Выполнять такие вычисления средствами платформы 1С Предприятие нецелесообразно. Как реализовать пооперационное планирование с использованием генетических алгоритмов и параллельных вычислений в докладе на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «ИНТЕХ» Сергей Сафаров.

 

Несколько слов о себе. Все меня знают, как автора множества статей для Инфостарта. Сейчас этих статей 42. Это волшебное число. Недавно 42, наконец, смогли разложить на три куба – оно было последним среди чисел от 1 до 100. Следующее интересное число – 73, поэтому я надеюсь достичь и этой цифры.

Статьи все разные. Многие были приняты с большим интересом, хотелось бы, чтобы так же стало с докладом.

 

 

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

На слайде в центре – наши программисты. Остальные фотографии – это наши заказчики. Они тут представлены с высоты птичьего полета. Видно, что это – большие, крупные фирмы. Наши заказчики подкидывают нам интересные задачи.

 

Интересные задачи 

 

 

Интересные задачи не появляются просто так. Их нужно искать и уметь находить. У нас глаз уже пристреленный, и мы видим эти задачи. В основном, потому что у нас сотрудники – это люди с научным прошлым. В том числе, и я. И мы стараемся находить задачи, которые соответствуют нашему профессиональному опыту. 

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

 

 

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

 

История разработки системы оптимизации расписания производства

 

 

Мы участвовали в большом проекте на крупном машиностроительном предприятии, с интенсивным многопередельным производством и с большим количеством заказов, в каждом из которых было большое количество операций. Внедрялось 1С:ERP, но производственное планирование в нем «не тянуло» тот объем данных, который требовался заказчику. 

Тогда заказчик приобрел систему Preactor и стал планировать уже в ней. Это импортная система составления расписания, ее, возможно, многие знают. Тем не менее, те критерии, которые требовались заказчику, система Preactor тоже не отрабатывала.

Нас попросили разработать для системы Preactor небольшой плагин (она позволяет это делать), чтобы улучшить работу с переналадками. Мы это сделали, но при этом недооценили объем работ и в результате потратили гораздо больше времени. В общем-то, сделали мини-Preactor – задублировали все объекты, которые в нем есть, всю систему ограничений. Кодовая база разрослась, терять ее стало жалко, тем более что, когда дедлайнов нет, разрабатывать всегда интересно. И мы решили нашу систему развить, усовершенствовать, чтобы вообще убрать необходимость использования системы Preactor.

 

 

Теперь наша система позволяет составлять производственное расписание напрямую в ERP.

 

Планирование в ERP

 

 

Как в ERP устроено планирование? 

Надо сказать, что по сравнению с УПП планирование в ERP сделало очень большой шаг вперед. Если изучить мировой опыт построения систем планирования, то наиболее развиты APS-системы, которые осуществляют планирование в масштабе предприятия, планируют по-крупному. А планирование в деталях, с привязкой к минутам и секундам в масштабе всего предприятия сделать невозможно из-за большого количества возмущений. И 1С очень точно угадала с тем, что сделала двухуровневую систему:

  • На верхнем уровне работает глобальный диспетчер – согласно теории ограничений систем по методу «Буфер-Барабан-Веревка» разбрасывает задания по цехам. 

  • А дальше на нижнем уровне эти задания исполняются как хотят – там уже все конкретно, задания уже более детализированные, и интервал меньше, и задания меньше, и зависят они от меньшего количества факторов. Уже вступает цеховой уровень планирования, на котором отдельные операции уже можно привязать ко времени. И мы на этом уровне для MES-планирования сделали свою разработку. 

Возможно, вы обратили внимание, что во всех обучающих роликах или лекциях по MES, когда преподаватель показывает построение расписания в ERP (даже на небольшом примере, в котором 10-20 операций), он нажимает на кнопку и довольно долго ждет, когда это расписание построится, хотя это всего лишь учебный пример. Естественно, ждать никто не любит, поэтому стандартной возможностью построения расписания в ERP заказчики вряд ли интенсивно пользуются. Хотя, может быть, у вас другое мнение.

Исходя из этого, складывается ощущение, что система MES в ERP была написана «для галочки» просто для того, чтобы она там была. И в реальных приложениях она, скорее всего, не работает, потому что осуществлять планирование можно десятком других способов, в том числе и вручную. Но если действительно хочется это автоматизировать, то нужно что-то думать. Поэтому мы сделали такой шаг вперед, чтобы появилась возможность построить расписание производства для практических случаев.

 

Что такое расписание производства

 

 

Проблема построения производственного расписания возникла давно, и был человек – Гантт Генри Лоуренс, который занимался организацией производства (вы все его хорошо знаете по фамилии, потому что так называется диаграмма), он описал вот такие требования к расписанию – где оно должно составляться, кем выполняться. Эти требования так и называются, «Принципы Гантта». 

И, если посмотреть в Википедии, как расшифровывается термин «Расписание», то там тоже написано, что это разновидность календаря, где указано, в какой момент, где и что должно делаться. 

Получается, что расписание производства – это производственные операции, привязанные ко времени и месту их выполнения. 

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

  • Во-вторых, получается, когда мы строим расписание, мы обязательно должны учитывать ограничения – например, у нас один станок в одно и то же время не может выполнять две отдельные операции. И производственный персонал тоже не может быть в 10 местах одновременно, как Фигаро. То есть, расписание – это не просто набор операций, этот набор должен удовлетворять весьма большому количеству ограничений.

  • В-третьих, расписание можно построить множеством способов, и разные расписания будут отличаться друг от друга – одно будет хорошим, второе – плохим, или вообще не будет укладываться ни в какие рамки. То есть, кроме того, что расписание должно удовлетворять системе ограничений, оно должно еще и отличаться качеством, которое также должно иметь какое-то числовое выражение.

 

Учитываемые при построении производственного расписания ограничения

 

 

Какие ограничения должна учитывать наша система:

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

  • Также должно учитываться, что каждая операция потребляет какие-то ресурсы, материалы, эти материалы должны к моменту начала операции быть уже подвезены или с самого начала иметься на складе – тут сумма остатков плюс накопленный итог – это запросом можно посчитать. 

  • Должны быть доступны рабочие центры. 

  • Должны быть доступны вспомогательные рабочие центры. Кто пытался разбираться в НСИ ERP, тот все эти названия и термины знает, мы здесь просто немного строже их описали. 

  • Рабочие центры обычно работают не круглосуточно, а по какому-то определенному графику – он тоже должен учитываться. 

  • А вообще мы очень часто сталкиваемся с тем, что в наши замыслы вносятся возмущения, и для того, чтобы с ними бороться, нужен запас прочности и запас по времени. Поэтому должны учитываться резервы доступности – если что-то сломалось или что-то не довезли, нужно время, чтобы это можно было исправить.

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

 

Критерии оценки расписания

 

 

Какие критерии влияют на качество построенного расписания:

  • Чаще всего обращают внимание на то, что все должно быть сделано вовремя. То есть, коммерческие предприятия должны выполнять заказы в срок. А если вдруг мы их в срок выполнить не можем, то это отставание должно быть минимальным. Время просроченности заказов – это один из критериев. 

  • Кроме этого мы учитываем количество просроченных заказов.

  • Также нужно учитывать, что время рабочих центров может использоваться не целенаправленно – например, на переналадку, когда нужно прекратить одну операцию и начать следующую, а за это время поменять настройки и инструменты. Например, если бы мы хотели послушать все доклады, нам пришлось бы бегать, «переналаживаться» от одного доклада к другому, а если бы все, что нас интересует, шло бы подряд и в одном месте, мы тратили бы меньше времени на «переналадку».

  • Также на качество расписания влияет равномерность загрузки рабочих центров. Иногда удивляешься, что рабочие при планировании расписания обижаются: «Почему меня забыли, почему меня никто ничего не просит делать?» Это удивительный факт, когда приходится сталкиваться с буквальными обидами, человек думает, что его сократят, он хочет, чтобы ему тоже попадали задачи. И если под рабочим центром понимать производственный персонал, то равномерная загрузка рабочих центров тоже является критерием. 

  • Также влияет стоимость выполнения производственной программы. Понятно, что на одном и том же станке разные операции можно делать быстро/дорого или медленно/дешево. 

  • Кроме стоимости влияет общее время выполнения –  здесь приведены формулы, можете их посмотреть. 

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

 

Сложность задачи

 

 

Вообще задача сложная. 

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

  • В ERP используется однопроходной алгоритм – когда мы выложили на доску какую-то операцию, зафиксировали это решение и поменять его уже не можем. Хотя, может быть, в самом конце мы увидим, что определенный шаг решения у нас был неудачным. Просто не хватает времени, чтобы принятое решение пересмотреть. Так оптимальное расписание не построить. 

  • Нет общей модели и общего метода решения. Многие люди думают, что мы сейчас возьмем задачу, полистаем книжки, посмотрим, найдем соответствующий нашему названию метод, разберемся и решим его. Но общий метод решения зависит от того, как сформулировано ограничение: если целевая функция линейная, то это один метод, если целевая функция квадратичная – то второй метод. Если ограничения целочисленные – третий метод и т.д. А клиент хочет все и сразу. И получается, что общего метода и общей модели нет. Это – очень сложно. И поэтому академические, высокоэффективные суперсложные решения здесь плохо работают.

  • Большинство методов в условиях сформулированных ограничений – NP-полные. Это означает, что мы, не перебрав все возможные расписания, самого лучшего решения не получим. А когда мы выстроим все операции в цепочку, у нас количество возможных расписаний станет равным факториалу (n!) – это очень много. Если операций три – это шесть, если пять – 120, если их сто – это уже больше, чем атомов во вселенной. 

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

  • Требуется большой объем вычислений. И хотя раньше мне казалось, что 1С может решить все, если исхитриться и что-то изобрести – в данном случае это не срабатывает. На стороне 1С такой большой объем вычислений производить нецелесообразно.

 

Метод решения – эволюционный генетический алгоритм

 

 

Тем не менее, мы выбрали метод решения. В его основе – эволюционный генетический алгоритм. Его достоинства:

  • он легко перестраивается на решение других задач;

  • легко добавить или изменить систему и форму ограничений;

  • легко добавить или изменить критерии;

  • он хорошо распараллеливается.

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

Время показало правильность нашего выбора, потому что ТЗ, с которого мы начинали, многократно уточнялось. И если бы та модель, которую мы выбрали, была строгая, то предлагаемый нами метод давно бы перестал работать. А так мы с задачей все-таки справились.

 

 

Если говорить о сущности нашего метода, то как он устроен:

  • У нас есть вариант расписания – это как индивидуум (какой-то зверек, животное в длинной цепи эволюции). 

  • Совокупность этих расписаний у нас соответствует популяции. 

  • Индивидуумы в ходе эволюции друг друга воспроизводят, в процессе этого они меняются под воздействием мутаций, скрещиваются, лучшие черты родителей переходят потомкам, отбираются – получается все, как в жизни. 

  • Собственно говоря, в некотором смысле наши занятия математикой, или прикладной математикой, или просто программированием подтверждают наши общие жизненные установки, общие представления. Нашей работой как будто подтверждается теория эволюции.

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

  • А фенотип – это расписание с привязкой операции по времени. Оно определяется уже в процессе интерпретации, когда мы применяем ограничения. 

 

Общая схема эволюционного алгоритма

 

 

Общая схема эволюционного алгоритма выглядит таким образом:

  • У нас имеется популяция – генерируется набор случайных или предварительно сформированных ручным способом расписаний. 

  • Каждое расписание получает оценку по соответствующему критерию, и помещается в популяцию с этой оценкой. 

  • Далее может производиться мутация – берется расписание, в него вносятся небольшие изменения, после чего оно оценивается и снова помещается в популяцию. 

  • Или расписание подвергается скрещиванию – берется два родителя, их операции каким-то образом смешивается, и также получается потомок. 

  • Плохие расписания отбраковываются – производится контроль популяции.

 

 

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

 

Применяемые методы мутаций и скрещиваний

 

 

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

  • мы переносим на ранние сроки операции запаздывающих заказов;

  • группируем операции с минимизацией переналадок;

  • переносим операции на другой РЦ с усреднением загрузки группы РЦ и т.д.

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

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

 

 

И скрещивания – их набор чуть победнее. Тем не менее, тоже не одно. 

 

Реализация многопоточности

 

 

Кроме того, уже после окончания проекта мы этот алгоритм распараллелили по ядрам процессора. У нас имеется общая память, где хранится популяция, и каждая веточка алгоритма выполняется параллельно, отдельным ядром. 

В результате мы получили практически линейное ускорение в 8 раз (у нас было 8 ядер). Если бы ядер было 16, было бы ускорение в 16 раз – мы пока не ощутили достижения предела на наших мощностях.

 

Сложности, возникшие при реализации

 

 

Какие у нас сложности возникали, как мы их преодолевали?

Когда у нас получается генотип, то фенотип образуется не всегда, потому что эта сгенерированная последовательность может не выжить – может получиться нежизнеспособный мутант. Это происходит за счет дедлоков (типа блокировок в СУБД). Чтобы их развязать, достаточно отбросить какую-то транзакцию, а здесь этого сделать нельзя, поскольку мы очень бережно относимся к сгенерированным нами последовательностям. Развязывание дедлоков – это довольно сложный математический алгоритм. Он тоже NP-полный. Нам пришлось изобретать свой, легкий алгоритм. Но, тем не менее, мы с этим справились, и получилось достаточно интересное решение.

И вот еще интересный момент, который мы здесь отметили – когда я давно занимался 3D-упаковкой, у меня было ощущение, что мы возьмем и распределим задачи по одному серверу кластера, второму, третьему, четвертому, и получим пропорциональный рост. То есть, после достижения этой полочки (количества ядер, по которому мы распараллелили алгоритм) мы таким же образом распределим между серверами. 

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

Мы, получается, очень долго не могли понять. Провели работу, у нас были SOAP-сервисы запущены для того, чтобы обмениваться между серверами. И не получаем мы ускорение. Оставляем на ночь, на воскресенье, на компьютерах всех разработчиков запускаем. И получается, наоборот, хуже. Почему? Оказывается, есть объяснение. Мы модель построили, чтобы это объяснить. Вкратце, дело в том, что для некоторых разновидностей вычислений обязательно требуется общая оперативная память и быстрый доступ к ней. Иначе передача промежуточных результатов с сервера на сервер съедает весь возможный выигрыш. Для борьбы с этим на суперкомпьютерах есть особые шины. А так просто, как в 1С, добавить сервер в кластер и ускорить вычисления не получиться. Вообще нужно следить за прогрессом в этой области. Когда появятся 128-ядерные процессоры, их нужно покупать. Нужно сказать, что это не только в нашей области решения задач оптимизации, но и в области нейросетевых технологий точно такой же эффект отмечается. Возможно, там другие объяснения. Но это – та вещь, которую мы почувствовали своими руками и поэтому этим хотелось бы поделиться.

 

Подробности реализации

 

 

Что представляет собой наше решение:

  • Оно сделано на C#. Платформа .NET Core. 

  • Размер кодовой базы примерно 15 тысяч строк. 

  • Обрабатываемые расписания состоят из десятков тысяч операций – у нас встречалось 13-15 тысяч. 

  • В результате построения одного расписания мы получаем десятки тысяч вариантов. Бывает 5 тысяч, бывает 15 тысяч. Когда мы запускали пример на неделю, там могли быть и миллионы.

  • Конечно, наше решение показывает гораздо более высокую скорость, чем встроенные методы в ERP. На несколько порядков (на три, наверное). 

  • И показывает лучшие результаты при том же самом времени. 

  • Также оптимизирует переналадки – наш метод работает в гораздо более широком диапазоне условий.

 

 

Мы оформили наше решение как расширение, которое добавляет кнопку в окно расчета расписания производства продукции.

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

 

 

Вот пример вызова. Тот, кто работал с MES, это окно знает. Сюда добавлена возможность расчета внешними средствами. 

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

 

 

Есть окно настроек. 

 

 

Окно с результатами работы – это то же самое окно.

 

 

И вот статистика. Здесь можно посмотреть, как все у нас происходит. 

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

А ниже у нас изображены частные критерии. 

Видно, что иногда какие-то из критериев растут навстречу рейтингу. Например, когда стали минимизировать переналадки, критерий OverdueTime, изображенный красной линией, у нас все-таки подрос – мы чуть-чуть пожертвовали просроченностью. 

Итого, у нас здесь всего лишь 3000 вариантов, но мы для них, судя по всему, уже вышли на самое оптимальное значение.

 

 

А здесь – другой вариант, когда встречных движений нет, все более-менее гладко. 

 

Общие выводы

 

 

  • Я довольно давно занимаюсь 1С и вижу, что, несмотря на надежды сообщества, 1С в области методов оптимизации работать не будет. Это – интересная ниша, пожалуйста, занимайте ее.

  • Выбирая метод решения задачи, связанной с оптимизацией, следует выбирать метод более общий, даже в ущерб каким-то маленьким достижениям. Условия задач меняются гораздо быстрее, чем программируется специализированный метод. Только так мы можем экономить. Это вообще тенденция сегодняшнего дня, что мы экономим свое время, а не компьютерное. 

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

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

 

Вопросы

  • Preactor в итоге совсем убрали?

  • Да, наша обработка работает без Preactor. Preactor очень многое может, мы можем работать вместе с ним. Но Preactor стоит полтора миллиона, это гораздо больше, чем стоимость ERP. А сейчас мы уже вышли на более широкий рынок – увидели потребность, что классическая ERP-шная обработка пооперационного планирования не работает в реальных применениях, и сделали так, чтобы она могла работать. Мне кажется, что это здорово. 

  • А на этом конкретном проекте Preactor был внедрен?

  • Да.

  • Вы сказали, что заказчика не устроила функциональность Preactor. Не скорость, а функциональность. 

  • Если говорить про тот конкретный проект, то мы на нем работали в качестве подрядчиков, за спиной исполнителя. Там Preactor выполнял очень много задач. Клиенту Preactor подошел, клиент с ним продолжает работать. Просто в некоторых случаях при некоторых настройках Preactor не минимизировал переналадки так, как хотелось клиенту. Они хотели иметь эту кнопочку, и мы эту кнопочку им сделали. 

  • А сколько по времени занимал ваш пересчет?

  • У нас много критериев остановки. В той исходящей задаче у нас было ограничение по времени 10 минут. За эти 10 минут мы отрабатывали 9000 расписаний. Кроме этого, у нас есть критерий остановки, когда график стабилизируется (выходит на «полочку»), расписание уже не меняется. В принципе, обычно мы старались уложиться на том объеме, который нам давали, в десятки минут. Когда мы проводили тестирование – на сложных задачах на большом количестве данных, то запускали расчет на сутки, и решение обычно находилось за 5-6 часов. А вообще критерий остановки в задачах оптимизации – это сложный вопрос.

  • А можно ли для составления расписаний использовать специальные математические пакеты – тот же самый MatLab или Python с библиотеками?

  • Я – большой любитель MatLab, напрограммировался на нем. Многие люди думают, что мы купим известный IBM-овский пакет и решим все задачи. Нет, потому что получается, как дерево – у корня его можно охватить, а у кроны задачи очень быстро расползаются и специальные математические пакеты в области построения расписаний не работают, потому что они работают тогда, когда задача поставлена совершенно конкретно и у нее есть строгие четкие ограничения. Такой узкий класс задач встречается очень редко. Поэтому мы эти специальные пакеты не использовали. Не потому, что мы про них не знаем, а потому, что не нашли такой возможности.

  • Но вы писали практически с нуля, и вам приходилось часть функциональности, которая есть в этих математических пакетах, в том числе ограничения по операциям с плавающей точкой, чтобы не набегала ошибка, делать все в ручном режиме. Потому что идеальный алгоритм (простейшее решение системы матриц 20*20, если его написать «в лоб»), не решится – это ограничение жестких систем.

  • Здесь таких проблем нет. В генетическом алгоритме для построения расписания при ограничении операций ошибки не набегают. Это не расчет себестоимости. Мы сейчас работаем на очень широком поле задач, поэтому я здесь убежден и готов отвечать, что специальные математические пакеты в этой области не работают. Можно привлечь к нашему разговору Евгения Борисовича Фролова – человека, который ведет школу оптимизации расписаний. В этом случае работают только практически ориентированные методы.

  • Два вопроса в сторону конкретики – какая в ваших кейсах была стандартная глубина прогноза этого расписания – насколько вперед они смотрели? И как часто приходилось уже просчитанное, казалось бы, расписание пересчитывать в случае каких-то отклонений по факту от него. 

  • На том проекте, с которого все началось – там глубина прогноза расписания была полтора месяца (7 недель). Не знаю, что это за волшебное число, но у меня довольно часто это число выскакивает в практике. Пересчитывать приходится часто, даже очень часто. Недавно мы решали задачу по производственной логистике, где применялись очень похожие методы. Там мы вообще отказались от долговременного прогноза – и просто перешли на часовой интервал пересчета.

  • Вы упомянули, что эвристический метод не дает одинаковый результат два раза. Получается, что вся глубина прогноза может очень сильно измениться?

  • У нас есть операции, которые начаты – они зафиксированы. У нас есть возможность закрепить операции в расписании и их не пересчитывать – это и в ERP есть. Конечно, иногда мы не можем за выделенное время составить оптимальное расписание – тут уже нужно чем-то жертвовать. Но бывают важные заказчики, важные заказы и т.д. Это все учитывается.

  • В вашем итоговом расписании соблюдается ли условие, что на рабочий центр запланировано не больше работы, чем его мощность? Эти алгоритмы учитывают, что мощность рабочих центров ограничена?

  • Да, они учитываются. В нашем сегодняшнем алгоритме это учитывается как ограничение, причем, с резервом доступности – не больше. Оно проигрывается и если сюда не вписывается, то оно переносится и расписание удлиняется или  появляются задержки. Иногда бывает (мы с этого начинали) – это можно перенести в разряд критериев – разрешить это, но оценить это каким-то штрафом. Например, если мы это перегрузили, то мы штрафуем это расписание чуть больше. В текущей реализации у нас доступность рабочих центров – это ограничение. Но можно поменять. И я говорил, что это – выбранный нами подход. Он позволяет гибко перестроить условия. Еще я просто не успел сказать, что мы сделали простую обработку для 3D-упаковки, где используется тот же самый алгоритм – просто немного поменяв несколько библиотек. А код в большинстве своем остался тем же самым. Сейчас мы боремся за результаты – и лучшие алгоритмы у нас показывают 80-90% плотности упаковки. К сожалению, пока ближе к 80%.

  • Как себя ведет ваш алгоритм при радикальном увеличении числа операций? Вы сказали, что у вас 13-15 тысяч операций. А если будет 100-500 тысяч операций?

  • У нас 10 тысяч операций – это предел, который не нужно превышать просто исходя из наших жизненных установок. Это общее понимание у всех методологов, кто занимается оптимизацией расписания, что большего количества операций в расписании никому не нужно, иначе оно за счет теории вероятности просто окажется неисполнимым. Поэтому это не нужно. Но наш алгоритм по затратам времени растет линейно, здесь нет квадратичных зависимостей. Получается, если операций у нас в расписании стало 100 тысяч, и мы влезаем в оперативную память, то оно просто будет выполняться в 10 раз дольше. Например, если мы в расписании за 10 минут считаем 10 тысяч операций, то при расчете 100 тысяч операций за 10 минут мы посчитаем только тысячу, соответственно, нужного качества не получим. Обратная линейная зависимость.

  • Все-таки качество итогового получившегося расписания зависит от количества операций?

  • Конечно. Это же поиск – если у нас скорость поиска медленнее, то мы и рыбы поймаем меньше.

  • А как вы оцениваете, на российском рынке, среди российских разработок у вас есть конкуренты в сегменте APS?

  • Мы с ними не сталкивались. Во-первых, у нас это не коробочное решение. Это у нас проекты – с конкретными заказчиками. Это проекты с небольшой стоимостью. Поэтому мне кажется, что мы не должны с ними пересечься. Мы позиционируем свое решение как плагин для ERP. Вы купили ERP, ERP не планирует. Доплатите нам немного, мы вам довнедрим, настроим, оттестируем. Есть фирма ИТРП – они для УПП реализовывали оптимизацию планирования с помощью отдельного сервера. Не знаю, повторили ли они этот опыт для ERP или нет. Во всяком случае, мы сами себе задачу поставили и решили ее. Наверное, я знаю только одну фирму, которая делала такую попытку – именно в этой области. Не в области столкновения с Preactor, где более высокие цены и другой интерфейс, а в области «навесок» к ERP.

  • В принципе, вы не считаете себя конкурентом для Preactor?

  • Нет, конечно. 

  • По вашей презентации выходит, что «пришли мы и уделали Siemens».

  • Я извиняюсь, если такое впечатление сформировалось. Тема доклада у меня обозначена скромно. Я хотел бы пояснить, что на том проекте Preactor остался, и работает все вместе. А мы предлагаем другие проекты, где Preactor можно не покупать. 

  • Я к чему говорю, у нас же сейчас импортозамещение – вроде хотелось бы импортозаместиться. Если люди привыкли к Preactor, они могут импортозаместиться с вашей помощью?

  • Мы пока себе такой цели не ставим. Если вы купили ERP и хотите использовать MES, приходите к нам, MES у вас заработает. А сделать «отечественный Preactor» мы себе цели не ставим. Мы идем по другому пути.

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Vladimir Litvinenko 2405 03.03.20 11:04 Сейчас в теме
Очень интересная тема. Но не хватает хотя бы одного слайда для практиков. Например со списком объектов 1С, данные из которых экспортировались и куда они после расчёта импортировались. Если даже код на C# настолько секретный, то хоть немного технических деталей для 1С-ников не помешало бы. Чтобы прочитавший публикацию не только вспомнил о существовании генетических алгоритмов и посмотрел на котиков картинки, но и хоть немного в знаниях прокачался. Так ведь опять реклама на слайдах, хотя возможно и достигающая целевой аудитории (заказчиков).

Пока что из всех материалов только доклад от Никиты Грызлова запомнился как ценный и в закладки попал: вот теория, а вот практика. Решение не на блюдечке, но если захотите, то можете за это зацепиться и научиться чему-то полезному. Хотелось бы чуть больше такого.

Замечание не столько к автору доклада - у него много интересного (хотя и тяжело читаемого ;)) кода на Инфостарте. Скорее к тому, что большинство докладов скорее развлекательные, чем поучительные ))

сделать «отечественный Preactor» мы себе цели не ставим. Мы идем по другому пути.

Интересно, а почему не ставите такой цели? Ведь выше было написано, что
В общем-то, сделали мини-Preactor – задублировали все объекты, которые в нем есть, всю систему ограничений. Кодовая база разрослась

Почему решили не работать в этом направлении дальше, и не развивать решение в сторону отечественного аналога? Да ещё и с интеграцией с 1С, которая уже есть.
4. ildarovich 7096 04.03.20 14:48 Сейчас в теме
(1) Понял замечания насчет неудовлетворенного желания "прокачаться в знаниях" и "тяжело читаемого кода". Учту на будущее. Действительно, у этого доклада была другая задача.

Не ставим такую цель (разработать отечественный Preactor) потому что для нас это слишком масштабный проект с неопределенными коммерческими перспективами. Плагин к ERP (или Preactor) - другое дело.
2. pm74 179 03.03.20 15:33 Сейчас в теме
интересно . так вы планировали расписания сразу для всех РЦ или по ограничениям (РЦ) ?
6. ildarovich 7096 04.03.20 15:04 Сейчас в теме
(2) Сразу для всех РЦ одного подразделения. В соответствии с концепцией MES, реализованной в ERP.
3. veri123 04.03.20 10:29 Сейчас в теме
Интересно рассматривали ли вы другой подход. Кода задача на цех планируется по классике (ббв), а вот задача на конкретный рц ищется как оптимальная на текущее состояние из ходя из задач на день. То есть аналог цепи Маркова каждая задача рассчитывается как лок экстремум но мы не анализируем не прошлые не последующие задачи которые должен выполнять рц. Да красивого графика мы не построим но и вычислений в разы меньше.
5. ildarovich 7096 04.03.20 15:01 Сейчас в теме
(3) В принципе, применению этого подхода при использованию нашей разработки ничего не мешает. Она как раз так и работает. Оптимизирует на уровне цеха распределение операций по рабочим центрам и их последовательность. Тогда как состав операций на день уже определен запланированными на верхнем уровне этапами. Другое дело, что при интервале планирования "день" просроченность нет большого смысла включать в критерии.
Ну и исходить лучше не из минимизации объема вычислений (мы с ним справляемся), а из требований заказчика, который часто ждет более точных данных по срокам выполнения заказа и хочет учесть в расчетах передачу полуфабрикатов между цехами в любой момент интервала планирования, а не только в его конце.
7. veri123 04.03.20 17:48 Сейчас в теме
(5) можно по поподробнее что физически значит "хочет учесть в расчетах передачу полуфабрикатов между цехами в любой момент интервала планирования".
Просто исходя из того что постоянно происходят авралы(поломка оборудования/брак производства/обнаружение- недостача материалов) перебалансировка нагрузки на рц должна происходить постоянно(ли с каким-то мин промежутком). Плюс генетический алгоритм по своей сути хаотичен, то есть нет точной временной оценки выполнения, есть только эмпирические замеры. То есть сегодня задача расчета заняла 10 мин, а завтра 1 минуту, а после завтра пол часа в зависимости от того какую популяцию мы выбрали и как сложилось скрещивание. Хотя эти минусы наверное более надуманы чем практические.
Оставьте свое сообщение

См. также

Диспетчер Хранилища Запросов в SQL Server 2016+ (он же Query Store) Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Если вы используете SQL Server 2016 или более позднюю версию, то у вас есть возможность использовать встроенную систему мониторинга, которая позволяет отслеживать самые базовые метрики выполняемых запросов и статистику ожиданий (потребления ресурсов). Эта информация позволяет быстро получить самые ресурсоемкие запросы с их планами и агрегированной статистикой выполнения.

26.04.2019    11354    Aleksey.Bochkov    7    

Описание почти всех событий технологического журнала

Технологический журнал v8 Бесплатно (free)

Краткое описание событий технологического журнала с примерами. Все для быстрого старта.

19.08.2020    5273    YPermitin    22    

1С: Документооборот, Data Science и Python

Документооборот и делопроизводство Математика и алгоритмы ДО Бесплатно (free)

В статье рассказывается о создании и обучении модели Data Science на языке Python и интеграции с системой 1С: Документооборот

04.08.2020    1509    Vaganov_Alexey    4    

Применение математических достижений в решении сложных задач бизнеса

Математика и алгоритмы Бесплатно (free)

Как правило, самые сложные задачи решаются с точки зрения математики очень легко. Но чтобы найти правильное решение, важно понять бизнес-цель, которую достигает эта задача. О практическом применении математических достижений для эффективного решения сложных задач бизнеса на конференции Infostart Event 2019 Inception рассказал Дмитрий Мишнов.

25.05.2020    3354    Mishnov    17    

Автоматические и управляемые блокировки применительно к типовым конфигурациям 1С Промо

Математика и алгоритмы Практика программирования v8 v8::blocking 1cv8.cf Бесплатно (free)

Основные принципы работы с режимами автоматических и управляемых блокировок в 1С Предприятие 8. Теория и применение в типовых конфигурациях: БП, УТ, ЕРП

10.11.2018    34679    ids79    40    

Выбор процессора для 1С: конец споров или начало?

Производительность и оптимизация (HighLoad) Бесплатно (free)

Периодически занимаясь исследованиями производительности я повидал много решений. Делюсь некоторыми выводами на основании теста Гилева и собственных мыслей.

25.05.2020    10001    starik-2005    230    

Учимся готовить кроликов с редиской: опыт применения Rabbit MQ и Redis в интеграционных проектах

Производительность и оптимизация (HighLoad) Интеграция Бесплатно (free)

При построении мощных производительных отказоустойчивых решений для интеграции во всем мире активно используются технологии обработки очередей сообщений с помощью брокера RabbitMQ и кэш-сервера Redis. О практическом опыте использования этих технологий при построении ИТ-ландшафта, включающего системы на 1С, на конференции Infostart Event 2019 Inception рассказал Сергей Наумов.

12.05.2020    5367    SergeyN    3    

Ок, Лариса! Мониторинг проблем производительности с применением нейронных сетей

Производительность и оптимизация (HighLoad) Бесплатно (free)

Проводить мониторинг производительности вручную, выявляя закономерности в куче графиков и десятках таблиц, довольно сложно. Но это не значит, что разбираться с инцидентами нужно только после жалоб от пользователей. О том, как обучить нейронную сеть и заставить ее оповещать о проблемах, на конференции Infostart Event 2019 Inception рассказал начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков.

27.04.2020    4066    ivanov660    5    

Опыт миграции из собственного датацентра в облако AWS Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Хотя данная публикация и не имеет прямого отношения к 1С, она может быть интересна тем, кто занимается крупными базами данных на MS SQL Server. Описывается опыт миграции баз данных в облако AWS в компании glassdoor.com, где я занимался этим проектом. Это первый драфт текста, получившийся довольно скомканным - в процессе буду дополнять.

29.07.2018    11492    Aleksey.Bochkov    9    

Пример поиска ошибок в технологическом журнале

Технологический журнал Производительность и оптимизация (HighLoad) Бесплатно (free)

Примеры bash - скриптов для поиска ошибок в технологическом журнале.

23.04.2020    2800    vasilev2015    7    

Фреймворк "Мониторинг производительности". Руководство пользователя

Производительность и оптимизация (HighLoad) Бесплатно (free)

Описание и руководство "Мониторинг производительности": краткое описание конфигурации, сборник из статей, примеров - собрано в одном файле.

21.04.2020    3329    ivanov660    3    

Эти занимательные временные таблицы

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    11449    YPermitin    0    

Как работает серверный вызов в 1С Промо

Математика и алгоритмы v8::УФ Бесплатно (free)

Клиент-серверная архитектура заложена в платформе изначально — со времен «1С:Предприятие 8.0». Однако при разработке на 8.0 и 8.1 о разделении кода на клиентскую и серверную часть можно было не заботиться, поскольку на клиенте (на толстом клиенте) был доступен тот же функционал, что и на сервере. Всё изменилось с выходом платформы «1С:Предприятие 8.2», когда появился тонкий клиент. Теперь на клиенте доступен один функционал, на сервере — другой. Клиент и сервер «общаются» между собой с помощью серверного вызова. Конечно, это усложнило процесс разработки, но с другой стороны – можно создавать более оптимальные (быстрые) решения, поскольку все сложные задачи выполняются на сервере.

18.11.2017    55845    pahich    82    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    12630    informa1555    31    

Делаем быстрее POSTGRESQL COUNT (*)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Laurenz Albe "POSTGRESQL COUNT(*) MADE FAST". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/postgresql-count-made-fast/

28.02.2020    2585    w.r.    1    

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    29557    MrWonder    42    

Простое обнаружение проблем производительности в PostgreSQL

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Hans-Jürgen Schönig "DETECTING PERFORMANCE PROBLEMS EASILY IN POSTGRESQL". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/detecting-performance-problems-easily-in-postgresql/ Актуально для всех 1С ников, перешедших с MS SQL на Postgres

20.02.2020    4152    w.r.    4    

Держи данные в тепле, транзакции в холоде, а VACUUM в голоде

Производительность и оптимизация (HighLoad) Бесплатно (free)

Чтобы база работала быстро – в ней нужен порядок. Это касается как MS SQL, так и PostgreSQL. Как настроить базу, чтобы в ней поддерживался порядок, какие регламентные операции нужно проводить, чтобы данные чистились, индексы перестраивались и оперативная память высвобождалась в своём выступлении на конференции Infostart Event 2019 Inception поделился руководитель ИТ в компании «ИнфоСофт» Антон Дорошкевич. 

07.02.2020    10196    a.doroshkevich    17    

Атака сервера кнопонажималкой

Нагрузочное тестирование Инструментарий разработчика Бесплатно (free)

Чтобы убедиться, что продукт выдержит планируемую нагрузку, необходимо провести нагрузочное тестирование – написать сценарии пользовательских действий и запустить их в несколько потоков, чтобы заранее найти проблемы в бизнес-логике и «узкие места». О том, как упростить написание сценариев тестирования для конфигурации Тест-центр с помощью фреймворка Vanessa Automation на конференции Infostart Event 2019 Inception рассказал ведущий программист компании «ПервыйБИТ» Никита Грызлов.

20.01.2020    5888    nixel    22    

Будни автоматизации или "мне нужна программка для 3D упаковки" Промо

Практика программирования Математика и алгоритмы Оптовая торговля Оптовая торговля v8 1cv8.cf УУ Бесплатно (free)

Автоматизация отечественных предприятий, которой приходиться заниматься, это нужная и высокооплачиваемая, но довольно нервная работа. Выручает юмор. Например, при общении с требовательным клиентом можно вспомнить анекдот: "Держась руками за стену, на ногах еле стоит мужик. К нему пристает ребенок: "Ну, папа, пожалуйста, сделай мне кораблик!", папа отвечает: "Ага! - Сейчас все брошу и пойду делать тебе кораблик!". Про один такой сделанный для клиента "кораблик" и хочется рассказать. Надеюсь, совместное погружение в теплое ламповое (то есть клиентоориентированное) программирование доставит Вам положительные эмоции, да и задача попалась интересная. Поплыли?

24.03.2014    45266    ildarovich    116    

История роста и работы команд 1С в условиях HighLoad и BigData

Автоматизация ИТ-компании Производительность и оптимизация (HighLoad) Бесплатно (free)

Современные потребности бизнеса заставляют программистов 1С решать все более сложные задачи. А главные требования, которым необходимо соответствовать, – вовремя поставлять ценности высокого качества. С какими сложностями приходится сталкиваться в работе программистам в динамично развивающейся брокерской сфере, и как их решают, на конференции Infostart Event 2018 Education рассказал начальник отдела интеграции БКС Технологии Сергей Артемов.

11.11.2019    7514    user826155    11    

Обслуживание баз данных. Не так просто, как кажется

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

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    17612    YPermitin    28    

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

Производительность и оптимизация (HighLoad) Администрирование СУБД Бесплатно (free)

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

30.09.2019    21934    YPermitin    15    

Метод Кларка-Райта. Оптимальное планирование маршрутов грузоперевозок Промо

Математика и алгоритмы Бесплатно (free)

Одной из наиболее важных задач каждого предприятия, осуществляющего доставку грузов в крупных населенных пунктах, является сокращение издержек. Возможное решение данной проблемы заключается в сокращении пробега автотранспорта и, как следствие, уменьшении расхода ГСМ. Появляются такие вопросы ... - СКОЛЬКО НУЖНО МАШИН ДЛЯ РАЗВОЗКИ КОНКРЕТНОГО ОБЪЕМА ГРУЗА ПО АДРЕСАМ ДОСТАВКИ ? - КАК РАЗБИТЬ ТОЧКИ ДОСТАВКИ НА ОПТИМАЛЬНЫЕ ПО ПРОБЕГУ И ЗАГРУЗКЕ МАШИН МАРШРУТЫ ? ... В этой статье Вы найдете один из многих способов получить ответ на эти вопросы.

10.02.2016    59822    mi1man    20    

Подбор оборудования для информационных систем на платформе 1С

Интеграция Производительность и оптимизация (HighLoad) Бесплатно (free)

При подборе оборудования по рекомендациям с сайта ИТС возникает противоречие: проводить ли нагрузочные тесты, чтобы определить возможную нагрузку, или достаточно просто взять данные из таблиц статистики? О том, какую тактику применить в том или ином случае, на конференции INFOSTART EVENT 2018 Education рассказал начальник отдела разработки компании IBS Филиппов Евгений.

09.09.2019    9058    jf2000    8    

Регистры бухгалтерии. Общая информация

Практика программирования Математика и алгоритмы v8 v8::БУ БУ Бесплатно (free)

Общая информация о внутреннем устройстве регистров бухгалтерии.

05.09.2019    28160    YPermitin    24    

Руководство по SQL: Как лучше писать запросы (Часть 2)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию продолжение перевода статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Первая часть доступна по ссылке https://infostart.ru/public/1115809/

03.09.2019    7561    w.r.    2    

Приемы обработки больших данных в 1С Промо

Универсальные обработки Математика и алгоритмы Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

Рассказ об эффективных приемах организации обработок больших объемов данных на платформе 1С

07.08.2015    67057    tormozit    27    

Руководство по SQL: Как лучше писать запросы (Часть 1)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL.

30.08.2019    10809    w.r.    19    

Иерархия без "В ИЕРАРХИИ"

Математика и алгоритмы v8 Бесплатно (free)

Говорится о том, как эффективно представлять иерархию в СУБД, как получать и использовать эти представления при решении задач в запросной технике. Уточняются и дополняются запросы из статьи "Уровни, глубина, прародители, циклы и аналоги запросом" [https://infostart.ru/public/160707/].

22.08.2019    12338    ildarovich    19    

Использование Union вместо OR

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Derek Dieter "Using Union Instead of OR". Оригинал доступен по ссылке http://sqlserverplanet.com/optimization/using-union-instead-of-or.

22.08.2019    3993    w.r.    35    

Опыт оптимизации и контроля производительности в БД с 3000 пользователей Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года. Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии". Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность. Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры. **update от 04.03.2016 по вопросам из комментариев

05.08.2015    61207    Sergey.Noskov    119    

Тюнинг производительности запросов в PostgreSQL

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Brady Holt "Performance Tuning Queries in PostgreSQL ". Оригинал доступен по ссылке https://www.geekytidbits.com/performance-tuning-postgres/

31.07.2019    7912    w.r.    5    

Обработчики событий при записи объектов. Зачем и что за чем?

Математика и алгоритмы v8 Бесплатно (free)

Программисту, имеющему немного опыта на платформе 1С 8.3, бывает сложно разобраться: ПередЗаписью, ПриЗаписи, ПослеЗаписи, на сервере, на клиенте, в модуле формы, в модуле объекта.... Эта шпаргалка была создана в процессе обучения и реального опыта с целью разложить всё по полочкам, чтобы было четкое понимание в каком случае какой обработчик нужно использовать и в какой последовательности они запускаются при записи и проведении документов. Данная статья будет полезна в большей степени начинающим разработчикам. Но и опытным позволит освежить информацию, упорядочить её.

25.07.2019    50032    AlbinaAAA    28    

Как проводятся документы в типовых конфигурациях от 1С

Математика и алгоритмы Практика программирования Разработка v8::ОУ ERP2 УТ11 Россия УУ Бесплатно (free)

В свое время, когда только начинал шаги в 1С и изучал, как проводятся документы в конфигурациях на платформе 1С по книге "Разработка управляемого интерфейса" (Хрусталева Е.Ю.), и там были представлены примеры совсем далекие от того, как сейчас проводятся документы в современных конфигурациях от 1С.

24.07.2019    27374    skv_79    35    

XDTO - это просто Промо

Математика и алгоритмы v8 1cv8.cf Бесплатно (free)

С появлением платформы 8.1 фирма “1С” представила механизм, носящий интригующее название XML Data Transfer Objects или, если коротко - XDTO. По традиции, документирование механизма составлял тот, кто хорошо разбирался в вопросе, а стало быть опустил “и так понятные” с его точки зрения моменты. Целью данной статьи (или цикла статей, как получится) стало желание поделиться накопленным опытом. Мне кажется, многие неочевидные вещи в механизме XDTO необходимо осветить получше.

24.12.2012    293758    Evil Beaver    173    

Управление качеством кода

Математика и алгоритмы Рефакторинг и качество кода v8 Бесплатно (free)

О SonarQube, АПК, EDT. Какие преимущества дает их использование. Для каких команд подходит.

22.07.2019    16406    Stepa86    33    

Настройка параметров PostgreSQL для оптимизации производительности

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tuning PostgreSQL Database Parameters to Optimize Performance". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/31/tuning-postgresql-database-parameters-to-optimize-performance/

08.07.2019    7208    w.r.    19    

Сравнительное тестирование работы PostgreSQL с большими страницами Linux

Производительность и оптимизация (HighLoad) Бесплатно (free)

Представляю вашему вниманию перевод статьи Ibrar Ahmed "Benchmark PostgreSQL With Linux HugePages". Оригинал расположен по ссылке https://www.percona.com/blog/2018/12/20/benchmark-postgresql-with-linux-hugepages/

05.07.2019    4704    w.r.    6    

Долго открывается конфигуратор Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    40865    Gilev.Vyacheslav    1    

Настройка параметров ядра Linux для оптимизации PostgreSQL

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tune Linux Kernel Parameters For PostgreSQL Optimization". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/

05.07.2019    5702    w.r.    2    

Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE

Производительность и оптимизация (HighLoad) Бесплатно (free)

Данная статья является переводом оригинальной статьи Martin Kováčik "PostgreSQL benchmark on FreeBSD, CentOS, Ubuntu Debian and openSUSE" https://redbyte.eu/en/blog/postgresql-benchmark-freebsd-centos-ubuntu-debian-opensuse/ В ней рассматриваются тесты СУБД PostgreSQL 10.1 в приближенных к реальным условиям средах на различных unix-системах

30.06.2019    6112    w.r.    2    

Создание отчетов с помощью СКД - основные понятия и элементы

Практика программирования Математика и алгоритмы v8 v8::СКД Бесплатно (free)

Основные принципы работы СКД. Понятия схемы компоновки и макета компоновки. Описание основных элементов схемы компоновки: наборы данных, поля, вычисляемые поля, ресурсы, параметры.

25.06.2019    52194    ids79    25    

Повышенная нагрузка на диски сервера баз данных SQL Server Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

С проблемой повышенной нагрузки на диски (дисковые хранилища и массивы, далее просто диски), сталкиваются почти все администраторы и специалисты технической поддержки при эксплуатации средних и крупных информационных систем на базе SQL Server (от 50 активных пользовательских сессий). Но всегда ли правильно идет интерпретация проблемы, попробуем разобраться на нескольких практических примерах.

15.03.2015    40244    gallam99    17    

Многопоточное ускорение однопользовательских нагрузок в 1С + Microsoft SQL Server 2017

Практика программирования Производительность и оптимизация (HighLoad) v8 v8::Запросы Бесплатно (free)

Взаимодействие с Microsoft SQL Server нередко вызывает трудности у 1С-ников, а потому интересны любые моменты, связанные с его использованием. О своем опыте работы с новым SQL Server 2017 участникам конференции Infostart-2018 рассказал директор ООО «Аналитика софт» Дмитрий Дудин.

11.06.2019    24977    dmurk    145    

Выдержки из книги Чистый код

Математика и алгоритмы Бесплатно (free)

Недавно я прочитал книгу "Чистый код" Роберта Мартина (Robert Cecil Martin). В ней описываются принципы организации и форматирование исходного кода программы так, чтобы в дальнейшем было легко поддерживать такой код. Эта книга является библией для многих программистов, но вот в среде программистов 1С, к сожалению, не очень распространено чтение подобной фундаментальной литературы. Книга более 400 страниц и так много порой лениво читать, да и времени всегда не хватает. По этому я решил выделить в виде цитирования по разделам самые важные моменты. А также снабдил текст своими примерами кода.

16.05.2019    10470    FreeArcher    105    

Мониторим тяжелые запросы, классифицируем результаты

Производительность и оптимизация (HighLoad) Бесплатно (free)

Дальнейшее развитие инструментария для мониторинга запросов.

08.05.2019    4939    ImHunter    0    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    67231    yuraos    112    

Мониторинг SQL Server с помощью Extended Events (и не только) для 1С. Как держать руку на пульсе?

Производительность и оптимизация (HighLoad) Бесплатно (free)

Что и как мониторить в работе SQL Server, чтобы держать Вашу систему в форме.

05.05.2019    33291    YPermitin    23    

Как работают управляемые блокировки

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

29.04.2019    22945    comol    198    

Мониторим тяжелые запросы

Производительность и оптимизация (HighLoad) Бесплатно (free)

Мониторинг тяжелых запросов с сохранением результатов для истории.

22.04.2019    6922    ImHunter    8