|
MS SQL потребляет много оперативной памяти
Здравствуйте.
Имеется сервер 1С и подключенный к нему через сеть в 1 Гбит/с сервер MS SQL Операционная система Win2008 Ent 64-bit Из 2-х SSD дисков сделан RAID1. Система и базы хранятся на нём. У сервера единственная задача - MS SQL! Всего 11 баз данных общим объёмом на 57 ГБ. В одной из баз (имеется в виду 1С) весом в 16 ГБ одновременно трудится около 20 человек. Иногда возникают вопросы связанные со скоростью работы типа: "Документ долго проводится", "Отчёт долго формируется". Во время этих жалоб следил за загруженностью ресурсов сервера. Единственное что смущает так это то, что оперативка, выделенная серверу (12 ГБ), полностью забита!!! Перезапустил службу MS SQL. На графике ниже видно резкое падение - это и есть момент рестарта службы. Жалобы прекратились. А потом примерно в 00-20 снова растёт загрузка - на это время сделан JOB на резервное копирование всех баз.  Мне интересно почему не очищается оперативка? Где могут быть слабые места в данной системе? Можно ли и стоит ли при помощи JOB создать задание, которое после создания бекапа перезапускает сервер (JOB создавал приходящий программист 1С)? Почему во время активной работы пользователей загрузка сети не превышает 4 Мбит/с (по-моему должно быть больше)? |
Цитата:
Ждем ответов и будем думать дальше :) Цитата:
|
Цитата:
Цитата:
Цитата:
 Verify that automation is enabled. Код:
