Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: обслуживание БД  [new]
Дима Лешин
Member

Откуда: Россия
Сообщений: 3
StarikNavy,

такое бывает, встречался
3 апр 15, 11:44    [17468441]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
artem_air
Member

Откуда:
Сообщений: 20
Дима Лешин
StarikNavy,

такое бывает, встречался


А как с этим боролись???
6 апр 15, 08:15    [17477175]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
artem_air
Дима Лешин
StarikNavy,

такое бывает, встречался


А как с этим боролись???
Вам же уже сказали - смотрите запросы которое это приложение отсылает на сервер.
7 апр 15, 00:20    [17481383]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
artem_air
Member

Откуда:
Сообщений: 20
...
Вы хотябы трасировку сняли в момент момент ваших этих зависаний.
...

К сообщению приложен файл. Размер - 82Kb
9 апр 15, 08:50    [17491847]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
artem_air
Member

Откуда:
Сообщений: 20
felix_ff,

Что Вы можете сказать?
9 апр 15, 08:52    [17491851]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
Glory
Member

Откуда:
Сообщений: 104760
Что вы хотели сказать подчеркнутыми на скриншоте значениями ?
Что какждое соединения за все время жизни использует CPU time в среднем 50 milliseconds ?
9 апр 15, 08:53    [17491857]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
artem_air
Member

Откуда:
Сообщений: 20
Glory,

я почему то думал, что CPU это ресурсы процессора? а не время.
9 апр 15, 09:07    [17491901]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
Glory
Member

Откуда:
Сообщений: 104760
artem_air
я почему то думал, что CPU это ресурсы процессора? а не время.

Что каждый коннект своими запросами нагружает процессор(ы) на 47-63% ?
А потом еще и "переписывает" эту загрузку процессора(ов) с mssql на aragonit.exe ?
9 апр 15, 09:25    [17491980]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
artem_air
Member

Откуда:
Сообщений: 20
Glory,

А что-нибудь полезное можно выявить из этой таблицы?
9 апр 15, 09:29    [17491996]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
gang
Member

Откуда:
Сообщений: 1394
artem_air,

Сказать можно следующее:
1. Glory прав - вы не понимаете, что видите. Вы предполагали что ваши логоны/логауты занимают по 40-60% CPU?
Таки нет. Эти миллисекунды. Стоит хотя бы бегло ознакомится с функционалом прежде чем пользоваться тулзой и тем более делать выводы.
2. Вопрос "Что Вы можете сказать?" по поводу непонятного скрина может быть уместен со стороны начальника или "эффективного менеджера". У вас не та ситуация. Придется и самому поработать. Сами-то что думаете по поводу Вашей картинки?
3. По поводу загрузки проца приложением. Если ресурс потребляется процессом приложения, то сиквел тут никаким боком. У него (SQL) отдельный процесс со своим счетчиком CPU, его кстати вы не показывали. То, что приложение может тратить CPU в ожидании обработки запроса(ов) сиквелом тоже проблемы приложения.
4. Про то что БД "разрослась" и поэтому хорошее ПО ломается от плохой, толстой БД - типичный разработчицкий бред. Это их софт и их БД, они их программировали и учили друг с другом работать. Если писали на коленке с тестовой БД в 100 строчек и не думали о том что их может стать 100 тыс. , значит хреново писали и хреново думали. Какие еще могут быть варианты? Вам банально ездят по ушам пользуясь тем что Вы не особо разбираетесь в вопросе. Хотя не исключено что если наедете более аргументировано - тупо пошлют. Ответ про "почистить таблички" это бред и отписка, его уровень показывает крайнее нежелание разраба заниматься проблемой по существу.
9 апр 15, 09:40    [17492059]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
Glory
Member

Откуда:
Сообщений: 104760
artem_air
А что-нибудь полезное можно выявить из этой таблицы?

Трасса показывает,
- что запросы на сервере выполняются за миллисекунды. особой загрузки сервера не видно
- что приложение зачем то постоянно делает пересоединения. То ли это особенность клиентского кода, то ли параллельные соеднения (номера коннекта не скриншоте не видно).
- загрузка процессора в 50%, приходящаяся на aragonit.exe, вряд ли возможна, если приложение просто ждет каких-то результатов от сервера. Конечно можно нагружать процессор при асинхронном ожидании пока коннект к серверу что-то вернет, но для приложения, которое "предназначено для открытия заявок" такая особенность выглядит по крайней мере странной.
9 апр 15, 09:49    [17492110]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
stavgreengo
Member

Откуда:
Сообщений: 710
artem_air,

подтвердите или опровергните моё предположение. Ваше приложение больше не поддерживается разработчиком, поскольку вы не платите ему денег ?
9 апр 15, 11:23    [17492690]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
artem_air
Member

Откуда:
Сообщений: 20
stavgreengo,

