SQL2000 - вдруг начались сильные тормоза.

[e-statik]

Nav3.70 + SQL2000 (Xeon 3.4GHz, 3.94Gb). Где-то обычно 50-60 сессий днём.
Вдруг начались тормоза. Сервер постоянно загружен на 95-100% (CPU). После чего - совсем непонятно... Блокировок нет. Перезапускаем сервер - люди начинают логиниться и шкала расхода CPU-ресурса быстро поднимается вверх. На прошлой неделе поставили туда 1С8 - подумали что сервака не хватает на обоих. Нифига. Отрубили 1С - SQL сервак с работающим навижном всё= жрёт 100%.
Джобы никакие не работают... Куда девается ресурс - неясно.

Врят ли кто что сможет подсказать конечно, но может... Хоть куда смотреть/копать.

[enroi]

У нас похожая конфигурация. В принципе хотелось бы быстрей но после корректировок работает стабильно.
1. Используется ли Navision Application Server ? Если используется пробовали ли отключать.
2. На каких дисках лежат база данных, файл лога сервера, и сама система со своп файлом? При такой загрузке должны четко лежать отдельно. Проверено кровью ... :-(
3. Что пишет сам SQL сервер в логе?
4 CheckDB на SQL базе делали?
5. Дефрагментацию индексов пускали? Какова дефрагментация ключевых таблиц с индексами?
6. Настроена ли регулярная оптимизация SQL сервера?
7. Сколько памяти? При такой нагрузке желательно4 гига.
8. Какие update под сервер ставили?
9. Ну и самое веселое. Нет ли пользователей с большой любовью к поиску по "гагабайтным" таблицам? Как замечено весело тормозит сервер.

P. S. Само собой ничего в этом мире не происходит ... иногда мы не может заметить причины ...

[e-statik]

Цитата:

Сообщение от enroi

У нас похожая конфигурация. В принципе хотелось бы быстрей но после корректировок работает стабильно.
1. Используется ли Navision Application Server ? Если используется пробовали ли отключать.
2. На каких дисках лежат база данных, файл лога сервера, и сама система со своп файлом? При такой загрузке должны четко лежать отдельно. Проверено кровью ... :-(
3. Что пишет сам SQL сервер в логе?
4 CheckDB на SQL базе делали?
5. Дефрагментацию индексов пускали? Какова дефрагментация ключевых таблиц с индексами?
6. Настроена ли регулярная оптимизация SQL сервера?
7. Сколько памяти? При такой нагрузке желательно4 гига.
8. Какие update под сервер ставили?
9. Ну и самое веселое. Нет ли пользователей с большой любовью к поиску по "гагабайтным" таблицам? Как замечено весело тормозит сервер.

P. S. Само собой ничего в этом мире не происходит ... иногда мы не может заметить причины ...

1. Нет
2. Своп на системном. Логи и база на втором харде.
3. Ничего криминального
4. Наш спец грит делали, но что толку. Там как будто бы тоже всё Ок.
5. Большинство основных таблиц содержат один не составной ключ. Насколько я понял, тут дефрагментация никак не спасёт?
6. А это как?
7. Памяти 4 гига как раз.
8. Никаких апдейтов за последние 2 недели
9. Были и есть. Но нечастые случаи. Поиск по базе контактов по неключевому полю - по имени (~130 000 записей, оч.тяжелая таблица). Вообще, хотя в навижне указаны вторичные ключи для поиска, в SQL они не определены никак. Только первичный ключ. Может ли это сыграть свою роль и можно ли указывать доп ключи в SQL, помимо навижна?

Вопрос такой:
есть мысль попробовать восстановить бэкап с прошлой недели, когда проблем небыло. Как восстановить только объекты, оставив данные? Так можно сделать?

[e-statik]

Ещё вопрос:
на сервере в активити столбец CPU, насколько он информативен и насколько это полезная информация? Какие нормальные/средние параметры для одного соединения? У меня разброс цифр от десятков тысяч до сотен тысяч на соединение.

[Dzemon]

С какими параметрами создана база из Навижина?
Auto Srink = FALSE
Recovery Model = Simple

Виндовс со свопом, база и лог должна находится на 3-х физически разных дисках (рейдах).

[e-statik]

2 Dzemon
А как/где можно посмотреть?

p.s. а на 3ий хард денег не спешат выделять )

[e-statik]

На тему "самого веселого". Смотрю на запросы пользователей профайлером и вижу, что очень много отъедает поиск по базе контактов - по имени. И операция достаточно частая. Каким-либо образом можно оптимизировать этот процесс (не изменяя порядок работы пользователей)?

[konrad_imported]

Цитата:

Сообщение от e-statik

Смотрю на запросы пользователей профайлером и вижу, что очень много отъедает поиск по базе контактов - по имени. И операция достаточно частая. Каким-либо образом можно оптимизировать этот процесс (не изменяя порядок работы пользователей)?

Если в плане запроса сервера при таких запросах сканирование идет - делать SQL-индекс однозначно. Степень опитмизации процесса зависит от продуманности ключа.

И еще гляньте - как с SIFT-индексами дело обстоит. Есть у 3.70 подленькое свойство. Если использовать CALCSUMS для поля, которое не указано в столбце SumIndexFields соответствующего ключа - навижн ничего не скажет и спокойно его посчитает. Но будет это очень медленно. А если столбец с таким полем выводится на табличную форму - то все, туши свет.

[Dzemon]

Цитата:

Сообщение от e-statik

На тему "самого веселого". Смотрю на запросы пользователей профайлером и вижу, что очень много отъедает поиск по базе контактов - по имени. И операция достаточно частая. Каким-либо образом можно оптимизировать этот процесс (не изменяя порядок работы пользователей)?

Просто не выбран ключ. Поиск должен происходить по полю "Описание Поиска" и должен быть ВЫБРАН соответствующий ключ.

[e-statik]

Т.е. поиск просто по названию отпадает и пользователям нужно искать по полю Search Name? Каким образом должен быть выбран ключ? В форме, в которой происходит поиск, SETCURRENTKEY("Search Name") ? Или я всё неправильно понял?

[Scorpie]

C индексами может профайлер помочь.
В разгар рабочего дня запускаем трейс всего что есть. Даем ему с часик поработать, потом индекс-тюнинг визардом смотрим где у нас запросы "проваливаются"...

Цитата:

Сообщение от e-statik

Т.е. поиск просто по названию отпадает и пользователям нужно искать по полю Search Name? Каким образом должен быть выбран ключ? В форме, в которой происходит поиск, SETCURRENTKEY("Search Name") ? Или я всё неправильно понял?

Можно заранее кодом указать SetCurrentKey. Можно дрессировать пользователей выбирать правильный ключ перед тем как искать(фильтровать) данные в окне.

[e-statik]

Дрессировка юзеров наверное не подходит. Ибо на прошлой неделе всё было Ок и никакого повода для переживаний небыло.
Вот индекс-тюнинг сейчас попробую, спасибо.

[Scorpie]

Цитата:

Сообщение от e-statik

Дрессировка юзеров наверное не подходит. Ибо на прошлой неделе всё было Ок и никакого повода для переживаний небыло.
Вот индекс-тюнинг сейчас попробую, спасибо.

Таких чудес не бывает
Нужно отфильтровать все объекты в навижне модифицированные за последнюю неделю и вдумчиво осознать что и как было сделано.
Если под фильтр попало 0 объектов - пинать админов пусть ковыряют железо...

[e-statik]

После всяких муторных тестов выяснилось, тормозит поиск даже по ключевому полю, даже когда я единственный пользователь в системе.
Более того, вне навижна аналогичные запросы LIKE работают так же не стабильно. По неясным причинам запрос может обрабатываться то 15 сек, то 40 сек... Один и тот же, запускаемый раз за разом... Видимо функционал тут уже совершенно непричем.
Так то.

Пинать IT-шников на тему железа/настроек_сервера?

[Dzemon]

Гляньте тут: http://www.sql.ru/articles/mssql/02111902T...SQLServer.shtml

[e-statik]

2 Dzemon:
Спасибо, сейчас посмотрю.

[e-statik]

К сожалению... Сделал две указанные проверки - вроде бы с ними всё гладко. Среднее время записи на диск ~0.003, а в тесте критическим называют 0.02

В Performance Monitor примерно одна и та же картина

[Dzemon]

А посмотритека сетевой трафик и утилизацию ресурсов сетевыми процессами. Надеюсь у вас на сервере не 10 баксовые сетевые карточки? ;-)

[e-statik]

2 Dzemon:
А можно чу-чуть поподробнее, где/как посмотреть? IT-шники не особо желают участвовать, буду искать сам.

[Dzemon]

Да в том же пефоманс мониторе. Просто есть подозрение, что либо сетевые службы много едят либо что-то с распределением памяти для SQL.