Как мы к этому пришли

В чём проблема

Офис будущего уже здесь

Компонента строки

• iSNumb – код спецсимвола. Спецсимволы и их номера приведены в файле NumbSymb.frw, входящем в комплект поставки КОМПАС. Он расположен в подкаталоге SDK основного каталога программы КОМПАС.
• s – строка. Если интерфейс ksTextItemParam используется для описания спецсимвола, то данная строка выводится после спецсимвола.
• type – задает назначение интерфейса. Если значение этого свойства равно SPECIAL_SYMBOL, то интерфейс описывает спецсимвол и строку. При этом строка располагается сразу за спецсимволом. Если же значение этого свойства отлично от SPECIAL_SYMBOL, то значение свойства iSNumb игнорируется, а интерфейс описывает только строку s. Учтите, что в заголовочных файлах старых версий КОМПАС данное свойство называется type_ (со знаком подчеркивания), а константа SPECIAL_SYMBOL не определена. Она равна 17.

• GetItemFont() – возвращает интерфейс параметров шрифта ksTextItemFont.
• SetItemFont – устанавливает новый интерфейс параметров шрифта ksTextItemFont. Устанавливаемый интерфейс передается в качестве значения единственного параметра. В случае успеха метод возвращает значение true.
• Init() – инициализирует нулями свойства интерфейса. В случае успеха возвращает значение true.

Основная надпись

• ksClearStamp – очищает основную надпись или ее отдельную ячейку. Единственным параметром данного метода является номер очищаемой ячейки. Если его значение равно нулю, то очищается вся основная надпись. В случае успеха данный метод возвращает единицу, а в случае ошибки — нуль.
• ksCloseStamp() – закрыть основную надпись. Это означает выйти из режима редактирования основной надписи. В случае успеха возвращает единицу, а в случае ошибки – нуль.
• ksColumnNumber – делает текущей заданную ячейку. В качестве единственного параметра в данный метод передается номер ячейки, которая делается текущей. В случае успеха данный метод возвращает единицу, а в случае ошибки — нуль.
• ksOpenStamp() – открыть основную надпись. Это означает войти в режим редактирования основной надписи. Не имеет входных параметров, в случае успеха возвращает единицу, а в случае ошибки — нуль.
• ksTextLine – записать строку в текущую ячейку. Текущая ячейка должна быть установлена методом ksColumnNumber. Единственным параметром метода ksTextLine является указатель на интерфейс ksTextItemParam, о котором я говорил чуть выше. В случае успеха метод ksTextLine возвращает единицу, а в случае ошибки — нуль.

1. Все ячейки основной надписи пронумерованы. В документации КОМПАС данных номеров нет, но есть отсылка к ГОСТам на основную надпись (ГОСТ 2.104-68 и ГОСТ 2.104-2006). Также нумерацию ячеек основной надписи можно посмотреть на странице. На рисунках ниже представлены номера ячеек основной надписи форм 2а и 2б, полученные экспериментальным путем.
   
   
   
   Первый лист
   
   
   
   Второй и последующие листы
   
2. Метод ksTextLine — не единственный способ записи строк в основную надпись. Помимо него у интерфейса ksStamp есть метод ksSetStampColumnText, который делает то же самое. Единственное отличие состоит в том, что в нем устанавливаемая строка задается не в виде интерфейса ksTextItemParam, а в виде динамического массива ksDynamicArray. В данной статье мы не будем его рассматривать.

Редактирование основной надписи

1. Получить указатель на интерфейс ksTextItemParam. Для этого используется метод GetParamStruct интерфейса ksKompasObject. Интерфейс ksTextItemParam нужен для представления строк, записываемых в основную надпись.
2. Получить указатель на интерфейс основной надписи ksStamp с помощью методов GetStamp или GetStampEx интерфейсов документа, спецификации.
3. Вызвать метод ksOpenStamp() интерфейса ksStamp. Так мы входим в режим редактирования основной надписи.
4. Подготовить строку, которая будет записана в ячейку основной надписи. Строка должна быть представлена в виде интерфейса ksTextItemParam.
5. Выделить ячейку, в которую нужно записать строку. Для выделения ячейки используется метод ksColumnNumber интерфейса ksStamp.
6. Вызвав метод ksTextLine интерфейса ksStamp, записать строку в выделенную ячейку.
7. Повторить пункты 4-6 для всех строк, записываемых в основную надпись.
8. Закрыть основную надпись методом ksCloseStamp интерфейса ksStamp.

Пример

//Получаем интерфейс представления строк
TextItemParamPtr TextItemParam;
TextItemParam = (TextItemParamPtr)kompas->GetParamStruct(ko_TextItemParam);

//Получаем интерфейс основной надписи
StampPtr Stamp;
Stamp = (StampPtr)Document2D->GetStamp();
//Открываем основную надпись
Stamp->ksOpenStamp();

Stamp->ksColumnNumber(1);
TextItemParam->s = SysAllocString(L"Деталь");
Stamp->ksTextLine(TextItemParam);

Stamp->ksColumnNumber(3);
TextItemParam->s = SysAllocString(L"");
TextItemParam->type = SPECIAL_SYMBOL;
TextItemParam->iSNumb = 51;
Stamp->ksTextLine(TextItemParam);

Stamp->ksColumnNumber(110);
TextItemParam->set_s(SysAllocString(L"Норсеев С.А."));
TextItemParam->type = 0;
Stamp->ksTextLine(TextItemParam);

//Закрываем основную надпись
Stamp->ksCloseStamp();

1. В данном примере не приводится код, ответственный за подключение к КОМПАС и создание чертежа. Я убрал его для облегчения понимания кода. О том, как подключаться к КОМПАС и настраивать чертеж (в том числе выбирать формат основной надписи в нем), говорилось в предыдущих статьях цикла.
2. Если внимательно посмотреть на приведенный выше код, то можно увидеть, что в одном случае строка устанавливалась в интерфейсе ksTextItemParam путем присвоения значения свойству s, а в другом — путем вызова метода set_s, про который я ничего не говорил. Дело в том, что в технологии COM все свойства представляются в виде методов (как правило, установки и чтения). Наименование этих методов формируется следующим образом:
   get_<имя свойства>
   set_<имя свойства>
   В своих программах вы можете использовать любой из этих подходов (присвоение значения свойству или же вызов соответствующего метода).

Хранит ли Outlook-iOS-Android копию почтового ящика на сервере микрософт?

Привет Хабр!
Хочу представить мою последнюю open-source разработку — CGLayout — вторая система разметки в iOS после Autolayout, основанная на ограничениях.

