Падение производительности при добавлении памяти в MSSQL

Mack · Сообщение **Mack** » 28 окт 2004, 02:09

Есть двухпроцессорный HP сервер P3 1Ghz; 1 Gb RAM; RAID на 5 сказевых дисков.
На нем стоит MS NT 2195 и на ней MSSQL 2000.
Есть база складского учета ~6 Gb, работает ~70 пользователей. Средняя загрузка процессоров ~30-40%. В среднем время показа простой экранной формы 1-3 сек, сложных - до 10 сек.

При ДОБАВЛЕНИИ еще одного гига оперативки (до 2-х гигабайт) повысилась раза в полтора средняя загрузка процессоров и открытие НЕКОТОРЫХ простых форм возросла до 1.5-2 минут независимо от клиентского места. Убрали гиг - снова все как было, зашустрила.

Восстановили копию базы из бекапа - результат работы с копией аналогичный при наличии всего одного клиента в базе, т.е. открывает форму за те же 1.5-2 минуты. Работа ведется через BDE. Установки работы с памятью - по умолчанию, впрочем, экпериментировали по-разному, на результат мало влияет.

Где копать, люди добрые?

Сообщение **Stranger03** » 28 окт 2004, 10:42

Mack писал(а):Есть двухпроцессорный HP сервер P3 1Ghz; 1 Gb RAM; RAID на 5 сказевых дисков.
На нем стоит MS NT 2195 и на ней MSSQL 2000.
Есть база складского учета ~6 Gb, работает ~70 пользователей. Средняя загрузка процессоров ~30-40%. В среднем время показа простой экранной формы 1-3 сек, сложных - до 10 сек.

Скажите, какой тайный смысл вы преследовали, добавляя память в сервер? Если все операции проходят достаточно корректно?
В принципе на KB есть статья по оптимизации памяти в SQL, регулируется двумя путями, через добавление опций и определение фиксированного объема занимаемой памяти SQL-ем.

a_shats · Сообщение **a_shats** » 28 окт 2004, 10:47

Stranger03
Эт ты зря

Смысл есть, тем более на 6 ГБ базе. Я бы даже сказал - мало добавили.
Mack
- выделите MSSQL фиксированный - большой - объем ОЗУ. Если на сервере никаких других задач нет - выделите 1,5 ГБ.
И результаты напишите здесь, если что - попробуем еще что-нибудь по делу подсказать.

Сообщение **Stranger03** » 28 окт 2004, 10:53

a_shats писал(а):Stranger03
Эт ты зря Смысл есть, тем более на 6 ГБ базе. Я бы даже сказал - мало добавили.

Да я не говорю, что нельзя добавлять, :twisted:. Знаешь первую заповедь системного администратора? "Работает - не трогай", :twisted:.
Ведь формирование отчета в 10 секунд это очень и очень нормально. А про фиксированный объем - мы уже высказались. Только не забудьте прочитать статью на KB. Там есть пара нюансов, а то базу будет коматозить...

a_shats · Сообщение **a_shats** » 28 окт 2004, 11:02

Знаю. Но: если при выполнении - замечу - вполне человечной и неопасной операции - добавления ОЗУ - что-то не так - значит - надо разбираться, почему это происходит. Вполне возможно, что это следы грабель, которые всплывут позже, и чем позднее, тем мощнее будет эффект.

Сообщение **Stranger03** » 28 окт 2004, 11:16

Статья кстати здесь:
http://support.microsoft.com/default.as ... duct=sql2k

Mack · Сообщение **Mack** » 28 окт 2004, 15:16

- выделите MSSQL фиксированный - большой - объем ОЗУ. Если на сервере никаких других задач нет - выделите 1,5 ГБ.
И результаты напишите здесь, если что - попробуем еще что-нибудь по делу подсказать

Спасибо за ответы. За последние трия дня уже перечитал все, что можно. Кстати, та статья пр добавление памяти сверх 2 гигов, а я нарашиваю с 1 до 2.
Других задач на моем сервере нет. Менял по-разному стратегии выделения памяти. Существенно ничего не меняется.
Как мне кажется, дело в каких-то тонкостях взаимодействия BDE и MSSQL. Дело в том, что используя Profiler я получил очень интересные результаты. Запуск одной и той же процедуры через рабочую оболочку (Delphi + BDE) занимает 5500-6200 мс. Запуск ее же через Query Analyser занимает 120-150 мс. Это с установленными 2 гигами.
С 1 Гб памяти эти же запросы из оболочки занимают 700-800 мс. Очень уж большая разница. Через Query Analyser - не меняются

