DAX 2009: Работает очень медленно

[Qaz Qwerty]

Цитата:

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

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

Цитата:

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

не хотите сами почитать, наймите специалистов что-ли.
не должно так быть. и не происходит так.

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

да прочитано уже все. на самом деле это буквально 3 темы, где есть полезное обсуждение.
Производительность
Местами тормозит DAX2009
AX 2009 тормозят формы

Единственная мысль возникла, что может еще сделать ребилд индексов из-под sql (а не reorganize),и еще раз из под аксапты перестроить? сейчас буду делать
...

Цитата:

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

если любая выборка вместо индекса приводит к копированию и к сортировке в tempdb, то tempdb будет тормозить что вы с ним ни сделайте.

в каком случае это происходит?

Цитата:

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

а они до конца выполнились?
какие-нибудь сообщения об ошибках/удачном завершении были?
сколько выполнялось хоть, можете сказать?

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

[mazzy]

Цитата:

Сообщение от Qaz Qwerty

в каком случае это происходит?

когда нет подходящих индексов.
выявить причины - это и есть работа.

некоторые частые причины:
= база повреждена или попала в режим нехватки места на диске - индексов на самом деле нет, хотя в Аксапте объявлены
= не тот collation - sql постоянно применяет функции преобразования кодировки к выборке. на на функциях индексы не работают.
= индексы в таблицах выключили в аксапте (иногда делают для ускорения апгрейда)
= индексов на самом деле не хватает
= индексов на самом деле много - слишком много времени тратится на обновление

кроме того, 4Гб - это очень малый размер памяти. особенно, если у вас 64битная система. если у вас и AOS, и SQL на одной машине, то они скорее всего бьются насмерть за память.

Цитата:

Сообщение от Qaz Qwerty

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

нормально. для виртуалки даже быстро.

[Logger]

Вам Wamr дельный совет дал. Проверьте скорость работы с диском.
Мы встречались с глюком драйвера диска под виртуалку win2003, когда активная работа с диском приводила к прогрузу проца и тормозам.
Есть подозрение что у вас что-то подобное.

Если проблема в скорости работы с диском, попробуйте развести не на виртуалке.

[EVGL]

Сколько компаний в базе? Есть такая ситуация, что работают 2 юрлица в одной БД, где одно - "маленькое" типа 1 Гб, а другое - "большое" типа 10 Гб?

[tvladimir]

Попробуйте отключить проверку прав на уровне фреймворка. Накатите последние обновление на фреймворк. Посмотрите эвентлог на сервере, может там есть к-то ошибки. Уровень совместимости на БД у вас соответствует SQL или ниже? Проверьте, версии клиента и сервера в пределах одного SP. Можно поискать запросы с фулсканами и наиболее медленные запросы и добавить на них индексы. Пинганите AD. Уменьшите использование памяти SQL сервером до Размер физической памяти - 1-0,8 Гб. Файл подкачки установите равным 2 ГБ без динамики (лучше выложить его на отдельный диск для исключения фрагментации). Отключите лишние службы в винде.

[Qaz Qwerty]

EVGL: Компаний много, действительно есть маленькие и есть большие, типа 4GB и совсем пустые, в которых только GL балансы.

[Qaz Qwerty]

Результаты разговора с админами:
Все это по какой то причине установлено на 32битный сервер (так кто-то скомандовал), причем было на standard edition, который работает только с 4GB памяти. Page file был 9GB, то есть он постоянно писался на диск, где уже работает приложение и база данных, что привело к тому, что диск перегружен.
Первое, что они собираются делать, это сделать upgrade до enterprise edition, и это позволит увеличить объем доступной для виртуальной машины оперативной памяти до 9GB.
Дальше, они спрашивают меня, как это все можно перевести на 64б процессор, но я не знаю. С моей точки зрения, это связано с полной переустановкой приложения, и я как то опасаюсь делать это. Достаточно ли просто переустановить все и скопировать файлы application?
Наконец, есть возможность вынести базу данных на другой сервер, где организован быстрый raid, возможно это поможет. Так как я совсем не админ, то прошу прощения, если что-то из терминологии напутано.

[Wamr]

Цитата:

Наконец, есть возможность вынести базу данных на другой сервер, где организован быстрый raid,

ура, товарищи

