Операционка под SQL2000

Как создать сервер оптимальной конфигурации.

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить

Наибольшее влияние на быстродействие SQL2000

Опрос закончился 08 мар 2004, 12:12

Железо
2
29%
Операционка
0
Голосов нет
Структура таблиц
4
57%
Другое.
1
14%
Выбор клиента.
0
Голосов нет
 
Всего голосов: 7

Freelancer
Junior member
Сообщения: 7
Зарегистрирован: 01 мар 2004, 11:58

Операционка под SQL2000

Сообщение Freelancer » 01 мар 2004, 12:12

Помогите плз!
Имеется сервер на базе SQL2000
Под него написан клиент....
Но проблема... пока записей (заказов, клиентов) меньше 100 = все ок.
Как только их становится больше = резко все начинает тормозить.

Коллеги высказывают подозрение, что виновата операционка..

стоит W2k AS (если не ошибаюсь)
1700Мгц Целерон... 512 ОЗУ.

Время отклика порядка 3 секунд на 1условное действие.

:oops: Просьба не ржать, а подсказать где именно могут быть тонкие места...
В железе, в самом движке... в построении базы (тут не должно быть)
В чем???

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 01 мар 2004, 12:36

Дык... Типичная программерская ошибка - стараться засосать все в ОЗУ. Пока его хватает - вроде все летает. С некоторого порога (когда ОЗУ или отведенного кэша на часто используемые данные не хватает) вдруг все начинает тормозить...
Выход один: правильно сбалансировать нагрузку на железо.
Да, поясняя свое голосование: MSSQL не Оракл, настолько тонко, как Оракл, его настроить нельзя. Да и не ориентировалась никогда Microsoft на возможности тонкой подстройки своего софта под железо ;) . Потому, до определенного момента, рулить можно только железом. Момент истины наступает тогда, когда одного четырехпроцессорника под сервер уже не хватает ;) . Обычно к этому моменту накоплен большой багаж данных, структуры и изменений БД, и переписывать софт чрезвычайно сложно (как правило, такой момент наступает при объеме БД от нескольких десятков до сотни Гб).
Для БД с такой перспективой рекомендация - изначально планировать возможность разложения нагрузки на несколько серверов.

Freelancer
Junior member
Сообщения: 7
Зарегистрирован: 01 мар 2004, 11:58

Сообщение Freelancer » 01 мар 2004, 12:58

Дык... и аналайзер вешается :))

Ладно бы только мой клиент вешался..
А так на вроде бы простой запрос к базе уходит секунды три.
неужели на получение запросом 15000 записей 41 секунда = это нормально?
в запросе три джойна и все.

Как сбалансировать нагрузку на железо? :)
Подобрать железо, чтобы не было тонких мест?
или переписывать клиент?

Freelancer
Junior member
Сообщения: 7
Зарегистрирован: 01 мар 2004, 11:58

Сообщение Freelancer » 01 мар 2004, 13:00

Не. База расчитана под одну корпорацию.... и все.
человек на 30.

Колво записей не больше 300 000 за год, я думаю.

Но как то не быстро летает.

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16622
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 01 мар 2004, 13:02

Шац имхо прав - скорее всего, пока база в память помещается, все хорошо. Как только надо лезть на диски - попа.
Поковыряйте систему перфмоном, чтобы найти причину тормозов. Например сколько дисковых transactions per second и queue lenght. Последний параметр самый показательный - если там цифра больше нескольких единиц, значит дисковая система просто не успевает.

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 01 мар 2004, 13:16

А объем одной из 15000 записей ? А объем ОЗУ, выделенного MSSQL ?
А учесть, что из базы выдирается "сырой" массив и сортируется (обязательно) он в том же ОЗУ ? :gigi: ЛеХко, в общем.
И еще - получение такого кол-ва записей на клиента - это в принципе неправильно, имхо. В идеале клиент должен получать одну-единственную - искомую - запись ;) . А хотите валить такую кучу на клиента - будьте добры - большое ОЗУ+быстрая дисковая.

