Аксапта. Производительность. Эпизод n+1-й

[Recoilme]

Цитата:

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

Ваша правда, и про varchar, и про не заполняет, везде стоит заполнение по default и всюду not Null constraints

Интересно почему никто не добавляет при таких открытиях матные слова в её адрес? ))

[Falcon]

Я для монироринга использую SpotLight by Quest Software. Только ни фига оно не мониторится. То есть показывает, что все ОК - кроме 200000 shared блокировок и периодического своппинга. Никаких проблем не обнаруживается.

[Falcon]

Цитата:

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

Я бы тоже на это поставил... если б не отсутствие зависимости этой глюки от количества юзеров. Т.е. хоть нас там 30 человек, хоть я один - все равно три часа. В таком случае, какие-такие могут быть "другие процессы", конкурирующие за "мою" таблицу? Аксапта вроде никакими внутренними пересчетами не занимается (IMTS, напомню, выключена!).
Барабашка?

[Wamr]

Запрос SELECT * FROM SalesLine A (UPDLOCK) WHERE ((DATAAREAID=?) AND (SALESID=?)) ORDER BY A.DATAAREAID,A.SALESID,A.LINENUM
по идеи, должен использовать индекс SalesLineIdx.
Складывается ощущение, что этого не происходит и тогда получается полный скан.
Предлагаю перестроить индекс и обновить статистики.

[Falcon]

Это - непосредственно запрос сиквела.

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

Структуру не меняли уже несколько лет...

[ALES]

Цитата:

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

Это - непосредственно запрос сиквела.

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

Структуру не меняли уже несколько лет...

чудеса с производительностью наблюдал как результат подъема модификаций без перезагрузки AOSа..

а дидлоки в этот момент действительно есть? (ну три часа, вопли других юзверей и все такое..)

[Yprit]

Неплохо бы профайлером или еще как отловить конкретные значения условий и посмотреть, что в них такого особенного...

[Falcon]

Цитата:

а дидлоки в этот момент действительно есть? (ну три часа, вопли других юзверей и все такое..)

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

Цитата:

Неплохо бы профайлером или еще как отловить конкретные значения условий и посмотреть, что в них такого особенного...

Условий - чего?

[ALES]

Цитата:

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

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

Вот где-то по Ok он сам себя держит, искать где еще к salesLine стучится.. не так давно на форуме пример нераспознаваемого SQLом дидлока мелькал.

[Yprit]

Цитата:

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

Условий - чего?

Условий запроса, т.е. какие значения DATAAREAID и SALESID уходят на сервак. А потом прогнать в QueryAnalyzer и посмотреть, что он выдаст в качестве плана.

[Falcon]

Хорошо, попробую..

[Yprit]

возможно, там в choosLines какой-то затык - то, о чем ALES писал.

[Falcon]

И тебе спасибо, синьор модератор.

Специально для тебя, еще раз: версия 2000, сп3а.

Предложения интересные. Попробую.

[Vadik]

Цитата:

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

Специально для тебя, еще раз: версия 2000, сп3а.

Спасибо, я в курсе того, на чем Вы работаете
Собственно, вопрос был адресован itfs - подозреваю, что он-то как раз имел в виду другую СУБД

[Falcon]

Про дисковый массив - у меня уже давно подозрения Все "штатные" средства диагностики показывают полное отсутствие проблем, однако же чисто субъективно: ну не может такое железо быть таким медленным... Сервер, кстати, самая что ни на есть фирмА, известной фабрики ИБМ, с пятым рейдом и 10К Ultra-SCSI хардами - в общем, не хужей чем у других... А тащится как телега несмазанная в гору...

[2A]

Цитата:

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

Про дисковый массив - у меня уже давно подозрения Все "штатные" средства диагностики показывают полное отсутствие проблем, однако же чисто субъективно: ну не может такое железо быть таким медленным... Сервер, кстати, самая что ни на есть фирмА, известной фабрики ИБМ, с пятым рейдом и 10К Ultra-SCSI хардами - в общем, не хужей чем у других... А тащится как телега несмазанная в гору...

По железу:
RAID-5 - не самый быстрый
Сколько всего RAID массивов ?
В идеале необходимо 3.
(3 года назад уже ставили Axapta на хороший сервер с дисковой подсистемой имеющей оптоволоконный интерфейс с сервером; это быстрее чем Ultra-SCSI )

[Falcon]

Цитата:

Сообщение от 2A

По железу:
RAID-5 - не самый быстрый
Сколько всего RAID массивов ?
В идеале необходимо 3.
(3 года назад уже ставили Axapta на хороший сервер с дисковой подсистемой имеющей оптоволоконный интерфейс с сервером; это быстрее чем Ultra-SCSI )

Три и есть - один под программы, другой под базу, и третий - под log-файлы.

Про оптоволокно - учту на будущее, спасибо.

[Torin]

Цитата:

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

Про дисковый массив - у меня уже давно подозрения Все "штатные" средства диагностики показывают полное отсутствие проблем, однако же чисто субъективно: ну не может такое железо быть таким медленным... Сервер, кстати, самая что ни на есть фирмА, известной фабрики ИБМ, с пятым рейдом и 10К Ultra-SCSI хардами - в общем, не хужей чем у других... А тащится как телега несмазанная в гору...

5-й RAID очень отказоустойчивый, при этом экономичный, но далеко не самый быстрый на чтении. Для производительности на чтении, лучьше переделать в 1+0 (10), если размеры базы позволяют. В Вашем случае полезный объем будет 5-ти дисков
http://www.ixbt.com/storage/raids.html
Еще советую на www.sql.ru почитать по теме.

[perestoronin]

Цитата:

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

5-й RAID очень отказоустойчивый, при этом экономичный, но далеко не самый быстрый на чтении. Для производительности на чтении, лучьше переделать в 1+0 (10), если размеры базы позволяют. В Вашем случае полезный объем будет 5-ти дисков
http://www.ixbt.com/storage/raids.html
Еще советую на www.sql.ru почитать по теме.

Осмелюсь добавить, 5-й тормозит как "пятая нога" (или "пятое колесо") на операциях по обновлению и вставке записей. А такие операции при интенсивном обновлении информации (как раз случай Аксапты) не редкость. При этом высокая производительность на операциях чтения становится просто незаметной на фоне общих тормозов. Рейд 5 противопоказан Аксапте! Лучше всего 10-й рейд (по соотношению - цена / производительность операций обновления-вставки) или хотя бы "зеркало".

[perestoronin]

Цитата:

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

Про дисковый массив - у меня уже давно подозрения Все "штатные" средства диагностики показывают полное отсутствие проблем, однако же чисто субъективно: ну не может такое железо быть таким медленным... Сервер, кстати, самая что ни на есть фирмА, известной фабрики ИБМ, с пятым рейдом и 10К Ultra-SCSI хардами - в общем, не хужей чем у других... А тащится как телега несмазанная в гору...

Сталкивался с таким, работает как тормоз, ситуация изменилась к лучшему когда вместо него ввели в эксплуатацию более производительный и значительно более дешевый (не IBM) с десятым рейдом.

PS. Если нет возможности заменить дисковый массив, то уж лучше тогда использовать "зеркало", чем "пятую ногу", "десятка" конечно лучше, спору нет.