--------
на мой взгляд, это самое простое, быстрое и правильное решение

[_scorp_]

Цитата:

Сообщение от Qaz Qwerty

32битный сервер (так кто-то скомандовал), причем было на standard edition, который работает только с 4GB памяти.

Ошибаетесь. Ключевое слово AWE. Ищите.

[Alexius]

Цитата:

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

Ошибаетесь. Ключевое слово AWE. Ищите.

Не факт, все зависит от версии ОС.

[EVGL]

Цитата:

Сообщение от Qaz Qwerty

EVGL: Компаний много, действительно есть маленькие и есть большие, типа 4GB и совсем пустые, в которых только GL балансы.

Тогда вам может помочь Optimize for unknown!

Готовит сервер БД к неизвестному, так сказать.
В случае Аксапты снижает опасность оптимизации под параметризированый запрос, сгенерированный для другой компании.

[Удвой Покуров]

Ничего не может помочь людям, которые жалеют денег на профессионалов, и заставляют сотрудников решать нетипичные для них задачи. Не посылая на курсы и проплачивая обучение, а просто фразами "а ты что, этого не умеешь?". Мы тебе столько платим, ты справишься! И т.д. Что вы за них переживаете? Да пусть все накрывается тазом. Может, мозгов прибавится, и бюджета. Кверти, вам советы дали дельные, но не корите себя, если что-то не получится. Ваша задача - это рассказать все риски руководству. Пусть у них голова болит.

[Qaz Qwerty]

Делают новую машину, на которой будет 64б сервер, а сейчас все на 32битной. Я так понимаю, что если я туда поставлю аксапту и все сервиспаки и скопирую файлы application, то все должно заработать? Файлы приложения ведь должны работать на любой системе? Там же вроде ничего такого нет, кроме слоев и индексов... Извините, в голове каша.

[mazzy]

да, будет работать.
AOS лучше поставьте 64-битный

[Alexius]

Цитата:

Сообщение от Qaz Qwerty

Извините, в голове каша.

Ну так попробуйте структурировать информацию о конфигурации сервера(ов), версиях ОС и СУБД. Тогда можно будет получить более точные рекомендации.

[Mabo]

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

При этом оговорюсь, что не сетевое соединение тормозит Аксапту, но если скорость локального соединения при выполнении какой-либо операции менее 8-10 Мегабит в секунду, то есть проблема.

второе, нам не удалось настроить нормальную работу 2009 АХ на виртуальном сервере, при этом 4.0 работает относительно сносно.Если есть возможность -- выносите АОС на физический сервер.

[gl00mie]

Цитата:

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

нам не удалось настроить нормальную работу 2009 АХ на виртуальном сервере, при этом 4.0 работает относительно сносно.Если есть возможность -- выносите АОС на физический сервер.

Это спорное утверждение. В моем случае, к примеру, абсолютно все АОСы работают в виртуалках (правда, на VMware ESX, а не Hyper-V, хотя это не принципиально, по-моему): и разработка, и тест, и рабочий кластер - и все замечательно пашет, тьфу-тьфу. Единственные две заморочки с производительностью были по таким причинам:

• АОСам не хватало выделенной виртуалкам оперативки. Дело в том, что 2009-я лопает память очень агрессивно + мапит файлы приложения в память, из-за чего зачастую сам АОС отъедает 1.8-2.5 гига + винда под memory-mapped files использует 2-3 гига. Если хост с АОСом(ами) начинает свопить - пиши пропало.
• заигрались с настройками трассировки. В конфигурации сервера на вкладке Tracing есть группа крыжей Calls to Application Object Server. Так вот, если в рабочей системе их взвести, то при средненьком числе пользователей +30-40% нагрузки на процы обеспечены (видимо, трассировка реализована настолько "удачно").

[AlGol]

Цитата:

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

В моем случае, к примеру, абсолютно все АОСы работают в виртуалках (правда, на VMware ESX, а не Hyper-V, хотя это не принципиально, по-моему): и разработка, и тест, и рабочий кластер - и все замечательно пашет, тьфу-тьфу.

Насчет не принципиально, поаккуратнее
У меня, как у дилетанта в данной области, сложилось стойкое впечатление, что работа системы на гипервизорах VMware протекает гораздо менее проблематично.