#.net #multithreading #sql-server-2008 #clr
#.net #многопоточность #sql-server-2008 #среда clr
Вопрос:
У меня есть CLR
процесс, который выполняется под SQL Server2008
. Он создает кэш из данных нескольких таблиц для хранения в статическом классе для последующего использования другими вызовами.
Мой вопрос в том, могу ли я улучшить процесс загрузки этого кэша, создав потоки для загрузки каждого набора данных / таблицы в моем кэше?
В прошлом я избегал этого, поскольку в различных сообщениях предлагалось оставить управление потоками SQL Server
. Однако я действительно мог бы ускорить этот процесс. В настоящее время это последовательный процесс загрузки каждого набора данных. Если бы я мог запускать их одновременно, это было бы очень удобно. Процесс, который я много раз выполнял за пределами CLR
обложки, чтобы получить дополнительный прирост производительности.
Любые идеи, помогающие советы, очень ценятся.
Ответ №1:
Вы можете использовать потоки, но они должны вести себя корректно. В противном случае вы потеряете преимущества их использования.
Как SQL Server и среда CLR работают вместе
В этом разделе обсуждается, как SQL Server объединяет модели потоковой обработки, планирования, синхронизации и управления памятью SQL Server и среды CLR. В частности, в этом разделе рассматривается интеграция в свете целей масштабируемости, надежности и безопасности. SQL Server по сути действует как операционная система для среды CLR, когда она размещена внутри SQL Server. Среда CLR вызывает процедуры низкого уровня, реализованные SQL Server для потоковой обработки, планирования, синхронизации и управления памятью. Это те же примитивы, которые использует остальная часть ядра SQL Server. Этот подход обеспечивает несколько преимуществ масштабируемости, надежности и безопасности.
Масштабируемость: общие потоки, планирование и синхронизация
Среда CLR вызывает API SQL Server для создания потоков, как для выполнения пользовательского кода, так и для собственного внутреннего использования. Для синхронизации между несколькими потоками среда CLR вызывает объекты синхронизации SQL Server. Это позволяет планировщику SQL Server планировать другие задачи, когда поток ожидает объект синхронизации. Например, когда среда CLR инициирует сборку мусора, все ее потоки ожидают завершения сборки мусора. Поскольку потоки среды CLR и ожидающие их объекты синхронизации известны планировщику SQL Server, SQL Server может планировать потоки, выполняющие другие задачи базы данных, не связанные с CLR. Это также позволяет SQL Server обнаруживать взаимоблокировки, связанные с блокировками, выполняемыми объектами синхронизации среды CLR, и использовать традиционные методы устранения взаимоблокировки.
Управляемый код выполняется с упреждением в SQL Server. Планировщик SQL Server имеет возможность обнаруживать и останавливать потоки, которые не давали результатов в течение значительного периода времени. Возможность подключения потоков CLR к потокам SQL Server подразумевает, что планировщик SQL Server может определять «неуправляемые» потоки в среде CLR и управлять их приоритетом. Такие неуправляемые потоки приостанавливаются и помещаются обратно в очередь. Потокам, которые неоднократно идентифицируются как неуправляемые потоки, не разрешается запускаться в течение определенного периода времени, чтобы могли выполняться другие исполняющие рабочие.
Ответ №2:
Статические данные, совместно используемые при вызовах — не лучший план для вызовов CLR: документация SQL Server
Ограничения модели программирования
Модель программирования для управляемого кода в SQL Server включает в себя написание функций, процедур и типов, которые обычно не требуют использования состояния, сохраняемого при нескольких вызовах, или совместного использования состояния в нескольких пользовательских сеансах. Кроме того, как описано ранее, наличие общего состояния может вызывать критические исключения, которые влияют на масштабируемость и надежность приложения.
Учитывая эти соображения, мы не рекомендуем использовать статические переменные и статические данные-члены классов, используемых в SQL Server. Для БЕЗОПАСНЫХ сборок и сборок EXTERNAL_ACCESS SQL Server проверяет метаданные сборки во время создания сборки и завершает создание таких сборок с ошибкой, если обнаруживает использование статических элементов данных и переменных.