Прекращение поддержки работы VOGBIT на оборудовании x86 - В 2025 г. мы планируем прекратить поддержку работы VOGBIT в 32-битных (x86) операционных системах

Последние темы на форумах VOGBIT

Вопрос на тему "Технология подробно" - Состав и технология
Zms.komissarov: Нужно открыть, какой-нибудь (из какого удобно печатать) вариант "подробного" графика производства, там выбрать соответствующую опе ...
Не отображается выпадающий список, а также неактивна кнопка "Импорт" - Ошибки в работе
Сергей: написал: Не отображается выпадающий список при нажатии на стрелочку Напишите на mailto:info@vogbit.ru info@vogbit.ru Попробуем починить
Вывод DXF или моделей в отдельную папку - Терминалы
Константин Чилингаров: Здравствуйте, Обычно, непосредственно с терминала выгружают управляющие программы какие-нибудь, к заданию, которое берется в работу. Н ...
График производства. Выполнение (по выделенным) - Производство
Zms.komissarov: Спасибки.
Комментарий к операции - Состав и технология
Zms.komissarov: Спасибо.
Пример создания плагина - Плагины
Bochik_88: С этим вопросом разобрался, спасибо)
Состав изделия - Состав и технология
Константин Чилингаров: К сожалению, проблема хронического отсутствия времени пока не позволила сделать. Лежит заготовка под второй ролик с лета. Пока отложена ...
График производства. Не отображает ТТП. - Производство
Константин Чилингаров: написал: Честно говоря, "средний" уровень как-то никогда не рассматривали для работы. Всё меняется... 10 лет назад там действитель ...
Множитель - Состав и технология
Константин Чилингаров: написал: Можно, пожалуйста, выложить скрины, как это реализовано Пожалуйста: Рис.1 - Параметры в справочнике. Которые я использовал, ка ...
Ошибка программы после обновления - Общие вопросы
Константин Чилингаров: Здравствуйте! Да, встречали такую ситуацию. Но, к сожалению, пока никак не можем научиться её стабильно повторять. Не можем пока найти к ...
Календарный план - Прочее
Veruz: Благодарю за ответ.
Установка - Установка
Константин Чилингаров: Здравствуйте, На совсем понял, если честно вопрос в Вашей терминологии. Давайте попробуем ещё раз разложить всё по полочкам…   Вы ...
Обновление тестовой базы - Обновление
Glavtech: Спасибо, проблема устранена
Сортировка по алфавиту и фильтр - Интерфейс программы
Константин Чилингаров: Здравствуйте, Ок. Принято. Записал в список пожеланий. Спасибо!
Единица нормирования при создании производственных заданий - Состав и технология
Константин Чилингаров: Здравствуйте, Вместе с расчетом материала на 7 шт. еще и штучное время поделилось на 7 В этом есть логика. Обычно эту "единицу нормир ...
На экране "распределение работ" при обновлении происходит смещение вправо. Приходиться каждый раз проматывать обратно - Производство
Константин Чилингаров: Здравствуйте, Не совсем понятно. Если речь идёт об окне, где отражается график работы и загрузки постов по дням и сменам (высокий/максим ...
Складской учет - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте,   Чтобы изделию «назначился» в программе некий «склад», куда такие именно изделия из производства сдавать, для этого д ...
Проблема при установке - Демо версия
Владимир Белов: Добрый день! Попробуйте выполнить установку еще раз, MSSQLLocalDB, установленный в первую попытку, должен подхватиться программой установки ...
Планирование производства - Демо версия
Sgrekhv: Извиняюсь, не в ту тему написал
Отсутствуют кнопки в поле правка - Установка
Константин Чилингаров: Здравствуйте! Не совсем понятно. Не могли бы Вы приложить скриншот, пожалуйста? Вообще, если речь идёт о вкладке меню "Правка" (в л ...

Производительность ПК

Вопросы, связанные с установкой и запуском программы - Установка - Вопросы новичков
Страницы: 1
Производительность ПК
 
Здравствуйте.
Возникла такая проблема. Мы имеем производственные заказы на одни сутки в количестве от 400 до 500 шт., количество изготовляемых деталей на все эти заказы может составить примерно от 500 до 1500 шт., и изготавливаем все это на 140 постах.
Вопрос: Мы не можем понять почему так медленно работает программа и так долгоооооооо думает.
Мы имеем следующий ПК:
Intel Core I 3 – 4 ядра — 3.4 Ghz и 4 Гб ОЗУ. (Windows 7)
Вот пример как работает на 120 заказах..
1. Перевожу из производственных заказов в режим график производства все 120 заказов и это занимает у меня от 20 до 30 минут или вообще программа не отвечает.
2. В графика производства, создать задание, у меня занимает про времени от 4 до 7 часов.
3. На одном рабочем месте закрываю все заказы как выполненные за одну смену, программа закрывает их часа два... и т.д.
Когда программа работает смотрю загрузку ресурсов ПК, показывает что из 4 ядер не работает не одино и загрузка ЦП составляет 1-4%, ОЗУ загружено только файлами windows.
В чем проблема и как решить ее пока ума не приложим....может у вас была такая проблема?
 
Здравствуйте,

Да уж. Цифры (длительность) заоблачные какие-то.

1.
1500 наименований деталей в день на 140 постах...
Неплохо так...

При реальной работе с такими объёмами надо SQL сервер, мне кажется, ставить уже не на бытовой компьютер с 4G ОЗУ. Тут надо какой-нибудь настоящий сервер уже. С быстрыми винтами, много памяти, много процессоров...

2.
Вот это:
Цитата
Евгений Спиридонов пишет:
Когда программа работает смотрю загрузку ресурсов ПК, показывает что из 4 ядер не работает не одино и загрузка ЦП составляет 1-4%, ОЗУ загружено только файлами windows.
странно.

Вы загрузку чего смотрите? Сервера? Или клиента? Или у вас это всё на одном компьютере?
По идее, при таких объёмах сервер должен быть загружен прилично при выполнении каких-нибудь операций типа создания заданий. И процессоры все должны быть загружены и пямять. Тем более, что её мало.
Если этого нет, то такое впечатление, что просто ничего не происходит.

3.
Как часто вы обслуживаете свою базу и как это делаете?
Вы вообще в этом направлении что-то делаете?

Наводящие вопросы:
Какого размера у вас сейчас база данных (сколько занимает на диске)?
Как часто вы чистите журнал событий? сколько у вас сейчас там записей (сеансов/событий)?
Как часто вы выполняете "пересчёт статистики" для этой базы?

Резюме:
1. Лучший вариант, чтобы сказать что-то поконкретнее - дайте копию базы, посмотрим. Можно сделать резервную копию, выложить её на файлообменник какой-нибудь и прислать нам на e-mail ссылку, где можно скачать.

2. При реальных объёмах, как вы озвучили, нужно использовать в качестве сервера не бытовой компьютер, а настоящий сервер со всеми вытекающими. Также большое значение приобретает регулярное регламентное обслуживание базы данных.
 
Отправил ответ почтой.
 
Результаты испытаний:

В качестве подопытного экземпляра использовался компьютер постарее и послабее вашего:

intel core 2 quad cpu q9550 @ 2.83GHz, 4ГБ

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

Итоги, выводы:

Пересчёт статистики в этой базе, похоже, никто не делал никогда.

Для начала запустили как есть. График производства для всего, что есть (2114 позиций), открылся примерно за 9 минут.

Пересчитали статистику в базе. График производства на тех же самых данных стал запускаться где-то 7 секунд.

С созданием заданий чистый эксперимент не вышел. Выделил все позиции, какие были без заданий в Графике производства (где-то 900+ по моим подсчётам), и попробовал создать для них всех задания (уровень выбрал «высокий»). Чистота эксперимента была сорвана тем, что постоянно пришлось жать «Ок» на окошки с сообщением типа «Для того-то того-то не создано ни одного задания». То ли техпроцессов там нет на половину позиций в Графике, то ли трудоёмкости. Разбираться не стал, т.к. не в этом был вопрос.

Создавалось, конечно, долго… Но не 7 часов, безусловно.
Где-то минут 40, примерно, с учётом постоянных нажатий на «Ок» в очередном окошке с сообщением.
Потом проверил для сравнения на минимальном уровне на том же объёме – где-то 15 мин. В принципе, не так плохо, учитывая количество и то на каком компьютере это делалось.

Но тут вопрос другой. Тут, всё таки, действительно реально много заданий создаётся за один заход. «Высокий» уровень, и счёт идёт на тысячи (создалось за один раз 1800 заданий где-то). Тут вопрос, нужно ли их создавать за один раз в таком виде и в таком количестве? Предположим, можно взять сервер помощнее, поставить вечером, и минут за 20 всё создастся. И 3, и 4 тысячи заданий. Но надо же ещё дальше что-то делать завтра со всеми этими заданиями. С таким количеством.

Не запаритесь дальше с таким количество созданных за раз заданий работать? Тут надо подумать, мне кажется, как лучше сам процесс организовать, если реально такой поток всего идёт. Может агрегировать как-то, укрупнять. Люди, например, метод «по комплектам» придумали в производстве металлоконструкций. Как раз для решения такого типа проблем (выдача заданий и учёт работ при огромной номенклатуре и большой скорости её изготовления). Может, что-то подобное применить, может, ещё что… Рекомендую обратить внимание на этот аспект. Мало ведь создавать задания тысячами, надо как-то процедуру дальнейшей работы с ними же организовывать.

Резюме:

1. Обязательно регулярно выполняйте пересчёт статистики. Его нужно делать периодически, чтобы база не «тупила». Чем более высокая интенсивность работы с базой, тем чаще надо делать. Хоть каждый день. Времени это занимает несколько секунд (пересчёт). Прирост производительности, как вы видите колоссальный в итоге (по вашей базе, на примере времени открытия Графика производства – с 9 мин до 7 сек) .

2. Пока, как я понял по базе, вы не использовали «высокий» уровень учёта. Только для пробы пример, может, какой-то. Если всерьёз намереваетесь использовать именно «высокий» уровень при таком количестве заказов/позиций/постов, то задумайтесь о кардинальном upgradе'е железа, на котором крутится SQL сервер. Тут уже не простой настольный компьютер нужен, а что-то заметно посерьёзнее.

И от себя рекомендую, в этом случае больше внимания уделить вопросу методологии. Как, кому, и какие задания выдавать, как закрывать их. С практической точки зрения. Если задания создавать каждый день по несколько тысяч, то компьютер то справится, можно в конце концов помощнее поставить. Но дальше то люди должны будут что-то делать с этим огромным количеством заданий. Им то как будет?
 
Чтобы выпустить Пересчёт статистики, нужно подключиться к базе с помощью Managenent Studio и выполнить процедуру:

[Health].[UpdateStatistics]
 
Спасибо большое за анализ!
Пересчет статистики никто не делал - я вот только узнал о том, как его сделать.

По поводу заданий.
Картина следующая. На завод поступает заявка на изготовление, например, 100 изделий. Изделия разные. Конструкции практически одинаковые за исключением размеров. Для повышения производительности, при вводе заявки в vogbit, я завожу описания изделий с разбивкой по группам размеров + все возможные изменения конструкции оформляю отдельными узлами. В итоге оператор выбирает нужные блоки для формирования заявки. Сейчас вручную, потом оформлю все в конфигураторе.
Для каждого рабочего места формируется задание. Оно и сейчас формируется, но вручную, наобум, по такому же вручную сформированному заводскому графику. Поэтому точности в планировании нет никакой.
В конечном итоге сейчас я пытаюсь запустить реальный, подтвержденный трудоемкостью, документооборот в производстве при помощи Vogbit, заменив им ручной, создаваемый методом тыка.
Не думаю, что трудоемкость работы с программой будет выше ручных перестановок в графике в попытках угадать реальные сроки изготовления. Но посмотрим.
Думаю, что можно будет разбить обработку заказов на группы по определенным параметрам изделий. В крайнем случае выработаем алгоритм постановки изделий в производстве (очередность).

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

По поводу методологии - спасибо, будем думать над вопросами оптимизации работы. Работники в любом случае все эти операции выполняют. С другой стороны часть операций можно объединить, если они производятся на одном и том же месте теми же людьми, либо если операции имеют схожую технологию и являются соседними.
Большая группа деталей будет или уже изготавливается по отдельным графикам. Это детали постоянного и группового применения. В составе изделия они фигурируют уже в качестве комплектующих.

По поводу учета. У нас пока все шаги были пробными. Задания формировали на большое количество изделий на высоком уровне учета. Проблемы с производительностью "вылезли" буквально пару дней назад. До этого особых проблем не было.
Видимо, все же, вопрос в том, что не производился пересчет статистики - это поправим.
Изменено: Валерий - 06.12.2014 06:38:31
 
Сделали пересчет статистики - забегало в разы шустрее.
 
А не думали логи хранить не в базе, а отдельном текстовом файле, чтобы не чистить его постоянно для повышения отзывчивости системы или, хотя бы, задание глубины сохранения?
 
Цитата
Валерий пишет:
не в базе, а отдельном текстовом файле
это плохое решение.

Цитата
Валерий пишет:
задание глубины сохранения?
Думали.
В предыдущей программе у нас так и было. Тогда был типичный вопрос: "А нельзя всё писать? Пусть будет, мы разберёмся..."

P.S.
Постоянно не нужно чистить. Достаточно иногда.
А вот пересчёт статистики можно делать почаще. Лучше всего поставить его, как задачу в scheduler.
 
Пересчет статистики стоит автоматом каждую ночь, но хорошо помогает, когда и логи вычищены.
 
После массового удаления чего-либо (в частности, сеансов) неплохо также запускать процедуру [Health].[RefreshDependencies]. Можно сделать сжатие базы данных (shrink). Но это точно не нужно делать слишком часто.

https://vogbit.ru/forum/messages/forum16/topic1127/message6997/1127#messages6997
 
А если ли вообще способ очистки событий в сеансах, в нашей базе на данный момент находится порядка 2 миллионов событий, как их очистить?
 
Зайти в Администрирование - Сеансы.
Выделить все закрытые сеансы (у которых дата закрытия не пустая).
Нажать удалить.
И ждать, пока удалится...

После этого сделать Shrink базы данных, пересчёт статистики и зависимостей.

И резервную копию базы данных перед всем этим не забудьте сделать, конечно.
 
У нас тоже стала "подвисать" программа, особенно когда работаем в окне подразделения, привязываем участки к постам, людям и прочее.
Также при формировании графика производства - очень сильно стал подвисать. Вопрос с покупкой сервера уже решен (я в это чайник) - и знаю только как чистить сеансы. А все что у вас выше описано знать не знаю как  (и сис. админ как раз уволился :cry: ) А раз ответственный за вогбит я, то хотелось бы быть в курсе, как увеличить производительность программки, потому как если хоть один человек сидит в режиме подразделения и корректирует там что то, у всех пользователей все подвисает, людей это бессит, в прямом смысле этого слова;)
Какую нибудь бы инструкцию для чайников надо бы :)
Изменено: Анастасия Алексеева - 27.10.2015 19:45:37
 
