Тормозит операция комплектации и не только - DAX: Администрирование

Natka_imported · 21.11.2004, 20:44

Доброе время суток всем.

Ребята. помогите, please. Две недели работаю по ночам только потому что, (я так подозреваю

) неправильно что-то где-от настроили. Ситуация в следующем:

работаем на ахапте с системе розничной торговли. Формат магазина - гипермаркет. Соответственно создается в течение дня заказ с огроменным кол-вом строк (1500 и больше)и когда начинается его обрабтка, все юзеры вешаются. При это надо пройти все стадии работы с Заказом(отгузка, отбор, накладная, так как используются почти все складские аналитики) и делать это в течение рабочего дня нет никакой возможности. Резервирование проходит в течение 2 часов, комплектация еще больше. Накладная обрабатывается в течение 3 часов.

Был вариант использования Системы множественных складских транзакций, но как-то она не очень помогает. Галочка exclusive mode в настройках тоже как-то не очень помогла.

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

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

Заранее благодарю за помощь.

**mazzy** · 21.11.2004, 20:47

Цитата:

Сообщение от Natka

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

1500 строк - это далеко не огромный заказ. Это просто большой заказ

Надо выполнять анализ. Что делается, какие запросы выполняются, как долго, где выполняется tablescan. Это обычная работа администратора и программиста.

см. http://axapta.mazzy.ru/hints/querytuning/

**mazzy** · 21.11.2004, 20:48

Да, и еще.
Начните с индексов на ГТД. Обычно это одна из самых тормозящих вещей при работе со складскими проводками.

**mazzy** · 21.11.2004, 20:53

И еще одно.
Иногда очень помогает усиление сервера.

Вот здесь описано очень радикальное решение
http://axapta.mazzy.ru/articles/axapta_itanium/
Но действенное.

Вывод: анализируйте, думайте, выбирайте решение.
Серебрянной пули нет.
Начните таки с анализа и программной оптимизации, дайте работу админу.

Natka_imported · 21.11.2004, 21:38

Это конечно очень хороший совет: у дайте работу для размышления программистам и сисадминам.

Мне хотелось бы знать, что подобная реакция ахапты от неправильной настройки функиональных параметров, или от неправильного обращения с ms sql server и оборудованием?

1500 да это просто большой, а как насчет 6000 строк?
Уже вторую ночь пытаюсь его скомплектовать и никак

**mazzy** · 21.11.2004, 22:20

Цитата:

Сообщение от Natka

Мне хотелось бы знать, что подобная реакция ахапты от неправильной настройки функиональных параметров, или от неправильного обращения с ms sql server и оборудованием?

Скорее с ms sql.
Скорее не "неправильное обращение".
Скорее надо говорить об отсутствии ухода.

Например, если кожу рук не смазывать кремом, то кожа очень быстро грубеет и покрывается морщинками. Если при этом работать с вредными средами (стирать например руками), то кожа очень быстро покрывается язвочками.

Думаю, что описанный вами случай из этой оперы.
Ласка, чистота и смазка.
Это нравится и компьютерам тоже.

**mazzy** · 21.11.2004, 22:23

Цитата:

Сообщение от Natka

1500 да это просто большой, а как насчет 6000 строк?
Уже вторую ночь пытаюсь его скомплектовать и никак

Это не вопрос.

Что значит: не можете скомплектовать?
Что происходит с deadlock'ами.
Какие запросы тормозят?
Сколько tablescan выполняется за ночь пока вы комплектуете?
Какова дисковая очередь?
Какова загрузка процессоров?
Что происходит со свопом?

Соберите статистику, наконец.
Тогда и вопрос у вас получится правильный.
А правильный вопрос - половина ответа.

Natka_imported · 21.11.2004, 22:26

Mazzy, вы надо мной тихо издеваетесь

Ну да,ю я конечно, многое не знаю про ахапту. И с компьютерами нежно... не привыкла... Они же не живые.
Завтра утром озадачу программистов, спс за совет

Natka_imported · 21.11.2004, 22:34

Наверное поздновато, но лучше поздно... Начинаю собирать статистику

**mazzy** · 21.11.2004, 22:36

Цитата:

Сообщение от Natka

Mazzy, вы надо мной тихо издеваетесь

Natka, ни в коей степени.
Старался говорить на языке, который вам близок и обыденен.

Именно из-за того, что вы предупредили, что в задачей столкнулись недавно.
А хотелось вам дать в руки не знания, а ощущения, когда вас завтра начнут водить за нос

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

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

Удачи вам в завтрашнем разговоре.

Natka_imported · 21.11.2004, 22:50

Спасибо за пожелание удачи, Mazzy. Вы настоящий джентельмен. опустили. что я почти не заметила

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

