Борьба с нагрузкой на систему.

[bucken]

Постановка:
Куча пользователей (100) из них ОДНОВРЕМЕНО 30 обрабатывает заказы - в результате аксапта начинает жутко тормозить. Иногда это бывает блокировки, иногда просто тормозит и все. Кто нибудь занимался оптимизацией быстродействия в данном месте? Как бороться короче говоря?

P.S. Axapta 2.5 и железо нормальное.

[Andrew Besedin]

Привет!
Не конкретный вопрос какой-то...

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

Обнови статистику на базе.

Проанализируй результаты DBCC SHOWCONTIG - полезная функция.

Внимательно посмотри, какие методы выполняет Аксапта при обработке - может, можно часть отключить (только это нужно делать аккуратно)

И т.д.

[glibs]

Цитата:

Изначально опубликовано bucken
...из них ОДНОВРЕМЕНО 30 обрабатывает заказы...

Обрабатывают — это как? Обработка обработке рознь...

Цитата:

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

Хм... а вы думали, она очень быстро разгонится и оторвется от земной орбиты?

В смысле, это нормально, что она тормозит.

Цитата:

Изначально опубликовано bucken
...Как бороться короче говоря?...

Есть один способ...

Вообще в штатном режиме буржуи не занимаются тем, что открывают заказики, смотрят на них, кнопочки нажимают и ждут, когда же это все закончится. Они заводят себе сервер пакетной обработки, обработку всех инвойсов и packing slip'ов вешают на этот сервер пакетной обработки и не дожидаются, пока все обработается, а продолжают работать дальше.

Потом они заходят в Расчеты с клиентами (поставщиками)\Запросы\История\Заказ\... (дальше на ваше усмотрение) и смотрят что обработалось, а что нет. Там есть текст для операций, завершившихся с ошибкой.

Вот такие вот они, буржуи.

Может и у вас получится так работать? Только пакетная группа должна быть одна для операций, дергающих номенклатуру и проводки в ГК. Так вероятность возникновения блокировок будет наименьшей.

PS. Sorry, все пути по 3.0.

[bucken]

Спасибо за информацию.
Будем разбираться дальше. А результатах обязательно сообщу.

[Lazy_Tiger]

а с сервером все хорошо?

в том смысле, что там диски не иде, памяти много достаточно, процессора не селероны, сеть не коаксиал ? и база грамотно (на www.mazzy.ru была статья на тему) раскидана по дискам?

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

[mazzy]

придется-придется... там Аксапта уже покуроченная

bucken, вы на файловые группы хотя бы закончили разбивать, чтобы в полную силу задействовать таки оба диска или все по прежнему на одном raid'е?
В свое время были tablescan'ы жуткие. Особенно по inventDim.
Полное сканирование таблиц хоть победили?

[bucken]

Цитата:

Изначально опубликовано mazzy
придется-придется... там Аксапта уже покуроченная

bucken, вы на файловые группы хотя бы закончили разбивать, чтобы в полную силу задействовать таки оба диска или все по прежнему на одном raid'е?
В свое время были tablescan'ы жуткие. Особенно по inventDim.
Полное сканирование таблиц хоть победили?

к сожалению нет.
Но большое всем спасибо за инфу!!!

[Lazy_Tiger]

Хочется уточнить...

правильно ли я понимаю.
Вы хотите лечить проблему методом "отломить чего нить в аксапте" не проделав элементарные вещи известные _любому_ DBA по оптимизации самого SQL сервера?

РАДИКАЛЬНО... уверены в правильности подхода?

[bucken]

Насчет РАДИКАЛЬНЫХ подходов по отламливанию....
Вовсе мы не так категоричны....
А на счет того, что можно легко определить любой DBA, что там крутиться и делается на СУБД Аксаптой - это по моему темный лес: запросы вида exec sp2342345233 12 12 ВАМ о чем нибудь говорят? Так вот - таких большинство. И только используя совместо средства мониторинга Аксапты со средствами мониторинга СУБД можно чего-то понимать.

P.S. Я не DBA - не скрываю.

[Lazy_Tiger]

хм... эт какие такие sp в аксапте? это ваше локальное изобретение?

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

[bucken]

Да нет не изобретиния....
MS SQL Profiler это показывает. (Я может чуть ошибся в точном написании - но в целом картина такая).

[mazzy]

bucken, смотри профайлер тщательнее.

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

Согласен с Lazy_Tiger, это уже тонкая настройка.
Начать надо с обычных для DBA вещей - со статистики и с планов исполнения запросов с table scan'ов.

Далее индексы. Убрали наконец индекс с поля name в LedgerTrans? Я понимаю что два программиста назад этот индекс создали для переноса в sd. Но еще тогда мы говорили, что так нельзя делать! Кстати, это тоже обычный dba может решить - нужность существующих индексов и/или необходимость новых.

Далее мониторинг исполнения запросов в Аксапте. У вас я про эту штуку уже раза три рассказывал. Но готов рассказать еще раз

bucken, у вас же Слава отлично такие вещи знает и делает, когда ему время на это выделяют Или сейчас на тебя эту задачу возложили?

[bucken]

Да нет никто особо не возлагал - просто надоело(и не только мне) торможение системы.

[mazzy]

а... тогда все просто.
Надо выделить время, сесть и сделать

[bucken]

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

[mazzy]

конкрентно для аксапты - не видел.
а общезначимые были на www.sql.ru

[Lazy_Tiger]

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

хотя можно и на www.sql.ru

[ax_f]

Цитата:

Изначально опубликовано glibs

Вообще в штатном режиме буржуи не занимаются тем, что открывают заказики, смотрят на них, кнопочки нажимают и ждут, когда же это все закончится. Они заводят себе сервер пакетной обработки, обработку всех инвойсов и packing slip'ов вешают на этот сервер пакетной обработки и не дожидаются, пока все обработается, а продолжают работать дальше.

Повесить обработку инвойсов на сервер пакетной обработки с помощью стандартной функциональностью нельзя?
Надо программить?

[mazzy]

инвойсы - можно. в периодических операциях.

а вот с российскими счетами-фактурами... разноску СФ в пакетах действительно придется программировать.

[glibs]

Цитата:

Изначально опубликовано ax_f
...
Повесить обработку инвойсов на сервер пакетной обработки с помощью стандартной функциональностью нельзя?
...

На всякий случай уточните, что именно вы понимаете под обработкой инвойсов. Инвойс ("накладная") по закупке?