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

Здравствуйте,

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

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

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

2.
Вот это:
странно.

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

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 сервер. Тут уже не простой настольный компьютер нужен, а что-то заметно посерьёзнее.

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

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

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

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

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

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

А не думали логи хранить не в базе, а отдельном текстовом файле, чтобы не чистить его постоянно для повышения отзывчивости системы или, хотя бы, задание глубины сохранения?

Пересчет статистики стоит автоматом каждую ночь, но хорошо помогает, когда и логи вычищены.

А если ли вообще способ очистки событий в сеансах, в нашей базе на данный момент находится порядка 2 миллионов событий, как их очистить?

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

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

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

Понятно, что в принципе это не дольше, чем сидеть прописывать задания для рабочих в ручную - тут скорее всего менталитет - хочется все быстро и сразу)