"Очередная система автолайаута… Зачем? Для чего?" — наверняка подумали вы.
Действительно iOS сообществом создано уже немало layout-библиотек, но ни одна так и не стала по-настоящему массовой альтернативой ручному layout`у, не говоря уже про Autolayout.

CGLayout работает с абстрактными сущностями, что позволяет одновременно использовать UIView, CALayer и not rendered объекты для построения разметки. Также имеет единое координатное пространство, что позволяет строить зависимости между элементами, находящимися на разных уровнях иерархии. Умеет работать в background потоке, легко кешируется, легко расширяется и многое-многое другое.
CGLayout функциональный продукт, у которого есть хорошие перспективы развиться в большой проект.

Но изначально цель была банальна, как и обычно, просто упростить себе жизнь.
Всем иногда приходится писать ручной layout, либо из-за плохой производительности Autolayout, либо из-за сложной логики. Поэтому постоянно писались какие-то расширения (а-ля setFrameThatFits и т.д.)
В процессе реализации таких расширений возникают идеи более сложного порядка, но из-за отсутствия времени, как обычно, это все остается в рамках записи в Trello и висит там вечность.
Но когда ты наконец добрался до реализации и не видно горизонта, тебя затягивает, и остановиться уже нереально. Все-таки я надеюсь время было потрачено не зря и мое решение облегчит кому-то жизнь, если не функциональностью фреймворка, то примером кода.
Помимо рассказа о своем решении, я попробую проанализировать и сравнить другие фреймворки, поэтому думаю скучно не будет.

Сравнение

Функциональность

Какие-то показатели могут быть субъективны, т.к. я не использовал эти фреймворки в production. Если я ошибся, поправьте меня пожалуйста.

Производительность

Для тестирования использовался LayoutFrameworkBenchmark.

AsyncDisplayKit не добавлен в график в силу того, что он не был включен разработчиком бенчмарка, да и ASDK осуществляет layout в бэкграунде, что не совсем честно для измерений производительности. В качестве альтернативы можно посмотреть приложение Pinterest. Производительность там действительно впечатляющая.

Анализ

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

LayoutKit

Github 25 issues

Не очень гибкий, требует написания большого количества кода, и достаточно большого включения программиста в реализацию. Не нашел информации об использовании LayoutKit'а в каких-то других приложениях, кроме самого LinkedIn.
И все-таки есть мнение, что LayoutKit не достиг своей цели, лента в приложении LinkedIn все равно тормозит.

Особенности:

• Под каждую нестандартную разметку необходимо создавать субкласс с реализацией этого layout'а.
• Ядро системы занимается созданием вью и их переиспользованием. Все вью крутятся в кеше, что может сломать ссылочную целостность при использовании внешней ссылки на вью. Да и в принципе вью недоступны через публичный интерфейс.
• Layout блоки (такие как LabelLayout) дублируют много информации о представлении. При их инициализации нужно задавать дефолтные значения (текста и т.д)
• Нет гибкости в создании относительных зависимостей между элементами.

FlexLayout (aka YogaKit)

Github 65 issues
AppSight

Предоставляет возможность заниматься только layout'ом. Никаких других плюшек, фишек нет.
Особенности:

• Нет возможности закешировать layout. Можно получить только размер.
• Не нативная реализация. API больше подходящее для кроссплатформерных разработчиков, веб-разработчиков.
• Проблемы с изменением размера экрана — приходится вручную изменять размер layout-объекта и делать пересчет.
• Требует создания лишних вью при организации layout-блоков.

AsyncDisplayKit (Texture)

Github 200 issues
AppSight

В Facebook пошли путем создания потокобезопасной абстракции более высокого уровня. Что вызвало необходимость реализовывать весь стек инструментов UIKit. Тяжелая библиотека, если вы решили ее использовать, отказаться потом от нее будет невозможно. Но все-таки это пока самое грамотное и развитое open-source решение.
Особенности:

• Не совместим с другими layout-фреймворками, кроме встроенного Yoga.
• Требует использования ASDisplayNode субклассы. По сути исключая работу с UIKit. Решив работать с ASDK можно забыть про другие средства, привыкайте писать вместо UI…, AS… .
• Собственная реализация большого количества UIKit механизмов, что может привести к устареванию кода и больших расхождений с реализацией от Apple, багам не связанным с релизами Apple.
• Дорогая поддержка.
• Мало информации связанных с решением проблем. Поиск на StackOverflow со строкой "AsyncDisplayKit" находит 181 совпадений (для сравнения “UIKit” — 66,550).

CGLayout

• Использование как на уровне UIView, так и на уровне CALayer. Можно комбинировать и ограничивать вью по положению layer'а и наоборот. Возможность использовать not rendered объекты.
• Переиспользование layout-спецификации для разных объектов.
• Возможность создания cross-hierarchy зависимостей.
• Строгая типизация.
• Кеширование разметки через получение snapshot'ов.
• Создание кастомных ограничений независимых от окружения. Например ограничение по размеру строки для лейбла.
• Поддержка layout guides и легкое создание плейсхолдеров для вью.
• Поддерживает любой доступный layout (прямой, background, кэшированный).
• Простая интеграция с UIKit.
• Легко расширяемая.

Текущие ограничения:

• Программисту необходимо думать о последовательности при определении layout-схемы и применении ограничений.
• Расчет разметки UIView, используя layer свойство ведет к неопределенному поведению, так как frame у UIView изменяется неявно и побочные действия (такие как drawRect, layoutSubviews) не вызываются. При этом layer UIView спокойно можно использовать как ограничение для другого layer'а.
• В случае получения snapshot для фрейма, отличающегося от текущего значения bounds в супервью и наличии ограничений, основанных на супервью, может приводить к неожидаемому результату.
• Пока не очень приспособлен к сложному layout'у с вероятностными ограничениями.
• Расчет разметки с ограничениями между UIView и CALayer медленный из-за необходимости конвертировать координаты с моей реализацией.

Что пока не реализовано:

1. Поддержка RTL.
2. Поведение при удалении вью из иерархии.
3. Поддержка macOS, tvOS.
4. Поддержка trait-коллекций.
5. Нет удобной конструкций для выполнения разметки переиспользуемых вью.
6. Динамическое изменение текущей layout-конфигурации.

Реализация CGLayout

CGLayout построен на современных принципах языка Swift.
Реализация управления разметкой в CGLayout базируется на трех базовых протоколах: RectBasedLayout, RectBasedConstraint, LayoutItem.

Условные обозначения

Основная разметка

public protocol RectBasedLayout {
    func layout(rect: inout CGRect, in source: CGRect)
}

RectBasedLayout — декларирует поведение для изменения разметки и определяет для этого один метод, с возможностью ориентирования относительно доступного пространства.

Структура Layout, имплементирующая протокол RectBasedLayout, определяет полную и достаточную разметку для layout-элемента, т.е. позиционирование и размеры.
Соответственно, Layout разделяется на два элемента выравнивание Layout.Alignment и заполнение Layout.Filling. Они в свою очередь состоят из горизонтального и вертикального лайаута. Все составные элементы реализуют RectBasedLayout. Что позволяет использовать элементы лайаута разного уровня сложности для реализации разметки. Все лайаут сущности легко могут быть расширены вашими имплементациями.

Составная схема структуры Layout:

Ограничения

Все ограничения реализуют RectBasedConstraint. Если сущности RectBasedLayout определяют разметку в доступном пространстве, то сущности RectBasedConstraint это доступное пространство определяют.

public protocol RectBasedConstraint {
    func constrain(sourceRect: inout CGRect, by rect: CGRect)
}

LayoutAnchor содержит конкретные ограничители (сторона, размер и т.д.), имеющие абстрагированное от окружения поведение.
В данный момент реализованы основные ограничители.

Составная схема структуры LayoutAnchor:

Layout constraints

public protocol LayoutConstraintProtocol: RectBasedConstraint {
    var isIndependent: Bool { get }
    func layoutItem(is object: AnyObject) -> Bool
    func constrainRect(for currentSpace: CGRect, in coordinateSpace: LayoutItem) -> CGRect
}

Определяют зависимость от layout-элемента или контента (текст, картинка и т.д.). Являются самодостаточными ограничениями, которые содержат всю информацию об источнике ограничения и применяемых ограничителях.
LayoutConstraint — ограничение, связанное с layout-элементом с определенным набором ограничителей.
AdjustLayoutConstraint — ограничение, связанное с layout-элементом, содержит size-based ограничители. Доступен для layout-элементов, поддерживающих AdjustableLayoutItem протокол.

Layout-элементы

public protocol LayoutItem: class, LayoutCoordinateSpace {
    var frame: CGRect { get set }
    var bounds: CGRect { get set }
    weak var superItem: LayoutItem? { get }
}

Его реализуют такие классы как UIView, CALayer, а также not rendered классы. Также вы можете реализовать другие классы, например stack view.

Во фреймворке есть реализация LayoutGuide. Это аналог UILayoutGuide из UIKit, но с возможностью фабрики layout-элементов. Что позволяет использовать LayoutGuide в качестве плейсхолдера, что довольно актуально в свете последних дизайн решений. В частности для этих целей создан класс ViewPlaceholder. Он реализует такой же паттерн загрузки вью как и UIViewController. Поэтому работа с ним будет очень знакомой.

Для элементов, которые могут рассчитать свой размер задекларирован протокол:

public protocol AdjustableLayoutItem: LayoutItem {
    func sizeThatFits(_ size: CGSize) -> CGSize
}

По умолчанию его реализуют только UIView.

Layout coordinate space

public protocol LayoutCoordinateSpace {
    func convert(point: CGPoint, to item: LayoutItem) -> CGPoint
    func convert(point: CGPoint, from item: LayoutItem) -> CGPoint
    func convert(rect: CGRect, to item: LayoutItem) -> CGRect
    func convert(rect: CGRect, from item: LayoutItem) -> CGRect

    var bounds: CGRect { get }
    var frame: CGRect { get }
}

Система лайаута имеет объединенную координатную систему представленную в виде протокола LayoutCoordinateSpace.

Она создаёт единый интерфейс для всех layout-элементов, при этом используя основные реализации каждого из типов (UIView, CALayer, UICoordinateSpace + собственная реализация для кросс-конвертации).

Layout-блоки

public protocol LayoutBlockProtocol {
    var currentSnapshot: LayoutSnapshotProtocol { get }
    func layout()
    func snapshot(for sourceRect: CGRect) -> LayoutSnapshotProtocol
    func apply(snapshot: LayoutSnapshotProtocol)
}

Layout-блок является законченной и самостоятельной единицей макета. Он определяет методы для выполнения разметки, получения/применения snapshot`а.

LayoutBlock инкапсулирует layout-элемент, его основной лайаут и ограничения, реализующие LayoutConstraintProtocol.

Процесс актуализации разметки начинается с определения доступного пространства с помощью ограничений. Следует учитывать, что система пока никак решает проблем с конфликтными ограничениями и никак их не приоритезирует, поэтому следует внимательно подходить к применению ограничений. Так в общем случае, ограничения основанные на размере (AdjustLayoutConstraint) следует ставить после ограничений, основанных на позиционировании. В качестве исходного пространства берется пространство супервью (bounds). Каждое ограничение изменяет доступное пространство (обрезает, смещает, растягивает и т.д.). После того как ограничения отработали, полученное пространство передается в Layout, где и рассчитывается актуальная разметка для элемента.

LayoutScheme — блок, который объединяет другие лайаут блоки и определяет корректную последовательность для выполнения разметки.

Layout snapshot

public protocol LayoutSnapshotProtocol {
    var snapshotFrame: CGRect { get }
    var childSnapshots: [LayoutSnapshotProtocol] { get }
}

LayoutSnapshot — снимок представленный в виде набора фреймов, сохраняя иерархию layout-элементов.

Extended

Все расширяемые элементы реализуют протокол Extended.

public protocol Extended {
    associatedtype Conformed
    static func build(_ base: Conformed) -> Self
}

Таким образом, при расширении функционала вы можете использовать уже определенный в CGLayout тип, для построения строго типизированного интерфейса.

Пример использования

CGLayout почти не отличается от ручного лайаута в смысле построения последовательности актуализации фреймов. Реализуя разметку в CGLayout программист обязан помнить, о том, что все ограничения до начала работы должны оперировать актуальными фреймами, иначе результат будет неожидаемым.

let leftLimit = LayoutAnchor.Left.limit(on: .outer)
let topLimit = LayoutAnchor.Top.limit(on: .inner)
let heightEqual = LayoutAnchor.Size.height()
...
let layoutScheme = LayoutScheme(blocks: [
   distanceLabel.layoutBlock(with: Layout(x: .center(), y: .bottom(50), 
                                     width: .fixed(70), height: .fixed(30))),
   separator1Layer.layoutBlock(with: Layout(alignment: separator1Align, filling: separatorSize), 
                                    constraints: [distanceLabel.layoutConstraint(for: [leftLimit, topLimit, heightEqual])])
...
])

...

override public func viewDidLayoutSubviews() {
    super.viewDidLayoutSubviews()
    layoutScheme.layout()
}

В этом примере сепаратор использует ограничения по distanceLabel, после того, как определено положение этого лейбла.

Итоги

Autolayout пока остаётся основным инструментом лайаута в силу своей стабильности, хорошего API и мощной поддержкой. Но сторонние решения могут помочь решить частные проблемы, в силу своей узкой направленности или гибкости.

CGLayout имеет не совсем привычную логику описания процесса layout'а, поэтому требует привыкания.
Тут еще много работы, но это вопрос времени, при этом уже сейчас видно, что он имеет ряд преимуществ, которые должны ему позволить занять свою нишу в области подобных систем. Работа фреймворка ещё не тестировалось в production, и у вас есть возможность попробовать это сделать. Фреймворк покрыт тестами, поэтому больших проблем возникнуть не должно.

Надеюсь на ваше активное участие в дальнейшей разработке фреймворка.

Github репозиторий

И в конце хотелось бы поинтересоваться у хабра-юзеров:
Какие требования предъявляете вы к layout-системам?
Что вам больше всего не нравится делать при построении верстки?

Предисловие

Решение

USE [НАЗВАНИЕ_БАЗЫ_ДАННЫХ]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO


CREATE view [inf].[vTableSize] as
with pagesizeKB as (
	SELECT low / 1024 as PageSizeKB
	FROM master.dbo.spt_values
	WHERE number = 1 AND type = 'E'
)
,f_size as (
	select p.[object_id], 
		   sum([total_pages]) as TotalPageSize,
		   sum([used_pages])  as UsedPageSize,
		   sum([data_pages])  as DataPageSize
	from sys.partitions p join sys.allocation_units a on p.partition_id = a.container_id
	left join sys.internal_tables it on p.object_id = it.object_id
	WHERE OBJECTPROPERTY(p.[object_id], N'IsUserTable') = 1
	group by p.[object_id]
)
,tbl as (
	SELECT
	  t.[schema_id],
	  t.[object_id],
	  i1.rowcnt as CountRows,
	  (COALESCE(SUM(i1.reserved), 0) + COALESCE(SUM(i2.reserved), 0)) * (select top(1) PageSizeKB from pagesizeKB) as ReservedKB,
	  (COALESCE(SUM(i1.dpages), 0) + COALESCE(SUM(i2.used), 0)) * (select top(1) PageSizeKB from pagesizeKB) as DataKB,
	  ((COALESCE(SUM(i1.used), 0) + COALESCE(SUM(i2.used), 0))
	    - (COALESCE(SUM(i1.dpages), 0) + COALESCE(SUM(i2.used), 0))) * (select top(1) PageSizeKB from pagesizeKB) as IndexSizeKB,
	  ((COALESCE(SUM(i1.reserved), 0) + COALESCE(SUM(i2.reserved), 0))
	    - (COALESCE(SUM(i1.used), 0) + COALESCE(SUM(i2.used), 0))) * (select top(1) PageSizeKB from pagesizeKB) as UnusedKB
	FROM sys.tables as t
	LEFT OUTER JOIN sysindexes as i1 ON i1.id = t.[object_id] AND i1.indid < 2
	LEFT OUTER JOIN sysindexes as i2 ON i2.id = t.[object_id] AND i2.indid = 255
	WHERE OBJECTPROPERTY(t.[object_id], N'IsUserTable') = 1
	OR (OBJECTPROPERTY(t.[object_id], N'IsView') = 1 AND OBJECTPROPERTY(t.[object_id], N'IsIndexed') = 1)
	GROUP BY t.[schema_id], t.[object_id], i1.rowcnt
)
SELECT
  @@Servername AS Server,
  DB_NAME() AS DBName,
  SCHEMA_NAME(t.[schema_id]) as SchemaName,
  OBJECT_NAME(t.[object_id]) as TableName,
  t.CountRows,
  t.ReservedKB,
  t.DataKB,
  t.IndexSizeKB,
  t.UnusedKB,
  f.TotalPageSize*(select top(1) PageSizeKB from pagesizeKB) as TotalPageSizeKB,
  f.UsedPageSize*(select top(1) PageSizeKB from pagesizeKB) as UsedPageSizeKB,
  f.DataPageSize*(select top(1) PageSizeKB from pagesizeKB) as DataPageSizeKB
FROM f_size as f
inner join tbl as t on t.[object_id]=f.[object_id]

GO

USE [НАЗВАНИЕ_БАЗЫ_ДАННЫХ]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

SET ANSI_PADDING ON
GO

CREATE TABLE [srv].[TableStatistics](
	[Row_GUID] [uniqueidentifier] NOT NULL CONSTRAINT [DF_TableStatistics_Row_GUID]  DEFAULT (newid()),
	[ServerName] [nvarchar](255) NOT NULL,
	[DBName] [nvarchar](255) NOT NULL,
	[SchemaName] [nvarchar](255) NOT NULL,
	[TableName] [nvarchar](255) NOT NULL,
	[CountRows] [bigint] NOT NULL,
	[DataKB] [int] NOT NULL,
	[IndexSizeKB] [int] NOT NULL,
	[UnusedKB] [int] NOT NULL,
	[ReservedKB] [int] NOT NULL,
	[InsertUTCDate] [datetime] NOT NULL CONSTRAINT [DF_TableStatistics_InsertUTCDate]  DEFAULT (getutcdate()),
	[Date]  AS (CONVERT([date],[InsertUTCDate])) PERSISTED,
	[CountRowsBack] [bigint] NULL,
	[CountRowsNext] [bigint] NULL,
	[DataKBBack] [int] NULL,
	[DataKBNext] [int] NULL,
	[IndexSizeKBBack] [int] NULL,
	[IndexSizeKBNext] [int] NULL,
	[UnusedKBBack] [int] NULL,
	[UnusedKBNext] [int] NULL,
	[ReservedKBBack] [int] NULL,
	[ReservedKBNext] [int] NULL,
	[AvgCountRows]  AS ((([CountRowsBack]+[CountRows])+[CountRowsNext])/(3)) PERSISTED,
	[AvgDataKB]  AS ((([DataKBBack]+[DataKB])+[DataKBNext])/(3)) PERSISTED,
	[AvgIndexSizeKB]  AS ((([IndexSizeKBBack]+[IndexSizeKB])+[IndexSizeKBNext])/(3)) PERSISTED,
	[AvgUnusedKB]  AS ((([UnusedKBBack]+[UnusedKB])+[UnusedKBNext])/(3)) PERSISTED,
	[AvgReservedKB]  AS ((([ReservedKBBack]+[ReservedKB])+[ReservedKBNext])/(3)) PERSISTED,
	[DiffCountRows]  AS (([CountRowsNext]+[CountRowsBack])-(2)*[CountRows]) PERSISTED,
	[DiffDataKB]  AS (([DataKBNext]+[DataKBBack])-(2)*[DataKB]) PERSISTED,
	[DiffIndexSizeKB]  AS (([IndexSizeKBNext]+[IndexSizeKBBack])-(2)*[IndexSizeKB]) PERSISTED,
	[DiffUnusedKB]  AS (([UnusedKBNext]+[UnusedKBBack])-(2)*[UnusedKB]) PERSISTED,
	[DiffReservedKB]  AS (([ReservedKBNext]+[ReservedKBBack])-(2)*[ReservedKB]) PERSISTED,
	[TotalPageSizeKB] [int] NULL,
	[TotalPageSizeKBBack] [int] NULL,
	[TotalPageSizeKBNext] [int] NULL,
	[UsedPageSizeKB] [int] NULL,
	[UsedPageSizeKBBack] [int] NULL,
	[UsedPageSizeKBNext] [int] NULL,
	[DataPageSizeKB] [int] NULL,
	[DataPageSizeKBBack] [int] NULL,
	[DataPageSizeKBNext] [int] NULL,
	[AvgDataPageSizeKB]  AS ((([DataPageSizeKBBack]+[DataPageSizeKB])+[DataPageSizeKBNext])/(3)) PERSISTED,
	[AvgUsedPageSizeKB]  AS ((([UsedPageSizeKBBack]+[UsedPageSizeKB])+[UsedPageSizeKBNext])/(3)) PERSISTED,
	[AvgTotalPageSizeKB]  AS ((([TotalPageSizeKBBack]+[TotalPageSizeKB])+[TotalPageSizeKBNext])/(3)) PERSISTED,
	[DiffDataPageSizeKB]  AS (([DataPageSizeKBNext]+[DataPageSizeKBBack])-(2)*[DataPageSizeKB]) PERSISTED,--показывает как изменяется само приращение
	[DiffUsedPageSizeKB]  AS (([UsedPageSizeKBNext]+[UsedPageSizeKBBack])-(2)*[UsedPageSizeKB]) PERSISTED,--показывает как изменяется само приращение
	[DiffTotalPageSizeKB]  AS (([TotalPageSizeKBNext]+[TotalPageSizeKBBack])-(2)*[TotalPageSizeKB]) PERSISTED,--показывает как изменяется само приращение
 CONSTRAINT [PK_TableStatistics] PRIMARY KEY CLUSTERED 
(
	[Row_GUID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

SET ANSI_PADDING ON
GO

USE [НАЗВАНИЕ_БАЗЫ_ДАННЫХ]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE PROCEDURE [srv].[InsertTableStatistics]
AS
BEGIN
	SET NOCOUNT ON;
	SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

	declare @dt date=CAST(GetUTCDate() as date);
    declare @dbs nvarchar(255);
	declare @sql nvarchar(max);

	select [name]
	into #dbs
	from sys.databases;

	while(exists(select top(1) 1 from #dbs))
	begin
		select top(1)
		@dbs=[name]
		from #dbs;

		set @sql=
		N'INSERT INTO [srv].[TableStatistics]
	         ([ServerName]
			   ,[DBName]
	         ,[SchemaName]
	         ,[TableName]
	         ,[CountRows]
	         ,[DataKB]
	         ,[IndexSizeKB]
	         ,[UnusedKB]
	         ,[ReservedKB]
			 ,[TotalPageSizeKB]
			 ,[UsedPageSizeKB]
			 ,[DataPageSizeKB])
	   SELECT [Server]
		  ,[DBName]
	         ,[SchemaName]
	         ,[TableName]
	         ,[CountRows]
	         ,[DataKB]
	         ,[IndexSizeKB]
	         ,[UnusedKB]
	         ,[ReservedKB]
			 ,[TotalPageSizeKB]
			 ,[UsedPageSizeKB]
			 ,[DataPageSizeKB]
		FROM ['+@dbs+'].[inf].[vTableSize];';

		exec sp_executesql @sql;

		delete from #dbs
		where [name]=@dbs;
	end

	drop table #dbs;

	declare @dt_back date=CAST(DateAdd(day,-1,@dt) as date);

	;with tbl1 as (
		select [Date], 
			   [CountRows],
			   [DataKB],
			   [IndexSizeKB],
			   [UnusedKB],
			   [ReservedKB],
			   [ServerName], 
			   [DBName], 
			   [SchemaName], 
			   [TableName],
			   [TotalPageSizeKB],
			   [UsedPageSizeKB],
			   [DataPageSizeKB]
		from [srv].[TableStatistics]
		where [Date]=@dt_back
	)
	, tbl2 as (
		select [Date], 
			   [CountRows], 
			   [CountRowsBack],
			   [DataKBBack],
			   [IndexSizeKBBack],
			   [UnusedKBBack],
			   [ReservedKBBack],
			   [ServerName], 
			   [DBName], 
			   [SchemaName], 
			   [TableName],
			   [TotalPageSizeKBBack],
			   [UsedPageSizeKBBack],
			   [DataPageSizeKBBack]
		from [srv].[TableStatistics]
		where [Date]=@dt
	)
	update t2
	set t2.[CountRowsBack]		=t1.[CountRows],
		t2.[DataKBBack]			=t1.[DataKB],
		t2.[IndexSizeKBBack]	=t1.[IndexSizeKB],
		t2.[UnusedKBBack]		=t1.[UnusedKB],
		t2.[ReservedKBBack]		=t1.[ReservedKB],
		t2.[TotalPageSizeKBBack]=t1.[TotalPageSizeKB],
		t2.[UsedPageSizeKBBack]	=t1.[UsedPageSizeKB],
		t2.[DataPageSizeKBBack]	=t1.[DataPageSizeKB]
	from tbl1 as t1
	inner join tbl2 as t2 on t1.[Date]=DateAdd(day,-1,t2.[Date])
	and t1.[ServerName]=t2.[ServerName]
	and t1.[DBName]=t2.[DBName]
	and t1.[SchemaName]=t2.[SchemaName]
	and t1.[TableName]=t2.[TableName];

	;with tbl1 as (
		select [Date], 
			   [CountRows], 
			   [CountRowsNext],
			   [DataKBNext],
			   [IndexSizeKBNext],
			   [UnusedKBNext],
			   [ReservedKBNext],
			   [ServerName], 
			   [DBName], 
			   [SchemaName], 
			   [TableName],
			   [TotalPageSizeKBNext],
			   [UsedPageSizeKBNext],
			   [DataPageSizeKBNext]
		from [srv].[TableStatistics]
		where [Date]=@dt_back
	)
	, tbl2 as (
		select [Date], 
			   [CountRows],
			   [DataKB],
			   [IndexSizeKB],
			   [UnusedKB],
			   [ReservedKB],
			   [ServerName], 
			   [DBName], 
			   [SchemaName], 
			   [TableName],
			   [TotalPageSizeKB],
			   [UsedPageSizeKB],
			   [DataPageSizeKB]
		from [srv].[TableStatistics]
		where [Date]=@dt
	)
	update t1
	set t1.[CountRowsNext]		=t2.[CountRows],
		t1.[DataKBNext]			=t2.[DataKB],
		t1.[IndexSizeKBNext]	=t2.[IndexSizeKB],
		t1.[UnusedKBNext]		=t2.[UnusedKB],
		t1.[ReservedKBNext]		=t2.[ReservedKB],
		t1.[TotalPageSizeKBNext]=t2.[TotalPageSizeKB],
		t1.[UsedPageSizeKBNext]	=t2.[UsedPageSizeKB],
		t1.[DataPageSizeKBNext]	=t2.[DataPageSizeKB]
	from tbl1 as t1
	inner join tbl2 as t2 on t1.[Date]=DateAdd(day,-1,t2.[Date])
	and t1.[ServerName]=t2.[ServerName]
	and t1.[DBName]=t2.[DBName]
	and t1.[SchemaName]=t2.[SchemaName]
	and t1.[TableName]=t2.[TableName];
END
GO

USE [НАЗВАНИЕ_БАЗЫ_ДАННЫХ]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

create view [srv].[vTableStatisticsShort] as 
with d as (select DateAdd(day,-1,max([Date])) as [Date] from [srv].[TableStatistics])
SELECT t.[ServerName]
      ,t.[DBName]
      ,t.[SchemaName]
      ,t.[TableName]
      ,t.[CountRows]
      ,t.[DataKB]
      ,t.[IndexSizeKB]
      ,t.[UnusedKB]
      ,t.[ReservedKB]
      ,t.[InsertUTCDate]
      ,t.[Date]
      ,t.[CountRowsBack]
      ,t.[CountRowsNext]
      ,t.[DataKBBack]
      ,t.[DataKBNext]
      ,t.[IndexSizeKBBack]
      ,t.[IndexSizeKBNext]
      ,t.[UnusedKBBack]
      ,t.[UnusedKBNext]
      ,t.[ReservedKBBack]
      ,t.[ReservedKBNext]
      ,t.[AvgCountRows]
      ,t.[AvgDataKB]
      ,t.[AvgIndexSizeKB]
      ,t.[AvgUnusedKB]
      ,t.[AvgReservedKB]
      ,t.[DiffCountRows]
      ,t.[DiffDataKB]
      ,t.[DiffIndexSizeKB]
      ,t.[DiffUnusedKB]
      ,t.[DiffReservedKB]
      ,t.[TotalPageSizeKB]
      ,t.[TotalPageSizeKBBack]
      ,t.[TotalPageSizeKBNext]
      ,t.[UsedPageSizeKB]
      ,t.[UsedPageSizeKBBack]
      ,t.[UsedPageSizeKBNext]
      ,t.[DataPageSizeKB]
      ,t.[DataPageSizeKBBack]
      ,t.[DataPageSizeKBNext]
      ,t.[AvgDataPageSizeKB]
      ,t.[AvgUsedPageSizeKB]
      ,t.[AvgTotalPageSizeKB]
      ,t.[DiffDataPageSizeKB]
      ,t.[DiffUsedPageSizeKB]
      ,t.[DiffTotalPageSizeKB]
  FROM d
  inner join [SRV].[srv].[TableStatistics] as t on d.[Date]=t.[Date]
  where t.[CountRowsBack] is not null
	and	t.[CountRowsNext] is not null
GO

USE [НАЗВАНИЕ_БАЗЫ_ДАННЫХ]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

select	t2.[DB_Name] as [DBName]
			,t1.FileId 
			,t1.NumberReads
			,t1.BytesRead
			,t1.IoStallReadMS
			,t1.NumberWrites
			,t1.BytesWritten
			,t1.IoStallWriteMS 
			,t1.IoStallMS
			,t1.BytesOnDisk
			,t1.[TimeStamp]
			,t1.FileHandle
			,t2.[Type_desc]
			,t2.[FileName]
			,t2.[Drive]
			,t2.[Physical_Name]
			,t2.[Ext]
			,t2.[CountPage]
			,t2.[SizeMb]
			,t2.[SizeGb]
			,t2.[Growth]
			,t2.[GrowthMb]
			,t2.[GrowthGb]
			,t2.[GrowthPercent]
			,t2.[is_percent_growth]
			,t2.[database_id]
			,t2.[State]
			,t2.[StateDesc]
			,t2.[IsMediaReadOnly]
			,t2.[IsReadOnly]
			,t2.[IsSpace]
			,t2.[IsNameReserved]
			,t2.[CreateLsn]
			,t2.[DropLsn]
			,t2.[ReadOnlyLsn]
			,t2.[ReadWriteLsn]
			,t2.[DifferentialBaseLsn]
			,t2.[DifferentialBaseGuid]
			,t2.[DifferentialBaseTime]
			,t2.[RedoStartLsn]
			,t2.[RedoStartForkGuid]
			,t2.[RedoTargetLsn]
			,t2.[RedoTargetForkGuid]
			,t2.[BackupLsn]
from fn_virtualfilestats(NULL, NULL) as t1
inner join [inf].[ServerDBFileInfo] as t2 on t1.[DbId]=t2.[database_id] and t1.[FileId]=t2.[File_Id]
GO

Результат

Источники:

Предисловие

Решение

1. Logical Disk
   
   1. Avg Disc sec/Read
      Показывает выраженное в секундах среднее время чтения данных с диска. Среднее значение счетчика производительности Avg. Disk sec/Read не должно превышать 10 миллисекунд. Максимальное значение счетчика производительности Avg. Disk sec/Read не должно превышать 50 миллисекунд.
      Zabbix: perf_counter[\LogicalDisk(_Total)\Avg. Disk sec/Read], а также важно проследить за нужным диском, например так: perf_counter[\LogicalDisk(C:)\Avg. Disk sec/Read]
      Примеры триггеров:
      {НАЗВАНИЕ_УЗЛА:perf_counter[\LogicalDisk(_Total)\Avg. Disk sec/Read].last()}>0.005, уровень-высокий
      и
      {НАЗВАНИЕ_УЗЛА:perf_counter[\LogicalDisk(_Total)\Avg. Disk sec/Read].last()}>0.0025, уровень-средний
      
   2. Avg Disc sec/Write
      Показывает выраженное в секундах среднее время записи данных на диск. Среднее значение счетчика производительности Avg. Disk sec/Write не должно превышать 10 миллисекунд. Максимальное значение счетчика производительности Avg. Disk sec/Write не должно превышать 50 миллисекунд.
      Zabbix: perf_counter[\LogicalDisk(_Total)\Avg. Disk sec/Write], а также важно проследить за нужным диском, например так: perf_counter[\LogicalDisk(C:)\Avg. Disk sec/Write]
      Примеры триггеров:
      {НАЗВАНИЕ_УЗЛА:perf_counter[\LogicalDisk(_Total)\Avg. Disk sec/Write].last()}>0.005, уровень-высокий
      и
      {НАЗВАНИЕ_УЗЛА:perf_counter[\LogicalDisk(_Total)\Avg. Disk sec/Write].last()}>0.0025, уровень-средний
   3. Avg Disk Queue Length
      Cредняя длина очереди запросов к диску. Отображает количество запросов к диску, ожидающих обработки в течении определенного интервала времени. Нормальным считается очередь не больше 2 для одиночного диска. Если в очереди больше двух запросов, то возможно диск перегружен и не успевает обрабатывать поступающие запросы. Уточнить, с какими именно операциями не справляется диск, можно с помощью счетчиков Avg. Disk Read Queue Length (очередь запросов на чтение) и Avg. Disk Wright Queue Length (очередь запросов на запись).
      Значение Avg. Disk Queue Length не измеряется, а рассчитывается по закону Литтла из математической теории очередей. Согласно этому закону, количество запросов, ожидающих обработки, в среднем равняется частоте поступления запросов, умноженной на время обработки запроса. Т.е. в нашем случае Avg. Disk Queue Length = (Disk Transfers/sec) * (Avg. Disk sec/Transfer).
      Avg. Disk Queue Length приводится как один из основных счетчиков для определения загруженности дисковой подсистемы, однако для его адекватной оценки необходимо точно представлять физическую структуру системы хранения. К примеру, для одиночного жесткого диска критическим считается значение больше 2, а если диск располагается на RAID-массиве из 4-х дисков, то волноваться стоит при значении больше 4*2=8.
      Zabbix: perf_counter[\LogicalDisk(_Total)\Avg. Disk Queue Length], а также важно проследить за нужным диском, например так: perf_counter[\LogicalDisk(C:)\Avg. Disk Queue Length]
      
   
   
2. Memory
   
   1. Pages/sec
      Показывает число страниц, которые SQL Server считал с диска или записал на диск для того, чтобы разрешить обращения к страницам памяти, которые не были загружены в оперативную память в момент обращения. Эта величина является суммой величин Pages Input/sec и Pages Output/sec, а также учитывает страничный обмен (подкачку/свопинг) системной кэш-памяти для доступа к файлам данных приложений. Кроме того, сюда включается подкачка не кэшированных файлов, непосредственно отображаемых в память. Это основной счетчик, за которым следует следить в том случае, если наблюдается большая нагрузка на использование памяти и связанный с этим избыточный страничный обмен. Этот счётчик характеризует величину свопинга и его нормальное (не пиковое) значение должно быть близко к нолю. Увеличение свопинга говорит о необходимости наращивания ОЗУ или уменьшения числа исполняемых на сервере прикладных программ.
      Zabbix: perf_counter[\Memory\Pages/sec]
      Пример триггера:
      {НАЗВАНИЕ_УЗЛА:perf_counter[\Memory\Pages/sec].min(5m)}>1000, уровень-информация
   2. Page Faults/sec
      Это значение счетчика ошибок страницы. Ошибка страницы возникает, когда процесс ссылается на страницу виртуальной памяти, которая не находится в рабочем множестве оперативной памяти. Данный счетчик учитывает как те ошибки страницы, которые требуют обращения к диску, так и те, которые вызваны нахождением страницы вне рабочего множества в оперативной памяти. Большинство процессоров могут обрабатывать ошибки страницы второго типа без особых задержек. Однако, обработка ошибок страницы первого типа, требующая доступа к диску, может привести к значительным задержкам.
      Zabbix: perf_counter[\Memory\Page Faults/sec]
      Пример триггера:
      {НАЗВАНИЕ_УЗЛА:perf_counter[\Memory\Page Faults/sec].min(5m)}>1000, уровень-информация
   3. Available Bytes
      Отслеживает количество доступной памяти в байтах для выполнения различных процессов. Низкие показатели означают нехватку памяти. Решение — увеличить память. Этот счётчик в большинстве случаев должен быть постоянно выше 5000 КВ.
      Есть смысл выставлять порог для Available Mbytes вручную из соображений:
      •50% свободной памяти доступно = Отлично
      •25% доступно памяти = Требует внимания
      •10% свободно = Возможны проблемы
      •Меньше 5% доступно памяти= Критично для скорости, нужно вмешиваться.
      Zabbix: perf_counter[\Memory\Available Bytes]
      
   
   
3. Processor (Total): % Processor Time
   Этот счетчик показывает процентное отношение времени, которое процессор был занят выполнением операций для не простаивающих потоков (non-Idle thread). Эту величину можно рассматривать как долю времени, приходящегося на выполнение полезной работы. Каждый процессор может быть назначен простаивающему потоку, который потребляет непродуктивные циклы процессора, не используемые другими потоками. Для этого счётчика характерны непродолжительные пики, которые могут достигать 100 процентов. Однако, если наблюдаются продолжительные периоды, когда утилизация процессора выше 80 процентов, то система будет более эффективной при использовании большего числа процессоров.
   Zabbix: perf_counter[\Processor(_Total)\% Processor Time], здесь же может иметь место по ядрам выводить
   Пример триггера:
   {НАЗВАНИЕ_УЗЛА:perf_counter[\Processor(_Total)\% Processor Time].min(5m)}>80, уровень-информация
   
4. Network Interface (*): % Bytes Total/sec
   Общее количество переданных и полученных байт за секунду по всем интерфейсам. Это пропускная способность интерфейса (в байтах). Необходимо сравнить значение этого счётчика с максимальной пропускной способностью сетевой платы. Вообще, этот счётчик должен показать не более 50% утилизации пропускной способности сетевого адаптера.
   Zabbix: perf_counter[\Network Interface(*)\Bytes Sent/sec]
   
5. MS SQL Server: Access Methods
   Объект Access Methods (Методы доступа) в SQL Server предоставляет счетчики, помогающие следить за доступом к логическим данным в рамках базы данных. Физический доступ к страницам базы данных на диске контролируется при помощи счетчиков диспетчера буферов. Наблюдение за методами доступа к данным в базе данных помогает определить, можно ли увеличить производительность запросов путем добавления или изменения индексов, добавления или перемещения секций, добавления файлов или групп файлов, дефрагментации индексов или изменения текста запросов. Кроме того, при помощи счетчиков объекта Access Methods можно следить за размером данных, индексов и свободного пространства в базе данных, контролируя объем и фрагментацию для каждого экземпляра сервера. Чрезмерная фрагментация индексов может значительно снизить производительность.
   
   1. Page Splits/sec
      Количество разбиений страниц в секунду, выполненных в результате переполнения страниц индекса. Большое значение этого показателя означает, что при выполнении операций вставки и изменения данных SQL Server приходится выполнять большое количество ресурсоемких операций по разбиению страниц и переносу части существующей страницы на новое место. Таких операций по возможности следует избегать. Проблему можно попытаться решить двумя способами:
      — создать кластерный индекс для столбцов с автоприращением. В этом случае новые записи не будут помещаться внутрь страниц, уже занятых данными, а будут последовательно занимать новые страницы;
      — перестроить индексы, увеличив значение параметра Fillfactor. Этот параметр позволяет зарезервировать в страницах индексов свободное место, которое будет использоваться для размещения новых данных, без необходимости производить операции разбиения страниц.
      Zabbix: perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Access Methods\Page Splits/sec",30]
      Пример триггера: {НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Access Methods\Page Splits/sec",30].last()}>{НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:SQL Statistics\Batch Requests/sec",30].last()}/5, уровень-информация
      
   2. Full Scans/sec
      Количество неограниченных операций полного сканирования в секунду. К таким операциям относятся сканирование основной таблицы и полное сканирование индекса. Стабильное повышение этого показателя может свидетельствовать о деградации системы (нехватка нужных индексов, их сильная фрагментация, неиспользование оптимизатором существующих индексов, наличие неиспользуемых индексов). Однако, стоит отметить, что полное сканирование в небольших таблицах невсегда плохо, т к если удается всю таблицу разместить в ОЗУ, то как раз быстрее будет произвести полное сканирование. Но в большинстве случаев стабильный рост показателя этого счетчика будет говорить о деградации системы. Все это применимо только для OLTP-систем. В OLAP-системах постоянные полные сканирования-это нормально.
      Zabbix: perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Access Methods\Full Scans/sec",30]
      
   
   
6. MS SQL Server: Buffer Manager
   Объект Buffer Manager (диспетчера буферов) предоставляет счетчики, позволяющие наблюдать за тем, как SQL Server использует следующие ресурсы:
   — память для хранения страниц данных;
   — счетчики, служащие для мониторинга физического ввода-вывода, когда SQL Server считывает и записывает страницы баз данных;
   — расширение буферного пула для расширения буферного кэша с использованием быстрой энергонезависимой памяти, например твердотельных накопителей (SSD);
   — мониторинг памяти и счетчиков, используемых SQL Server, помогает получить следующие сведения;
   — существуют ли «узкие места», вызванные недостатком физической памяти. Если часто используемые данные не могут быть сохранены в кэше, SQL Server вынужден считывать их с диска;
   — можно ли повысить эффективность выполнения запросов, увеличив объем памяти или выделив дополнительную память для кэширования данных или хранения внутренних структур SQL Server;
   — насколько часто SQL Server считывает данные с диска. В сравнении с другими операциями, такими как доступ к памяти, физический ввод-вывод выполняется дольше. Уменьшение объема ввода-вывода может повысить производительность выполнения запросов.
   
   1. Buffer Cache hit radio
      Показывает, насколько полно SQL Server может разместить данные в буфере кэша. Чем выше это значение, тем лучше, т.к. для эффективного обращения SQL сервера к страницам данных, они должны находиться в буфере кэша, и операции физического ввода-вывода (I/O) должны отсутствовать. Если наблюдается устойчивое снижение среднего значения этого счётчика, необходимо рассмотреть возможность добавления ОЗУ. Данный показатель всегда должен быть выше 90% для OLTP-систем и выше 50% для OLAP-систем.
      Zabbix: perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Buffer Manager\Buffer cache hit ratio",30]
      Примеры триггеров: {НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Buffer Manager\Buffer cache hit ratio",30].last()}<70, уровень-высокий
      и
      {НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Buffer Manager\Buffer cache hit ratio",30].last()}<80, уровень-средний
      
   2. Page life expectancy
      Показывает, как долго страница будет постоянно находиться в памяти в нынешнем состоянии. Если значение постоянно падает, то это означает, что система злоупотребляет буферным пулом. Таким образом, потенциально работа памяти может вызывать проблемы, приводящие к снижению производительности. Стоит отметить, что не существует универсального показателя, ниже которого можно однозначно судить о том, что система злоупотребляет буферным пулом (показатель в 300 секунд устарел с MS SQL Server 2012).
      Zabbix: perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Buffer Manager\Page life expectancy",30]
      Пример триггера: {НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Buffer Manager\Page life expectancy",30].last()}<5, уровень-информация
   
   
7. MS SQL Server: General Statistics
   Объект General Statistics (Общая статистика) в SQL Server предоставляет счетчики, позволяющие наблюдать общую активность сервера, например количество одновременных соединений и количество пользователей в секунду, подключающихся или отключающихся от компьютера, где запущен экземпляр SQL Server. Эти показатели полезно использовать в больших системах оперативной обработки транзакций (OLTP), где большое количество клиентов постоянно подключаются и отключаются от экземпляра SQL Server.
   
   1. Process blocked
      Количество блокированных в данный момент процессов.
      Zabbix: perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:General Statistics\Processes blocked",30]
      Пример триггера: ({НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:General Statistics\Processes blocked",30].min(2m,0)}>=0)
      and ({НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:General Statistics\Processes blocked",30].time(0)}>=50000)
      and ({НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:General Statistics\Processes blocked",30].time(0)}<=230000), уровень-информация (здесь идет ограничение по сигнализации с 05:00 до 23:00)
      
   2. User Connections
      Количество пользователей, подключенных в данный момент к серверу SQL Server.
      Zabbix: perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:General Statistics\User Connections",30]
   
   
8. MS SQL Server: Locks
   Объект Locks (Блокировки) в Microsoft SQL Server предоставляет сведения о блокировках SQL Server, полученных для отдельных типов ресурсов. Блокировки выдаются на такие ресурсы SQL Server, как прочитанные или измененные транзакцией строки, для предотвращения одновременного использования ресурсов несколькими транзакциями. Например, если исключительная (X) блокировка получена транзакцией на строку в таблице, никакая другая транзакция не сможет изменить эту строку, пока блокировка не будет освобождена. Минимизация использования блокировок повышает параллелизм, что может улучшить общую производительность. Одновременно может отслеживаться несколько экземпляров объекта Locks, каждый из которых будет представлять собой блокировку отдельного вида ресурсов.
   
   1. Average Wait Time (ms)
      Средняя длительность ожидания (в миллисекундах) для всех запросов блокировки, при которых потребовалось ожидание. Этот счетчик показывает, сколько в среднем процессам пользователей приходится проводить в очереди, чтобы наложить на ресурс блокировку. Максимально допустимое значение этого счетчика полностью зависит от вашей задачи, какое-то среднее значение для всех приложений здесь определить сложно. Слишком высокое значение этого счетчика может означать проблемы с блокировками в вашей базе данных.
      Zabbix: perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)\Average Wait Time (ms)",30]
      Пример триггера: {НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)\Average Wait Time (ms)",30].last()}>=500, уровень-информация
      
   2. Lock Wait Time (ms)
      Суммарное время ожидания блокировок (в миллисекундах) за последнюю секунду.
      Zabbix: perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)\Lock Wait Time (ms)",30]
   3. Lock Waits/sec
      Количество случаев за последнюю секунду, когда потоку приходилось ожидать в связи с запросом блокировки.
      Zabbix: perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)\Lock Wait Time (ms)",30]
   4. Lock Timeouts/sec
      Количество повторений, когда не удается получить блокировку путем циклического обращения. Значение параметра конфигурирования SQL Server spin counter определяет количество «оборотов» потока (spins), прежде чем истечет время тайм-аута и поток перейдет в неактивное состояние.
      Zabbix: perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Lock Timeouts/sec",30]
      Пример триггера: {НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)\Lock Timeouts/sec",30].last()}>1000, уровень-информация
   5. Lock Requests/sec
      Количество запросов в секунду указанного типа блокировки.
      Zabbix: perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Lock Requests/sec",30]
      Пример триггера: {НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)\Lock Requests/sec",30].last()}>500000, уровень-информация
   6. Lock Number of Deadlocks/sec
      Количество запросов блокировки в секунду, приводящих к взаимоблокировке. Наличие взаимоблокировок свидетельствует о неправильно построенных запросах, которые блокируют совместные ресурсы.
      Zabbix: perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Number of Deadlocks/sec",30]
      Пример триггера: {НАЗВАНИЕ_УЗЛА:perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Locks(_Total)\Number of Deadlocks/sec",30].last()}>1, уровень-высокий
   
   
9. MS SQL Server: Memory Manager
   Объект Memory Manager (Диспетчер памяти) в Microsoft SQL Server обеспечивает счетчики для контроля использования памяти всего сервера. Контроль над использованием памяти всего сервера для оценки действий пользователя и использования ресурсов может помочь идентифицировать нехватку производительности. Контроль над памятью, используемый экземпляром SQL Server, может помочь определить:
   — существуют ли нехватки в недостаточной физической памяти для хранения в кэше часто используемых данных. Если памяти недостаточно, SQL Server должен получить данные с диска;
   — может ли производительность запроса улучшиться, если будет добавлена память или увеличится объем доступной памяти для кэширования данных или внутренних структур SQL Server.
   
   1. Memory Grants Outstending
      Указывает общее число процессов, успешно получивших память рабочей области. При стабильном падении показателя, необходимо увеличить ОЗУ.
      Zabbix: perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Memory Manager\Memory Grants Outstanding",30]
      
   2. Memory Grants Pending
      Указывает общее число процессов, ожидающих предоставления памяти рабочей памяти. При стабильном росте показателя, необходимо увеличить ОЗУ.
      Zabbix: perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:Memory Manager\Memory Grants Pending",30]
   
   
10. MS SQL Server: Statistics
    Объект Statistics (Статистика) в Microsoft SQL Server обеспечивает работу счетчиков для наблюдения компиляции и типов запросов, отправляемых экземпляру SQL Server. Наблюдение за числом компиляций и повторных компиляций запросов и числа пакетов, полученных экземпляром SQL Server, дает представление о том, как быстро SQL Server выполняет запросы пользователей и насколько эффективно их обрабатывает оптимизатор запросов.
    
    1. Butch Requests/sec
       Число пакетов команд Transact-SQL, полученных за секунду. На эту статистику влияют любые ограничения (ввод-вывод, число пользователей, размер кэша, сложность запросов и т. д.). Высокое число запросов пакетов свидетельствует о высокой пропускной способности.
       Zabbix: perf_counter["\MSSQL$НАЗВАНИЕ_ЭКЗЕМПЛЯРА:SQL Statistics\Batch Requests/sec",30]
       
    
    

USE [ИМЯ_БАЗЫ_ДАННЫХ]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE PROCEDURE [nav].[ZabbixGetCountRequestStatus]
	@Status nvarchar(255)
AS
BEGIN
	/*
		возвращает кол-во запросов с заданным статусом
	*/
	SET NOCOUNT ON;

	select count(*) as [Count]
	from sys.dm_exec_requests ER with(readuncommitted)
	where [status]=@Status
END

$SQLServer = "НАЗВАНИЕ_ЭКЗЕМПЛЯРА";
$uid = "ЛОГИН"; 
$pwd = "ПАРОЛЬ";
$Status="running";

$connectionString = "Server = $SQLServer; Database=НАЗВАНИЕ_БД; Integrated Security = False; User ID = $uid; Password = $pwd;";

$connection = New-Object System.Data.SqlClient.SqlConnection;
$connection.ConnectionString = $connectionString;

#Создаем запрос непосредственно к MSSQL / Create a request directly to MSSQL
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand;
$SqlCmd.CommandType = [System.Data.CommandType]::StoredProcedure;  
$SqlCmd.CommandText = "nav.ZabbixGetCountRequestStatus";
$SqlCmd.Connection = $Connection;

$paramStatus=$SqlCmd.Parameters.Add("@Status" , [System.Data.SqlDbType]::VarChar);
$paramStatus.Value = $Status;

$connection.Open();
$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter;
$SqlAdapter.SelectCommand = $SqlCmd;
$DataSet = New-Object System.Data.DataSet;
$SqlAdapter.Fill($DataSet) > $null;
$connection.Close();

$result = $DataSet.Tables[0].Rows[0]["Count"];

write-host $result;

$SQLServer = "НАЗВАНИЕ_ЭКЗЕМПЛЯРА";
$uid = "ЛОГИН"; 
$pwd = "ПАРОЛЬ";
$Status="suspended";

$connectionString = "Server = $SQLServer; Database=НАЗВАНИЕ_БД; Integrated Security = False; User ID = $uid; Password = $pwd;";

$connection = New-Object System.Data.SqlClient.SqlConnection;
$connection.ConnectionString = $connectionString;

#Создаем запрос непосредственно к MSSQL / Create a request directly to MSSQL
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand;
$SqlCmd.CommandType = [System.Data.CommandType]::StoredProcedure;  
$SqlCmd.CommandText = "nav.ZabbixGetCountRequestStatus";
$SqlCmd.Connection = $Connection;

$paramStatus=$SqlCmd.Parameters.Add("@Status" , [System.Data.SqlDbType]::VarChar);
$paramStatus.Value = $Status;

$connection.Open();
$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter;
$SqlAdapter.SelectCommand = $SqlCmd;
$DataSet = New-Object System.Data.DataSet;
$SqlAdapter.Fill($DataSet) > $null;
$connection.Close();

$result = $DataSet.Tables[0].Rows[0]["Count"];

write-host $result;

select ER.[session_id]
      ,ER.[request_id]
      ,ER.[start_time]
      ,ER.[status]
      ,ER.[command]
      ,ER.[sql_handle]
      ,ER.[statement_start_offset]
      ,ER.[statement_end_offset]
      ,ER.[plan_handle]
      ,coalesce(ER.[database_id], ES.[database_id]) as [database_id]
	  ,DB_Name(coalesce(ER.[database_id], ES.[database_id])) as [DBName]
      ,(select top(1) text from sys.dm_exec_sql_text(ER.[sql_handle])) as [TSQL]
	  ,(select top(1) [query_plan] from sys.dm_exec_query_plan(ER.[plan_handle])) as [QueryPlan]
      ,ER.[user_id]
      ,ER.[connection_id]
      ,ER.[blocking_session_id]
      ,ER.[wait_type]
      ,ER.[wait_time]
      ,ER.[last_wait_type]
      ,ER.[wait_resource]
      ,ER.[open_transaction_count]
      ,ER.[open_resultset_count]
      ,ER.[transaction_id]
      ,ER.[context_info]
      ,ER.[percent_complete]
      ,ER.[estimated_completion_time]
      ,ER.[cpu_time]
      ,ER.[total_elapsed_time]
      ,ER.[scheduler_id]
      ,ER.[task_address]
      ,ER.[reads]
      ,ER.[writes]
      ,ER.[logical_reads]
      ,ER.[text_size]
      ,ER.[language]
      ,ER.[date_format]
      ,ER.[date_first]
      ,ER.[quoted_identifier]
      ,ER.[arithabort]
      ,ER.[ansi_null_dflt_on]
      ,ER.[ansi_defaults]
      ,ER.[ansi_warnings]
      ,ER.[ansi_padding]
      ,ER.[ansi_nulls]
      ,ER.[concat_null_yields_null]
      ,ER.[transaction_isolation_level]
      ,ER.[lock_timeout]
      ,ER.[deadlock_priority]
      ,ER.[row_count]
      ,ER.[prev_error]
      ,ER.[nest_level]
      ,ER.[granted_query_memory]
      ,ER.[executing_managed_code]
      ,ER.[group_id]
      ,ER.[query_hash]
      ,ER.[query_plan_hash]
	  ,EC.[most_recent_session_id]
      ,EC.[connect_time]
      ,EC.[net_transport]
      ,EC.[protocol_type]
      ,EC.[protocol_version]
      ,EC.[endpoint_id]
      ,EC.[encrypt_option]
      ,EC.[auth_scheme]
      ,EC.[node_affinity]
      ,EC.[num_reads]
      ,EC.[num_writes]
      ,EC.[last_read]
      ,EC.[last_write]
      ,EC.[net_packet_size]
      ,EC.[client_net_address]
      ,EC.[client_tcp_port]
      ,EC.[local_net_address]
      ,EC.[local_tcp_port]
      ,EC.[parent_connection_id]
      ,EC.[most_recent_sql_handle]
	  ,ES.[login_time]
	  ,ES.[host_name]
	  ,ES.[program_name]
	  ,ES.[host_process_id]
	  ,ES.[client_version]
	  ,ES.[client_interface_name]
	  ,ES.[security_id]
	  ,ES.[login_name]
	  ,ES.[nt_domain]
	  ,ES.[nt_user_name]
	  ,ES.[memory_usage]
	  ,ES.[total_scheduled_time]
	  ,ES.[last_request_start_time]
	  ,ES.[last_request_end_time]
	  ,ES.[is_user_process]
	  ,ES.[original_security_id]
	  ,ES.[original_login_name]
	  ,ES.[last_successful_logon]
	  ,ES.[last_unsuccessful_logon]
	  ,ES.[unsuccessful_logons]
	  ,ES.[authenticating_database_id]
from sys.dm_exec_requests ER with(readuncommitted)
left join sys.dm_exec_sessions ES with(readuncommitted)
on ES.session_id = ER.session_id 
left join sys.dm_exec_connections EC  with(readuncommitted)
on EC.session_id = ER.session_id
where ER.status in ('suspended', 'running')

/*
creation_time - Время, когда запрос был скомпилирован. Поскольку при старте сервера кэш пустой, данное время всегда больше либо равно моменту запуска сервиса. Если время, указанное в этом столбце позже, чем предполагаемое (первое использование процедуры), это говорит о том, что запрос по тем или иным причинам был рекомпилирован.
last_execution_time - Момент фактического последнего выполнения запроса.
execution_count - Сколько раз запрос был выполнен с момента компиляции
Количество выполнений позволяет найти ошибки в алгоритмах - часто в наиболее выполняемых запросах оказываются те, которые находятся внутри каких-либо циклов однако могут быть выполнены перед самим циклом один раз. Например, получение каких-либо параметров из базы данных, не меняющихся внутри цикла.
CPU - Суммарное время использования процессора в миллисекундах. Если запрос обрабатывается параллельно, то это время может превысить общее время выполнения запроса, поскольку суммируется время использования запроса каждым ядром. Во время использования процессора включается только фактическая нагрузка на ядра, в нее не входят ожидания каких-либо ресурсов.
Очевидно, что данный показатель позволяет выявлять запросы, наиболее сильно загружающие процессор.
AvgCPUTime - Средняя загрузка процессора на один запрос. 
TotDuration - Общее время выполнения запроса, в миллисекундах.
Данный параметр может быть использован для поиска тех запросов, которые, независимо от причины выполняются "наиболее долго". Если общее время выполнения запроса существенно ниже времени CPU (с поправкой на параллелизм) - это говорит о том, что при выполнения запроса были ожидания каких-либо ресурсов. В большинстве случаев это связано с дисковой активностью или блокировками, но также это может быть сетевой интерфейс или другой ресурс. 
Полный список типов ожиданий можно посмотреть в описании представления sys.dm_os_wait_stats.
AvgDur - Среднее время выполнения запроса в миллисекундах.
Reads - Общее количество чтений.
Это пожалуй лучший агрегатный показатель, позволяющий выявить наиболее нагружающие сервер запросы.
Логическое чтение - это разовое обращение к странице данных, физические чтения не учитываются.
В рамках выполнения одного запроса, могут происходить неоднократные обращения к одной и той же странице.
Чем больше обращений к страницам, тем больше требуется дисковых чтений, памяти и, если речь идет о повторных обращениях, большее время требуется удерживать страницы в памяти.
Writes - Общее количество изменений страниц данных.
Характеризует то, как запрос "нагружает" дисковую систему операциями записи.
Следует помнить, что этот показатель может быть больше 0 не только у тех запросов, которые явно меняют данные, но также и у тех, которые сохраняют промежуточные данные в tempdb.
AggIO - Общее количество логических операций ввода-вывода (суммарно)
Как правило, количество логических чтений на порядки превышает количество операций записи, поэтому этот показатель сам по себе для анализа применим в редких случаях.
AvgIO - Среднее количество логических дисковых операций на одно выполнение запроса.
Значение данного показателя можно анализировать из следующих соображений:
Одна страница данных - это 8192 байта. Можно получить среднее количество байт данных, "обрабатываемых" данным запросом. Если этот объем превышает реальное количество данных, которые обрабатывает запрос (суммарный объем данных в используемых в запросе таблицах), это говорит о том, что был выбран заведомо плохой план выполнения и требуется заняться оптимизацией данного запроса.
Я встречал случай, когда один запрос делал количество обращений, эквивалентных объему в 5Тб, при этом общий объем данных в это БД был 300Гб, а объем данных в таблицах, задействованных в запросе не превышал 10Гб.
В общем можно описать одну причину такого поведения сервера - вместо использования индекса сервер предпочитает сканировать таблицу или наоборот.
Если объем логических чтений в разы превосходит общие объем данных, то это вызвано повторным обращениям к одним и тем же страницам данных. Помимо того, что в одном запросе таблица может быть использована несколько раз, к одним и тем же страницам сервер обращается например в случаях, когда используется индекс и по результатам поиска по нему, найденные некоторые строки данных лежат на одной и той же странице. Конечно, в таком случае предпочтительным могло бы быть сканирование таблицы - в этом случае сервер обращался бы к каждой странице данных только один раз. Однако этому часто мешают... попытки оптимизации запросов, когда разработчик явно указывает, какой индекс или тип соединения должен быть использован.
Обратный случай - вместо использования индекса было выбрано сканирование таблицы. Как правило, это связано с тем, что статистика устарела и требуется её обновление. Однако и в этом случае причиной неудачно выбранного плана вполне могут оказаться подсказки оптимизатору запросов.
query_text - Текст самого запроса
database_name - Имя базы данных, в находится объект, содержащий запрос. NULL для системных процедур
object_name - Имя объекта (процедуры или функции), содержащего запрос.
*/
with s as (
	select  creation_time,
			last_execution_time,
			execution_count,
			total_worker_time/1000 as CPU,
			convert(money, (total_worker_time))/(execution_count*1000)as [AvgCPUTime],
			qs.total_elapsed_time/1000 as TotDuration,
			convert(money, (qs.total_elapsed_time))/(execution_count*1000)as [AvgDur],
			total_logical_reads as [Reads],
			total_logical_writes as [Writes],
			total_logical_reads+total_logical_writes as [AggIO],
			convert(money, (total_logical_reads+total_logical_writes)/(execution_count + 0.0))as [AvgIO],
			[sql_handle],
			plan_handle,
			statement_start_offset,
			statement_end_offset
	from sys.dm_exec_query_stats as qs with(readuncommitted)
	where convert(money, (qs.total_elapsed_time))/(execution_count*1000)>=100 --выполнялся запрос не менее 100 мс
)
select
	s.creation_time,
	s.last_execution_time,
	s.execution_count,
	s.CPU,
	s.[AvgCPUTime],
	s.TotDuration,
	s.[AvgDur],
	s.[Reads],
	s.[Writes],
	s.[AggIO],
	s.[AvgIO],
	--st.text as query_text,
	case 
		when sql_handle IS NULL then ' '
		else(substring(st.text,(s.statement_start_offset+2)/2,(
			case
				when s.statement_end_offset =-1 then len(convert(nvarchar(MAX),st.text))*2      
				else s.statement_end_offset    
			end - s.statement_start_offset)/2  ))
	end as query_text,
	db_name(st.dbid) as database_name,
	object_schema_name(st.objectid, st.dbid)+'.'+object_name(st.objectid, st.dbid) as [object_name],
	sp.[query_plan],
	s.[sql_handle],
	s.plan_handle
from s
cross apply sys.dm_exec_sql_text(s.[sql_handle]) as st
cross apply sys.dm_exec_query_plan(s.[plan_handle]) as sp

Результат

Источники:

Просьба

И тут, вдруг...

Как то прям даже неловко

Послесловие

Древности

Зачем нужны кастомные свойства и как они работают?

В языках программирования есть переменные: вы что-нибудь один раз объявляете, присваиваете значение, а потом снова и снова используете. Если значение переменной меняется, то оно меняется везде. Похоже на местоимения в языке: из предложения или абзаца всегда понятно, кто «мы» или что за «оно», мы их как будто объявили раньше и наверняка переопределим потом.

Но это языки программирования, а что со стилями? Вообще, декларативная природа CSS не подразумевает никаких переменных и соавтор CSS Берт Бос очень против, почитайте. Но жизнь внесла свои коррективы в изначальную идею, и переменные в стилях появились — слишком уж удобно было. Но сначала в препроцессорах.

Как работают препроцессоры? Вы пишете на каком-то языке, который внешне напоминает CSS, а иногда вообще не напоминает.

@mixin sass
  @if &
    &:hover
      color: tomato
  @else
    a
      color: plum

Потом это компилируется в настоящие стили. Переменные там — это такая сложная автозамена переменных на их значения. Sass, Less, Stylus, PostCSS-плагины — все они работают только так. Эти переменные существуют только в разработке, в браузере их уже нет.

.scss {
  $variable: value;
  color: $variable;
}

Если сравнить такое поведение с JavaScript, то становится очень обидно за CSS. В JS переменные живут прямо в браузере, их можно создавать и менять на лету. Тем не менее такие переменные и другие элементы программирования в CSS-препроцессорах получили огромную популярность. Уже почти не бывает больших проектов без препроцессоров.

К счаcтью нашлись люди, недовольные такими куцыми переменными. После ряда черновиков и вариаций синтаксиса, Таб Аткинс написал спецификацию полноценных CSS-переменных, точнее, кастомных свойств. Эти переменные поддерживаются уже в 70% браузеров по миру и сильно меняют принцип написания стилей.

Кастомные кто? Объясняю. Помните, я говорил, что CSS не очень-то готов к переменным? Чтобы сохранить синтаксическую совместимость со старыми браузерами и не противоречить модели языка, было решено сделать не просто переменные с долларом в начале, а механизм создания собственных свойств для нужд разработчика. Ещё их переводят как «пользовательские» свойства, но с этим возникает путаница: кто здесь пользователь, а кто здесь разработчик? Сразу скажу, синтаксис у них немножко странный, но вы поймёте почему.

Например, у нас сейчас есть свойство box-shadow, чтобы отбрасывать тень. А раньше его не было, оно появилось первым в браузере Safari в 2008 году. Но появилось не просто так, а как -webkit-box-shadow, с префиксом, начинающимся с дефиса. То есть разработчики движка WebKit придумали своё свойство. Только потом, когда оно стало частью стандарта и появилось в других браузерах, префикс убрали.

.shady {
  -webkit-box-shadow: 0 0 0 4px tomato;
  box-shadow: 0 0 0 4px tomato;
}

Теперь вы тоже можете создавать собственные свойства, только не нужно указывать между дефисами название движка: дефис, дефис, название свойства. Давайте создадим свойство --box-shadow-color и зададим ему значение tomato. Чтобы использовать это значение в коде, нужно передать его в функцию var().

.shady {
  --box-shadow-color: tomato;
  box-shadow: 0 0 0 5px var(--box-shadow-color);
}

Мы сейчас объявили новое свойство, которое потом можно повторно использовать снова и снова. А ещё свойства box-shadow-color никогда не было в природе и чтобы менять тени, например, по наведению, приходилось переписывать box-shadow целиком. А теперь по ховеру можно просто поменять значение переменной. Круто?

.shady {
  --box-shadow-color: tomato;
}
.shady:hover {
  --box-shadow-color: plum;
}

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

.shady {
  font-size: var(--font-size, 12px);
}

Из-за того, что это кастомные свойства, а не просто доллары с автозаменой, они ведут себя как обычные свойства: наследуются вглубь для всех детей элемента и не видны между элементами-соседями. Чтобы переменную точно было видно во всём документе, её нужно задать самому корневому элементу , но лучше даже :root, на случай если это корневой элемент .

:root {
  --font-size: 12px;
  --theme-color: tomato;
}

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

@media (min-width: 320px) {
  .shady {
    --font-size: 48px;
  }
}

Кастомные свойства можно использовать даже внутри функции calc(), которая посчитает результат выражения внутри. Уже не очень похоже на привычный CSS, правда? Стоит ли говорить, что все препроцессоры уже умерли от зависти, глядя на такое.

.shady {
  font-size: calc(var(--font-size) * 2);
}

Ещё кастомные свойства становятся идеальным транспортом для данных между скриптами и стилями. Например, вы можете динамически считать координаты мыши в JS и пробрасывать их в кастомные свойства через setProperty в нужный элемент.

element.style.setProperty('--pointer-left', event.clientX);

Дальше в стилях уже можно решить: использовать их в top и left или transform: translate(). И наоборот: значение свойства можно получить в JS с помощью getPropertyValue.

И это я только кастомные свойства лапкой потрогал, дальше ещё куча интересного, что кардинально меняет работу со стилями. Читайте и смотрите дальше сами: статьи, видео и слайды.

Кастомные свойства — это не border-radius, который либо делает красиво, либо нет. Бросаться всё переделывать на них пока рано, вёрстка может сильно поломаться в браузерах, которые их не поддерживают. Но уже пришло время пробовать и уметь.

Видеоверсия

Вопросы можно задавать здесь.

Жизнь изнутри

От теории к практике

Рассмотрение паттерна на примере №1: Сложение двух чисел с выводом результата

• 1. Разработать модель программы.
• 2. Нарисовать интерфейс программы.
• 3. Соединить интерфейс и модель прослойкой VM.

 static class MathFuncs {
    public static int GetSumOf(int a, int b) => a + b;
  }

Реализация Примера №1 в WPF

public class MainVM : INotifyPropertyChange
{
  public event PropertyChangedEventHandler PropertyChanged;
  protected virtual void OnPropertyChanged(string propertyName) {
      PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
  }
}

private int _number1;
public int Number1 { get {return _number1;}
  set { _number1 = value;
    OnPropertyChanged("Number3"); // уведомление View о том, что изменилась сумма
  }
}

private int _number2;
public int Number2 { get {return _number2;}
  set { _number1 = value; OnPropertyChanged("Number3"); } }

//свойство только для чтения, оно считывается View каждый раз, когда обновляется Number1 или Number2
public int Number3 { get; } => MathFuncs.GetSumOf(Number1, Number2);

public class MyMathModel : BindableBase
{
  private readonly ObservableCollection _myValues = new ObservableCollection();
  public readonly ReadOnlyObservableCollection MyPublicValues;
  public MyMathModel() {
    MyPublicValues = new ReadOnlyObservableCollection(_myValues);
  }
  //добавление в коллекцию числа и уведомление об изменении суммы
  public void AddValue(int value) {
    _myValues.Add(value);
    RaisePropertyChanged("Sum");
  }
  //проверка на валидность, удаление из коллекции и уведомление об изменении суммы
  public void RemoveValue(int index) {
      //проверка на валидность удаления из коллекции - обязанность модели
    if (index >= 0 && index < _myValues.Count) _myValues.RemoveAt(index);
    RaisePropertyChanged("Sum");
  }
  public int Sum => MyPublicValues.Sum(); //сумма
}

public class MainVM : BindableBase
{
  readonly MyMathModel _model = new MyMathModel();
  public MainVM()
  {
    //таким нехитрым способом мы пробрасываем изменившиеся свойства модели во View
    _model.PropertyChanged += (s, e) => { RaisePropertyChanged(e.PropertyName); };
    AddCommand = new DelegateCommand(str => {
      //проверка на валидность ввода - обязанность VM
      int ival;
      if (int.TryParse(str, out ival)) _model.AddValue(ival);
    });
    RemoveCommand = new DelegateCommand(i => {
        if(i.HasValue) _model.RemoveValue(i.Value);
    });
  }
  public DelegateCommand AddCommand { get; }
  public DelegateCommand RemoveCommand { get; }
  public int Sum => _model.Sum;
  public ReadOnlyObservableCollection MyValues => _model.MyPublicValues;
}

• CMS «1С-Битрикс» (функциональность и интерфейс);
• «Битриксоид» (техническая поддержка);
• «Сервионика» (облачный хостинг);
• научно-технический центр «Атлас» (защита от ботов и DDoS-атак);
• ITSumma (подготовка ИТ-инфраструктуры и серверов);
• Stepik (платформа для онлайн-диктанта).

Подготовка сайта к нагрузке

1. Все А-записи сайта были переключены на IP антиддоса.
2. Настройки почтового сервера были изменены таким образом, чтобы в заголовках исходящих писем нигде не фигурировали реальные IP проекта.
3. На стороне антиддос были настроены фильтрация всех поступающих на сайт запросов и их последующее проксирование на сервера проекта.

1. Настроили репликацию БД и синхронизацию файлов проекта со старого сервера на новый.
2. В момент переключения включили проксирование всех запросов со старого сервера на новый с помощью nginx.
3. Отключили репликацию БД.

Нагрузка в день акции

Общий итог

• Блочный доступ, операционная система сервера работает с СХД как с SCSI жестким диском (упрощенно).
• Файловый доступ, операционная система сервера работает с СХД как с файловым хранилищем по протоколу NFS, SMB и тд.

Для оценки производительности СХД используют три основные метрики:

1. Service Time, часто именуемый latency или responce time, измеряется в миллисекундах и обозначает:
   
   • при чтении: время с момента получения СХД задания на чтение блока информации до отправки запрошенной информации.
   • при записи: время с момента получения записываемого блока информации до подтверждения о его успешной записи.
2. IO/s — количество операций ввода вывода в секунду.
3. MB/s — количество переданных мегабайт в секунду.
   

Повышенный Service Time.

Планка по MB/s

Конкурирующие значения по MB/s или IO/s.

Понижение IO при возрастании ST.

Утилизация CPU

• С использованием ASIC, в таких СХД передача данных внутри массива обрабатывается отдельным высокопроизводительным чипом, а CPU остаются сервисные задачи, такие как создание и удаление дисков и снапшотов, сбор статистики и тд.
• Без использования ASIC, в таких СХД все задачи выполняет CPU.

Медленный рост IO на чтение.

Какой характер нагрузки не свидетельствует о проблемах?

Как определить трешхолды для Service Time, IO/s и MB/s?

Вместо заключения.

Анонсы VMware на конференции

VMware Workstation 14

• поддержка актуальных версий гостевых ОС: Windows 10 Creator Update, Ubuntu 17.04, Fedora 26;
• поддержка Secure Boot для гостевых ОС;
• поддержка Virtualization Based Security (VBS) в Windows 10;
• поддержка виртуальных NVMe-накопителей для ВМ;
• расширенные сетевые настройки, позволяющие ограничивать полосу пропускания, эмулировать задержки и потери пакетов при передаче данных по сети;
• возможность развертывания VMware vCenter Server Appliance (VCSA) в виртуальной машине Workstation;
• расширенные возможности по управлению хостами ESXi.
• Также были анонсированы VMware Fusion 10 и Fusion 10 Pro — клиентские гипервизоры для MAC OS X.

End-of-life VMware vCenter Server для Windows

VMware Integrated OpenStack 4.0

• поддержка развертывания контейнеров;
• интеграция с порталом самообслуживания VMware vRealize Automation, позволяющая управлять инсталляцией OpenStack прямо из интерфейса vRA, а также создавать шаблоны (blueprints) vRA, содержащие объекты OpenStack;
• возможность добавить под управление VIO несколько серверов vCenter Server для наращивания вычислительных ресурсов облака;
• дополнительные возможности, например, увеличение процессоров или добавления памяти без выключения ВМ, функции Firewall as a Service и многое другое.

VMware AppDefense

• заблокировать или ограничить сетевую активность подозрительного процесса при помощи VMware NSX,
• выключить или приостановить ВМ,
• создать снапшот для дальнейшего изучения, а также уведомить администратора безопасности.

VMware vRealize Network Insight 3.5

vSphere Integrated Containers

• поддержка аутентификации и авторизации пользователей, включая интеграцию SSO с сервером VMware Platform Service Controller;
• интеграция интерфейса управления VIC Registry и портала управления;
• возможность изменять параметры (количество процессоров, объем ОЗУ) виртуальных хостов, на которых запускаются контейнеры (Virtual Container Host) без пересоздания;
• полноценная поддержка Docker Engine, поддержка команд commit, diff, stats, cp в CLI.

vRealize LifeCycle Manager

Выставка Solutions Exchange

Стенд NVIDIA

Стенд-грузовик AMD

Стенд Pure Storage

Стенд Infinidat

Стенд Veeam

1. Поддержка функции Veeam Continuous Data Protection, использующая технологию vSphere API for I/O filtering, которая позволяет выполнять практически синхронную репликацию данных виртуальных машин на резервный физический сервер или в хранилище. Практически все современные средства репликации данных для виртуальных сред используют асинхронный метод передачи данных и механизм создания снапшотов VMware. У этого подхода есть ряд недостатков. Во-первых, высокие показатели RPO, которые достигают 5 и более минут, что может быть неприемлемо для высококритичных ВМ. Во-вторых, использование снапшотов VMware приводит к снижению производительности ВМ. С помощью CDP можно в реальном времени транслировать все операции записи на специальный CDP прокси-сервер, который будет их аккумулировать и кэшировать, а затем передавать на целевой сервер. Такой подход позволит восстановить ВМ на любой интервал времени — от нескольких секунд до пары часов сбоя. Для обеспечения консистентности данных внутри ВМ могут использоваться VSS снапшоты.
   
   
   
   
2. Полная поддержка агентов Veeam Backup Agent. Сервер VBR позволяет централизованно устанавливать агенты на рабочие станции и серверы, настраивать политику резервного копирования и восстанавливать данные. Поддерживаются динамические группы на основе объектов Active Directory, позволяющие выполнять установку агентов и резервное копирование компьютеров, которые находятся в определенном организационном подразделении или входят в определенную группу.
3. Возможность резервного копирования сетевых папок. Функция, которую давно ждали пользователи, поскольку во многих инфраструктурах для хранения файлов используются выделенные NAS-устройства. VBR может хранить историю всех измененных файлов, а также удаленные файлы за определенный промежуток времени.
4. Архивные хранилища. VBR может автоматически перемещать или копировать старые резервные копии в архивные хранилища для экономии дискового пространства или обеспечения дополнительной сохранности копий. Администраторы могут настраивать разные параметры архивирования – например, перемещать бэкапы старше X дней, или перемещать бэкапы только в случае, когда основное хранилище будет заполнено более чем на X процентов, перемещать только еженедельные копии и так далее. В качестве архивных хранилищ могут выступать объектные хранилища Swift, Amazon S3, Amazon Glacier или Microsoft Azure Blob.
5. Расширение ролевой модели. VBR может просматривать права, которые были назначены пользователям в vSphere, и отображать только те ВМ для резервного копирования и восстановления, на которые у пользователей есть права.
6. Поддержка RMAN плагина для консистентного резервного копирования БД Oracle.
7. Выход VBR 10 ожидается зимой этого года.

Стенд Nutanix

• Near-Sync Replication — новый механизм репликации данных между системами, расположенными на разных площадках, с использованием легких снапшотов (LWS — lightweight snapshots), который позволит уменьшить интервал асинхронной репликации отдельных ВМ и гарантировать RPO вплоть до 1 минуты.
• Встроенное программное шифрование данных без необходимости использования Self-encrypted drives.
• Поддержка режима проброса графических адаптеров vGPU для собственного гипервизора AHV.
• Поддержка гипервизора Microsoft Hyper-V 2016.
• Tech preview-версия встроенного распределенного межсетевого экрана, позволяющего фильтровать трафик между ВМ (микросегментация).
• И многое другое.

Стенд QNAP

• два контроллера на базе процессоров Intel Xeon E5-2400 v2, работающие в режиме active-active или active-passive.
• до 64 Гб ОЗУ на контроллер и до 16 Гб кэш-памяти на запись с батареей для защиты от пропадания питания.
• 16 отсеков для установки 12G SAS-накопителей с возможностью расширения путем подключения дополнительных корзин по интерфейсам HD-SAS.
• 4 порта SFP+ 10G Ethernet и 2 порта RJ-45 1G Ethernet на каждый контроллер + PCI-E слоты расширения для установки дополнительных адаптеров ввода-вывода.
• два блока питания с поддержкой горячей замены.

Стенд Atrust

Стенд компании Nakivo

• Возможность резервного копирования и восстановления ВМ, размещенных на платформах виртуализации VMware vSphere, Microsoft Hyper-V и облаке Amazon AWS.
• Поддержка LAN-Free бекапов ВМ (режимы Hot-Add и Direct SAN Backup).
• Консистентный бекап и гранулярное восстановление данных внутри ВМ: файлов, почтовых ящиков Microsoft Exchange, БД Microsoft SQL и объектов Active Directory.
• Функция Instant recover, позволяющая запустить ВМ прямо из бекапа, подключив его в виде логического устройства к серверу виртуализации по протоколу iSCSI. Запущенную таким образом ВМ можно восстановить за секунды и затем перенести в постоянное хранилище, используя функцию Storage vMotion.
• СРК управляется через простой и интуитивно понятный HTML5 веб-интерфейс.
• Поддержка асинхронной репликации ВМ на серверы на другой площадке для сценариев Disaster Recovery.

Что еще было интересного

Заключение