Чтобы не "подвисало" нужно обслуживать базу данных:

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

Это всё на форуме уже много раз писалось.

Если информации на форуме не достаточно, то оплачивайте поддержку, мы вам лично напишем персональную инструкцию "для чайников".
 
Формирование заданий из 100 деталей на минимальном уровне в течении 3-5 минут это норм для программы? Установили новые современные сервера (думали проблема в них), делаем периодически перессчет статистики, удаляем переодически события, но производительность совсем не улучшилась. Чуть только стоит залезть в подразделени - настройка постов, участов, что либо поменять, удалить,добавить- зависание всего. Работа с графиком производства, формированием заданий - зависание - что же будет если перейдем на более высокие уровни? Сотрудники очень не довольны - особенно когда аврал в работе
 
Ну пришлите базу посмотреть что ли... Глянем, что там у вас...

Да, процедура создания заданий достаточно ресурсоёмкая. Несколько минут - это нормально.
Сколько по времени вы изготавливаете эти 100 партий деталей?

Цитата
Анастасия Алексеева пишет:
только стоит залезть в подразделени - настройка постов, участов
А зачем туда лазить то?

а) это ж настраивается 1 раз в жизни. Ну, может, потом как-нибудь ещё пару раз в жизни зайти, что-нибудь поправить или ввести одну-две строчки ещё. Зачем туда лазить то всё время в это место?

б) На минимальном и среднем уровне "посты" вообще не нужны.

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

Понятно, что в принципе это не дольше, чем сидеть прописывать задания для рабочих в ручную - тут скорее всего менталитет - хочется все быстро и сразу)
 
Я бы не рекомендовал возиться с заведением работников до тех пор, пока это реально не понадобится.
На "среднем" уровне они не нужны.
Когда вы реально дойдёте до "высокого" или "максимально" - не ясно. За это время тысячу раз всё поменяется, а вы будете всё это время делать лишнюю, бесполезную работу. Человек придёт - вы его заведёте, уйдёт - вы его удалите. Поскольку реального персонального учёта в программе в это время не ведётся - в этих действиях нет никакого смысла. Что выполняли их, что нет - результат одинаковый.

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

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

P.S. Операции с привязкой работников к подразделениям выполняются действительно довольно долго. Но и делать их массово приходится редко.
Страницы: 1
Сейчас на форуме
Всего зарегистрированных пользователей: 4105
Приняло участие в обсуждении: 425
Всего тем: 804
Всего сообщений: 6067

×
Вход на сайт