Freelancer
Junior member
Сообщения: 7
Зарегистрирован: 01 мар 2004, 11:58

Сообщение Freelancer » 01 мар 2004, 13:23

Зашивается только процессор....
Avg. Disk queue length =0.006
Памяти жрет 300 Кб на 80 обращений.

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 01 мар 2004, 13:27

А в каком смысле - на 80 обращений ? На 80 - клиентских подключений ? Или - еще чего-то ?

Freelancer
Junior member
Сообщения: 7
Зарегистрирован: 01 мар 2004, 11:58

Сообщение Freelancer » 01 мар 2004, 13:29

Все верно.

Клиент получает искомые две-три записи... по 2-3Кб. :roll:

Но на один запрос уходит порядка 2-3 секунд, что не есть гуд.
хочется меньше секунды.


Просто для исследования скорости работы я беру скриптик на 80 обращений к серверу.


(Я бестолковый, да?) :)

Наверное на получение клиентом из сети 400 записей по 3-5 Кб, и вывод их на экран требуется пара секунд?


upd:
(Под обращением я понимаю два-три запроса к серверу, на получение данных о заказе), сорри.
Что то вроде
Exec OrderGet @OrderId=2

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 01 мар 2004, 13:57

Нужно разобраться, где тормоза.
Механизм вообще-то такой: SQL разбирает запрос, проверяет наличие табличек, полей и т.п., далее - чего нет в кэше - дочитывается с винта(-ов)(!).Далее получившаяся сырая куча сортируется (это все еще Prepare идет), и только после этого сливается к клиенту (fetch).
Т.е. :
1. Разбираемся, где тормоз - на сервере (время Prepare) или же на клиенте (время fetch)
2. Если на сервере:
- смотрим планы запросов, стараемся избежать Natural, как огня ;) .Если надо - доделываем нужные индексы.
- лезем в perfmon (счетчики MSSQL для него надо доинсталлить, если не инсталлены), смотрим - кэш-хит. Если более 60% - разбираемся с собственно синтаксисом запроса - получается, что проц зверски молотит крохотный объем данных, что не есть хорошо. Если менее 50% - наращиваем ОЗУ и объем оного, выделенный под MSSQL. Кстати объем этот желательно зафиксировать и в разумных пределах - дабы свапом вместо работы не заниматься ;) .
Посмотрите, попробуйте, отпишитесь - может, еще что скажу... ;)

serebryak
Junior member
Сообщения: 4
Зарегистрирован: 15 фев 2004, 15:43
Откуда: Moscow

Сообщение serebryak » 05 мар 2004, 14:30

Freelancer писал(а):Дык... и аналайзер вешается :))
А так на вроде бы простой запрос к базе уходит секунды три.
неужели на получение запросом 15000 записей 41 секунда = это нормально?
в запросе три джойна и все.

Как сбалансировать нагрузку на железо? :)
Подобрать железо, чтобы не было тонких мест?
или переписывать клиент?
Эххх..
Боюсь что железо тут не причем...
41 секунда на 15000 записей - самоубийство!
Говорю по собственному опыту ;-)
Что-то не правильно в базе...
В первую очередь - Проиндексируй базу!!!
Потом смотри структуру таблиц.
Джойны тоже посмотри на предмет оптимизации! Один и тотже запрос можно реализовать туевой хучей способов соответственно будет разная скорость..
Используются ли хранимые процедуры в базе?
Используются ли курсоры - довольно тяжело их переживает сиквел...
Могу с уверенностью сказать, что после хорошей проработки базы производительность резко возрастет и сократятся аппаратные требования.
В общем тебе надо в форум по сиквелу ;-)
WBR,
Serebryakov Alexandr.

Ответить

Вернуться в «Серверы - Конфигурирование»