Use windows fibers lightweight pooling что это

Обновлено: 03.07.2024

Современные сетевые инфраструктуры постоянно расширяются, становясь все более универсальными и сложными. Точки доступа Wi-Fi, камеры видеонаблюдения, элементы систем автоматизации и контроля зданий – все больше различных устройств подключаются к сетям. По мере добавления новых устройств, развивается и необходимая для их подключения кабельная инфраструктура, а возможность организации их питания по СКС становится все более привлекательной.

Подача электропитания по кабельной проводке сети Ethernet (PoE) – замечательная технология, которая используется для подключения все более широкого спектра устройств. По различным данным, в общей сложности по всему миру уже более 100 миллионов узлов используют PoE. И эта технология постоянно развивается.

Первый стандарт PoE, IEEE 802.3af, принятый организацией IEEE в 2003 году, ограничивал возможности технологии подачей лишь 15 Вт – на уровне устройства PSE (Power Source Equipment). Поскольку при передаче неизбежны потери, при использовании систем IEEE 802.3af до устройств, на которых подается питание (Powered Device, PD), доходит только лишь 13 Вт.

Не успел институт IEEE принять этот стандарт, как растущий спрос на приложения PoE с большей мощностью привел к началу работ по его обновлению. Новый стандарт IEEE 802.3at (его еще называют PoE+) был ратифицирован в 2009 году. С его принятием оборудование PSE смогло подавать в сеть до 30 Вт. Соответственно, мощность питаемых устройств PD увеличилась до 25,5 Вт. Как и системы PoE IEEE 802.3af, технические решения PoE+ используют для подачи напряжения две из четырех пар стандартного кабеля СКС.

Для дальнейшего увеличения мощности в мае 2013 года комитетом IEEE 802.3 была сформирована специальная группа для изучения вопроса стандартизации технологии PoE, которая бы использовала все четыре пары кабельной проводки. По завершении ее работы в ноябре 2013 года институт IEEE сформировал Рабочую группу IEEE 802.3bt, которой поручено разработать 4-парный стандарт PoE. На 2018 года запланирована ратификация стандарта PoE IEEE 802.3bt, который повышает мощность (на уровне PSE) до 90 Вт.

Наряду со стандартными активно развиваются и нестандартные (проприетарные) варианты PoE. Примером такой технологии служит Cisco Universal PoE (UPoE), расширяющая возможности IEEE 802.3af PoE+ до поддержки 60 Вт на каждый порт.

Технологии дистанционной подачи электропитания PoE имеют массу преимуществ. Это и снижение расходов на инсталляцию (поскольку для подачи электропитания используется та же проводка, что и для передачи информации), и улучшенный контроль за устройствами для более эффективного управления, и использование централизованного ИБП для надежной и отказоустойчивой работы конечных устройств. В целом, совмещение в единой кабельной системе функций подачи электропитания и передачи информации упрощает реализацию универсальной «интеллектуальной» инфраструктуры. Однако у PoE есть один серьезный недостаток: дальность действия ограничена «дальнобойностью» витопарных каналов Ethernet – всего 100 м. А как часто возникают задачи подключить по PoE более удаленные объекты…

Компания CommScope предлагает решить эти задачи с помощью системы Powered Fiber Cable System. Такая система состоит из трех основных элементов:

Устройство подачи электропитания (PSU)
Гибридный кабель
Устройство-удлинитель PoE Extender

Гибридный кабель состоит из оптических волокон (для передачи информации) и медных жил (для подачи электропитания). Он имеет простую модульную конструкцию, удобен в прокладке и разделке, не требует использования специального инструмента. Кабель выпускается как с одномодовым, так и с многомодовым волокном – поддержка того или иного типа волокна определяется выбором SFP-модуля, который устанавливается в PoE Extender.

Гибридный кабель, используемый в системе PFCS

Для крепежа кабеля подходит широко распространенный крепеж для плоских кабелей, используемых в FTTx-инсталляциях. Кабель выпускается в версиях для внешней прокладки (оболочка РЕ) и универсальный (оболочка LSZH).

На дальнем конце такой кабель терминируется специальным устройством-удлинителем PoE Extender, который обеспечивает изменение среды передачи информации (конвертер оптика-медь) и необходимые преобразования электропитания. На вход этого компактного устройства заводится гибридный кабель, а на его выходе – стандартный интерфейс RJ-45 с поддержкой PoE. Через удлинитель конечные устройства, получающие питание по PoE, могут подключаться по обычному витопарному кабелю.

Внешний вид однопортового PoE Extender

Внутренняя начинка PoE Extender

Максимальная дальность работы системы Powered Fiber Cable System при подключении устройств PoE (мощность до 15 Вт) – 3 км. При повышении мощности до 30 Вт (для устройств PoE+) максимальная дальность снижается примерно вдвое. Сам удлинитель PoE Extender может устанавливаться на улице – степень пылевлагозащиты IP67. Помимо преобразования среды передачи информационного сигнала, он обеспечивает управление электропитанием. В него встроено несколько уровней электрической защиты, в том числе от всплесков напряжения (например, при ударе молнии), колебаний электромагнитного поля и напряжения.

Компания CommScope предлагает как однопортовые, а также двухпортовые удлинители. К последним можно подключать, в том числе, два устройства PoE+, потребляющие до 30 Вт каждый.

Двухпортовый PoE Extender

Режимы работы его портов

К новинкам семейства Powered Fiber Cable System следует отнести удлинители, обеспечивающие поддержку мощности до 60 Вт (технология UPoE). (Поддержка 60 Вт возможна и в двухпортовом удлинителе, но тогда второй порт не используется). Такая мощность часто требуется для работы HD-видеокамер с нагревательным элементом и других устройств с повышенным энергопотреблением. Выпускаемые CommScope продукты поддерживают подачу электропитания 60 Вт на расстояние до 650 м. С учетом 100-м тракта между удлинителем и сетевым устройством, максимальная дальность достигает 750 м.

Одним из многочисленных преимуществ использования Powered Fiber Cable System является централизация основных элементов системы электропитания. ИБП и другие элементы электропитания размещаются в хорошо защищенном центральном помещении, что повышает общую надежность и безопасность системы. Размещать же подключаемые устройства можно точно там, где это оптимально с точки зрения решаемых им задач, не привязываясь к розеткам электросети.

Существует масса сценариев применения системы Powered Fiber Cable System.

Например, в классической кампусной сети она может применяться для подключения видеокамер (в том числе на опорах освещения), точек доступа Wi-Fi, микросот для улучшения покрытия сетей сотовой связи и другого оборудования. Универсальный гибридный кабель с оболочкой LSZH можно прокладывать по помещениям, а затем – по внешним трассам (без дополнительных муфт). Источник электропитания, равно как и системы резервного питания (ИБП), располагается в узле связи или в ЦОДе.

Система Powered Fiber Cable System окажется чрезвычайно полезной и для операторов сотовой связи, которые с ее помощью смогут подключать устройства, располагающиеся вблизи базовых станций. Это могут быть те же камеры наблюдения, точки доступа Wi-Fi, микросоты. Источник электропитания удобно расположить в месте размещения самой базовой станции.

Еще один пример – организация системы видеонаблюдения в аэропорту. Помимо видеокамер, система Powered Fiber Cable System может также обеспечить работу внешних точек доступа Wi-Fi, используемых для организации закрытых сетей аэропорта. Использование кабеля для внешней прокладки (оболочка PE) расширяет возможности прокладки, включая использование кабельной канализации и прямую закладку в грунт.

И это лишь некоторые примеры применения системы Powered Fiber Cable System. Увеличивая «дальнобойность» технологии РоЕ до 3 км, она позволяет размещать устройства без привязки к сети электропитания – там, где они требуются.

При этом предполагается "вмешательство" в стандартные структуры и процедуры БД от 1С.

Вот к чему я пришел:

У всех этих методов есть существенный недостаток:
- если вмешиваться в штатные механизмы от 1С: тогда сложно поддерживать восстановление своих "хотелок" после реструктуризации БД - .

Предлагаю собственно иной взгляд и подход: посмотрим на родные средства сервера SQL+Win и попробуем оптимизировать скорость только "там", не изменяя "коробочные" технологии от 1С.

* В БОЛЬШИНСТВЕ СЛУЧАЕВ СТАНДАРТНЫЕ МЕХАНИЗМЫ 1С "ИЗ КОРОБКИ" ОПТИМАЛЬНЫ (в 90%)
* НЕ ОПТИМАЛЬНЫ (как правило) НАШИ ДОПОЛНИТЕЛЬНЫЕ "навески" НА ТИПОВЫЕ РЕШЕНИЯ
- либо потому что мы чего-то не знаем
- либо потому что этот "узкоспециализированный костыль" по другому не работает
В результате мы начинаем оптимизировать "всё" и "вся" , жадно вычитывая решения из интернет.

Я же предлагаю (исходя из соображения стоимости сопровождения) по-иному взглянуть на проблему:
1) свои ошибки (внутри 1С) исправлять (однозначно)
2) бросить затею "оптимизировать 1С" - вместо этого посмотрим на САМ сервер WIN+SQL

В моем случае (на одной площадке, сервере) имеем 8шт 1С7.7 баз + 3 штуки 1С8, одна из которых УПП
Все разного размера и интенсивности.

Как угодить всем?

железо (минимум, для моего объема)

По настройкам SQL+Win:

2) настройки собственно самого SQL (у меня такие - методом проб и экспериментов, для этого железа):

если запрос долше 1сек

заставляем SQL принудительно использовать

все ядра, что имеются

по умолчанию (когда = 0) использует 512

количество блокировок вплоть до этого значения

не будем считать проблемой

у нас сеть 1Гбит, интенсивность работы высокая,

увеличиваем размер пакета чтоб не ходили вхолостую

оставляем стандартно, но

не забываем про количество пакетов
( у меня макс доходит до 5000 batch/sec )

смотрите чтобы не сьели всю память

чекпоинты БД делаем не чаще 1раз/час (для скорости),

хотя это условность (см.MSDN)

3) выносим tempdb - на RAM-диск в 2Гб (я пользуюсь imDisk Toolkit-ом, ни разу не подводил, GPL)

4) для всех баз устанавливаем такие параметры (много раз писалось, приведу еще раз для общей картины):

обсуждалось много раз

или вообще NONE: надежность вряд ли пострадает, скорость выше

* если более 1 (физического) массива дисков - разностим MDF/LDF (иначе не обращаем внимания)

* путь к файлам MDF/LDF - должен быть без длинных путей (т.е. переностим все MDF/LDF файлы в корень диска/ков)

* но не на диске С:\ (естественно)

* помним про autogrow и прочее. (думаем)

5) В СЛУЧАЕ МОНОПОЛЬНОГО ПЕРЕПОВЕДЕНИЯ БАЗЫ (1С77) :
делаем "финт ушами":
- средставим тогоже imDisk создаем RAM диск размером 20Гб (ну или сколько там БД + 10%)
- переносим туда БД (backup/restore в новое место)
- выставляем: autocreate stat / autoupdate stat = ON
- запускаем _1sp_DbReindex + sp_updatestats
- проводим базу
- выставляем: autocreate stat / autoupdate stat = OFF
- опять backup и restore на диск, на старое место.

6) если RAM совсем много: переносим "туда" нашу БД "на всегда" :
при этом:
- каждые 10 минут FULL BACKUP
- при старте SQL - агентом вызываем скрипт для restore
- при стопе SQL - агентом вызываем скрипт для full backup

Все остальные способы (индексы и прочее)

- именно в случае вмешательсва в стандартные структуры и процедуры от 1С-ки
- дают выигрыш в производительности максимум 10-15%
- при этом затрат на обслуживание (времени) уходит просто уйма.

А с учетом того что память и диски сегодня стоят .
Проще наростить мощность сервера и вынести (когда нужно) базу в память.

Я пошел экстенсивным путем.

Всё это - к обсуждению

Специальные предложения

В большинстве случаев (1с77/1с8х) всё рекомендации, методики и алгоритмы сводятся к двум вещам:
- оптимизация индексов и статистики
- управление блокировками

Основная и единственная рекомендация - это грамотные, оптимальные запросы! Оптимизация индексов, это что, добавить новые, реструктуризировать старые? Блокировки - сейчас все на управляемых блокировках, автоматических режим - это редкость. А в целом, все проблемы от самих же программистов, а точнее, их безграмотности. (ИМХО)

(1) DoctorRoza, не все проблемы от программистов. Если сам скуль настроен криво, то никакие хорошие запросы не помогут. Если работает типовое решение, то вероятность его положить плохими запросами есть, но она не так сильно может испортить жизнь, как кривой скуль. Спасибо, очень помогло: exec sp_configure 'max degree of parallelism',64. (заставляем SQL принудительно использовать все ядра, что имеются). Была проблема недозагруженности процессоров. Респект! По моему опыту, для существенного ускорения 1Сv7.7, особенно в случаях массового перепроведения документов, не обязательно на RAM-диск отсылать всю базу. Достаточно туда перепрописать temp-каталоги!

"путь к файлам MDF/LDF - должен быть без длинных путей"

А зачем? Путь используется один раз - при открытии файла. Дальше все обращения через дескриптор. Физическое место записи файла тоже от пути не зависит.

Кстати, не стоит переоценивать мастерство типовых программистов. Я тут пару дней назад хотел даже статью написать, как ускорил УПП на 40%, слегка изменив типовой код, да что-то глюкануло и она не сохранилась, зараза такая. Перевод на "Прямые запросы" очень сильно помогает при больших размерах баз For servers that use more than eight processors, use the following configuration:
MAXDOP=8
For servers that have hyperthreading enabled, the MAXDOP value should not exceed the number of physical processors.
autocreate stat off
autoupdate stat off
page verify torn page detection

Учитывая, что указанные опции строго рекомендуется ВКЛЮЧИТЬ, а PAGE_VERIFY даже после сброса сервером в NONE после апгрейда базы рекомендуют выставить в CHECKSUM, то данные рекомендации похожи на способ поиметь проблем на ровном месте.

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

UPD. А да, для базы sharepoint и biztalk серверов указанные опции по дефолту выключены и включать их не нужно. Сомневаюсь, что характер работы 1С с SQL сервером похож на работу указанных приложений.

(8) Автор, видимо, предполагает ручное обновление статистики, что для больших баз не просто лучший выход, а единственный, так как триггериться автообновление статистики будет реже (меньше процент изменений) и в итоге планы запросов будут строиться по статистике данных давно забытых периодов.

Для больших баз все решается индивидуально. Вот только базы с параметрами "создаем RAM диск размером 20Гб (ну или сколько там БД + 10%)" вряд ли можно отнести к большим базам, хотя бы 100-200Gb надо для начала.

exec sp_configure 'recovery interval (min)',60
чекпоинты БД делаем не чаще 1раз/час (для скорости), хотя это условность (см.MSDN)
То MDSN https://msdn.microsoft.com/ru-ru/library/ms191154.aspx прямо говорит, что "Этот параметр является дополнительным и его следует изменять только опытным администраторам баз данных или сертифицированным техническим специалистам SQL Server."

В комментариях увидел 6 критических замечаний. Постараюсь ответить.

1) Вы утверждаете (ссылаясь на MS)

рекомендуемое значение равно 8, и не должно превышать 16. .

у них же (MS) здесь https://msdn.microsoft.com/en-us/library/ms188611.aspx
сказано, что "Setting the max degree of parallelism option to 0
allows SQL Server to use all available processors upt to a maximum of 64 processors
in a parallel plan execution." иными словами
"дает ВОЗМОЖНОСТЬ использовать все процессоры вплоть до значения 64"
Я же ЗАСТАВЛЯЮ его использовать ВСЕГДА значение 64
(это не значит, что у меня 64 ядра, это значит что реально будет использовать ВСЕ что есть физически)

2) по поводу статистики

В моем случае
* очень высокая интенсивность работы (кол-во запросов доходит до 5000шт/сек)
* tempdb - находится в памяти
* БД (иногда) тоже там же (а значит IOPS в 100 выше чем при работе с дисками)
Поэтому
* статистика - не нужна (оптимизация планов только зря расходует ресурсы CPU на вычисления для планов)

Опять же
* на сервере установлена ECC-память (аппаратный CHECKSUM)
* базы (как правило) в пямяти (опять же экономим ресурсы CPU на вычислениях)

Сомневаюсь, что характер работы 1С с SQL сервером похож на работу указанных приложений

Я не знаю, какой "характер" работы у указанных Вами приложений, я знаю 2 типа работы приложений с БД
* OTLP (очень большая интерсивность маленьких, часто повторяющихся запросов, например FOREX)
* OLAP (объемные запросы на выборку данных, для построения "глобальных" аналитических отчетов)
В моем (конкретном) случая я бы отнес "характер работы"
(при массированном проведении документов) к типу OTLP
где критическим местом является: (1) дисковая подсистема (2) процессор

(11) yukon, Чуть ниже постом, Вы говорите:

Вот только базы с параметрами . <skip>. вряд ли можно отнести к большим базам

Данная статья не рассматривает работу SQL с большими базами данных.
В данной статье идет разговор "о производительности" (т.е. о скорости работы)
в высоконагруженных системах.
В данном случае (как в пословице) : "Размер не имеет значения".
Я считаю (когда показатель "Количество запросов в секунду" доходит иногда до 5000)
- у меня HighLoad System

Что касается . exec sp_configure 'recovery interval (min)',60

Опять же - я делаю не "просто изменить параметр", а ровно 2 вещи:
* recovery interval (min) = 60
= хочу отключить АВТОМАТИЧЕСКИЙ вызов CHECKPOINT "мыслями" сервера SQL
* и выполняю каждые 10 минут FULL BACKUP(который уже имеет CHECKPOINT)
= своей головой (у меня БД в RAM)
Так что здесь - проблем не вижу.

Надеюсь, "осветил" все критические моменты.
Коллеги, задавайте вопросы, с удовольствием отвечу.

Поэтому
* статистика - не нужна (оптимизация планов только зря расходует ресурсы CPU на вычисления для планов)

Знаете, очень напомнило серию Футурамы, как Зойдберг кино снимал: "Самым длительным и дорогим этапом в кинопроизводстве является монтаж и прочий постпродакшн, поэтому мы решили обойтись без него".

Почитайте на MSDN, в каких случаях апдейтится статистика, вычисляются планы и для чего это вообще нужно.

1) предполагается что будут использоваться родные 1С-кие кластерные индексы "из коробки"
и в (собственно) запросах никаких хинтов писать не будем.
Естественно: не забываем про порядок полей в запросах (как в индексах). и т.д.

2) как я уже говорил
* "родные индексы" (как правило) - изначально оптимальны в большинстве случаев
* или Вы хотите еще что-то ускорить ? может insert/update при помощи статистики ? 8))

3) Еще раз:
* физически скорость носителя RAM "без статистики" выше чем HDD "со статистикой"
* конкретно в случае с RAM: нагружать процессор расчетами статистики - считаю абсолютно лишним (+память сьедает)
* индексы никто не отменял (по крайней мере я)
* настаиваю - в структуры и процедуры от 1С (на строне SQL) не нужно "лазить"

4) прочитайте на том же MSDN как влияет статистика на производительность
* как в сторону ускорения - о чем говорят все (в том числе и Вы, и я)
* а также в сторону ухудшения - о чем тоже написано, но никто об этом не говорит (Вот я хочу сказать, но не дают)
Не зря ведь в самом видимом места свойств базы есть флажек "ON/OFF" ?

Не нужно носом тыкать других, читать умеют все (ну или почти).
Да, и простите за мой "футуристический" язык.

Хотелось бы больше услышать "практиков" ( а не умеющих читать теоретиков ).
Коллеги, больше конструктивизма.

конкретно в случае с RAM: нагружать процессор расчетами статистики - считаю абсолютно лишним