IF (msdb.dbo.fn_syspolicy_is_automation_enabled() != 1)Код:
EXEC msdb.dbo.sp_syspolicy_purge_historyКод:
if ('$(ESCAPE_SQUOTE(INST))' -eq 'MSSQLSERVER') {$a = '\DEFAULT'} ELSE {$a = ''};Программист сказал, что возникала ошибка из за которой он какой-то из пунктов задания отключил. Нашёл ошибку в другом задании (это создание резервной копии) в старых логах но это может и не она. Пакет лежит в Maintenance Plans\MaintenancePlan ... как его оттуда достать я не знаю :( Цитата:
Цитата:
Цитата:
|
Цитата:
Всего 11 баз. Из них только одна 1С? И именно на 1С, я так понимаю, делается космическая переиндексация какая то? Что меня всегда убивало в 1С, так это то, как они умудряются своим софтом вешать такие вещи как SQL Server. Но это так, в качестве оффтопа. Пойдем другим путем. Как часто выполняется переиндексация? Одновременно с основным JOB-ом ежедневно в 00-20? Или чаще? Создание бекапов мы в расчет не берем, эта технология отлажена и из-за нее настолько тормозить не будет. Я бы сделал следующее: 1. Через Profiler с утра пораньше, когда нет пользователей в базе, помониторил бы, какие обращения идут к SQL серверу и какие задачи выполняются. 2. Через Management Studio помониторил бы активные соединения, есть ли незакрытые транзакции и что они выполняют. 3. В момент жалоб еще внимательней повторил бы пункт.2 Согласно этому анализу будет примерно видно, в чем проблема. Ну и собственно, Performance Monitor от OS Windows еще никто не отменял. И на OsZone, если я не ошибаюсь, есть отличные статьи по оптимизации SQL Server. Настоятельно рекомендую к прочтению :).(http://www.oszone.net/4482/Microsoft_SQL_Server) ПО поводу вытаскивания задания из плана. Под руками дома sql нет, попробую в понедельник посмотреть на работе, ну или может, пораньше кто нибудь подскажет здесь :) |
Цитата:
Цитата:
Цитата:
Задание MaintenancePlan.Вложенный_план_1, которое я не могу достать, выполняется в 00:00. Задание syspolicy_purge_history которое я попытался описать выше выполняется в 02:00. Теперь понимаю что скорее всего проблема в MaintenancePlan.Вложенный_план_1 .... нужно его как то вытащить. Цитата:
|
Нашёл что делает MaintenancePlan.Вложенный_план_1. Лежит он в Планах обслуживания
Вроде бы ничего криминального. Так что почему на каком-то шаге забивается оперативка и потом не очищается я не знаю :(... Может скрипт спотыкается на какой-то базе? В предыдущей ошибке была указана база buh2011... |
Цитата:
Проблема однозначно во втором плане. Точнее, не в самом плане, а в данных в БД. Что можно сделать: - ПКМ на плане - Wizard - запустить мастер плана. Пройтись по шагам, посмотреть, что он выполняет. Думаю, не ошибусь в предположении, что там выставлена опция Rebuild Indexes - и далее будет список баз, где это надо провести. Убираешь базу Buh2011, сохраняешь план, смотришь на результаты после запуска плана. Если проблема исчезнет, значит БД мы локализовали и будем смотреть дальше. Если же нет, то убирай еще БД из плана, вычленяя источник проблемы. |
Цитата:
Слева на панели есть "Реорганизация индекса" и "Перестроение". Я думаю в данном переводе Престроение и есть Rebuild Indexes. Если да, то как видно в этом плане данный шаг не используется. Стоит ли исключать БД из шага "Восстановить индекс"? Сегодня обработка отработала нормально (без ошибок) но оперативка снова в полке :( P.S. В сообщениях о успешном завершении резервного копирования нет ни слова о каких то других базах кроме BUH2011. Может и не стоит обращать внимание на неё? Просто эта база стоит первая в списке на копирование. |
Тебе нужно отловить, связано ли увеличение расхода оперативки с обработкой какой то конкретной базы, или же это происходит независимо от базы. Убирая по одной базы из плана, можно выловить источник проблемы. А дальше будем думать :)
|
Цитата:
|
Delirium, в очередной раз поражаюсь твоей категоричности в рекомендациях. При этом они зачастую идут в разрез с общепринятой практикой/рекомендациями разработчика ПО.
RAID-5 не рекомендуется под БД если создать RAID-массив, то на отдельных дисках уже ничего не сделаешь. Видимо имелись ввиду отдельные массивы. Правда, опять же, в современных реалиях чаще рекомендуется делить один массив на LUN'ы, чем создавать отдельные массивы - но это в контексте "взрослых" контроллеров. 1с официально рекомендует регулярно переиндексировать БД и обновлять статистику (насколько это имеет смысл, зависит от конкретной ситуации) Не вижу никакой проблемы в том, что SQL Server занимает доступную свободную память - её же для этого и покупали в сервер ;-) |
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
|
Цитата:
|
Busla, в таком случае как объяснить заторможенность действий при заполненной памяти и почему заполнение памяти происходит после выполнения переиндексации? Мы же не оспариваем работу SQL Server'а, а пытаемся найти решение, которое позволит устранить недостаток.
P.S. И опять же, я в упор не вижу конструктивных предложений "по теме" :) |
Спасибо за увлекательную переписку выше :)
Я сделал отдельное задание в котором оставил 3 шага как в исходном задании : восстановить индекс, обновить статистику, резервное копирование. И стал запускать это задание, изменяя базы данных. Наблюдал за общим объёмом используемой оперативной памяти до запуска и после завершения выполнения задания (ниже объём в ГБ). Вот что получилось: BUH2011 4.38 - 5.16 Leonidov 5.16 - 5.73 Novikova2 5.73 - 7.07 Stushniy 7.07 - 7.72 ZUP 7.72 - 7.86 trade 2.02 - 13.9 Потом я решил сделать задание только с восстановлением индекса для базы trade . Объём используемой памяти вырос с 1.94 ГБ до 13.5 ГБ. С обновлением статистики для этой базы примерно то же... оперативка полностью забивается. Похоже что что-то с базой trade. База достаточно большая. Может для диагностики нужны какие-то параметры этой базы? Цитата:
|
Цитата:
|
Цитата:
файл trade.mdf 15,7 ГБ (16*958*619*648 байт) Цитата:
Цитата:
Цитата:
Можете доступно объяснить для чего нужна эта операция? Она просто уменьшит размер базы без потери производительности ну и наверное ж без потери информации? |
Цитата:
Цитата:
Почитай вот эту переписку на sql.ru, подобная ситуация обсуждается. |
сделал сегодня утром shrink базы trade... размер базы 8230,00 МБ
Смотрим за скоростью работы. |
с 15 до 8 Гб - неслабый результат :)
|
Цитата:
После окончания работы загрузка оперативки на сервере 8.5 ГБ. Жду отработки ночных скриптов. На скорость работы в базе жалоб не было! |
Извиняюсь, за никрофилию, но как в мексиканских сериалах: На самом интересном месте... (((
Чем дело хоть закончилось? |
Цитата:
|
| Время: 06:12. |
Время: 06:12.
© OSzone.net 2001-