a_shats · Сообщение **a_shats** » 28 окт 2004, 15:32

Query Analyzer, afaik, идет напрямую через MSSQL API, а BDE - криво: Delphi компоненты-BDE-ODBC-API-MSSQL. Ну и плюс прелести такого универсального подхода - грабли с использованием вещей, не входящих в ANSI SQL и прочим. Вполне, кстати, возможно, что грабли где-то в этой цепочке...

Mack · Сообщение **Mack** » 28 окт 2004, 15:37

Query Analyzer, afaik, идет напрямую через MSSQL API, а BDE - криво: Delphi компоненты-BDE-ODBC-API-MSSQL. Ну и плюс прелести такого универсального подхода - грабли с использованием вещей, не входящих в ANSI SQL и прочим. Вполне, кстати, возможно, что грабли где-то в этой цепочке...

Да я в курсе. Удивляет разница между 700 мс и 6000 мс в одной оболочке. То, что native драйвера будут быстрее от 2 до 10 раз и так понятно. Может, просто из этой дельфовой оболочки ставятся какие-то опции на сеанс, влияющие на производительность сервера в зависимости от размера RAM?

a_shats · Сообщение **a_shats** » 28 окт 2004, 16:07

Уууу... Залезьте в BDE Administrator, посмотрите скока опций там при создании коннекта к MSSQL... только осторожнее со schema cache - это локальное кэширование схем запросов а не их содержимого.

Сообщение **Stranger03** » 28 окт 2004, 16:13

Mack писал(а):Спасибо за ответы. За последние трия дня уже перечитал все, что можно. Кстати, та статья пр добавление памяти сверх 2 гигов

Эта статья просто показывает процедуру управления памятью в SQL. Других к сожалению не нашел, :(.

Mack · Сообщение **Mack** » 28 окт 2004, 16:43

a_shats писал(а):Уууу... Залезьте в BDE Administrator, посмотрите скока опций там при создании коннекта к MSSQL... только осторожнее со schema cache - это локальное кэширование схем запросов а не их содержимого.

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

При этом ProcessID при обращении к серверу остается тот же, никаких реконнектов или установок опций сервера не происходит. В общем, "разумом начали, разумом кончили". И при этом обращения с разных рабочих станций с разными настройками BDE дают практически одинаковый результат (в пределах процентов). То есть с одной стороны, сервер как бы ни при чем, с другой - на скорость вляет установка дополнительной памяти в сам сервер и ничто другое

(

Mack · Сообщение **Mack** » 28 окт 2004, 16:51

Stranger03 писал(а):Эта статья просто показывает процедуру управления памятью в SQL. Других к сожалению не нашел, :(.

Спасибо, нашел несколько в MSDN. По сути, при ручном управлении памятью стратегии две - зажать сервер между максимумом и минимумом значения используемой памяти в точке максимальной производительности (но это вариант для очень ровно нагруженных систем) или разрешить использовать определенную долю с учетом внешних приложений и наличия/отсутствия сервиса MSSearch. Первая стратегия мне не подходит совсем, вторая - в широком диапазоне изменения параметров никаких изменений производительности не происходит. Более того, я делал так, что 1 гиг оперативки оставался совершенно свободным (типа софтверно имитировал вынимание одного гига), система тормозила так же, как и с двумя. Но как только вынимаешь, производительность восстанавливается.

Сообщение gs » 28 окт 2004, 17:00

А может быть для верности мемтест прогнать?

Mack · Сообщение **Mack** » 28 окт 2004, 17:10

gs писал(а):А может быть для верности мемтест прогнать?

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

Там ведь синхронный доступ к памяти, он обычно либо работает, либо нет. Причем: раньше там стояло 4*256 Mb. Потом поставили 4*512. Сейчас оставили 2*512 и все ок. Так что если и глючит, то только два вынутых 2*512. Новые чипы 133 Мгц, а рабочая частота 100 Мгц, так что глюки маловероятны. У нас несколько серверов проапгрейжены аналогичным образом и все ок, только с этим головняк.

Причем не может же глючить память при выполнении только определенных хранимых процедур изо дня в день

Падение производительности при добавлении памяти в MSSQL

Падение производительности при добавлении памяти в MSSQL

Re: Падение производительности при добавлении памяти в MSSQL

Кто сейчас на конференции