**mazzy** · 21.11.2004, 22:51

Цитата:

Сообщение от Natka

Вы настоящий джентельмен. опустили. что я почти не заметила

.

Извините.

Sergik · 22.11.2004, 13:01

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

Хотя, скорее всего, у вас БОЛЬШИЕ проблемы с качеством программных доработок, по которым естественно нельзя дать конкретный удаленный совет, тем не менее сообщите технические характеристики вашего всего серверного оборудования. Тип архитектуры трехзвенная? Количество конкурентных пользователей? Объем базы данных?

**Vadik** · 22.11.2004, 13:12

Может быть, есть смысл начать с версии аксапты?

Вообще-то странно, что эти вопросы задает экономист, это при живых-то администраторах и разработчиках

Sergik · 22.11.2004, 13:17

Раз внедрение идет, значит очевидно 3-ая версия.

Вот что еще интересно: требуемое (приблизительное) количество строк заказов за сутки (ввод и обработка). Приблизительно понятна будет необходимая мощность системы.

Alks · 23.11.2004, 07:32

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

Даже если бы заказ разносился 20 минут, а не 6 часов, это было бы проблемой.

По поводу системных мощностей - они у нас более чем достаточные, при выполнении всех вышеописанных операций загрузка AOS-сервера и SQL-сервера ни по процессору ни по памяти ни по обращений к диску не превышает даже 50%. Сетку еще надо померять... но как бы там ни было - проблема не в том что пользователи слишком медленно работают, а в том что их работа просто блокируется.

lastelf · 23.11.2004, 08:36

Попробуйте на SalesLine создать индекс, включающий в себя ItemId, SalesId и InventDimId. Посмотрите, не улучшит ли это ситуации с обработкой заказа

Natka_imported · 23.11.2004, 15:31

Доброе время суток.
Версия 3.0 сервис пак2, насчет статистики обработки напишу чуть попозже.
Что странного в том, что я экономист-информатик?

**Vadik** · 23.11.2004, 16:16

Цитата:

Сообщение от Natka

Что странного в том, что я экономист-информатик?

Ну вот, уже теплее. А какова она, Ваша типичная номенклатура? Например, какие складские аналитики у нее настроены?

В ТЕПЛИЧНЫХ условиях (1 пользователь, у 90% всей номенклатуры складские аналитики - ТОЛЬКО СКЛАД) вчера все операции по заказу на 2000 строк проходили конечно не моментально, но порядка 5-6 минут. Приложение почти

стандартное, но на половине таблиц из Top 50 есть модификации в структуре. Плюс регулярное выполнение операций "Очистки" из штатного функционала. Плюс обновление статистик. Плюс.. Плюс.. В общем, все то, что обычно делает администратор или разработчик, а не экономист. Так что и оставлять на ночь в офисе надо его, а не экономиста. Вот это мне кажется странным.

Если Вам есть что добавить к тому, что Вы уже описали, не стесняйтесь

Кстати, о каких статистиках обработки идет речь?

Alks · 29.11.2004, 11:17

Мдяя...

Отгрузка из 50-ти позиций резервируется от 2-3 до 30-ти минут!

Трехзвеньевая архитектура, мощности серверов примерно следующие:
AOS: Двухпроцессорный Xeon 3.2 (2Мб кэш, 533 шина), 2 Гб ОЗУ.
SQL: Двухпроцессорный Xeon 3.2 (такой же), 8 Гб ОЗУ. 8 винтов в 10 RAID-е + 2 зеркала.
Между собой сервера соединены гигабитной сеткой.
Во время обработок загруженности серверов по любым пунктам (память, винты, сетка) не поднимаются выше 10-20%, только процессор на AOS загружен на 50% и всё.
Полный анализ всех SQL-запросов происходящих в процессе резервирования показал что fullscan-ов нет нигде.
В конфигурации включены аналитики: Склад, Номер партии, Ячейка, Код палеты, Цвет.
База в настоящий момент имеет размер 6 Гб из которых на активную кампанию приходится 2,5.
Во время резервирования из-за блокировок таблиц InventDim / InventSum и пр. колом встаёт служба сервиса и менеджеры по закупкам - ни заказы ни закупки не разносятся.
Конфигурация умеренно модифицировалась, но главным образом поверхностно - в заблокированные таблицы и алгоритмы разносок/резервирования никаких модификаций не было.
Число активных пользователей (периодически создающих и разносящих заказы/перемещения/закупки) - 10-20. Пассивных (просматривающих карточки товаров и очень редко набивающих (но не разносящих) заказы и т.п.) еще 10-20. Все сидят в трехзвеньевой архитектуре.

Вопрос - в чём и где тут подвох??? С такой скоростью при таких блокировках просто невозможно работать!