Галактика в вопросах и ответах

Добрый день!
Пользователи давно жалуются на скорость работы системы. Думали, что дело в большом объеме данных.
Но при одном из последних обновлений заметил сильно разную скорость проверки реестра настроек, когда база у меня локально и когда на сервере.
У меня локально реестр настроек полностью проверяется за 20 секунд, а на сервере за 1 минуту 25 секунд. Начал проверять в других режимах и оказалось, что почти все на сервере медленней.
Хотя конфигурация сервера на порядок мощнее, чем у моего рабочего компьютера.
Создал практически одинаковую среду у себя и на сервере. Везде полностью одинаковые конфиги, одна и та же база данных, одинаковая версия MSSQL Server 2008R2. Проверяю на одном и том же документе.
Списание накладной, в которой 54 позиции, локально длится 3-4 секунды, а на сервере 8-9 секунд. Все проверял на свежеперезагруженном сервере, когда с ним больше никто не работал.

Начали копать дальше и почти сошли с ума. Решили исключить из возможных причин галактику. Нашел на просторах интернета вот такой скрипт:

Код: Выделить всё

create table Test(id int, descr varchar(100))
set nocount on
declare @i int
set @i = 0
while @i < 100000
begin
insert into Test values(@i, 'xxx')
set @i = @i + 1
end
drop table test;

У меня локально и на старом сервере он выполняется за 12-16 секунд.
На боевом сервере он выполняется около 1 минуты.

На сервере 10 рэйд, скорость чтения и записи по тестам даже выше, чем на старом сервере. У меня в рабочем компе вообще обычный HDD.
Попробовали вставить в сервак SSD и проверить на нем. Почему-то на SSD еще хуже, около 2 минут.

Уже даже не можем придумать в какую сторону копать. Может есть у кого-то идеи как отловить это узкое место?

1. Сравнивать свою рабочую станцию и рабочий сервер бессмысленно - разве что по ночам.
2. Сейчас мода на виртуалззацию серверов. Когда то очень давно видел реальное падение раза в 4 скорости обращений к диску после этого.
так что можете попробовать на самом севере покопировать exe галактики и сравнить с тем же у себя. Возможно дело в не очень хорошей настройке RAID контролера. Менять нужно аккуратно с записыванием того, что поменяли и за раз по одному параметру. В общем последуйте дисковую подсистему.
3. Если Галактика работает не непосредственно на сервере СУБД, то в дело вмешивается сеть. Очень плохо если по ней идет много ошибок. Влиять может все что угодно, вплоть до мощного оборудования включаемого рядом со switch.
4. Где то здесь я давал советы по оптимизации быстродействия. Например часть пользовательских таблиц (кроме Pick и возможно TMPSaldo1-3) можно отправить на локал(при этом они перестанут быть доступными в DSQL). Вообще по возможности все должно быть на локаале - TMP, OUT и та длаее ( или на терминальном сервере - в общем в месте где непосредственно работает галактики). Исключение можно сделать для DSK в случае работы на пуле терминальных серверов - ищите.
5. Очень важно понимать какой драйвер вы используется в ODBC. Native сам по себе быстрее, и лет 5 назад галактику прооптимизировали под него, при этом придушив обычный. На тот момент насколько помню падение составляло до 7 раз местами. Но в cfg оставили возможность указать другие параметры оптимизации. При этом очень важно, что бы у всех драйверы одбс были одинаковые, поскольку иначе на сервер буде двойная нагрузка по оптимизации планов запросов под разные драйвера. Ищите в описаниях к патчам Native.
6. Ну и закуску - аппаратный ключ. Лучше его использовать в режиме TCP|IP - избавитесь от многих проблем.
7. И еще учтите что новому серверу нужно какое то время чтобы набрать статистику и прооптимизировать планы запросов. Но обычно за несколько часов он уже успеет набрать достаточную. Из за этого тесты нужно повторять дважды - второй всегда будет чуть быстрее.
8. Возможно дело в параметрах СУБД - сравните со старым сервером.
9. Возможно сам сервак придушен - например Hyper-threading выключен (для СУБД он может быть полезен) или сервер работает в экономичном режиме. Или антивирус другой.

spark писал(а):Добрый день!
Уже даже не можем придумать в какую сторону копать. Может есть у кого-то идеи как отловить это узкое место?

Вы уже почти полную диагностику сделали - дело в Win+SQL, даже napserver исключен.
Проверьте
Посмотрите оптимизацию СУБД на целевых площадках, там вообще что угодно может быть вплоть до не корректной работы железа с набором ПО. Либо надо железо в другие слоты поставлять.
На серверах это сплошь и рядом, если сервер официальный и на гарантии звоните им в ТП они могут подсказать.

Галактика в вопросах и ответах

Производительность MSSQL

Производительность MSSQL

Re: Производительность MSSQL

Re: Производительность MSSQL