Падение производительности при добавлении памяти в MSSQL
Модераторы: Trinity admin`s, Free-lance moderator`s
Падение производительности при добавлении памяти в MSSQL
Есть двухпроцессорный 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. Установки работы с памятью - по умолчанию, впрочем, экпериментировали по-разному, на результат мало влияет.
Где копать, люди добрые?
На нем стоит MS NT 2195 и на ней MSSQL 2000.
Есть база складского учета ~6 Gb, работает ~70 пользователей. Средняя загрузка процессоров ~30-40%. В среднем время показа простой экранной формы 1-3 сек, сложных - до 10 сек.
При ДОБАВЛЕНИИ еще одного гига оперативки (до 2-х гигабайт) повысилась раза в полтора средняя загрузка процессоров и открытие НЕКОТОРЫХ простых форм возросла до 1.5-2 минут независимо от клиентского места. Убрали гиг - снова все как было, зашустрила.
Восстановили копию базы из бекапа - результат работы с копией аналогичный при наличии всего одного клиента в базе, т.е. открывает форму за те же 1.5-2 минуты. Работа ведется через BDE. Установки работы с памятью - по умолчанию, впрочем, экпериментировали по-разному, на результат мало влияет.
Где копать, люди добрые?
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Re: Падение производительности при добавлении памяти в MSSQL
Скажите, какой тайный смысл вы преследовали, добавляя память в сервер? Если все операции проходят достаточно корректно?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-ем.
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Да я не говорю, что нельзя добавлять, :twisted:. Знаешь первую заповедь системного администратора? "Работает - не трогай", :twisted:.a_shats писал(а):Stranger03
Эт ты зря Смысл есть, тем более на 6 ГБ базе. Я бы даже сказал - мало добавили.
Ведь формирование отчета в 10 секунд это очень и очень нормально. А про фиксированный объем - мы уже высказались. Только не забудьте прочитать статью на KB. Там есть пара нюансов, а то базу будет коматозить...
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Статья кстати здесь:
http://support.microsoft.com/default.as ... duct=sql2k
http://support.microsoft.com/default.as ... duct=sql2k
Спасибо за ответы. За последние трия дня уже перечитал все, что можно. Кстати, та статья пр добавление памяти сверх 2 гигов, а я нарашиваю с 1 до 2.- выделите MSSQL фиксированный - большой - объем ОЗУ. Если на сервере никаких других задач нет - выделите 1,5 ГБ.
И результаты напишите здесь, если что - попробуем еще что-нибудь по делу подсказать
Других задач на моем сервере нет. Менял по-разному стратегии выделения памяти. Существенно ничего не меняется.
Как мне кажется, дело в каких-то тонкостях взаимодействия BDE и MSSQL. Дело в том, что используя Profiler я получил очень интересные результаты. Запуск одной и той же процедуры через рабочую оболочку (Delphi + BDE) занимает 5500-6200 мс. Запуск ее же через Query Analyser занимает 120-150 мс. Это с установленными 2 гигами.
С 1 Гб памяти эти же запросы из оболочки занимают 700-800 мс. Очень уж большая разница. Через Query Analyser - не меняются
Последний раз редактировалось Mack 28 окт 2004, 16:00, всего редактировалось 1 раз.
Да я в курсе. Удивляет разница между 700 мс и 6000 мс в одной оболочке. То, что native драйвера будут быстрее от 2 до 10 раз и так понятно. Может, просто из этой дельфовой оболочки ставятся какие-то опции на сеанс, влияющие на производительность сервера в зависимости от размера RAM?Query Analyzer, afaik, идет напрямую через MSSQL API, а BDE - криво: Delphi компоненты-BDE-ODBC-API-MSSQL. Ну и плюс прелести такого универсального подхода - грабли с использованием вещей, не входящих в ANSI SQL и прочим. Вполне, кстати, возможно, что грабли где-то в этой цепочке...
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Да, опций там есть несколько интересных. Но особенность проблемы в том, что другие запросы из соседних экранных форм работают при добавлении памяти быстрее или так же (включая несколько, работающих с теми же таблицами). Это-то меня и убивает При этом ProcessID при обращении к серверу остается тот же, никаких реконнектов или установок опций сервера не происходит. В общем, "разумом начали, разумом кончили". И при этом обращения с разных рабочих станций с разными настройками BDE дают практически одинаковый результат (в пределах процентов). То есть с одной стороны, сервер как бы ни при чем, с другой - на скорость вляет установка дополнительной памяти в сам сервер и ничто другое (a_shats писал(а):Уууу... Залезьте в BDE Administrator, посмотрите скока опций там при создании коннекта к MSSQL... только осторожнее со schema cache - это локальное кэширование схем запросов а не их содержимого.
Спасибо, нашел несколько в MSDN. По сути, при ручном управлении памятью стратегии две - зажать сервер между максимумом и минимумом значения используемой памяти в точке максимальной производительности (но это вариант для очень ровно нагруженных систем) или разрешить использовать определенную долю с учетом внешних приложений и наличия/отсутствия сервиса MSSearch. Первая стратегия мне не подходит совсем, вторая - в широком диапазоне изменения параметров никаких изменений производительности не происходит. Более того, я делал так, что 1 гиг оперативки оставался совершенно свободным (типа софтверно имитировал вынимание одного гига), система тормозила так же, как и с двумя. Но как только вынимаешь, производительность восстанавливается.Stranger03 писал(а):Эта статья просто показывает процедуру управления памятью в SQL. Других к сожалению не нашел, :(.
Самому хочется, но, сервер очень загружен, некогда до выходных это сделать. Причем это фирменный HP сервер, с развитой диагностикой, наверняка бы что-нибудь заулюлюкало Там ведь синхронный доступ к памяти, он обычно либо работает, либо нет. Причем: раньше там стояло 4*256 Mb. Потом поставили 4*512. Сейчас оставили 2*512 и все ок. Так что если и глючит, то только два вынутых 2*512. Новые чипы 133 Мгц, а рабочая частота 100 Мгц, так что глюки маловероятны. У нас несколько серверов проапгрейжены аналогичным образом и все ок, только с этим головняк. Причем не может же глючить память при выполнении только определенных хранимых процедур изо дня в деньgs писал(а):А может быть для верности мемтест прогнать?
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 26 гостей