1. Тогда должно быть все ок, но на всякий случай проверьте, хотя я не уверен что это имеет смысл делать, т.к. у вас не pass-through.
2. Вроде как рекомендуется именно pass-through. А вообще странно, есть ИТ отдел, в котором есть начальник, есть программисты, и есть вы (я намекаю на величину общих затрат на одни ваши зарплаты), и нет возможности купить пару жестких дисков, при условии того что 1сная база — главный учетный софт конторы??? Это фиерия какая-то, честно слово.
3. ТойСкуль? Я знаю автора :)
4. Скорее всего всё прозаичнее: либо настройки самого скуля не идентичны в плане резервирования памяти (вы цифры одинаковые поставьте), либо во_всем_виновата виртуализация.
6. Ее не нужно собирать, ее нужно обновлять: запускаете MS SQL Server Management Studio и делаете новый план обслуживания (Открываете папку Management, выделяете папку Maintenance Plans, правая кнопка мыши, New Maintenance Plan...). В нем создаете субплан и добавляете в него задачу Update Statistics Task. В нем все оставляете по умолчанию, только указываете вашу базу. Все. В этом же субплане, после обновления статистики добавляете задачу Execute T-SQL Statement Task, с текстом запроса: DBCC FREEPROCCACHE
7. Вряд ли :) 12-13 Гб — это размер ни о чем вообще.
И вот еще что. Вы написали, что в виртуалке у вас 4 виртуальных ядра. А сколько на самом хосте физических сокетов и ядер? Есть ли отличия по равномерности загрузки ядер на железе и в виртуалке? И какую нагрузку на ядра дает именно MS SQL в момент ваших тормозов?
Я без понятия чем питаются ваши партизаны, но. Ребята, как же вы надоели со своей политотой. Вот реально, со всякими вашими украинами, партизанами, [подставьте_нужное] — вот этим всем. Вы на хабре (гике, мозге)! Вы понимаете это? Еще раз: ВЫ ПОНИМАЕТЕ ЭТО???? Зачем вы тащите все это сюда, специально разжигая и включая вентилятор? Если вам так охота обсудить чем питается кто-то где-то, и за чей счет — это обязательно делать на ресурсе ДЛЯ ГИКОВ? Есть тыщи! Тыщи ресурсов, где няши, всепропальщики, хочукакунишек, ольгинцев, охранителей, создателей_культа, хитропланщиков — вот эти всё -где они ведут свои священные войны, уличая, подначивая, закидывая друг-друга шоколадом. Я уже давно из-за этого перестал смотреть телек и читать газеты, залочил себе овер до фига новостных агенств, и вообще стараюсь поменьше даже не слушать, а слышать весь этот желтяк. И вот открываешь старый-добрый-Хабр...-е-маё, тот самый Хабр, который «не место для политики» и что видим? Партизаны, воюя с регулярными частями армии, Святым духом не питаются. Да итить бы вашу мать!!!..
Описали много чего, но… все таки, какой же размер вашей базы?
Затем выше, я упустил вашу цитату:
>>И я понимаю связь между размером блока на реальном диске и виртуальном. Но я не знаю, какой размер оптимален именно для базы скуля или базы 1с.
У вас же ОС 2008 R2, а она сама для дисков устанавливает нужное смещение, если система ставилась с нуля. Если вы ее накатывали поверх, то есть смысл проверить.
>> база (не фрагментирована) на VHDX фиксированного размера, который не фрагментирован и покоится на SSD
Я не шибко великий гуру виртуальных машин, и могу заблуждаться: у вас же не pass-through диск, т.е. не подключение физического диска напрямую к виртуальной машине без создания VHDx?..
>> И вот на железном сервере из-за пары обработок (пополнение резервов? Перенос остатков?) вставала колом вся работа
Если лечить по фото, то в 2000 скуле была знатная бага, суть которой сводится к тому, что время выполнения процедуры sp_executesql, которую очень активно юзает семера, при длительном коннекте сессии к SQL, начинает сильно увеличиваться. Я думаю ваши программисты в курсе из-за чего это, я вдаваться в подробности не буду. В рамках 2000 скуля, проблема не решается в принципе. Либо реконектиться через какое-то время, либо использовать специальную компоненту, которая будет очищать буфер сессии. Но, конечно, в эту тему должны погружаться явно не вы, и тогда, когда уже другие программные моменты прояснены и уточнены, что проблема точно не в них, хотя тяжело так говорить в контексте 7.7 :)
>>Я не уверен даже, реально ли скуль берёт всю ту память… Но что происходит внутри, как сам sqlsrv.exe распоряжается этим объёмом — для меня загадка.
У вас 2000 скуль. Там все относительно просто и тот же Task Manager будет показывать правду. А из-за чего на железяке не жрется вся память, а в виртуалке вам рисует — что жрется — это вопрос отличный, при условии что в данный момент на самом скуле нагрузка идентична.
>>а у кого вылетает 1С — потом не могут войти, «база заблокирована».
Вылетает — с ошибками? Или просто закрывается само приложение 1С? Какие точные текста?
>>Про какую статистику спрашиваете
статистики базы данных MS SQL.
>> определённые действия с железом и ПО могут улучшить ситуацию, но панацеей это не будет в любом случае, мне так кажется.
Ну почему же? Если сама конфа более или менее нормальная, и пишут ее в данный момент, адекватные люди, то скорее всего все таки определенные «админские» штуки-дрюки, о которых я тут уже не знаю сколько пишу, вполне могут немножко подразогнать жирок с базы.
>>И вот на тестовом производительность хуже, чем на виртуальном.
Так надо же для начала разобраться с железневым. На нем вы хотя бы достоверно сможете определить узкое место. Пока я вижу, что на виртуальном «само рассосалось» (по крайне мере лучше, чем было на железе), что не обычно, т.к. обычно (сори), все с точностью да наоборот. Тут на вскидку, два варианта видятся:
— либо у железного сервера (тестовый) есть реальные проблемы с железом, но вы пока их не про диагностировали;
— либо ему не хватает мощи по какому-то критически разделяемому ресурсу: память, сеть, дисковая подсистема, процессор. Но память вы вроде как отсекли, т.к. ее в виртуалке вроде как больше.
Кстати, вы так и не ответили про статистику. Но я так понимаю, это не по адресу уже. Туда же, а что за сложные вещи в самой 1С, про которые вы пишите? Тоже видимо не по адресу. Но заметьте, вы выдвигаете какие-то гипотезы, но подтверждаете ее… словами ж?
Виртуализация семеры на 2000 скуле, который в свою очередь завиртуализирован на 2012 сервере, который тоже виртуализирован? :) Ваш случай — это вершина айсберга по степени своей плохопахнущей массы, т.к. все расследования нужно начинать с самого сервера виртуализации. Внутри виртуалки смотреть особо смысла нет, ибо она может показывать не верь глазам своим что. А произвести диагностику проблемы в виртуалке в полной мере у вас не получится. Вам для начала нужно откатить сервер скуля на железо, и попытаться там продиагностироваться с учетом вышесказанного.
«ибо AWE активирована» < — оооох… Я надеюсь Вы не в историческом музее работаете? :) Про 2000 скуль я вам вряд ли что-то могу сказать, ибо в годы его рассвета, я еще не работал. Но кое-какие направления для дум может и дам, исходя из гипотезы, что с кодом все хорошо, а горло — именно в настройках.
1. У вас регламентные операции с БД на самом скуле выполняются? Статистика как обновляется? Не асинхронно ли случайно? В каких-то древних версиях скуля при таком виде обновлений он тек по памяти.
2. Как организована дисковая подсистема? Файлы mdf и ldf размещены на разных дисковых массивах? Диск (-ая подсистема) журнала транзакций должна быть «более отзывчивой», т.е. требования к скорости повышены. Если все так — то хотелось бы взглянуть на времена отклика обоих файлов в момент тормозов, и в обычные моменты. Кстати, проверьте заодно, что эти файлы не сжимаются.
3. Модель восстановления самой базы какая? Если ее в simple перевести — тормоза такие же?
4. Если ОС Win 2003 или меньше, то поглядите выровнены ли сектора дисков по границе 1024Кб и отформатированы ли с размером блока 64Кб?
5. MAXDOP = 1?
Вы пишите: «мониторинг не показывает ничего аномального». Если я включу моего начальника, то сразу вопросы: что собиралось, чем, какие цифры, за какое время? И вот за все это время, Вы не выявили ничего-ничего? Прямо все идеально, а сервер — тормозит? «не верю» (с). Смотрите очереди к дискам в ОС, наличие доступной ОП. Если все гут, значит нужно промониторить механизм ожиданий SQL Server'а: на каких типах ресурсов возникают самые большие ожидания. Как выясните нужно дальше оценить какие типы ожиданий самые большие. Исходя из этого далее можно пытаться что-то делать, а не сервер постоянно перезагружать (рестарта службы ему не мало, в случае если у вас по памяти ничего больше не течет). Естественно, что все регламентные задания на уровне СУБД с базами должны выполнятся, сам скуль должен быть минимально настроен, как и сервер Win. По поводу перезагрузки терминальных серверов: а если Вы их не перезагружаете, что происходит? Я так понимаю же, все таки, что-то происходит, коли Вы их перезагружаете? Наверное, от этого и надо начинать плясать.
И еще вы пишите, что вы — не DBA. Я тоже, и не системный администратор. Но имея опыт постоянного и в хвост и в гриву, приходится в части доказательств, разбираться на уровне, хотя бы достаточном, чтоб от меня отвязались :) Я просто для себя выработал такой кейс: если мне говорят — ДОКАЖИ, мне мое расследование нужно в конце обязательно закончить словами «что и следовало доказать». Исходя из этого, я и выстраиваю свою линию защиты, т.к. априори я — виноватый. Напр., в вашем случае, я бы подготовил ответ на вопросы, которые я Вам задал выше. Но опять же, Вы считаете, что это не ваши обязанности. А я, напр., тоже не считаю это своими обязанностями. За код ответить готов, и отвечаю. Но постоянная позиция — твой код — причина всех бед, немного выбешивает. Хочется, все таки, от системного администратора немного более глубокого погружения в тему мониторинга элементарной загрузки оборудования средствами самого Win.
>>трудно спорить с начальником IT-отдела, который больше программист 1С, чем эникейщик
Зеркальная ситуация: начальник Сис.Админ, а я — программист 1С. Это какой то грёбаный Адъ! Я все время должен доказывать ему, что виновата «не ваша 1С». Если есть любая проблема — ответ один: иди разбирайся, это ваша 1С! Если скажешь — найн, то сразу же — докажи!!! Вот типовой случай: тормозит сервер, на нем 1 база (Карл, ОДНА!) с парой тройкой активных сеансов, которые вообще ни о чем. Смотришь в Activity Monitor SQL нагрузку на подсистему ввода-вывода, там одни ожидания WRITELOG и LOGBUFFER. Показываешь, что время отклика журнала транзакций с диска в районе 5000(!!!) мс, и получаешь ответ — и что? Ну и что? Это в вашей 1С запросы «тяжелые» :) А то что утилита, которая мониторит рэйд показывает, что один диск вылетел, и включился рибилд — это ничего страшного. Ну вообщем и все вот ровно в таком духе. Самое ужасное, что я должен, просто должен всегда ДОКАЗЫВАТЬ с пруфами к сайту microsoft, к 1С, что да — вот это, так.
_хттп://i.imgur.com/CQdySGn.jpg
Авторам-смутьянам все ж таки желаю обрести истинную веру :)
2. Вроде как рекомендуется именно pass-through. А вообще странно, есть ИТ отдел, в котором есть начальник, есть программисты, и есть вы (я намекаю на величину общих затрат на одни ваши зарплаты), и нет возможности купить пару жестких дисков, при условии того что 1сная база — главный учетный софт конторы??? Это фиерия какая-то, честно слово.
3. ТойСкуль? Я знаю автора :)
4. Скорее всего всё прозаичнее: либо настройки самого скуля не идентичны в плане резервирования памяти (вы цифры одинаковые поставьте), либо во_всем_виновата виртуализация.
6. Ее не нужно собирать, ее нужно обновлять: запускаете MS SQL Server Management Studio и делаете новый план обслуживания (Открываете папку Management, выделяете папку Maintenance Plans, правая кнопка мыши, New Maintenance Plan...). В нем создаете субплан и добавляете в него задачу Update Statistics Task. В нем все оставляете по умолчанию, только указываете вашу базу. Все. В этом же субплане, после обновления статистики добавляете задачу Execute T-SQL Statement Task, с текстом запроса: DBCC FREEPROCCACHE
7. Вряд ли :) 12-13 Гб — это размер ни о чем вообще.
И вот еще что. Вы написали, что в виртуалке у вас 4 виртуальных ядра. А сколько на самом хосте физических сокетов и ядер? Есть ли отличия по равномерности загрузки ядер на железе и в виртуалке? И какую нагрузку на ядра дает именно MS SQL в момент ваших тормозов?
Затем выше, я упустил вашу цитату:
>>И я понимаю связь между размером блока на реальном диске и виртуальном. Но я не знаю, какой размер оптимален именно для базы скуля или базы 1с.
У вас же ОС 2008 R2, а она сама для дисков устанавливает нужное смещение, если система ставилась с нуля. Если вы ее накатывали поверх, то есть смысл проверить.
>> база (не фрагментирована) на VHDX фиксированного размера, который не фрагментирован и покоится на SSD
Я не шибко великий гуру виртуальных машин, и могу заблуждаться: у вас же не pass-through диск, т.е. не подключение физического диска напрямую к виртуальной машине без создания VHDx?..
>> И вот на железном сервере из-за пары обработок (пополнение резервов? Перенос остатков?) вставала колом вся работа
Если лечить по фото, то в 2000 скуле была знатная бага, суть которой сводится к тому, что время выполнения процедуры sp_executesql, которую очень активно юзает семера, при длительном коннекте сессии к SQL, начинает сильно увеличиваться. Я думаю ваши программисты в курсе из-за чего это, я вдаваться в подробности не буду. В рамках 2000 скуля, проблема не решается в принципе. Либо реконектиться через какое-то время, либо использовать специальную компоненту, которая будет очищать буфер сессии. Но, конечно, в эту тему должны погружаться явно не вы, и тогда, когда уже другие программные моменты прояснены и уточнены, что проблема точно не в них, хотя тяжело так говорить в контексте 7.7 :)
>>Я не уверен даже, реально ли скуль берёт всю ту память… Но что происходит внутри, как сам sqlsrv.exe распоряжается этим объёмом — для меня загадка.
У вас 2000 скуль. Там все относительно просто и тот же Task Manager будет показывать правду. А из-за чего на железяке не жрется вся память, а в виртуалке вам рисует — что жрется — это вопрос отличный, при условии что в данный момент на самом скуле нагрузка идентична.
>>а у кого вылетает 1С — потом не могут войти, «база заблокирована».
Вылетает — с ошибками? Или просто закрывается само приложение 1С? Какие точные текста?
>>Про какую статистику спрашиваете
статистики базы данных MS SQL.
>> определённые действия с железом и ПО могут улучшить ситуацию, но панацеей это не будет в любом случае, мне так кажется.
Ну почему же? Если сама конфа более или менее нормальная, и пишут ее в данный момент, адекватные люди, то скорее всего все таки определенные «админские» штуки-дрюки, о которых я тут уже не знаю сколько пишу, вполне могут немножко подразогнать жирок с базы.
Так надо же для начала разобраться с железневым. На нем вы хотя бы достоверно сможете определить узкое место. Пока я вижу, что на виртуальном «само рассосалось» (по крайне мере лучше, чем было на железе), что не обычно, т.к. обычно (сори), все с точностью да наоборот. Тут на вскидку, два варианта видятся:
— либо у железного сервера (тестовый) есть реальные проблемы с железом, но вы пока их не про диагностировали;
— либо ему не хватает мощи по какому-то критически разделяемому ресурсу: память, сеть, дисковая подсистема, процессор. Но память вы вроде как отсекли, т.к. ее в виртуалке вроде как больше.
Кстати, вы так и не ответили про статистику. Но я так понимаю, это не по адресу уже. Туда же, а что за сложные вещи в самой 1С, про которые вы пишите? Тоже видимо не по адресу. Но заметьте, вы выдвигаете какие-то гипотезы, но подтверждаете ее… словами ж?
1. У вас регламентные операции с БД на самом скуле выполняются? Статистика как обновляется? Не асинхронно ли случайно? В каких-то древних версиях скуля при таком виде обновлений он тек по памяти.
2. Как организована дисковая подсистема? Файлы mdf и ldf размещены на разных дисковых массивах? Диск (-ая подсистема) журнала транзакций должна быть «более отзывчивой», т.е. требования к скорости повышены. Если все так — то хотелось бы взглянуть на времена отклика обоих файлов в момент тормозов, и в обычные моменты. Кстати, проверьте заодно, что эти файлы не сжимаются.
3. Модель восстановления самой базы какая? Если ее в simple перевести — тормоза такие же?
4. Если ОС Win 2003 или меньше, то поглядите выровнены ли сектора дисков по границе 1024Кб и отформатированы ли с размером блока 64Кб?
5. MAXDOP = 1?
И еще вы пишите, что вы — не DBA. Я тоже, и не системный администратор. Но имея опыт постоянного и в хвост и в гриву, приходится в части доказательств, разбираться на уровне, хотя бы достаточном, чтоб от меня отвязались :) Я просто для себя выработал такой кейс: если мне говорят — ДОКАЖИ, мне мое расследование нужно в конце обязательно закончить словами «что и следовало доказать». Исходя из этого, я и выстраиваю свою линию защиты, т.к. априори я — виноватый. Напр., в вашем случае, я бы подготовил ответ на вопросы, которые я Вам задал выше. Но опять же, Вы считаете, что это не ваши обязанности. А я, напр., тоже не считаю это своими обязанностями. За код ответить готов, и отвечаю. Но постоянная позиция — твой код — причина всех бед, немного выбешивает. Хочется, все таки, от системного администратора немного более глубокого погружения в тему мониторинга элементарной загрузки оборудования средствами самого Win.
Зеркальная ситуация: начальник Сис.Админ, а я — программист 1С. Это какой то грёбаный Адъ! Я все время должен доказывать ему, что виновата «не ваша 1С». Если есть любая проблема — ответ один: иди разбирайся, это ваша 1С! Если скажешь — найн, то сразу же — докажи!!! Вот типовой случай: тормозит сервер, на нем 1 база (Карл, ОДНА!) с парой тройкой активных сеансов, которые вообще ни о чем. Смотришь в Activity Monitor SQL нагрузку на подсистему ввода-вывода, там одни ожидания WRITELOG и LOGBUFFER. Показываешь, что время отклика журнала транзакций с диска в районе 5000(!!!) мс, и получаешь ответ — и что? Ну и что? Это в вашей 1С запросы «тяжелые» :) А то что утилита, которая мониторит рэйд показывает, что один диск вылетел, и включился рибилд — это ничего страшного. Ну вообщем и все вот ровно в таком духе. Самое ужасное, что я должен, просто должен всегда ДОКАЗЫВАТЬ с пруфами к сайту microsoft, к 1С, что да — вот это, так.