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

[Freelancer]

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

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

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

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

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

[a_shats]

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

[Freelancer]

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

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

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

[Freelancer]

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

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

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

[gs]

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

[a_shats]

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

[Freelancer]

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

[a_shats]

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

[Freelancer]

Все верно.

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

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


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


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

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


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

[a_shats]

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

[serebryak]

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

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

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