Каталог решений - Сильное падение производительности MS SQL сервера из-за VMWare

Сильное падение производительности MS SQL сервера из-за VMWare

Сильное падение производительности MS SQL сервера из-за VMWare

В наличии

История о том, как:
Жила была себе база 1С УПП 1.3 для Украины. В один прекрасный момент, стала сильно тормозить. Две недели бились над решением проблемы, нашли. Может кому пригодится.

Категория:

Описание

Итак предыстория:

2 года тому назад, была поднята Виртуальная инфраструктура VMWare, на ней работали сервера:

1. 1С

2. MS SQL 2008

3. Сервер терминалов 2008

40 пользователей.

Работало все это хозяйство около 2-х лет, на 3-х хостах с выделенным сетевым хранилищем по iSCSI.

Как водится что-то настраивали, как в части 1С так и в части железа, сетей и т.п.

Теперь сама история:

В один прекрасный момент стали жаловаться пользователи о заметном снижении производительности и с каждым днем все хуже и хуже. Причем картина наблюдалась следующая:

с 08 до 12 полный ступор

с 12 до 17 троможения

с 17 до 20(оставался только сбыт) терпимо.

Проанализировав загруженность серверов наблюдали следующую картину:

— Сервер 1С работал хорошо и шустро с загрузкой процессора до 20%

— Сервер терминалов работал хорошо и шустро с загрузкой процессора до 20%, иногда до 80%

— Сервер MS SQL работал как-то очень затянуто, вроде загрузка процессора до 20%, а тормоза ужасные

Нашли на форуме статью Как правильно настроить MS SQL сервер для работы с 1С.

Все вроде ок. Запустили ночью регламентные задания, к утру они не закончились,

Перенесли начало на вечер, та-же картина.

Начали индексы по таблично перестраивать, картина не улучшилась.

Пришли праздники (1-2 мая) Регламентное задание завершилось, длилось 23 часа, в том числе перестроение индексов 7,5 часов, обновление статистики 9 часов), но это ситуацию не изменило.

Руководство к стенке ставит, скоро растрел, а мы не знаем что делать.

Нашли статью Пример оптимизации производительности 1С УПП. Ничего не дало.

Причем все выполнялось очень долго, мы что-то запускали с надеждой, а на утро надежда рушилась.

Перечитав кучу информации об индексах статистиках и т.п., бились две недели, вроде все упирается в статистику и индексы.

Но в один прекрасный момент (когда все стало колом и сервер стал перезагружаться при добавлении ему процессоров) случайно наткнулись на интересную информацию, у нашей виртуальной машины MS SQL, с размером дисков около 300 Г,  размер snapshot-ов был такой-же, задав в гугле «Влияние snapshot на производительность», нашли кучу информации, но одна из них  очень порадовала, автор подробно расписал, Snapshot’ы и производительность, огромное ему спасибо. Запустили процесс удаления snapshot-ов, который длился около 12 часов. Зато после этого, все заработало, как швейцарские часы.

PS: А ларчик просто открывался. Пишу может кому пригодится мой горький опыт.

PSS: Торможения SQL — это чистая случайность, могло тормозить сервер терминалов, или сервер 1С.

 

has been added to your cart:
Оформление заказа