Программа и оборудование установлены давно (я работаю совсем недавно), но не приняты полностью в эксплуатацию.
То есть с разработчика еще можно что-то требовать.
9 апр 15, 11:31    [17492735]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
VladimirKr
Member

Откуда: СПб
Сообщений: 1052
artem_air,

Если вам не важна история входов-выходов, отключите audit login, audit logout в настройках сервера. Оставьте только протоколирование неудачных входов (в SSMS свойства сервера\безопасность)
в приведенной вами картинке дикое количество reads при audit logout.
При включенном аудите каждое connection.open/close записывает строчку в лог сервера. А в клиентской программе это может быть в цикле из 100500 итераций, мол connection pull - все быстро. Быстро, если нет аудита. Посмотрите на лог сервера - он наверняка гигантских размеров из-за этого мусора.
9 апр 15, 12:24    [17493072]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
Glory
Member

Откуда:
Сообщений: 104760
VladimirKr
в приведенной вами картинке дикое количество reads при audit logout

audit logout дает суммарные значения для закрываемого коннекта за все время его существования.
9 апр 15, 12:27    [17493089]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
VladimirKr
Member

Откуда: СПб
Сообщений: 1052
Glory,
Спасибо, этого не знал.
9 апр 15, 12:33    [17493114]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
artem_air
Member

Откуда:
Сообщений: 20
gang
artem_air,

Сказать можно следующее:
1. Glory прав - вы не понимаете, что видите. Вы предполагали что ваши логоны/логауты занимают по 40-60% CPU?
Таки нет. Эти миллисекунды. Стоит хотя бы бегло ознакомится с функционалом прежде чем пользоваться тулзой и тем более делать выводы.
2. Вопрос "Что Вы можете сказать?" по поводу непонятного скрина может быть уместен со стороны начальника или "эффективного менеджера". У вас не та ситуация. Придется и самому поработать. Сами-то что думаете по поводу Вашей картинки?
3. По поводу загрузки проца приложением. Если ресурс потребляется процессом приложения, то сиквел тут никаким боком. У него (SQL) отдельный процесс со своим счетчиком CPU, его кстати вы не показывали. То, что приложение может тратить CPU в ожидании обработки запроса(ов) сиквелом тоже проблемы приложения.
4. Про то что БД "разрослась" и поэтому хорошее ПО ломается от плохой, толстой БД - типичный разработчицкий бред. Это их софт и их БД, они их программировали и учили друг с другом работать. Если писали на коленке с тестовой БД в 100 строчек и не думали о том что их может стать 100 тыс. , значит хреново писали и хреново думали. Какие еще могут быть варианты? Вам банально ездят по ушам пользуясь тем что Вы не особо разбираетесь в вопросе. Хотя не исключено что если наедете более аргументировано - тупо пошлют. Ответ про "почистить таблички" это бред и отписка, его уровень показывает крайнее нежелание разраба заниматься проблемой по существу.


gang,

1. Вы правы, многого еще не понимаю.
2. Потому и спрашиваю, чтобы помогли разобраться, самому очень сложно. Готов сам поработать, но не знаю в каком направлении действовать, что лучше почитать, слишком много информации (верной и неверной).
3. Вот и я не понимаю, дело в SQL или в самом приложении. Смотреть картинку.
4. Получается, что разработчики написали "Плохой" продукт и ездят мне по ушам. Мне нужно потихоньку их расшевелить, но нужно задавать грамотные вопросы и предъявлять претензии, чтобы они не могли съехать. И сам хочу понять в чем тут дело.

К сообщению приложен файл. Размер - 31Kb
9 апр 15, 13:27    [17493521]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
Glory
Member

Откуда:
Сообщений: 104760
artem_air
3. Вот и я не понимаю, дело в SQL или в самом приложении. Смотреть картинку.

MSSQL не может заставить приложение использовать процессор и другие ресурсы.
"Зависание" приложения из-за ожидания результатов запроса, отпралвенного серверу, должно выглядеть как полное бездействие приложения без потребления каких-либо ресурсов.
9 апр 15, 13:32    [17493557]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
virtuOS
Member

Откуда: большая деревня
Сообщений: 265
+

Может, приложение после отправки запроса к sql в цикле проверяет результат. Если правильно помню, то при интервале менее 100 мс используется не системный таймер, а ресурсы процессора. Вот и высокая загрузка и зависания приложения
9 апр 15, 13:46    [17493685]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
gang
Member

Откуда:
Сообщений: 1394
artem_air
2. Готов сам поработать, но не знаю в каком направлении действовать, что лучше почитать, слишком много информации (верной и неверной).