дык не вопрос, нагружайте Nested Loops'ами.

Я еще вечером до вас доберусь и пройдусь по вашим "рекомендациям".

сказано, что "Setting the max degree of parallelism option to 0
allows SQL Server to use all available processors upt to a maximum of 64 processors
in a parallel plan execution." иными словами
"дает ВОЗМОЖНОСТЬ использовать все процессоры вплоть до значения 64"
Я же ЗАСТАВЛЯЮ его использовать ВСЕГДА значение 64
(это не значит, что у меня 64 ядра, это значит что реально будет использовать ВСЕ что есть физически)

Тут дело в том, что в 1С стандартно довольно сложные запросы, которые почти не параллелятся, либо делают это очень криво и в итоге теряют в скорости. Я неоднократно слышал о том, что надо принудительно выставлять max degree of parallelism в 1 и именно это ускоряет работу. Поэтому лично мне принудительное выставление maxdop в 64 для 1с кажется нонсенсом, ведь 90% запросов всё равно будут выполнять однопоточно, ещё 9% просто замедлят свою производительность изза кривого распараллеливания и 1% может быть ускорится :) но может у вас на это другие взгляды

Просто я не админ, я программист. У меня конечно стоит sql на своем компе и я частенько играюсь с планами запросов и разбираюсь в них. И в принципе крайне редко я видел многопоточные планы запросов.
Быть может на крупных hightload базах это выглядит иначе)

1с77 - да, криво, однопоточно.
Не зря ведь все (или почти все) "прикрутили" 1С++ и ПрямыеЗапросы к 77,
и получили побольше вольностей в отношении SQL на стороне клиента. Запросы пишем САМИ, не 1С.
При проведении документов: "ВременныеРегистры" считаю оптимизировать бессмысленно: единственное что может ускорить проведение: правильная расстановка измерений (чтобы select отрабатывал быстрее) и отказ на регистрах от лишних галочек (чтобы не тормозил insert/delete/update).
На этом оптимизация проведения документов заканчивается
(ну кроме - как всегда - собственно "бизнес" логики, и запутанных циклов/ветвлений/. )
Дальше: начинаем лезть во внутренности 1С77, кишки ей накручивать, оптимизировать SQL сервер.

1С8х
А разве "язык запросов" в снеговике не "просто парсится" самой 1С-кой в обычный SQL и отдается ODBC?
Или Вы про те запросы, которые отвечают за стандартные 1С-вские диалоги ?
Ну так их много и они очень коротки, там параллелится собственно нечему.

У меня = только те, что больше 1й секунды = exec sp_configure 'cost threshold for parallelism',1
Остальные автоматом будут последовательными.

РЕБЯТА. ОПЯТЬ ВЫ ПРО "ТОЛЩИНУ БАЗЫ" .
Параллелизм не зависит от толщины базы - он зависит от времени выполнения запроса.

А в случае сервера 1С (который типа кластер): разве там не используется параллелизм?
Они явно указывают MAXDOP=1 для всех и всегда .
Не верится что-то . Неужели настолько всё запущено.
уж 2015 год, 2014 SQL, 2012 Win. а 1С всё в ХХ веке?

Я действительно - не знаю, может Вы и правы.
Внутренности 1С8 не исследовал, но тогда. Блин, что же делать.
Нужно переходить на OpenERP ! или SAP .
Шутка.

(0) мы на курсах http://www.gilev.ru/kurs/ рассказываем прежде всего о том, что нет единого универсального рецепта для всех
создаваемое замедление состоит из набора разного количества причин и степени вклада в общее замедление
можно конечно делать "с бубном", но анализ причин на перспективу даст больше пользы

и железо, и настройки среды, и код - все должно быть сбалансировано

для маленьких баз можно больше результата достичь улучшением железа
для больших баз больше кодом.

Конечно же, это не универсальный рецепт на все случаи жизни.
Это ПОДХОД для решения конкретной задачи:

Условия:
* размер БД позволяет "засунуть" ее в RAM
* высокая интенсивность (нагрузка) на SQL - большое количество МЕЛКИХ запросов (у меня иногда до 5000/сек)
* крутится несколько "разношерстных" баз на одном SQL - оптимизировать каждую (средствами 1С) затратно (time=mony)
* в данных условиях узким местом являются: (а) дисковая система (б) процессор

Решение:
1. снять нагрузку на процессор: убираем ВСЁ что заставляет его пересчитывать и оптимизировать
2. отказываемся от тяжеловесных механизмов (таких как CHECKPOINT-ы)
3. помещаем БД в память

Требования:
1. памяти должно быть достаточно
2. память обязательно должна быть ECC .
3. обязательно "шедулим" бекапы БД из памяти на диск (чаще, чем это предполагает делать SQL авто-CHECKPOINT-ом)

Замечание1:
* у меня замечено, что даже при запуске "бухами" всяких там "концемесячных"
регламентов в 1С8 УПП = нагрузка на сервер сохраняется равномерная
* поэтому (конечно же, прежде всего) такой "подход подходит" (каламбурчик) к 1С77 (особенно при перепроведении БД)
* а уж если их (77) несколко запустить на перепроведение одновременно , тогда держитесь.
* да собственно и пользователи (если оставить БД в памяти на всегда) будут ОЧЕНЬ благодарны за скорость 8))

Замечание2:
* конечно же эти "мои" 1с77 давно используют "костыли": такие как 1С++, "ПрямыеЗапросы" и т.д.
* "ПрямыеЗапросы" (однозначно) использовать в 2х случаях: для форм (параметризованные) и для отчетов (select-ы всякие)
* а вот если говорить про модуль проведения: не думаю, что они будут эффективней "временных регистров" от 1С.
(кстати, известный всем, кто в теме 1с++ = ЁПРСТ = тоже так думает = это я о проведении и прямых запросах. )

ЭТА СТАТЬЯ НЕ РЕЦЕПТ - ЭТО ПОДХОД . И ДЛЯ 1С8 = ОН ТОЖЕ РАБОТАЕТ .

А рецепты - действительно - каждый должен варить сам: по своему вкусу. и своей ситуации 8))

SQL Server 2000 является практически самонастраиваемой системой, но вы все же можете изменять способ работу вашей системы, модифицируя значения определенных параметров конфигурирования. В этом разделе вы узнаете, как конфигурировать эти параметры и как они влияют на работу вашей системы. Скорее всего, вам не потребуется изменять эти параметры, но знание их возможностей позволяет вам решать, нужно ли вам их изменение. Вы можете конфигурировать эти параметры с помощью Enterprise Manager или с помощью хранимой процедуры T-SQL sp_configure .

Чтобы использовать Enterprise Manager, щелкните правой кнопкой мыши на имени сервера, который вы хотите конфигурировать, и выберите из контекстного меню пункт Properties (Свойства), чтобы появилось окно SQL Server Properties. Это окно содержит девять вкладок, и каждая вкладка содержит параметры, которые вы можете конфигурировать. Эти вкладки и соответствующие параметры описаны в следующих разделах.

Используя sp_configure для конфигурирования этих параметров, вы должны помнить, что определенные параметры считаются дополнительными (advanced options). (В следующих разделах указывается, какие параметры являются дополнительными.) Для изменения какого-либо дополнительного параметра с помощью sp_configure вы должны задать для параметра show advanced options (показать дополнительные параметры) значение 1 (активизировать). Для этого параметра по умолчанию задано значение 0 (деактивизировать). (Этот параметр не оказывает влияния на дополнительные параметры, если вы используете Enterprise Manager.) Чтобы активизировать параметр show advanced options , используйте следующий оператор:

Обычно для установки любого параметра с помощью sp_configure используется следующий синтаксис:

Параметр affinity mask

Параметр affinity mask (маска "родственности") используется, чтобы указывать, на каких ЦП могут выполняться потоки SQL Server в многопроцессорной среде. Значение 0 (принятое по умолчанию) указывает, что родственность потоков определяется алгоритмами планировщика Windows 2000. Ненулевое значение задает битовую маску, определяющую ЦП, на которых могут выполняться потоки SQL Server. Десятичное значение 1 (или двоичное значение маски 00000001) указывает, что может использоваться только ЦП 1; значение 2 (или 00000010) указывает использование только ЦП 2; 3 (или 00000011) указывает использование ЦП 1 и ЦП 2, и т.д.

Этот параметр относится к группе дополнительных параметров, поэтому для его конфигурирования с помощью sp_configure вы должны задать для параметра show advanced options значение 1. Вы можете также конфигурировать параметр affinity mask с помощью Enterprise Manager. Для этого щелкните на вкладке Processor (Процессор) в окне SQL Server Properties и в секции Processor Control (Управление процессорами) установите флажки перед каждым ЦП (CPU), который хотите использовать для SQL Server. Щелкните на кнопке Apply (Применить) и затем щелкните на кнопке OK, чтобы сохранить данное изменение. Чтобы это изменение начало действовать, вы должны закрыть и перезапустить SQL Server.

В системе, выделенной только для SQL Server, вы должны задать такое значение параметра affinity mask , чтобы использовать для SQL Server все ЦП. В системе, которая не полностью выделена для SQL Server (то есть содержит другие процессы, которым требуется время ЦП) вам, возможно, потребуется задать такую маску, чтобы для SQL Server использовались все ЦП, кроме одного.

Параметр lightweight pooling

Параметр lightweight pooling (упрощенная организация пула) используется чтобы сконфигурировать SQL Server для использования упрощенных потоков (или "волокон" – fibers). Использование "волокон" может снизить количество переключений контекста за счет того, что планирование процессов выполняет SQL Server (а не планировщик Windows NT или Windows 2000). Если ваше приложение выполняется в многопроцессорной системе и вы видите много переключений контекста , то можете попытаться задать для параметра lightweight pooling значение 1, которое активизирует упрощенную организацию пула, и затем снова выполнить мониторинг количества переключений контекста , чтобы убедиться в снижении этого количества. Значение по умолчанию – 0 (запрещение использования "волокон").

Параметр lightweight pooling относится к группе дополнительных параметров, поэтому его можно конфигурировать с помощью sp_configure , если для параметра show advanced options задано значение 1. Вы можете также конфигурировать lightweight pooling с помощью Enterprise Manager. Щелкните на вкладке Processor в окне SQL Server Properties и в секции Processor Control установите флажок Use Windows NT Fibers (Использовать "волокна" Windows NT) для его активизации или сбросьте этот флажок для деактивизации параметра. Щелкните на кнопке Apply, щелкните на кнопке OK и затем закройте и перезапустите SQL Server, чтобы этот параметр начал действовать.

Параметр max server memory

SQL Server динамически выделяет память. Чтобы задать максимальное количество памяти (в мегабайтах), которое SQL Server может выделить для буферного пула, вы можете использовать параметр max server memory (максимальная память для сервера). Поскольку SQL Server требуется определенное время для освобождения памяти, если у вас есть другие приложения, которым периодически нужна память, то для параметра max server memory можно задать такое значение, чтобы SQL Server оставлял определенную часть памяти свободной для других приложений. Значение по умолчанию – 2147483647 – означает, что SQL Server будет забирать у системы максимально возможное количество памяти, динамически освобождая память, когда она требуется другим приложениям, и снова захватывая память, когда эти приложения освобождают ее. Это рекомендованное значение для выделенной системы SQL Server. Если вы хотите изменить это значение, рассчитайте максимальный объем памяти, который вы можете предоставить SQL Server, вычитая из полного объема физической памяти количество памяти, необходимое для Windows 2000, а также для любых приложений, не относящихся к SQL Server.

Этот параметр относится к группе дополнительных параметров, поэтому для его конфигурирования с помощью sp_configure вы должны задать значение 1 для параметра show advanced options . Для задания этого параметра с помощью Enterprise Manager щелкните на вкладке Memory (Память) в окне SQL Server Properties и используйте движок Maximum (MB) (Максимум [Мб]). Затем щелкните опцию Dynamically Configure SQL Server Memory (Динамическое конфигурирование памяти SQL Server). Этот параметр начинает действовать сразу – без необходимости закрытия и повторного запуска SQL Server. (Если щелкнуть опцию Use A Fixed Memory Size [Использовать фиксированный размер памяти], то SQL Server выделит память до указанного объема и затем уже не будет освобождать память.)

Параметр min server memory

Параметр min server memory (минимальная память для сервера) используется для указания минимального количества памяти (в мегабайтах), которое должно выделяться для буферного пула SQL Server. Устанавливать этот параметр полезно в системах, где SQL Server, возможно, резервирует слишком много памяти для других приложений. Например, в среде, где данный сервер используется для служб печати и файловых служб , а также для служб базы данных, SQL Server должен "уступать" слишком много памяти другим приложениям. Это приводит к увеличению времени отклика для пользователей. Значение по умолчанию min server memory равно 0, что позволяет SQL Server динамически забирать и освобождать память. Это рекомендованное значение, но вам может потребоваться его изменение, если ваш сервер не полностью выделен для SQL Server.

Параметр recovery interval

Вы можете использовать параметр recovery interval (интервал восстановления), чтобы определить максимальное количество минут, которое может потратить система для восстановления после аварии. SQL Server использует значение этого параметра и специальный встроенный алгоритм, определяя, насколько часто следует автоматически создавать контрольные точки, чтобы восстановление занимало только указанное количество минут. SQL Server определяет длительность интервала между контрольными точками в соответствии с объемом работы, выполняемой в системе. Если выполняется много работы, то контрольные точки создаются чаще, чем при небольшом объеме работы. Чем меньше объем выполняемой работы, тем меньше времени требуется SQL Server для восстановления после аварии. И чем больше заданный интервал восстановления, тем больше будет интервал между контрольными точками.

Увеличение интервала восстановления повышает производительность системы за счет снижения количества контрольных точек. (При создании контрольной точки выполняется большое число операций записи на диск, что может несколько замедлять выполнение транзакций пользователей.) Но при этом также увеличивается количество времени, которое SQL Server потратит на восстановление. Значение по умолчанию равно 0, указывая на то, что этот интервал будет определять для вас SQL Server и время восстановления будет составлять примерно 1 минуту. Увеличивайте параметр recovery interval на свое усмотрение. Значение от 5 до 15 (минут) находится в обычных пределах, но ваш выбор зависит только от вашего согласия, чтобы пользователи ждали от 5 до 15 минут для восстановления базы данных в случае аварии системы. Обычно значение параметра recovery interval требуется увеличить, чтобы снизить частоту создания контрольных точек, предоставляя пользователям возможность более свободного выполнения операций ввода-вывода для их транзакций без прерывания.

Параметр recovery interval входит в группу дополнительных параметров: для его конфигурирования с помощью sp_configure вы должны задать значение 1 для параметра show advanced options . Вы можете задать этот параметр с помощью Enterprise Manager, щелкнув на вкладке Database Settings (Параметры базы данных) окна SQL Server Properties и задав нужное значение в поле-счетчике Recovery Interval (min). Изменение этого параметра начинает действовать сразу – без необходимости закрытия и повторного запуска SQL Server.

Заключение

В этой лекции вы узнали о некоторых проблемах производительности, с которыми можете столкнуться как DBA. Вы узнали, как использовать System Monitor и Enterprise Manager для мониторинга системы и выявления узких мест, влияющих на производительность. Вы также узнали, как обнаруживать и разрешать наиболее распространенные проблемы производительности системы.

Этот курс провел вас через все "как, что и почему" в администрировании SQL Server 2000. Теперь вы сможете эффективно управлять своей системой и конфигурировать ее, а также легко и эффективно выполнять задачи повседневного администрирования. Авторы надеются, что вы с удовольствием прочитали этот курс.

В отличие от межзапросного параллелизма ([14]), означающего одновременное выполнение разных запросов на нескольких потоках (threads) операционной системы, внутризапросный (intraquery) параллелизм был реализован в SQL Server 7.0 впервые. Внутризапросный параллелизм, как следует из его названия, есть возможность распараллеливания процесса обработки одного запроса по нескольким потокам, что позволяет эффективно использовать многопроцессорные архитектуры при обработке сложных запросов. Использование внутризапросного параллелизма не требует специального разбиения данных при их хранении, а также внесения каких-либо изменений в их структуру или текст запроса. Процессор запросов рассматривает параллелизм наряду с другими этапами стратегии построения оптимального плана. Основными критериями при принятии решения о паралельном выполнении запроса выступают количество активных пользователей, доступная память и предположительный объем данных, обрабатываемых запросом. Очевидно, что параллельное выполнение простого запроса по сравнительно небольшому числу записей невыгодно, так как потребует больше памяти, нежели последовательное. При этом приходится забирать потоки, которые в противном случае могли бы быть использованы для поддержки большего числа пользователей. Общее правило можно сформулировать так: в OLTP-системах, характеризующихся большим количеством пользователей, обстреливающих SQL Server многочисленными короткими транзакциями, он будет отдавать предпочтение последовательным планам, расходуя поточный пул (см. опцию max worker threads) на пользовательские соединения. В OLAP-приложениях, для которых, напротив, характерны массивные долгоиграющие транзакции, а число пользователей относительно невелико, процессор запросов прибегнет к параллельным планам. Например, запрос
select * from sales_fact_1997 union select * from sales_fact_1998 (количество записей в таблице, как мы помним, 86837) выполняется по следующему плану:

Параллельное выполнение запроса достигается введением в план специальных операторов параллелизма, к которым относятся Distribute (произвести разбиение данных на несколько потоков (streams)), Gather (собрать результаты обработки данных c предыдущих шагов на нескольких потоках) и Repartition (перераспределить данные по потокам). Запросы на обновление (UPDATE / INSERT / DELETE) выполняются последовательно, однако подчитка данных в них может производиться в параллельном режиме. Специфика динамических курсоров предполагает строго последовательный план выполнения. В то же время для заполнения статических и keyset-курсоров может использоваться межзапросный параллелизм.

В смешанных приложениях может возникнуть необходимость провести количественную грань между понятиями простого и сложного запроса. Это делается с помощью конфигурационного параметра cost threshold for parallelism, который характеризует пороговую стоимость запроса, начиная с которой оптимизатор начинает рассматривать возможность использования параллельного плана выполнения. Запросы, чья стоимость не превышает пороговой величины, всегда будут выполняться последовательно. Значение этой опции по умолчанию равно 5. Ее также можно модифицировать из меню Server Properties (закладка Processor) в SQL Enterprise Manager.

Ключевым понятием параллельного выполнения является степень параллелизма (Degree of Parallelism, или DOP), иными словами, количество процессоров, которые будут задействованы для одновременной обработки запроса. Отметим, что эффект внутризапросного параллелизма будет проявляться только на машинах, где для работы SQL Server отведено два и более процессоров (см. опцию affinity mask ([1])). Для настройки DOP используется конфигурационный параметр max degree of parallelism, который может принимать значения от 0 до 32: 1 запрещает внутризапросный параллелизм, 0 (по умолчанию) означает, что при построении параллельных планов процессор запросов будет использовать максимально доступное на данный момент число процессоров. Количество потоков, на которых начинается выполнение запроса в параллельном режиме запрос, остается неизменным до момента его окончания. Вместе с тем, необходимо иметь в виду, что оптимальный план может изменяться в зависимости от конфигурации и загрузки SQL Server, так что тот же самый запрос через некоторое время может выполняться с другой DOP, в частности, последовательно. Просмотр DOP осуществляется при помощи соответствующего подкласса события в SQL Profiler.

Наряду с обычными потоками SQL Server 7.0 обладает возможностью использовать волокна (fibers) Windows NT - особый вид легковесных потоков, из которых может состоять thread. Легковесность заключается в особенностях планирования (scheduling). Переключение между потоками требует перехода в режим ядра операционной системы, что само по себе является довольно дорогостоящей операцией, в то время как переключение волокон происходит в контексте приложения. SQL Server использует волокна вместо потоков, если конфигурационный параметр lightweight pooling установлен в 1.

Читайте также: