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

[sukhanchik]

Цитата:

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

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

Маленькая поправка. Если в запросе не указан ни индекс, ни сортировка, но на таблице присутствует кластерный индекс - то выборка будет осуществляться с сортировкой по кластерному индексу (просто так данные на диске в таком порядке расположены).
Собственно - на всех справочниках в АХ обычно присутствует кластерный индекс, ибо Best Practice его ставить рекомендует на ключевое поле совместно с первичным индексом.

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

PHP код:

DBCC SHOWCONTIG('tablename') 


для отдельно взятой таблицы.

НО! Тут надо смотреть. Если проблема на табличке без кластерного индекса - то тогда "это оно". Если нет, и проблема явно в дисках - то тут нужно думать в другом направлении. Если бы у Вас был бы Recovery Model=Full - то я бы обратил внимание на то, на какой диск пишется Shipping Log - ибо частые снимки базы не могут не напрягать диски.

[Wamr]

ребята, о чем вы, какая оптимизация индексов и бд. Этож виртуалка с АОСом и БД и 4гигами.
Попробуйте простой тест - возьмите большой файл и скопируйте его из одной папки в другую (не перемещать, а именно копировать), посмотрите скорость передачи данных.

[sukhanchik]

Цитата:

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

ребята, о чем вы, какая оптимизация индексов и бд. Этож виртуалка с АОСом и БД и 4гигами.
Попробуйте простой тест - возьмите большой файл и скопируйте его из одной папки в другую (не перемещать, а именно копировать), посмотрите скорость передачи данных.

Кстати, да - дельное предложение - я упустил момент что это виртуалка.

[Logger]

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

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

[EVGL]

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

[Qaz Qwerty]

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

[EVGL]

Цитата:

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

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

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

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

[Qaz Qwerty]

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

[_scorp_]

Цитата:

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

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

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

[Alexius]

Цитата:

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

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

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

[Wamr]

Цитата:

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

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

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

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

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

[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 протекает гораздо менее проблематично.