Почитать хелп по трассировкам в BOL. Начать можно отсюда. Собрать трассу по событиям, например, SQL:BatchCompleted и RPC:Completed, а лучше 2: с проблемного сервера и "хорошего". Поискать аномалии по времени выполнения запросов (суммарному, максимальному), утилизации CPU, частоте запусков. Возможно, но необязательно, это поможет Вам лучше понять что делает приложение в процессе "зависания", какие команды оно шлет к SQL Server-у и как долго ожидает ответа. Но на самом деле тут Вы уже начинаете делать за разработчика его работу. По-хорошему это он должен дать вам инструкции что и как собрать, получить от Вас "объективку" и на ее основании выдать фиксы или инструкции как ситуацию исправить.
artem_air
3. Вот и я не понимаю, дело в SQL или в самом приложении. Смотреть картинку.

Лечат по фотографиям в известной передаче на ТНТ. У Вас есть объективные данные о потреблении CPU процессом приложения. Т.о. у Вас есть факт: приложение "зависает" при работе с центральной БД. Процесс приложения потребляет при этом до 100% CPU.
artem_air
4. Получается, что разработчики написали "Плохой" продукт и ездят мне по ушам. Мне нужно потихоньку их расшевелить, но нужно задавать грамотные вопросы и предъявлять претензии, чтобы они не могли съехать. И сам хочу понять в чем тут дело.

Самый грамотный вопрос Вам уже подсказали. Потребуйте объяснить, на что процесс приложения расходует 100% cpu. Если будут ссылаться на некие мифические "особенности" SQL при работе с большими таблицами, потребуйте описать эти особенности и связь между ними и потреблением ресурсов софтом. Не принимайте ссылок на "эфир", типа "известная особенность", "как все знают" и т.п. Если действительно говорят об общеизвестных вещах, то не должно быть проблем с тем чтобы дать подтверждение ссылкой на документацию, статью KB или хотя бы форум. Помните, что "плохая" база это тоже часть их продукта. И за нее они также отвечают как и за код. Ну и самое главное - не останавливайтесь на объяснениях, требуйте решение. Если как Вы писали "исправить нет возможности", значит софт банально не работает. То что он как-то живет на периферийных машинах ничего не значит. Не работает значительная, если не сказать основная часть софта - функционал центрального офиса. Вы заплатили за то, чтобы софт работал у Вас на сервере, в том числе центральном,а не не тестовом ноуте разработчика. Все остальное лепет и виляние пятой точкой.
9 апр 15, 14:46    [17494026]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
artem_air
Member

Откуда:
Сообщений: 20
gang,

Спасибо Вам =) Вопрос разработчику про "особенности" задал, он пока не отвечает.
9 апр 15, 15:01    [17494121]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Glory
VladimirKr
в приведенной вами картинке дикое количество reads при audit logout

audit logout дает суммарные значения для закрываемого коннекта за все время его существования.
Да, но при этом, на картинке есть audit login и logout для процесса 56. Но суммарно reads всех запросов не дадут 398834 reads. Значит в трассе что-то отсутствует, то что генерит столько reads?
9 апр 15, 20:41    [17495831]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
artem_air
Member

Откуда:
Сообщений: 20
artem_air
gang,

Спасибо Вам =) Вопрос разработчику про "особенности" задал, он пока не отвечает.


Разработчики продукта сообщили следующее :
приняли данную информацию к сведению, в новых обновлениях постараются решить данную проблему.
Нет ли тут какого подвоха?
17 апр 15, 11:20    [17528179]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
gang
Member

Откуда:
Сообщений: 1394
artem_air
Разработчики продукта сообщили следующее :
приняли данную информацию к сведению, в новых обновлениях постараются решить данную проблему.
Нет ли тут какого подвоха?

Да тут ничего нет: ни признания своего косяка, ни объяснения причин, ни обязательств, ни сроков.
Ну и то, что про механизм возникновения проблемы молчат может говорить о том что они его либо еще не поняли,
либо даже не пытались.
Какой же тут может быть подвох. Подвох это когда что-то пообещали, но оставили себе лазейку чтобы выкрутится.
А так Ваша проблема по-прежнему осталась Вашей. Обязательств они никаких не приняли и своей ее не сделали. Удачи!
17 апр 15, 11:53    [17528360]     Ответить | Цитировать Сообщить модератору
 Re: обслуживание БД  [new]
artem_air
Member

Откуда:
Сообщений: 20
Наткнулся на такую статью: https://bvas.ru/2015/02/03/обслуживание-баз-ms-sql-server-скрипт/
В этой статье описывается скрипт для обслуживания БД SQL Server Express (в ней нет планов обслуживания БД, т.е. нужно самому вручную писать запросы) - у меня как раз такая.

Можно ли использовать данный скрипт для обслуживания БД? Может что-то лучше исключить или исправить?
У меня база небольшая 3Гб, модель восстановления простая, пользователей около 10.
Если да, то как часто следует выполнять такое обслуживание?
20 апр 15, 13:30    [17539187]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить