Операционка под SQL2000
Модераторы: Trinity admin`s, Free-lance moderator`s
-
- Junior member
- Сообщения: 7
- Зарегистрирован: 01 мар 2004, 11:58
Операционка под SQL2000
Помогите плз!
Имеется сервер на базе SQL2000
Под него написан клиент....
Но проблема... пока записей (заказов, клиентов) меньше 100 = все ок.
Как только их становится больше = резко все начинает тормозить.
Коллеги высказывают подозрение, что виновата операционка..
стоит W2k AS (если не ошибаюсь)
1700Мгц Целерон... 512 ОЗУ.
Время отклика порядка 3 секунд на 1условное действие.
Просьба не ржать, а подсказать где именно могут быть тонкие места...
В железе, в самом движке... в построении базы (тут не должно быть)
В чем???
Имеется сервер на базе SQL2000
Под него написан клиент....
Но проблема... пока записей (заказов, клиентов) меньше 100 = все ок.
Как только их становится больше = резко все начинает тормозить.
Коллеги высказывают подозрение, что виновата операционка..
стоит W2k AS (если не ошибаюсь)
1700Мгц Целерон... 512 ОЗУ.
Время отклика порядка 3 секунд на 1условное действие.
Просьба не ржать, а подсказать где именно могут быть тонкие места...
В железе, в самом движке... в построении базы (тут не должно быть)
В чем???
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Дык... Типичная программерская ошибка - стараться засосать все в ОЗУ. Пока его хватает - вроде все летает. С некоторого порога (когда ОЗУ или отведенного кэша на часто используемые данные не хватает) вдруг все начинает тормозить...
Выход один: правильно сбалансировать нагрузку на железо.
Да, поясняя свое голосование: MSSQL не Оракл, настолько тонко, как Оракл, его настроить нельзя. Да и не ориентировалась никогда Microsoft на возможности тонкой подстройки своего софта под железо . Потому, до определенного момента, рулить можно только железом. Момент истины наступает тогда, когда одного четырехпроцессорника под сервер уже не хватает . Обычно к этому моменту накоплен большой багаж данных, структуры и изменений БД, и переписывать софт чрезвычайно сложно (как правило, такой момент наступает при объеме БД от нескольких десятков до сотни Гб).
Для БД с такой перспективой рекомендация - изначально планировать возможность разложения нагрузки на несколько серверов.
Выход один: правильно сбалансировать нагрузку на железо.
Да, поясняя свое голосование: MSSQL не Оракл, настолько тонко, как Оракл, его настроить нельзя. Да и не ориентировалась никогда Microsoft на возможности тонкой подстройки своего софта под железо . Потому, до определенного момента, рулить можно только железом. Момент истины наступает тогда, когда одного четырехпроцессорника под сервер уже не хватает . Обычно к этому моменту накоплен большой багаж данных, структуры и изменений БД, и переписывать софт чрезвычайно сложно (как правило, такой момент наступает при объеме БД от нескольких десятков до сотни Гб).
Для БД с такой перспективой рекомендация - изначально планировать возможность разложения нагрузки на несколько серверов.
-
- Junior member
- Сообщения: 7
- Зарегистрирован: 01 мар 2004, 11:58
Дык... и аналайзер вешается )
Ладно бы только мой клиент вешался..
А так на вроде бы простой запрос к базе уходит секунды три.
неужели на получение запросом 15000 записей 41 секунда = это нормально?
в запросе три джойна и все.
Как сбалансировать нагрузку на железо?
Подобрать железо, чтобы не было тонких мест?
или переписывать клиент?
Ладно бы только мой клиент вешался..
А так на вроде бы простой запрос к базе уходит секунды три.
неужели на получение запросом 15000 записей 41 секунда = это нормально?
в запросе три джойна и все.
Как сбалансировать нагрузку на железо?
Подобрать железо, чтобы не было тонких мест?
или переписывать клиент?
-
- Junior member
- Сообщения: 7
- Зарегистрирован: 01 мар 2004, 11:58
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Шац имхо прав - скорее всего, пока база в память помещается, все хорошо. Как только надо лезть на диски - попа.
Поковыряйте систему перфмоном, чтобы найти причину тормозов. Например сколько дисковых transactions per second и queue lenght. Последний параметр самый показательный - если там цифра больше нескольких единиц, значит дисковая система просто не успевает.
Поковыряйте систему перфмоном, чтобы найти причину тормозов. Например сколько дисковых transactions per second и queue lenght. Последний параметр самый показательный - если там цифра больше нескольких единиц, значит дисковая система просто не успевает.
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
А объем одной из 15000 записей ? А объем ОЗУ, выделенного MSSQL ?
А учесть, что из базы выдирается "сырой" массив и сортируется (обязательно) он в том же ОЗУ ? ЛеХко, в общем.
И еще - получение такого кол-ва записей на клиента - это в принципе неправильно, имхо. В идеале клиент должен получать одну-единственную - искомую - запись . А хотите валить такую кучу на клиента - будьте добры - большое ОЗУ+быстрая дисковая.
А учесть, что из базы выдирается "сырой" массив и сортируется (обязательно) он в том же ОЗУ ? ЛеХко, в общем.
И еще - получение такого кол-ва записей на клиента - это в принципе неправильно, имхо. В идеале клиент должен получать одну-единственную - искомую - запись . А хотите валить такую кучу на клиента - будьте добры - большое ОЗУ+быстрая дисковая.
-
- Junior member
- Сообщения: 7
- Зарегистрирован: 01 мар 2004, 11:58
-
- Junior member
- Сообщения: 7
- Зарегистрирован: 01 мар 2004, 11:58
Все верно.
Клиент получает искомые две-три записи... по 2-3Кб.
Но на один запрос уходит порядка 2-3 секунд, что не есть гуд.
хочется меньше секунды.
Просто для исследования скорости работы я беру скриптик на 80 обращений к серверу.
(Я бестолковый, да?)
Наверное на получение клиентом из сети 400 записей по 3-5 Кб, и вывод их на экран требуется пара секунд?
upd:
(Под обращением я понимаю два-три запроса к серверу, на получение данных о заказе), сорри.
Что то вроде
Exec OrderGet @OrderId=2
Клиент получает искомые две-три записи... по 2-3Кб.
Но на один запрос уходит порядка 2-3 секунд, что не есть гуд.
хочется меньше секунды.
Просто для исследования скорости работы я беру скриптик на 80 обращений к серверу.
(Я бестолковый, да?)
Наверное на получение клиентом из сети 400 записей по 3-5 Кб, и вывод их на экран требуется пара секунд?
upd:
(Под обращением я понимаю два-три запроса к серверу, на получение данных о заказе), сорри.
Что то вроде
Exec OrderGet @OrderId=2
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Нужно разобраться, где тормоза.
Механизм вообще-то такой: SQL разбирает запрос, проверяет наличие табличек, полей и т.п., далее - чего нет в кэше - дочитывается с винта(-ов)(!).Далее получившаяся сырая куча сортируется (это все еще Prepare идет), и только после этого сливается к клиенту (fetch).
Т.е. :
1. Разбираемся, где тормоз - на сервере (время Prepare) или же на клиенте (время fetch)
2. Если на сервере:
- смотрим планы запросов, стараемся избежать Natural, как огня .Если надо - доделываем нужные индексы.
- лезем в perfmon (счетчики MSSQL для него надо доинсталлить, если не инсталлены), смотрим - кэш-хит. Если более 60% - разбираемся с собственно синтаксисом запроса - получается, что проц зверски молотит крохотный объем данных, что не есть хорошо. Если менее 50% - наращиваем ОЗУ и объем оного, выделенный под MSSQL. Кстати объем этот желательно зафиксировать и в разумных пределах - дабы свапом вместо работы не заниматься .
Посмотрите, попробуйте, отпишитесь - может, еще что скажу...
Механизм вообще-то такой: SQL разбирает запрос, проверяет наличие табличек, полей и т.п., далее - чего нет в кэше - дочитывается с винта(-ов)(!).Далее получившаяся сырая куча сортируется (это все еще Prepare идет), и только после этого сливается к клиенту (fetch).
Т.е. :
1. Разбираемся, где тормоз - на сервере (время Prepare) или же на клиенте (время fetch)
2. Если на сервере:
- смотрим планы запросов, стараемся избежать Natural, как огня .Если надо - доделываем нужные индексы.
- лезем в perfmon (счетчики MSSQL для него надо доинсталлить, если не инсталлены), смотрим - кэш-хит. Если более 60% - разбираемся с собственно синтаксисом запроса - получается, что проц зверски молотит крохотный объем данных, что не есть хорошо. Если менее 50% - наращиваем ОЗУ и объем оного, выделенный под MSSQL. Кстати объем этот желательно зафиксировать и в разумных пределах - дабы свапом вместо работы не заниматься .
Посмотрите, попробуйте, отпишитесь - может, еще что скажу...
Эххх..Freelancer писал(а):Дык... и аналайзер вешается )
А так на вроде бы простой запрос к базе уходит секунды три.
неужели на получение запросом 15000 записей 41 секунда = это нормально?
в запросе три джойна и все.
Как сбалансировать нагрузку на железо?
Подобрать железо, чтобы не было тонких мест?
или переписывать клиент?
Боюсь что железо тут не причем...
41 секунда на 15000 записей - самоубийство!
Говорю по собственному опыту
Что-то не правильно в базе...
В первую очередь - Проиндексируй базу!!!
Потом смотри структуру таблиц.
Джойны тоже посмотри на предмет оптимизации! Один и тотже запрос можно реализовать туевой хучей способов соответственно будет разная скорость..
Используются ли хранимые процедуры в базе?
Используются ли курсоры - довольно тяжело их переживает сиквел...
Могу с уверенностью сказать, что после хорошей проработки базы производительность резко возрастет и сократятся аппаратные требования.
В общем тебе надо в форум по сиквелу
WBR,
Serebryakov Alexandr.
Serebryakov Alexandr.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 48 гостей