shared memory что такое

STL, allocator, его разделяемая память и её особенности

Так и автор однажды задался мыслью, а что если … если произойдёт вырождение адресов сегментов разделяемой памяти в разных процессах. Вообще-то именно это происходит, когда процесс с разделяемой памятью делает fork, а как насчет разных процессов? Кроме того, не во всех системах есть fork.

Казалось бы, совпали адреса и что с того? Как минимум, можно пользоваться абсолютными указателями и это избавляет от кучи головной боли. Станет возможно работать со строками и контейнерами С++, сконструированными из разделяемой памяти.

Отличный, кстати, пример. Не то, чтобы автор сильно любил STL, но это возможность продемонстрировать компактный и всем понятный тест на работоспособность предлагаемой методики. Методики, позволяющей (как видится) существенно упростить и ускорить межпроцессное взаимодействие. Вот работает ли она и чем придётся заплатить, будем разбираться далее.

Введение

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

А с распространением 64-разрядных операционных систем и повсеместным использованием когерентного кэша, идея разделяемой памяти получила второе дыхание. Теперь это не просто циклический буфер — реализация “трубы” своими руками, а настоящий “трансфункционер континуума” — крайне загадочный и мощный прибор, причем, лишь его загадочность равна его мощи.

Рассмотрим несколько примеров использования.

Фиг.1 структура разделяемой памяти PostgreSQL (отсюда)

Из общих соображений, а какой бы мы хотели видеть идеальную разделяемую память? На это легко ответить — желаем, чтобы объекты в ней можно было использовать, как если бы это были объекты, разделяемые между потоками одного процесса. Да, нужна синхронизация (а она в любом случае нужна), но в остальном — просто берёшь и используешь! Пожалуй, … это можно устроить.

Для проверки концепции требуется минимально-осмысленная задача:

Аллокатор STL

Допустим, для работы с разделяемой памятью существуют функции xalloc/xfree как аналоги malloc/free. В этом случае аллокатор выглядит так:

Этого достаточно, чтобы подсадить на него std::map & std::string

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

Разделяемая память

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

Windows

segment size 0 означает, что будет использован размер, с которым создано отображение с учетом сдвига.

Самое важно здесь — hint. Если он не задан (NULL), система подберет адрес на своё усмотрение. Но если значение ненулевое, будет сделана попытка создать сегмент нужного размера с нужным адресом. Именно определяя его значение одинаковым в разных процессах мы и добиваемся вырождения адресов разделяемой памяти. В 32-разрядном режиме найти большой незанятый непрерывный кусок адресного пространства непросто, в 64-разрядном же такой проблемы нет, всегда можно подобрать что-нибудь подходящее.

Linux

Здесь принципиально всё то же самое.

Здесь также важен hint.

Ограничения на подсказку

Что касается подсказки (hint), каковы ограничения на её значение? Вообще-то, есть разные виды ограничений.

Во-первых, архитектурные/аппаратные. Здесь следует сказать несколько слов о том, как виртуальный адрес превращается в физический. При промахе в кэше TLB, приходится обращаться в древовидную структуру под названием “таблица страниц” (page table). Например, в IA-32 это выглядит так:

Фиг.2 случай 4K страниц, взято здесь

Входом в дерево является содержимое регистра CR3, индексы в страницах разных уровней — фрагменты виртуального адреса. В данном случае 32 разряда превращаются в 32 разряда, всё честно.

В AMD64 картина выглядит немного по-другому.

Фиг.3 AMD64, 4K страницы, взято отсюда

В CR3 теперь 40 значимых разрядов вместо 20 ранее, в дереве 4 уровня страниц, физический адрес ограничен 52 разрядами при том, что виртуальный адрес ограничен 48 разрядами.

И лишь в(начиная с) микроархитектуре Ice Lake(Intel) дозволено использовать 57 разрядов виртуального адреса (и по-прежнему 52 физического) при работе с 5-уровневой таблицей страниц.

До сих пор мы говорили лишь об Intel/AMD. Просто для разнообразия, в архитектуре Aarch64 таблица страниц может быть 3 или 4 уровневой, разрешая использование 39 или 48 разрядов в виртуальном адресе соответственно (1).

Во вторых, программные ограничения. Microsoft, в частности, налагает (44 разряда до 8.1/Server12, 48 начиная с) таковые на разные варианты ОС исходя из, в том числе, маркетинговых соображений.

Между прочим, 48 разрядов, это 65 тысяч раз по 4Гб, пожалуй, на таких просторах всегда найдётся уголок, куда можно приткнуться со своим hint-ом.

Аллокатор разделяемой памяти

Во первых. Аллокатор должен жить на выделенной разделяемой памяти, размещая все свои внутренние данные там же.

Во вторых. Мы говорим о средстве межпроцессного общения, любые оптимизации, связанные с использованием TLS неуместны.

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

В четвертых. Обращения к ОС за дополнительной памятью недопустимы. Так, dlmalloc, например, выделяет фрагменты относительно большого размера непосредственно через mmap. Да, его можно отучить, завысив порог, но тем не менее.

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

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

Описание деталей реализации оставим до лучших времён, сейчас интересен публичный интерфейс:

Деструктор тривиальный т.к. никаких посторонних ресурсов BuddyAllocator не захватывает.

Последние приготовления

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

Похоже, можно начинать.

Эксперимент

Сам тест очень прост:

Curid — это номер процесса/потока, процесс, создавший разделяемую память имеет нулевой curid, но для теста это неважно.
Qmap, LOCK/UNLOCK для разных тестов разные.

Проведем несколько тестов

qmap — glob_header_t::pglob_->q_map_

Результаты (тип теста vs. число процессов\потоков):

Эксперимент проводился на двухпроцессорном (48 ядер) компьютере с Xeon® Gold 5118 2.3GHz, Windows Server 2016.

Итого

Вдогонку

Разделяемую память часто используют для передачи больших потоков данных в качестве своеобразной “трубы”, сделанной своими руками. Это отличная идея даже несмотря на необходимость устраивать дорогостоящую синхронизацию между процессами. То, что она не дешевая, мы видели на тесте PRC_MTX, когда работа даже без конкуренции, внутри одного процесса ухудшила производительность в разы.

Объяснение дороговизны простое, если std::(recursive_)mutex (критическая секция под windows) умеет работать как спинлок, то именованный мутекс — это системный вызов, вход в режим ядра с соответствующими издержками. Кроме того, потеря потоком/процессом контекста исполнения это всегда очень дорого.

Но раз синхронизация процессов неизбежна, как же нам уменьшить издержки? Ответ давно придуман — буферизация. Синхронизируется не каждый отдельный пакет, а некоторый объем данных — буфер, в который эти данные сериализуются. Если буфер заметно больше размера пакета, то и синхронизироваться приходится заметно реже.

Удобно смешивать две техники — данные в разделяемой памяти, а через межпроцессный канал данных (ex: петля через localhost) отправляют только относительные указатели (от начала разделяемой памяти). Т.к. указатель обычно меньше пакета данных, удаётся сэкономить на синхронизации.

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

Напоследок

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

UPD: исходники BuddyAllocator выложены здесь под BSD лицензией.

Источник

Использование протокола Shared Memory в MS SQL Server 2012 /2008 на примере работы с сервером «1С:Предприятия» 8

В этой статье я расскажу о протоколе «Общая память» (Shared Memory) обмена данными в MS SQL Server 2012 (справедливо и для MS SQL Server 2008 (R2)). Данный протокол может использоваться при подключении к SQL-серверу клиента, установленного на том же компьютере, где и запущена служба SQL Server, и при использовании дает ощутимый прирост производительности за счет использования оперативной памяти для передачи данных, и как следствии, ликвидации накладных расходов при обмене данными между приложениями. В системе «1С:Предприятие» 8 начиная с версии 8.2.17 появилась поддержка протокола Shared Memory. По оценкам специалистов фирмы 1С, прирост производительности при использовании протокола «Общая память» (Shared Memory) должен составить от 10 до 15%. На примере совместной работы MS SQL Server 2012 с сервером 1С:Предприятие 8 и рассмотрим настройку данного протокола.

0. Оглавление

1. Включение протокола «Общая память» (Shared Memory) в MS SQL Server

Хоть протокол «Общая память» (Shared Memory) и включен по умолчанию, все же стоит убедиться что данный протокол работает и имеет наивысший приоритет над другими протоколами подключений к MS SQL Server. Для этого запустим оснастку «Диспетчер конфигурации SQL Server» (SQL Server Configuration Manager). В Microsoft Windows Server 2012 (R2) ее можно найти в списке всех программ.

В Microsoft Windows Server 2008 (R2) в меню «Пуск» (Start) — «Microsoft SQL Server 2012» — «Средства настройки» (Configuration Tools) — «Диспетчер конфигурации SQL Server» (SQL Server Configuration Manager)

В запустившейся оснастке раскроем вкладку «Сетевая конфигурация SQL Server» (SQL Server Network Configuration), затем выделим вкладку «Протоколы для » (Protocols for …) (экземпляр по умолчанию называется MSSQLSERVER). В таблице справа увидим используемые для данного экземпляра протоколы. Убедимся, что протокол «Общая память» (Shared Memory) имеет состояние «Включено» (Enabled). В противном случае необходимо кликнуть по данной строке правой кнопкой мыши и в контекстном меню выбрать «Включить» (Enable), после чего перезапустить экземпляр SQL Server.

Далее убедимся что на закладках «Клиентские протоколы» (Client Protocols) настроек клиента «Native Client SQL версии 11.0 (32-разрядная версия)» (SQL Native Client 11.0 Configuration (32bit)) и «Native Client SQL версии 11.0» (SQL Native Client 11.0 Configuration) также включен протокол «Общая память» (Shared Memory), и он имеет порядок — «1», т. е. наивысший приоритет над другими протоколами. Если это не так, необходимо изменить настройки до данного состояния.

2. Настройки строки подключения баз данных в системе «1С:Предприятия»

Как уже говорилось ранее, сервер «1С:Предприятия» должен быть запущен на том же самом компьютере, где и запущенна служба MS SQL Server. Кроме того, формат строки подключения информационных баз к SQL серверу должен быть задан в виде \ или для экземпляра по умолчанию. Для того, чтобы проверить или изменить это значение необходимо запустить оснастку «Администрирование серверов 1С:Предприятия» (предварительно должна быть установлена). Далее в запустившейся оснастке раскрываем вкладки — «Кластеры» — «Локальный кластер» — «Информационные базы» и вызываем свойства информационной базы выбрав соответствующий пункт контекстного меню.

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

Затем запустим клиент «1С:Предприятие» для данной информационной базы, для инициализации соединения с указанным экземпляром SQL сервера.

3. Просмотр текущих подключений в MS SQL Server

Теперь просмотрим все активные подключения к MS SQL Server, а также протоколы используемые в каждом из подключений. Для этого запустим программу SQL Server Profiler. В Microsoft Windows Server 2012 (R2) ее можно найти в списке всех программ.

В Microsoft Windows Server 2008 (R2) в меню «Пуск» (Start) — «Microsoft SQL Server 2012» — «Средства обеспечения производительности» () — «SQL Server Profiler».

В запустившейся программе выберем в меню «Файл» (File) — «Создать трассировку…» (New Trace…).

В окне соединения с сервером введем имя текущего экземпляра SQL Server, данные для авторизации и нажмем «Соединить» (Connect).

Запуститься окно настройки свойств новой трассировки. Не меняя параметров, перейдем на вкладку «Выбор событий» (Events Selection), снимем отметку со всех событий кроме «ExistingConnection» и нажмем «Запустить» (Run).

Затем в активном окне трассировки увидим все подключения к данному экземпляру SQL Server. Среди них и соединение с именем 1CV83 Server, что соответствует подключению сервера «1С:Предприятия». В столбце TextData увидим используемый для подключения протокол. В данном случае надпись LPC (Local Prpcedure Call) означает использование протокола Shared Memory, что нам и в общем то и требуется.

Посмотреть активные соединения можно также выполнив запрос:

Для этого подключимся к текущему экземпляру SQL Server с помощью программы «SQL Server Management Studio». Далее, в окне программы кликнем правой кнопкой мыши в обозревателе объектов по строке с именем сервера и в контекстном меню выберем «Создать запрос» (New Query).

Вставляем текст запроса в появившейся справа окно и нажимаем кнопку «Выполнить» (Execute) на панели задач. После чего в окне «Результаты» (Results), расположенном ниже, увидим результат выполнения запроса, а именно все текущие соединения с данным экземпляром SQL Server. Среди них и соединение с именем 1CV83 Server и используемым протоколом Shared memory.

4. Соединение с помощью протокола «Именованные каналы» (Name pipe)

Для чистоты эксперимента попробуем подключиться к SQL Server с помощью какого-нибудь другого протокола, например с помощью протокола «Именованные каналы» (Name pipe). Для этого, соответственно, включим поддержку протокола именованных каналов для данного экземпляра SQL Server. Создадим псевдоним экземпляра, например, с именем TEST1. В настройках соединения информационной базы «1С:Предприятия» с сервером баз данных укажем имя только что созданного псевдонима и запустим клиент «1С:Предприятия» для данной информационной базы.

Запускаем заново трассировку и видим, что теперь приложение с именем 1CV83 Server использует протокол Name Pipes.

То же самое увидим выполнив запрос из предыдущего пункта.

Смотрите также:

Может случиться так, что в процессе установки MS SQL Server 2012 были установлены компоненты, необходимость в которых со временем отпала (или были установлены по ошибке). В этом случае, в целях…

В данной статье будут рассмотрены способы лицензирования Microsoft SQL Server 2012. Будет приведен краткий обзор каждого из способов лицензирования, а также указаны возможные варианты лицензирования для различных выпусков MS SQL Server…

Microsoft SQL Server 2012 / 2008 включает в себя 9 предопределенных серверных ролей. Данные роли определены на уровне сервера и поэтому существуют вне баз данных. Они предусмотрены для удобства администрирования MS…

Источник

Как ускорить 1С за 5 минут – Протокол Shared Memory

Что Вы узнаете из этой статьи?

• Рассмотрены возможности ускорения «1С:Предприятие 8» в небольших организациях
• Показана процедура включения протокола Общая память (Shared Memory)
• Продемонстрирована диагностика использования Shared Memory

Настройка ускорения делается очень просто и займет всего лишь несколько минут.

Что такое Shared Memory, для чего он нужен, и зачем его включать?

В режиме работы, задаваемом по умолчанию, Microsost SQL Server и сервер приложений «1С:Предприятия» работают друг с другом только через TCP/IP.

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

Но все меняется, когда серверы находятся на одной вычислительной системе: лучше и быстрее использовать оперативную память для обмена данными, используя протокол Shared Memory (общая память). Этот протокол позволяет добиться увеличения скорости обмена данными между серверами за счет отсутствия передачи данных по сети, причем прирост производительности может составлять от 10 до 15%. Особенно заметно ускорение на операциях с частыми вызовами сервера.

Включение Shared Memory

Запускаем Диспетчер конфигурации SQL Server.

Производим следующую настройку SQL Native Client – Клиентские протоколы – Общая память – Включено = Да, нажимаем Ok.

Перезапускаем службу SQL сервера

При этом отключение протокола TCP/IP необязательно.

Как проверить что 1С использует Shared Memory?

Существует два способа: 1. С помощью запроса в Management Studio Запускаем на исполнение запрос:

В результате получаем:

Во второй колонке видим результат «Shared Memory», то есть нужный нам протокол работает. 2. С помощью SQL Profiler

При трассировке увидим следующее:

В нижней части окна должна отображаться надпись: «network protocol: LPC», расшифровывается как «Local Procedure Call».

Это говорит о том, что протокол Shared Memory включен и используется.

Некоторые источники отмечают, что данный протокол не начинал работать, пока в качестве сервера СУБД не прописали localhost для информационной базы «1С:Предприятия».

Бурмистров Андрей

Другие полезные статьи и видео смотрите на нашем сайте: http://

Источник

Как ускорить 1С за 5 минут – Протокол Shared Memory

Другие статьи по оптимизации 1С:

Как ускорить 1С за 5 минут – Протокол Shared Memory

В версии 8.2.17 платформы «1С: Предприятие 8» появилась интересная возможность ускорить 1С в том случае, когда сервер приложений и сервер СУБД находятся на одном компьютере.

Настройка ускорения делается очень просто и займет всего лишь несколько минут.

Что такое Shared Memory, для чего он нужен, и зачем его включать?

В режиме работы, задаваемом по умолчанию, Microsost SQL Server и сервер приложений «1С:Предприятия» работают друг с другом только через TCP/IP. Это выглядит правильным и логичным в случае работы серверов на разных компьютерах, иной возможности нет.

Но все меняется, когда серверы находятся на одной вычислительной системе: лучше и быстрее использовать оперативную память для обмена данными, используя протокол Shared Memory (общая память).

Этот протокол позволяет добиться увеличения скорости обмена данными между серверами за счет отсутствия передачи данных по сети, причем прирост производительности может составлять от 10 до 15%. Особенно заметно ускорение на операциях с частыми вызовами сервера.

Включение Shared Memory

Запускаем Диспетчер конфигурации SQL Server.

Производим следующую настройку SQL Native Client – Клиентские протоколы – Общая память – Включено = Да, нажимаем Ok. Перезапускаем службу SQL сервера

При этом отключение протокола TCP/IP необязательно.

Как проверить что 1С использует Shared Memory?

Существует два способа:

1. С помощью запроса в Management Studio

Запускаем на исполнение запрос:

В результате получаем:

Во второй колонке видим результат «Shared Memory», то есть нужный нам протокол работает.

2. С помощью SQL Profiler

При трассировке увидим следующее:

В нижней части окна должна отображаться надпись: «network protocol: LPC», расшифровывается как «Local Procedure Call». Это говорит о том, что протокол Shared Memory включен и используется.

Некоторые источники отмечают, что данный протокол не начинал работать, пока в качестве сервера СУБД не прописали localhost для информационной базы «1С:Предприятия».

PDF-версия статьи для участников группы ВКонтакте

Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.

Статья в PDF-формате

Вы можете скачать эту статью в формате PDF по следующей ссылке: Ссылка доступна для зарегистрированных пользователей)

Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)

Содержание курса и форма заказа: https://курсы-по-1с.рф/1c-v8/optimization/

35 учебных часов, подготовка к 1С:Эксперт, правильная настройка серверной части, оптимизация кода, мониторинг загруженности оборудования и прочие взрослые вещи.

Комментарии / обсуждение (13):

Добрый день!
В один момент на сервере почти всё дисковое пространство, как сказали ИТ-специалисты, “съело” именно из-за Shared memory.
Имеет ли под собой основание данное утверждение?
(помогла только перезагрузка)
Спасибо.

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

В свое время встречал на партнерском форуме рекомендацию (к сожалению сейчас доступа туда нет, не могу привести ссылку) если есть проблемы с использованием протокола Shared Memory указывать сервер баз данных (в консоли кластера – параметры информационной базы) как lpc:ИмяСервера (например lpc:db01).
Насчет “localhost” рекомендацию слышу впервые.

Добрый день. У меня запрос выдает следующее:

1CV83 Server TCP
SQLAgent – Generic Refresher Shared memory
1CV83 Server TCP
SQLAgent – Job invocation engine Shared memory
1CV83 Server TCP
1CV83 Server TCP
1CV83 Server TCP

грешу на “Некоторые источники отмечают, что данный протокол не начинал работать, пока в качестве сервера СУБД не прописали localhost для информационной базы «1С:Предприятия».”

Попробуйте перезагрузить службу сервера 1С и СУБД.
Насчет localhost, это прописывается в свойствах базы в консоли кластера.

Сделал все как указано в инструкции. Отключил все кроме shared memory. Перезапустил. В итоге запрос выдает 1CV82 Server Named pipe. Что не так?

Иногда протокол начинает работать только после перезапуска служб сервера 1С и сервера СУБД.

Источник