Как работают управляемые блокировки

Публикация № 1051660

Администрирование - Производительность и оптимизация (HighLoad)

Управляемые блокировки

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

Казалось, о работе сервера 1С и механизма блокировок за годы разработки уже знаешь всё, но 1С не перестаёт удивлять. Механизм управляемых блокировок создан 1С для того, чтобы по сути полноценно заменить механизм транзакционных блокировок на уровне сервера СУБД, отчасти из за политики "1С работает с любыми СУБД". Но на самом деле всё получилось не совсем так - далее проведём "лабораторную работу", и сделаем из неё выводы - в лучших традициях школьной физики :).

Итак начнём - простой кейс:

Конфигурация 2 объекта РС и Документ.

Конфигурация

Регистр сведений независимый, код следующий:

Блок кода 1

	Если Блокировать Тогда		
		Блокировка = Новый БлокировкаДанных();
		Элемент = Блокировка.Добавить("РегистрСведений.РегистрСведений1");
		Элемент.Режим = РежимБлокировкиДанных.Исключительный;
		Блокировка.Заблокировать();
	КонецЕсли;
	
	Если ЧитатьЗапросом Тогда		
		Запрос = Новый  запрос();
		Запрос.Текст = "ВЫБРАТЬ
	            	   |	РегистрСведений1.Рес КАК Рес
	        	       |ИЗ
	    	           |	РегистрСведений.РегистрСведений1 КАК РегистрСведений1";
		ТЗ = Запрос.Выполнить().Выгрузить();
	КонецЕсли;

	Если ЧитатьНабор Тогда		
		Набор = РегистрыСведений.РегистрСведений1.СоздатьНаборЗаписей();
		Набор.Прочитать();
	КонецЕсли;

	Если ЗаписатьНабор Тогда		
		Запись = набор.Добавить();
		Запись.Изм = Строка(Новый УникальныйИдентификатор());
		Запись.Рес = 3;	
		Набор.Записать();
	КонецЕсли;

Всё предельно просто.

Теперь Запускаем два сеанса.

Сеанс 1: Проводим документ с галкой "Блокировать". Ставим точку останова на строке:

"Если ЧитатьЗапросом Тогда".

Сеанс 2: Проводим документ с галкой "Читать запросом". 

Внимание вопрос: "Проведётся ли документ во втором сеансе или нет?"

Нам бы очень хотелось чтобы ответ на данный вопрос был "нет".

Тем не менее, документ проводится - без особых проблем.

 

Повторяем эксперимент - только во втором сеансе ставим галку "чтение набора"

Тот же вопрос "Проведётся?"

Очевидный ответ - "Конечно", ведь по сути что там что там чтение всего регистра.

Тем не менее наблюдаем примерно следующую историю: 

Конфликт блокировок

Таким образом, объектное чтение и чтение запросом работает по-разному. На мой взгляд, это в корне неправильно. При этом объектное чтение, очевидно, учитывает управляемые блокировки, а чтение запросом - ни коим образом.

Спойлер - эти тесты проводим пока в режиме "клиент-сервер".

Из эксперимента выше сделаем несколько первых выводов:

Вывод 1: 1С полностью игнорирует все управляемые блокировки при чтении в транзакции запросом.

Вывод 2: Объектное чтение и чтение запросом работает по разному

 

Тут можно сказать: "здравствуй фантомное чтение, неповторяющееся чтение". От "Грязного чтения" нас убережет MS SQL: в уровне изоляции READ COMMITED SNAPSHOT "грязное чтение" невозможно. Хотя я тоже сомневаюсь, потому как объектная модель 1С не полностью отражается в СУБД возможно могут быть нюансы, но примеров подобрать пока не удаётся.

 

Для того, чтобы понять на каком этапе своего развития в платформе 1С потеряли требование "согласованности данных" обратимся к истории.

Попробуем выполнить следующий код в разных версиях платформы:

 

Блок кода 2

	Запрос = Новый Запрос;
	Запрос.Текст = "ВЫБРАТЬ
	               |	СУММА(РегистрСведений1.Рес) КАК Рес
	               |ИЗ
	               |	РегистрСведений.РегистрСведений1 КАК РегистрСведений1
	               |
	               |ДЛЯ ИЗМЕНЕНИЯ";
	Выборка = запрос.Выполнить().Выбрать();
	Выборка.Следующий();
	Количество = Выборка.Рес;
	
	
	
	Если Количество > 0 Тогда
		
		Запись = РегистрыСведений.РегистрСведений1.СоздатьМенеджерЗаписи();
		Запись.Изм = Строка(Новый УникальныйИдентификатор());
		Запись.Рес  = -1;
		Запись.Записать();
			
	КонецЕсли;

 

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

Этот код выполняется в транзакции - в обработке проведения документа в моём случае. Первую транзакцию нужно конечно остановить и попытаться провести вторую. По условию мы не должны уйти в минус.

 

1С 8.1  и ранее (ну или просто Автоматический режим блокировки)   

второй документ "висит на блокировке". После прохождения точки останова второй документ проводится, запись в РС не создаётся.

Код отрабатывает правильно как в случае остановки "после записи" так и в случае "после чтения".

Секрет конечно в инструкции "для изменения", которая кроме всего прочего превращает S блокировку в U.

На уровне СУБД уровень изоляции MS SQL - SERIALIZABLE. MS SQL блокирует всё что надо и не надо. Чтобы получить несогласованные данные  надо очень постараться.

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

 

1С 8.2 и первые версии 8.3 (режим управляемых блокировок)

Появились "Управляемые блокировки". Самое главное что происходит с MS SQL при установке "управляемой блокировки" - уровень изоляции становится "READ COMMITED". 

Чтобы включить его в последних редакциях 8.3 нужно выполнить:

ALTER DATABASE databasename
SET ALLOW_SNAPSHOT_ISOLATION OFF
GO
ALTER DATABASE databasename
SET READ_COMMITTED_SNAPSHOT OFF
GO

Здесь уже немного похуже. Если точку останова в коде поставить после записи - всё отработает как и в предыдущем примере - транзакция установит X блокировку и всё будет OK. А вот если точку останова поставить после чтения - получим совместимые S блокировки - одна и та же информация будет считана двумя транзакциями.

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

В приведённом примере, тем не менее, в большинстве случаев всё будет работать верно, потому что всё-таки поведение системы в транзакции более-менее прогнозируемо - если данные считаны, то на них устанавливается как минимум S блокировка. 

Конечно нужно добавить в этот код начало вроде:

		Блокировка = Новый БлокировкаДанных();
		Элемент = Блокировка.Добавить("РегистрСведений.РегистрСведений1");
		Элемент.Режим = РежимБлокировкиДанных.Исключительный;
		Блокировка.Заблокировать();

и нам уже ничего не страшно.

Зачем я тогда делаю на этом акцент?

В данном примере вы читаете остатки (по сути) - их конечно нужно блокировать.

Но если у вас в транзакции происходит чтение элемента справочника, который в данный момент может изменять другая транзакция?

Вот тут как раз S блокировка очень сильно пригодилась бы. Но об этом дальше.

 

Современные версии 1С 8.3

Возвращаем обратно режим версионника:

ALTER DATABASE databasename
SET ALLOW_SNAPSHOT_ISOLATION ON
GO
ALTER DATABASE databasename
SET READ_COMMITTED_SNAPSHOT ON
GO

Выполняем код - получаем "-1" как в случае установки "точки останова" при чтении, так и в случае установки "точки останова" при записи.

Теперь можно сделать ещё один вывод:

Вывод 3: чем современнее версия 1С, тем больше возможности для параллельной работы и тем меньше шансов обеспечить согласованность данных.

 

А теперь "Гвоздь программы": файловая база - код приведенный в блоке кода 1 выполняем в ней. Единственное изменение - код чтения данных из регистра придётся перенести в обработку, т.к. в файловой базе два одинаковых документа параллельно провести не получится.

В обработке будет код:

      НачатьТранзакцию();
	  	 	Запрос = Новый  запрос();
			Запрос.Текст = "ВЫБРАТЬ
	            	   |	РегистрСведений1.Рес КАК Рес
	        	       |ИЗ
	    	           |	РегистрСведений.РегистрСведений1 КАК РегистрСведений1";
			ТЗ = Запрос.Выполнить().Выгрузить();
	  ЗафиксироватьТранзакцию();

В документе ставим галку "блокировать" и точку останова, выполняем обработку - уверенно висит на блокировке. 

Убираем галку "блокировать" в документе (но не точку останова) конечно без проблем читает регистр.

Итак, в завершение "чудес" управляемых блокировок получаем их разную работу в файловой и клиент-серверной версии.

Вывод 4: Управляемые блокировки в файловой и клиент-серверной версиях работают по-разному. В файловой - "нормально".

 

Теперь о косяках в типовых. Для примера возьму УТ 11.

Перед записью в набор движения естественно читаются, происходит это в функции "ТекстЗапросаТаблицаТоварыНаСкладах(Запрос, ТекстыЗапроса, Регистры)" - для Товаров на складах. 

Так вот, "косяк" потенциально будет во всех строчках этого запроса где "точка" фигурирует дважды:

"КОГДА ЕСТЬNULL(ТаблицаТовары.Назначение.ДвиженияПоСкладскимРегистрам, ЛОЖЬ)"

"И (НЕ ТаблицаТовары.Склад.ИспользоватьОрдернуюСхемуПриОтгрузке

И ТаблицаТовары.Номенклатура.ТипНоменклатуры В"

Что в этом плохого? 

Ну вот представьте - начали вы проведение документа пока склад ещё был не ордерным, а в процессе проведения кто-то его поменял на ордерный...

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

Кроме того - есть прекрасная возможность в один регистр записать данные исходя из информации что склад ордерный, а в другой - нет, и всё это в одной транзакции. Это и есть так называемое "фантомное чтение", которое, как мы помним, для "READ COMMITED SNAPSHOT" вполне возможно. 

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

"Эти справочники защищены от изменений, не так всё просто" - напрашивается комментарий. На самом деле всё просто. Распределенная база, полный обмен. Задано небольшое число элементов в транзакции. В каждом справочнике есть код:

Процедура ПередЗаписью(Отказ)

	Если ОбменДанными.Загрузка Тогда
		Возврат;
	КонецЕсли;

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

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

К слову, реально это нужно только для проведения - в других случаях необходимость что-то блокировать сомнительна.

Вывод 5: В типовых конфигурациях не учитывается необходимость блокировать записи таблиц с которыми происходит неявное соединение при проведении

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

Почему на это не особенно обращают внимание? Да потому что эти ошибки видны только в случае реальной параллельной работы большого количества пользователей, да и то крайне редки. Если у вас много пользователей в базе 1С, у вас скорее всего наберётся несколько куч проблем более актуальных, чем описанный выше кейс. Ну а у кого всё хорошо и все вопросы решены скорее всего уже правильно расставлены блокировки, и такие крупные компании редко работают на типовых базах. Но вообще знать о таком "поведении" платформы нужно, как и учитывать его в проектах, которые ориентированы на большое количество параллельно работающих пользователей. Ведь пока мы (1С-ники) не научимся корректно работать с системами, в которых 1000+ активных пользователей и обеспечивать в них согласованность данных SAP нам на рынке не подвинуть. 

P.S. Всё описанное выше "не баг а фича", вполне нормально документировано на ИТС, который всё равно никто не читает  на котором вы можете детально ознакомиться с описанием работы управляемых блокировок "от Вендора" https://its.1c.ru/db/v8314doc#bookmark:dev:TI000000535 

P.P.S. Если это прочитают коллеги из 1С - тут нет "камня в огород типовых" или в сторону реализации управляемых блокировок (хотя конечно хм...). Из статьи выше должно по задумке стать очевидным, что прикладным разработчикам очень не хватает возможности выбирать уровень изоляции с которым будет начинаться транзакция (в т.ч. неявная). READ COMMITED для проведения документов списания товара это слишком лайтово. Всех косяков, с этим связанных, не выловить.
 

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

Лучшие комментарии
177. kolya_tlt 08.05.19 15:53 Сейчас в теме
Люто плюсую по выводу №5. Но моя практика показала, что платформа просто не справляется с таким количеством блокировок. Сервер 1С просто ложился каждые два часа. Кейс был абсолютно такой же - движения документа зависели от галок номенклатуры и мы блокировали ссылки номенклатур документа, который проводится. Пришлось от этой идеи отказаться :(
acanta; comol; +2 Ответить
165. alex_sh2008 4 07.05.19 18:35 Сейчас в теме
(164)Уровни изоляции уже есть в скл сервере, в 1С достаточно просто транслировать объектные блокировки на реляционную базу, а то что сейчас сделали мне вообще не понятно.
Остальные комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. w.r. 579 29.04.19 19:50 Сейчас в теме
15. starik-2005 2177 30.04.19 10:44 Сейчас в теме
16. comol 4327 30.04.19 11:28 Сейчас в теме
(1) Правильная и хорошая статья. То о чём я пишу в своей на ИТС конечно не напишут. Вернее инфу можно найти и на ИТС, мелким шрифтом в разных местах, не в базовой статье конечно
37. w.r. 579 30.04.19 20:23 Сейчас в теме
(16)

К слову, про файловые и клиент серверные версии, есть такая табличка с сайта 1С, которая абсолютно все объясняет

39. comol 4327 30.04.19 22:29 Сейчас в теме
(37)
которая абсолютно все объясняет

Как бы мне хотелось чтобы это было так.
Конечно она не объясняет почему управляемые блокировки - пусть даже не всю таблицу в файловой и клиент серверной версии работают по-разному
41. acanta 30.04.19 22:31 Сейчас в теме
(37) эта табличка показывает как правильно называется составляющие технического решения Сама проблема в применении к 1с в том, что специалист по sap (например) при переходе с 1с на что то другое имеет и квалификацию и полномочия и возможность прямого доступа к данным при помощи СУБД не используя ни код ни платформу ни лицензии 1с.
Достаточно описания структуры метаданных.
А 1с ник при такой работе с данными чего то нарушает, а без соответствующего сертификата ещё и не имеет необходимой квалификации.
"либо крестик снимите либо трусы наденьте."
38. w.r. 579 30.04.19 20:26 Сейчас в теме
(16)

И ещё вопрос - зачем для чтения (ЧитатьЗапросом) используете исключительную блокировку, а не разделяемую
40. comol 4327 30.04.19 22:30 Сейчас в теме
(38) Ну для контроля остатков должна быть исключительная... А то ведь кто-то ещё прочитает
45. w.r. 579 30.04.19 23:10 Сейчас в теме
(40)

Это только мое предположение, но мне кажется, что дело здесь в объекте НаборЗаписей. Платформа его интерпретирует как объект, производящий запись данных (даже только при чтении набора) и работает с ним не так, как с объектом Запрос. Я бы обратился с этим вопросом в поддержку фирмы 1С ради интереса
48. comol 4327 30.04.19 23:35 Сейчас в теме
(45) Всё так. И это будет официальная позиция 1С. Но суть в том что чтобы правильно наложить все блокировки при чтении запросом нужно или выполнить его дважды или полноценно разбирать, а это уже сделать из 1С сервер СУБД по сути :)
49. acanta 01.05.19 08:53 Сейчас в теме
(48) Ни менеджер среднего звена ни бухгалтер с екселем и выгрузкой из СУБД тоже в этом комбайне не нуждаются. А для операторов достаточно любой (той же веб надстройки над любой СУБД) для формирования и распечатки первички.
И тогда все те же блокировки возникают на уровне коммуникации между людьми и решаются так же.
Если есть проблемы с коммуникациями, то полноценно заменить их при помощи 1с не получится.
И если за 20 лет существования 1с проблема параллельной работы с контролем остатков не решена до сих пор, значит на нее нет спроса в данном сегменте.
А те сегменты где такая потребность есть уже давно заняты.
50. comol 4327 01.05.19 12:49 Сейчас в теме
(49)
А те сегменты где такая потребность есть уже давно заняты

И будут заняты другими пока проблема не будет решена :)
51. starik-2005 2177 01.05.19 15:06 Сейчас в теме
(49) проблема решается тем, что остатки контролируются после записи движений. И тот документ, при проведении которого зарегистрирован минус, просто отменяет транзакцию. Это сложно понять современным 1С-никам, но, с другой стороны, и не надо - без них разберутся.
jONES1979; Akvals; vano-ekt; chernov.gigansk.ru; zakiap; acanta; +6 Ответить
52. acanta 01.05.19 15:10 Сейчас в теме
(51) зарегистрирован минус на когда?
При одновременном проведении двух документов с одинаковым временем запрос это вообще может определить?
53. starik-2005 2177 01.05.19 15:55 Сейчас в теме
(52) ну у обоих пользователей документ не проведется, что такого? Фактически две транзакции. В первой остаток меняется, во второй меняется, вот первая транзакция записывает регистр, в это время в модуле регистра срабатывает событие "при записи", там читается остаток по отбору из записанного уже набора записей и проверяется, есть ли минус. Если есть - отказ. То же самое во втором документе. Если у обоих внезапно стал минус - ну оба отвалятся и потом кто-то снова проведет документ.

Сам SQL (если говорить о СУБД) не пишет данные одновременно - он одновременно в очередь поместить может. А пишет отдельный поток.

ЗЫ: Вообще в компьютере нет ничего "одновременного" в плане записи на один диск. И для целостности софт делает sync, чтобы быть уверенным в изменениях. А вот при чтении мы можем что-то взять из кеша дважды, но, опять же, кеш обнолвляется при записи, которая не одновременна. Такой вот "парадокс".
54. acanta 01.05.19 16:16 Сейчас в теме
(53)Вы меня простите, не хочу никого обидеть. Но вот есть два спринтера. Они пересекают финиш и срывают ленточку одновременно. Приз достанется кому то одному, что тут такого.
Но журнал регистрации отключен в конфигураторе, а запросы к журналу транзакций превратили бы 1с в СУБД, а если учитывать файловую систему с кэшами и буферами то и в ось..
И вот уже программист 1с заводит регистр сведений и прописывает очередь проведения с учётом приоритета пользователей по своему усмотрению.
Сначала проводить все документы Тани, затем Васи и и только потом МарьИвановны. И все они на процентах.
59. starik-2005 2177 01.05.19 20:53 Сейчас в теме
(54) ну вот пересекают они финишь, но один оказался в очереди раньше - никуда не деться. И второй при записи регистра упирается в Х-блокировку ресурса уже на сервере SQL и будет ждать. Если регистры во всех документах записываются в одной последовательности, то дедлока не будет - будет простая очередь ожидания. Именно для этого в свое время придумали механизм записи регистров при записи документа - там последовательность строго блюдется. А еще в УПП лет сто назад (в 8.1) контроль регистра остатков был сделан в модуле набора записей этого регистра. И ничего не тормозило у товарищей с нормальной техникой, и никогда (ни разу) не было никаких случайных отрицательных остатков. Читайте "библию разработчика 1С" - там это уже лет надцать как описано. А то, что себе придумывают люди - это от незнания.
55. alex_sh2008 4 01.05.19 18:17 Сейчас в теме
(51) С таким подходом производительность вашего приложения упадет в разы на больших нагрузках
46. SanchoD 188 30.04.19 23:22 Сейчас в теме
(40) Сейчас в тренде новый подход к проведению. Сначала проводим документ as is. А потом снимаем остатки на регистрах. Вышли в минус - откатываем транзакцию.
zakiap; w.r.; acanta; +3 Ответить
47. comol 4327 30.04.19 23:34 Сейчас в теме
(46) "Сейчас" это лет 5 или 6 вроде? :)). Но суть дела не меняет - всё равно надо накладывать исключительную блокировку.
56. alex_sh2008 4 01.05.19 18:19 Сейчас в теме
(47)Не только исключительную но и уменьшать количество записей в одной транзакции, лучше сделать несколько последовательных транзакции ,1 строка 1 транзакция , чем 1 транзакцию для записи 100 строк.
57. acanta 01.05.19 18:43 Сейчас в теме
(56) даже в этом случае документ или справочник с табличными частями при изменении или добавлении строки будет записан целиком. Или нет?
58. alex_sh2008 4 01.05.19 19:33 Сейчас в теме
(57) На ваши транзакции наложится еще главная транзакция на весь документ или справочник. Поэтому все эти танцы с бубнами просто пустая затея. Не забывайте есть транзакция 1С и транзакция сервера базы данных, это разные вещи, если вы делаете блокировку в коде 1С это во все не означает что эта блокировка происходит на sql сервере, блокировки на скл сервере включаются только тогда когда действительно происходит запись/чтение данных самой 1С. Чем быстрее будет выполнен код 1С в транзакции тем меньше будет блокировок.

Если хотите добиться максимальной параллельности выполнения транзакций:
1. максимально исключите использование табличных частей у документов и справочников.
2. Используйте минимум транзакций в своем коде, включайте транзакции только тогда когда это действительно необходимо.
3. Не выполняете в транзакции какие либо емкие операции
4. проверяйте остатки и другие параметры не во время записи данных, а во время подготовки данных перед записью, до начала основной транзакции записи данных. Например во время редактирования данных в табличной части документа.
creatermc; Aleskey_K; zakiap; acanta; +4 Ответить
61. acanta 01.05.19 22:54 Сейчас в теме
(58) не понимаю, вы хотите сказать что блокировка сервера 1с накладывается на объект метаданных 1с (например документ или справочник с табличными частями, но без подчинённых справочников или записей регистра сведений)
62. alex_sh2008 4 01.05.19 22:59 Сейчас в теме
(61)Ну да, за исключением документов, все движения тоже по падают в транзакцию и блокируются (в зависимости от режима записи/чтения)
60. comol 4327 01.05.19 22:49 Сейчас в теме
(56)
лучше сделать несколько последовательных транзакции ,1 строка 1 транзакция , чем 1 транзакцию для записи 100 строк

лучше конечно... но согласованность данных при такой истории обеспечить намного сложнее.
63. alex_sh2008 4 01.05.19 23:03 Сейчас в теме
(60)Это вопрос планирования архитектуры приложения и методик разработки. Много конечно из 1С не выжать но что то можно.
2. Evil Beaver 6755 29.04.19 20:23 Сейчас в теме
Читал-читал, а все свелось к тому что "блокируйте все, что надо и не блокируйте то, чего не надо"...

В свое время управляемые блокировки мне коллега объяснил, как мьютекс. Блокировка это мьютекс. Обьектное чтение захватывает его автоматом, а запрос - нет. Вот и все объяснение.

А писать параллельный код правильно - да сложно, и без косяков никак. Тут Олег прав :)
17. comol 4327 30.04.19 11:30 Сейчас в теме
(2) свелось к тому что "блокируйте всё что надо, само не заблокируется за вас" :).
Технически там наверное всё-таки не мьютекс.... надо доп. инфу хранить и между серверами синхронизировать.
в SQL захватывается автоматом, а в 1С этого не стали делать... я думаю просто потому что очень сложно реализовать технологически.
197. Evil Beaver 6755 12.05.19 19:34 Сейчас в теме
(17) "Мьютекс" - это абстрактно, чтобы было проще объяснить принцип: захватил/отпустил. А что там внутри - это один БГ ведает.
3. Rustig 1487 29.04.19 21:38 Сейчас в теме
(0) интересная работа!
то, что система несовершенна - стало очевидным.

а если абстрагироваться от названий "автоматический" и "управляемый", можно ли огласить (описать) алгоритм "на пальцах" - как должна вести себя блокировка записей таблиц при параллельной работе пользователей?
(желательно на примере) есть у кого красивая идея?
18. comol 4327 30.04.19 11:30 Сейчас в теме
4. Rustig 1487 29.04.19 21:43 Сейчас в теме
(0) в 8.1 (на обычных формах) всегда была возможность программировать свою функциональность по блокировкам - то есть в каждом конкретном случае разработчику приходилось прорабатывать механизм и тестировать все варианты "идеальной" параллельной работы самим, не надеясь на встроенный механизм автоматич. блокировок.
как сейчас усложнилась технология на управляемых формах - не знаю. наверное, усложнилась...
5. bulpi 174 29.04.19 23:11 Сейчас в теме
Я знал! Я предполагал! Я чувствовал! Автор молодец, грамотно изложил мои подсознательные подозрения :)
6. par_62 30.04.19 06:46 Сейчас в теме
Нет программ,в которых " и рыбку съесть и ... ( по тексту)". Обычно оценивается вероятность тех или иных событий. Вероятность изменения неордерного склада на ордерный - минимальна в процессе работы и обычно выполняется только специалистом учета или администратором системы. Если это нет - вопрос к организаторам учета на предпииятии и к специалистам внедрения.
vdscom; Alias; +2 Ответить
19. comol 4327 30.04.19 11:32 Сейчас в теме
(6) всё так конечно... просто задача хорошей ИС обеспечить согласованность данных при любой ситуации...
7. Kami4 30.04.19 07:21 Сейчас в теме
Возьму на заметку, всё подробно и с полным анализом!
8. Rustig 1487 30.04.19 07:33 Сейчас в теме
На мой взгляд, проблема блокировок заключается в том, что пока не закончилась транзакция операции, кто-то пытается изменить что-то связанное с данной операцией. Чем длительнее транзакция, тем более вероятно, что будут блокировки.
Отсюда рекомендация - сократить транзакции по времени.
К примеру, при проведении документа запускаются 10 проверок, сведения записываются поочередно в разные 10 регистров накоплений, и все это в одной транзакции. Возможно, стоит попробовать отделить какой-то регистр , и записывать в него в отдельной транзакции - в другом месте и в другое время....
В свое время я доработал отправку счетов по электронке - создал кнопку - так в период массовых рассылок - когда три бухгалтера отправляют в течение часа по 20 писем - стали возникать блокировки... Когда письмо уходит через электронную почту - транзакция по времени становится длительной - ждем ответа от электронки - ушло письмо или нет, чтобы изменить статус письма в 1С...
Тогда я создал регистр сведений "Очередь отправки писем". Блокировки исчезли, поскольку письма вставали в очередь мгновенно, а отправкой занимался робот в фоновом режиме...Делал на платформе 8.1 на БП 1.6 лет 5 назад. До сих пор работают по этой схеме.
В дальнейшем в УТ 11 перешли на расчет себестоимости при проведении реализации в отдельной транзакции - в другом месте и в другое время. Так они сократили время транзакции проведения реализации, и уменьшили вероятность возникновения блокировок.
9. nvv1970 30.04.19 07:54 Сейчас в теме
Олег, может объясните что делает флаг ALLOW_SNAPSHOT_ISOLATION? К чему этот привет из прошлого?
1с его сто лет как не использует для переключения снепшотов. А msdn как-то не до конца понятно это объясняет. Например, здесь достаточно подробно (хотя это и не документация) https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/snapshot-isolation-in-sql-server. Однако, snapshot и rcsi - это два разных уровня изоляции, а речь вроде как об уровне snapshot.
20. comol 4327 30.04.19 11:42 Сейчас в теме
(9) Ну насколько я помню этот флаг включает версионник для базы в MS SQL. Без него read commiten snapshot не включите.
В последних версиях MS SQL он включен по умолчанию при создании новой БД, видимо 1С это детектит.
В статье речи об уровне изоляции snapshot нет - везде конечно read commiten snapshot. Сам уровень изоляции snapshot прокомментировать не могу - не разбирался. 1С его не использует.
24. nvv1970 30.04.19 12:00 Сейчас в теме
(20)
В статье речи об уровне изоляции snapshot нет - везде конечно read commited snapshot. Сам уровень изоляции snapshot прокомментировать не могу - не разбирался. 1С его не использует.
Да, все верно. Snapshot будет тяжеловат для 1С. Не встречал, чтобы его использовали где-то... Поспрашиваю на sql.ru
Ну насколько я помню этот флаг включает версионник для базы в MS SQL. Без него read commiten snapshot не включите.
В последних версиях MS SQL он включен по умолчанию при создании новой БД, видимо 1С это детектит.
А вот тут - НЕТ.
Прикрепил файлик... Нигде, кроме master и msdb данный режим не используется. Это собственно два разных, режима. И на сколько я понимаю по различным описаниям на msdn - никак не пересекающихся. Один флаг отвечает за включение версионирования уровня RCSI, второй Snapshot. Думал, что вы, как человек бывалый, мне про это подробнее ответите )) Очевидно, что платформа первым флагом не оперирует. А рекомендация устанавливать два флага появилась с каких-то бородатых годов и сейчас вероятно не актуальна. SI появился кажется в 2005. И возможно там нужно было оба флага устанавливать.
Прикрепленные файлы:
25. comol 4327 30.04.19 12:06 Сейчас в теме
(24)
А рекомендация устанавливать два флага появилась с каких-то бородатых годов и сейчас вероятно не актуальна


Ну вообще 2017 год MSDN:

The following statements activate snapshot isolation and replace the default READ COMMITTED behavior with SNAPSHOT:

SQL

Копировать
ALT ER DATABASE MyDatabase
SET ALLOW_SNAPSHOT_ISOLATION ON

ALT ER DATABASE MyDatabase
SET READ_COMMITTED_SNAPSHOT ON

Я не разработчик Micrisoft и даже не MVP по MS SQL, поэтому обычно следую документации если это работает.

А ещё я буду долго ржать если второй флаг без первого не работает и 1С по факту не использует версионность :)))))))))))))))
30. nvv1970 30.04.19 13:11 Сейчас в теме
(25) В документации же нет указания "нажимать все кнопки одновременно" )) Скорее трудности перевода.
Это два разных уровня изоляции. С разным поведением для чтения и модификации, с разными сценариями использования, с разной нагрузкой на tempdb. Достаточно погуглить Read committed Snapshot Isolation VS Snapshot Isolation
В общем случае MS не рекомендует использовать SNAPSHOT ISOLATION, а ограничиваться RSCI.

А то что флаг READ_COMMITTED_SNAPSHOT точно работает без ALLOW_SNAPSHOT_ISOLATION проверял лично еще на совместимости 8.2.16 - при равномерной нагрузке продуктовой базы поведение в части блокировок СУБД ну очень явно отличалось.
42. comol 4327 30.04.19 22:33 Сейчас в теме
(30)
А то что флаг READ_COMMITTED_SNAPSHOT точно работает без ALLOW_SNAPSHOT_ISOLATION

Ну верю... Не только у 1С есть косяки в документации

MS не рекомендует использовать SNAPSHOT ISOLATION

ХЗ что это такое. Его никто не использует

Скорее трудности перевода.
у меня всё норм с английским. По-другому перевести фразу "выполните эти инструкции SQL чтобы включить Read commited snapshot вместо Read commited" трудно.
198. Evil Beaver 6755 12.05.19 19:37 Сейчас в теме
(25)
и 1С по факту не использует версионность :)))))))))))))))


Использует. На ИС, по-моему, Андрей Бурмистров, показывал графики с разницей замеров между режимами.
10. frkbvfnjh 582 30.04.19 08:46 Сейчас в теме
Еще больше запутался с этими блокировками, теперь ваще не хочу программировать на 1С. Держать столько нюансов по работе с блокировками в голове, которые к тому же еще и меняю от платформы к платформе - это не нормально и не реально. Пока 1С определится как им нужно работать с блокировками пострадает много народу
acanta; wowik; +2 Ответить
11. Rustig 1487 30.04.19 09:24 Сейчас в теме
(10) волков бояться - в лес не ходить - и на первомайские шашлыки не ездить... :)
13. nvv1970 30.04.19 09:45 Сейчас в теме
(10) стоп-стоп.... никакой путаницы нету )))
Может автор немного сумбурно что-то изложил - так это только потому, что затронуты лишь отдельные специфические моменты, а не представлена вся система целиком.
В 1с нет ничего загадочного и нового, что есть в мире программирования, и все предельно просто.
Практически все лежит не в технической плоскости, а в плоскости логики и математики.
Что касается механизма управляемых блокировок, то он намного проще (на много порядков), чем блокировки СУБД (я вам не скажу за всю Одессу, а за MSSQL - скажу).

"пока создатели автомобилей не определятся куда водителям ехать - пострадает много народу"
Что это за.... ? ))) Как работать с блокировками - должна определиться не 1С, а автор программного кода, т.е. вы сами. По моему статьи про яблоки более чем достаточно. А детали поведения платформы (неявные управляемые блокировки) описаны в документации и немного в статье. Вы их должны знать. А наиболее очевидно и просто выяснить что генерирует блокировки, а что нет - посмотреть по техжурналу.
CSiER; Dach; comol; +3 Ответить
12. Dach 295 30.04.19 09:39 Сейчас в теме
Куда печальней, что нет нормальных инструментов, позволяющих с помощью менеджера 1с-ных блокировок посмотреть - какие блокировки наложены, на какие таблицы, кем и когда, с возможностью адекватного их завершения и т.д. Мониторить все это дело нечем, грубо говоря. И ТЖ тут тоже не особо помощник
babys; herfis; acanta; Rustig; comol; YPermitin; +6 Ответить
14. YPermitin 8568 30.04.19 10:44 Сейчас в теме
(12)
ожностью адекватного их завершения и т.д. Мониторить все это дело нечем, грубо говоря. И ТЖ тут


А чем ТЖ не устроил в этом плане? Он фактически всегда дает ответы на вопросы:
- Кто поставил
- На что
- Сколько длится блокировка
- Причины конфликтов

С помощью ТЖ можно практически в реальном времени мониторить блокировки, если нужно. Такой опыт есть, даже где-то на ИС такое реализовывали. Но зачем? В нагруженных системах этот онлайн-мониторинг столько данных будет показывать, что стане бессмысленным.

Раскройте подробнее посыл, интересно узнать что еще нужно.
21. comol 4327 30.04.19 11:49 Сейчас в теме
(14) И умирает сервер если в ТЖ блокировки включить. А их надо бы как то фоново онлайн собирать - как MS SQL делает.
22. YPermitin 8568 30.04.19 11:55 Сейчас в теме
(21) Смотря как настроить и что искать. :) Возможно конфигурация, когда влияние сбора ТЖ будет минимальным.

Но, согласен. У SQL Server инструменты гораздо лучше в этом плане.
23. comol 4327 30.04.19 11:59 Сейчас в теме
(22)
Смотря как настроить
Запись всех блокировок в текстовый файл... ну это убийство дисковой подсистемы при любом раскладе. ИМХО конечно, но у меня настроить так чтобы работало быстро не получается....
26. nvv1970 30.04.19 12:07 Сейчас в теме
(23) вы о упрблокировках 1с? Неожиданно... Если исключить <property name="Locks"> и хоть какого-то порог длительности установить, то все весьма компактненько...
27. comol 4327 30.04.19 12:08 Сейчас в теме
(26) а если установить порог и длительность смысл их вообще собирать? :)))))
YPermitin; +1 Ответить
28. YPermitin 8568 30.04.19 12:21 Сейчас в теме
(27) обычно сбор ведь идет уже тогда, когда знаешь что ищешь.

Вообще, сбор массовый логов лучше изолировать от прода по максимуму. В этом случае отдельный диск или SSD. Анализ и разбор логов тоже на отдельном сервере.

Да что мы спорим :)
ТЖ это монстр, который надо готовить по необходимости)))

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

Если нужен прямо онлайн мониторинг, то пробовать отдельные диски и сервер для анализа данных с Эластиком!
31. comol 4327 30.04.19 14:18 Сейчас в теме
(28)
сбор ведь идет уже тогда, когда знаешь что ищешь

Сбор обычно идёт когда уже что то случилось и надо понять что...

Онлайн с ТЖ не получится... в Elastic тоже надо сначала выгрузить...
29. Rustig 1487 30.04.19 13:01 Сейчас в теме
(14) есть инструменты как консоль запросов, консоль заданий - открыл и мониторишь - вот такой инструмент нужен.
В сравнении с ТЖ - ТЖ перегруженный неудобный сложный. Консоль заданий - открыл и мониторишь...

Есть задачи и в не нагруженных системах - при которых было бы полезно мониторить блокировки. Да и потом в мониторе блокировок должен быть фильтр по объектам , которые мониторим...
YPermitin; +1 Ответить
36. YPermitin 8568 30.04.19 17:42 Сейчас в теме
(29) (33) Поддерживаю.

Вот был бы аналог Extended Events, то жизнь стала бы проще.

Сейчас удавалось передавать асинхронно данные ТЖ в ElasticSearch с помощью утилиты на .NET Core (C#). Но событий было ограниченное количество, т.к. фильтры были установлены. Сам ТЖ за сутки набирал всего 2 ГБ. Что будет, если собирать все блокировки не могу сказать. Возможно, что передача данных в ES займет значительный объем ресурсов.
85. DonAlPatino 142 06.05.19 13:03 Сейчас в теме
(36) Отдельная статья с рассказом "как готовить ТЖ и ЕЛКу" будет?
86. YPermitin 8568 06.05.19 13:05 Сейчас в теме
(85) а нужно?

В том плане, что об этом вроде и так много сказано. Даже на ИС был материал.
87. DonAlPatino 142 06.05.19 13:05 Сейчас в теме
(86) Пропустил видимо :-( Пошел искать...
88. YPermitin 8568 06.05.19 13:06 Сейчас в теме
(87) не найдете - пишите. Что-нибудь придумаем :)
33. Dach 295 30.04.19 15:39 Сейчас в теме
(14) в том то и дело, что собирать с помощью ТЖ все блокировки 1с-ные - тяжко как для сервера, так и потом для анализа.

А хотелось бы вот что: ставишь в консоли администрирования "Пороговое время = N минут", показать все блокировки, которые висят дольше порога. Фильтр на таблицы метаданных тоже бы неплохо. Нет, может я чего-то не знаю и такое уже кто-то сделал? Просто у менеджера блокировок ведь есть эта информация! Он же как-то дает это понять другим сеансам, другим rphost ну и т.д.! Взаимодействие между процессами и т.д. и т.п. Просто дайте нам тоже посмотреть, вот и все. Хотя бы посмотреть
herfis; Rustig; YPermitin; +3 Ответить
32. PerlAmutor 104 30.04.19 14:55 Сейчас в теме
(0)

Если Блокировать Тогда
Блокировка = Новый БлокировкаДанных();
Элемент = Блокировка.Добавить("РегистрСведений.РегистрСведений1");
Элемент.Режим = РежимБлокировкиДанных.Исключительный;
Блокировка.Заблокировать();
КонецЕсли;

Если ЧитатьЗапросом Тогда
Запрос = Новый запрос();
Запрос.Текст = "ВЫБРАТЬ
| РегистрСведений1.Рес КАК Рес
|ИЗ
| РегистрСведений.РегистрСведений1 КАК РегистрСведений1";
ТЗ = Запрос.Выполнить().Выгрузить();
КонецЕсли;
Показать

Если после установки исключительной блокировки, таки прочитать что-нибудь из этого регистра сведений в той же транзакции. Блокировка на чтение сработает?
43. comol 4327 30.04.19 22:35 Сейчас в теме
(32)
той же транзакции
хоть заблокируйтесь и зачитайтесь :). Блокировка нужна для защиты от других транзакций.
66. PerlAmutor 104 03.05.19 06:09 Сейчас в теме
(43) Я о другом. В примерах, везде где ставится явная блокировка, впоследствии идет чтение данных и блокировка ставится на основании того, какие измерения были считаны. После этого в других транзакциях уже нельзя писать/читать те же измерения, что были заблокированы в первой транзакции. В статье идет установка блокировки, но, видимо, данные не читаются, так как для этого должны стоять две галочки одновременно и "Блокировать" и "ЧитатьЗапросом". Какая именно комбинация галочек установлена из статьи непонятно.
67. comol 4327 03.05.19 13:54 Сейчас в теме
(66) ничего не понял про галочки. В примере данные лочатся а потом читаются. Блокируется весь регистр потому что лень было делать более полноценный пример
68. PerlAmutor 104 03.05.19 15:23 Сейчас в теме
(67) Я сделал тестовую обработку, чтобы воспроизвести эффект, когда блокировка на чтение не ставится при явном задании исключительного варианта. Пробовал на 3 версиях платформы: 8.2, 8.3.7, 8.3.13. На трех конфигурациях ERP, ЗУП 2.5, БП2.0. Поведение везде одинаковое - регистр блокируется от чтения. Возможно дело именно в том, что если перед чтением данных не ставить никаких блокировок, то платформа даст это сделать, так как не будет выполняться попытка сравнения совместимости установленных блокировок (Исключительная+Никакая = Дает читать, Исключительная+Исключительная = Не дает читать) ?
Прикрепленные файлы:
ТестБлокировки.epf
69. comol 4327 03.05.19 18:42 Сейчас в теме
70. PerlAmutor 104 03.05.19 19:25 Сейчас в теме
(69) Все 3 базы клиент-серверные, на продакшене.

В общем я проверил. Заблокировал "Справочник.Пользователи", если открывать его в другой сессии или использовать консоль запросов, то данные из него прекрасно читаются. Но если запустить эту же обработку и попробовать установить Блокировку, то через 20 секунд выдает ошибку
"Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки"

Т.е. через управляемую блокировку можно обезопасить от чтения - идентичные объекты в разных сессиях с одним и тем же кодом, где идет попытка установки несовместимой блокировки. От запросов без использования объекта БлокировкаДанных - это не спасает.
71. PerlAmutor 104 03.05.19 19:59 Сейчас в теме
(70) Но вот что интересно. От ЗАПИСИ блокировка спасает. Установив исключительную блокировку в обработке на "Справочник.Пользователи" и попытавшись снять галочку "Показывать в списке" с последующей записью - я получаю все тот же конфликт блокировок.
Таким образом получается, что исключительная управляемая блокировка защищает от чтения только, если перед чтением идет попытка установки блокировки. Если нет, тогда она срабатывает уже при записи (видимо уже на уровне СУБД).
73. PerlAmutor 104 04.05.19 05:45 Сейчас в теме
(71) Правда, если блокировка будет снята после удачного чтения, но до попытки записи или в течении тех 20 секунд ожидания блокировки, то могут записаться некорректные данные. Таким образом в критичных местах надо обязательно использовать объект БлокировкаДанных явным образом, чтобы уберечь свой код от возможного чтения заблокированных данных.
76. comol 4327 06.05.19 00:04 Сейчас в теме
(70)
через управляемую блокировку можно обезопасить от чтения
можно конечно. Другой вопрос что это надо делать своими руками
75. comol 4327 06.05.19 00:03 Сейчас в теме
(68) Посмотрел. Ну ещё один пример аналогичный приведённому. Не ставим блокировки = не защищаемся. Собственно у вас они только в начале.
34. Dach 295 30.04.19 16:39 Сейчас в теме
И кстати, автор. По поводу блока кода №1. Замените набор регистра сведений набором регистра накопления - и Вы удивитесь)))

Спойлер:

Объектное чтение набора РС в транзакции накладывает неявную разделяемую управляемую блокировку.
Объектное чтение набора РН в транзакции НЕ накладывает неявную разделяемую управляемую блокировку.

Такое ощущение, что наборы записей РС и РН разные люди программировали в 1С.

Вывод 1: 1С полностью игнорирует все управляемые блокировки при чтении в транзакции запросом.

Ну и как бы логично, что игнорирует. Внутри транзакции запросом можно прочитать только "чистые" (закоммиченные) данные и их чистоту Вам СУБД гарантирует, а не сервер приложения. На самом деле, хотите обеспечить дополнительную "чистоту" и неизменность тех данных, которые читаете - ставьте перед чтением сами блокировку и именно на ней и отвалится выполнение кода по таймауту (если уже есть блокировка).
Именно, кстати, на чтении РС у Вас и отваливается выполнение по таймауту, так как см. выше - неявная разделяемая управляемая блокировка.

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

И с вот этим Вывод 5: В типовых конфигурациях не учитывается необходимость блокировать записи таблиц с которыми происходит неявное соединение при проведении

не могу согласиться.

Зачем блокировать то, что я в результате выполнения алгоритма менять не собираюсь? Как раз таки это избыточно будет. Собираюсь менять остатки - вот их и блокирую. Ну а то, что товар на момент чтения был товаром, а потом стал услугой - ну извините, сами себе злые буратины. Это уже уровень защиты в прикладной логике должен отвечать, при записи вида/свойства номенклатуры. А то так можно эту цепочку продлить еще и еще, у вида/свойства номенклатуры тоже свои реквизиты есть, у тех тоже свои и т.д. и т.п. Что же нам - все разименования блокировать? Не надо так )))
alexsey777; CSiER; comol; +3 Ответить
35. comol 4327 30.04.19 16:56 Сейчас в теме
(34)
хотите обеспечить дополнительную "чистоту" и неизменность тех данных, которые читаете - ставьте перед чтением

В этом весь смысл данной статьи :)))) Дело в том что в типовых 1С их не ставит... при проведении документа "с контролем" очевидно должна быть "дополнительная чистота"
44. comol 4327 30.04.19 22:38 Сейчас в теме
(34)
Что же нам - все разименования блокировать
именно так а никак иначе. Представьте что у вас меняется не "товар на услугу" а "вагон нефти" на "вагон хлора" в распределенной системе :)

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

А вцелом коммент очень дельный
sergathome; +1 Ответить
64. CheBurator 3422 01.05.19 23:08 Сейчас в теме
65. acanta 02.05.19 00:31 Сейчас в теме
Спасибо. Пробелы постепенно заполняются.
72. acanta 03.05.19 20:58 Сейчас в теме
Вы хотите сказать, что если на всю таблицу справочника пользователи наложить исключительную блокировку, то при обновлении ранее открытого списка мы получим пустой список или неполный?
А как же политика оптимистических блокировок?
74. PerlAmutor 104 04.05.19 20:11 Сейчас в теме
(72) Оптимистические и пессимистические блокировки относятся к объектным блокировкам, в основном касаются интерактивного варианта работы. Управляемые (транзакционные) блокировки не будут накладывать эти варианты блокировок на записи при использовании (это два разных механизма, которые друг о друге ничего не знают). Как я понимаю, с версии 8.3 в режиме Управляемых блокировок СУБД MSSQL использует уровень изоляции RCSI (Read Commited Snapshot Isolation), что позволяет повысить параллельность работы (concurency) за счет того, что в момент блокировки записи на чтение - копия (версия) данных (текущей транзакции) помещается в TempDb, а остальные транзакции читают основную версию. В моем случае, установка блокировки справочника Пользователи на чтение приводит к тому, что все остальные транзакции по факту читают старую (существующую) версию справочника, до завершения моей транзакции. Если другие транзакции попробуют явно установить блокировку через БлокировкаДанных или неявно, когда сама СУБД начнет её устанавливать, через попытку записи справочника - тогда блокировка встанет в очередь.Если мы хотим избежать рассогласованности данных в собственной транзакции и считаем, что изменение данных другими транзакциями критично для нашей бизнес-логики, то необходимо установить блокировку в явном виде, чтобы механизм Управляемых блокировок 1С и СУБД среагировал. В противном случае считается, что считанная ("старая" версия) данных имеет право на существование, так как заранее неизвестно завершится транзакция удачей или нет. И все кто не наложил блокировку в явном виде - сам отвечает за последствия. Это не является ошибкой, так как решение принимается исходя из логики прикладного решения, и в основном играет положительную роль, увеличивая параллельность работы системы. Проблема может возникнуть, если мы ничего не блокируем, считываем "старую" версию и на основании этой информации пишем в совершенно другое место (в этом случаем блокировок надо накладывать, как минимум, две)

Поправьте меня если я не прав.
sergathome; +1 Ответить
77. comol 4327 06.05.19 00:09 Сейчас в теме
(74) Во всём прав (вроде как) кроме того что к форме списка справочника это никак не относится ибо там нетранзакционное чтение данных, которому абсолютно покласть на все блокировки и уровни изоляции :)
78. Quantum81 06.05.19 10:46 Сейчас в теме
Авто!!! Напугал!
Ты должен исключение получить, когда будешь блокировать второй раз регистр. Т.е. проводи эксперимент при всегда включенной галке блокировать. Вот если ты смог заблокировать данные, то и читай их, зная что никто их не поправит в этот момент, т.к. ты наложил блокировку.
81. comol 4327 06.05.19 11:23 Сейчас в теме
(78) Галка "блокировать" это неявная установка управляемой блокировки просто.
82. Quantum81 06.05.19 11:49 Сейчас в теме
(81) Вы, наверно, меня не поняли. У вас же документ проводится. Если установлена галочка блокировать, то вы накладываете ЯВНУЮ управляемую блокировку на регистр. Так вот чтобы не получать неконсистентных данных - это надо делать ВСЕГДА (блокировать). Если вы блокировку не наложили перед чтением - то оно будет ГРЯЗНОЕ. Что здесь удивительного? :)
79. herfis 365 06.05.19 11:06 Сейчас в теме
Удивлен, что автор для многих открыл америку. Значит, статья в самом деле полезная.
ИМХО, если понимать, как работают блокировки СУБД и знать что управляемые блокировки не имеют никакого отношения к уровню СУБД, то вывод что управляемые блокировки никак не влияют на чтение запросами - очевиден.
Аналогичные реализации управляемых блокировок я еще на 7.7 припоминаю (с помощью внешних библиотек).
Астиг; sergathome; +2 Ответить
80. comol 4327 06.05.19 11:21 Сейчас в теме
(79)
вывод что управляемые блокировки никак не влияют на чтение запросами - очевиден

а можете пояснить почему для вас этот вывод очевиден?
Просто опыт говорит что в 1С работают одни разгильдяи и вот уж этого они точно не сделают? :)
83. herfis 365 06.05.19 11:59 Сейчас в теме
(80) Потому, что по тексту запроса невозможно в общем случае определить, пересечется ли получение результата запроса с управляемой блокировкой.
Ну вот смотрите. Наложил я блокировку по конкретному ТМЦ. А выбираю данные по всем ТМЦ из регистра за период. Анализом текста запроса невозможно определить - попадется ли там заблокированный ТМЦ. Анализом результата запроса это определить также невозможно - блокируемые данные могут использоваться как промежуточные и не входить в конечный результат. Приходим к тому, что контролировать это возможно только на уровне СУБД.
Но управляемые блокировки - это грубо говоря просто системный справочник. Полностью отдельно стоящая параллельная система. И ничего другого тут особо не придумаешь. Я бы реализовывал точно также. И как я уже говорил, подобные реализации были и для 7.7. Если не путаю, автор ToySQL что-то подобное продавал.
sergathome; +1 Ответить
89. comol 4327 06.05.19 13:11 Сейчас в теме
(83)
по тексту запроса невозможно в общем случае определить, пересечется ли получение результата запроса с управляемой блокировкой.
тем не менее СУБД это как то делает. Если очень хочется можно сначала прочитать а потом заблокировать. А можно тупо уровень изоляции поднять.
Я бы реализовывал точно также.
. Печально. Не смог донести видимо :(. Я бы такую херь делать не стал. И тому кто сделал по рукам бы надовал. Я бы дал возможность разработчику поднимать уровень изоляции. Или принудительно бы поднимал при проведении.
91. herfis 365 06.05.19 16:02 Сейчас в теме
(89) СУБД это делает с помощью блокировок СУБД. Уровень изоляции - это те же самые блокировки (плюс переключатель блокировочник/версионник в mssql).
С блокировками на уровне СУБД и поднятием уровня изоляций в 1С уже наигрались в автоматическом режиме блокировок. При проведении как раз и поднималось до Serializable. Но оказалось, что это не самый лучший вариант - слишком из пушки по воробьям. Целостность-то обеспечивается, но параллельность далеко не такая, как хотелось бы. Хотелось бы более тонкое управление блокировками, но его можно обеспечить только на прикладном уровне. Разбор полетов как раз и привел к появлению управляемых блокировок, которые можно применять "хирургически", а не "по площадям". Печально, что вы этого не понимаете. Здесь в принципе нет "более лучшей альтернативы".
ЗЫ. Хотя :) Если бы у 1С была своя СУБД, тогда 1С теоретически могла бы прямо транслировать управляемые блокировки в блокировки этой СУБД. Вот тогда бы могло получиться как вы хотите. Со сторонними СУБД на текущий момент это невозможно.
92. acanta 06.05.19 16:11 Сейчас в теме
(91) я понимаю в общих чертах что конфигурация на файловой СУБД и на sql с управляемыми блокировками долга быть не только написана с дополнительными командами заблокировать освободить, и даже не только с запросами (используя временные таблицы или нет) но и иметь другую архитектуру.
И несмотря на возможность открыть ее в конфигураторе, разработать конфигурацию для такого режима работы в файловой базе не получится и протестировать тоже.
94. spacecraft 06.05.19 16:23 Сейчас в теме
(92) да в общем-то нет. На то и универсальный объект Управляемые блокировки. Его стратегия определяет общие правила для разных СУБД. В том числе и для встроенного. Конечно есть особенности использования под разные СУБД, но они исключение из правила.
Это как запрос и СКД. В СКД тоже используется запрос, но он скорее руководство к действию, а не пошаговое выполнение.
Так и с управляемыми блокировками. Это объект (класс), который сам определяет, что и как заблокировать в самом sql.
95. comol 4327 06.05.19 16:26 Сейчас в теме
(92) (94) В общем то да. Я бы сказал "хорошая" конфигурация на 1С должна разрабатываться или под использование в файловой версии или под использование с конкретной СУБД.
Типовые конфигурации я не отношу к "хорошим" - я их отношу к "типовым".
93. comol 4327 06.05.19 16:22 Сейчас в теме
(91)
Уровень изоляции - это те же самые блокировки (плюс переключатель блокировочник/версионник в mssql)

"Садись два". Тут конечно нужно прочитать несколько матчасти. Уровень изоляции это намного более широкое понятие, и в общем случае не имеющее отношения к блокировочник/версионник.

Ещё раз постараюсь объяснить - надеюсь получится:

1) В СУБД реализованы НОРМАЛЬНЫЕ - ХОРОШИЕ блокировки. Которые вцелом всех устраивают.
2) Потому как в разных случаях разные требования к согласованности данных в СУБД придумали уровни изоляции. От Read Uncommited - когда нам "всё равно", до "Serializable" когда "не дай бог что сломается"
3) Блокировки в СУБД это целая нехилая система, с совместимостью, эскалацией, предварительным расчетом и т.п. которая ОЧЕНЬ сложна, но при этом отработана годами
4) УБ в 1С - это просто некие "флажки" - "тут можно, а тут нельзя", предельно упрощенная и не имеющая ничего общего с "тем как надо", более того - никак не распространяющаяся на реальные данные.


Так вот - 99% НОРМАЛЬНЫХ систем используют в своей работе механизм блокировок и транзакций от СУБД, потому как реализация аналогичного "очень трудна и дорога". И да, в них параллельность обеспечивается на лучшем уровне (Dynamix Ax и SAP (который не HANA)).

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

а про
более тонкое управление блокировками, но его можно обеспечить только на прикладном уровне
вы начитались методичек от 1С и просто не понимаете что это возможно БЕЗ 1С и БЕЗ управляемых блокировок.
96. spacecraft 06.05.19 16:27 Сейчас в теме
(93) а теперь отбросьте знания про последние версии mssql и оперируйте полным спектром поддерживаемых версий sql в 1С (в том числе и встроенной). А теперь создаете правило, которое поддерживается ими всеми и сразу.
97. acanta 06.05.19 16:32 Сейчас в теме
(96) что мешает 1с сузить поддерживаемые версии СУБД для каждого релиза конфигурации, как платформы к примеру.
Лицензионная политика ms sql?
98. spacecraft 06.05.19 16:34 Сейчас в теме
(97) предлагаете для каждой версии СУБД отдельную конфигурацию?
99. acanta 06.05.19 16:38 Сейчас в теме
(98) при запуске конфигурации пишут же обновите платформу. А почему не СУБД? Его надо заново покупать или только переустановить?
Оставьте свое сообщение

См. также

И тогда наверняка нас захватят облака Промо

Интеграция Бесплатно (free)

Внимание! Данный текст содержит достаточно мало технических подробностей и готовых рецептов. Главным образом некоторые размышления на предмет будущего технологий и профессий. Некое лёгкое чтение на досуге.

28.06.2019    9501    0    comol    36    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

Обычно предметом оптимизации являются заранее определенные ключевые операции, т.е. действия, время выполнения которых значимо для пользователей. Причиной недостаточно быстрого выполнения ключевых операций может быть неоптимальный код, неоптимальные запросы либо же проблемы параллельности. Если выясняется, что основная доля времени выполнения ключевой операции приходится на запросы, то осуществляется оптимизация этих запросов. При высоких нагрузках на сервер СУБД в оптимизации нуждаются и те запросы, которые потребляют наибольшие ресурсы. Такие запросы не обязательно связаны с ключевыми операциями и заранее неизвестны. Но их также легко выявить и определить контекст их выполнения, чтобы оптимизировать стандартными методами.

24.05.2020    5968    0    DataReducer    22    

[SQL Server] Использование trace flag 9592 для сжатия траффика в кластере AlwaysOn

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

18.05.2020    1637    0    Aleksey.Bochkov    3    

Эти занимательные временные таблицы

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    10044    0    YPermitin    0    

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    28797    0    MrWonder    42    

Оптимизация запросов 1С посредством индексации временных таблиц. Миф? Тестируем, смотрим, считаем

Производительность и оптимизация (HighLoad) Практика программирования v8 Бесплатно (free)

Появилось свободное время, решил проверить на работе индексацию таблиц. Решил поделиться с Вами результатами исследования. Давайте порассуждаем на эту тему? Часто ли вы пользуетесь индексацией в запросах? Платформа 8.3.16.1224

03.04.2020    3256    0    feva    14    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    11155    0    informa1555    21    

Многострочный контекст событий

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

31.03.2020    2768    0    vasilev2015    9    

Долго открывается конфигуратор Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    40066    0    Gilev.Vyacheslav    1    

Анализ взаимоблокировок

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

20.03.2020    4060    0    vasilev2015    21    

Многопоточность

Практика программирования Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Увеличиваем скорость загрузки данных в 20 раз. Как следует использовать многопоточность и готовый модуль для внедрения.

18.03.2020    6118    0    kaliuzhnyi    43    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    66477    0    yuraos    112    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    8076    0    Evil Beaver    13    

Оптимизатор запросов. Вторая часть

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Продолжение статьи об оптимизаторе запросов. Во второй части мы попробуем создать свой оптимизатор и попутно разберемся с такими вопросами, как: хранение файлов; индексы; статистика.

23.01.2020    5866    0    darkdan77    59    

Улучшаем производительность 1С. Рекомендации

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

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

23.01.2020    7155    0    Kaval88    26    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

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

21.06.2013    53257    0    Антон Ширяев    116    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    9948    0    ivanov660    16    

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    6967    0    EugeneSemyonov    11    

Обслуживание баз данных. Не так просто, как кажется

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    16383    0    YPermitin    28    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    53887    0    Gilev.Vyacheslav    46    

Мониторинг высоконагруженной системы

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    8504    0    Repich    5    

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux

Администрирование данных 1С Zabbix v8 Бесплатно (free)

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    17497    0    Sloth    24    

Хранение файлов - как уменьшить размер базы данных

Чистка базы Производительность и оптимизация (HighLoad) Практика программирования Разработка v8 Россия Бесплатно (free)

Хранение файлов в базе 1С можно оптимизировать для уменьшения размера хранимых данных.

09.09.2019    7968    0    2tvad    17    

Параллельные вычисления в 1С 8 Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    29642    0    gallam99    19    

Анализ производительности APDEX

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

31.08.2019    9845    2    YPermitin    7    

Неочевидные проблемы производительности: важность системного подхода при анализе

Производительность и оптимизация (HighLoad) v8 Россия Бесплатно (free)

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

19.07.2019    8475    0    Филин    12    

Ловля блокировок на связке "Microsoft SQL server - 1С"

Производительность и оптимизация (HighLoad) v8 v8::blocking Бесплатно (free)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    9130    0    fhqhelp    0    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    41841    0    madmpro    32    

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным

Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка v8 Бесплатно (free)

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

02.07.2019    10619    0    igordynets    119    

Ускорение чтения правил обмена в УПП 1.3 в 20 раз!

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Способ оптимизации чтения правил обмена конвертации данных. Может понадобиться при большом размере правил и высокой периодичности обмена.

27.06.2019    9336    0    YPermitin    16    

Хотите снизить нагрузку на процессор сервера в 2 раза?

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

27.06.2019    8950    0    Дмитрий74Чел    6    

Непридуманные истории по оптимизации. История 1

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    12100    0    Repich    117    

Оптимизация: неэффективные запросы

Производительность и оптимизация (HighLoad) Практика программирования Разработка v8 1cv8.cf Бесплатно (free)

В большинстве случаев основной причиной медленной работы системы при многопользовательском режиме работы является блокировка данных СУБД (говорим про клиент-серверную версию). Блокировка - это не есть хорошо или плохо, это жизненно необходимая вещь при построении прикладной логики работы системы. Но блокировки таблиц, записей могут быть как вполне законными, так и далеко не всегда оправданными в каждой конкретной ситуации. Одной из самых распространенных причин неоптимальной блокировки ресурсов является некорректное написание запросов.

13.06.2019    5592    0    slayer-ekb    10    

Многопоточное ускорение однопользовательских нагрузок в 1С + Microsoft SQL Server 2017

Практика программирования Производительность и оптимизация (HighLoad) v8 v8::Запросы Бесплатно (free)

Взаимодействие с Microsoft SQL Server нередко вызывает трудности у 1С-ников, а потому интересны любые моменты, связанные с его использованием. О своем опыте работы с новым SQL Server 2017 участникам конференции Infostart-2018 рассказал директор ООО «Аналитика софт» Дмитрий Дудин.

11.06.2019    22842    0    dmurk    144    

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    17733    0    ivanov660    9    

Не думать о секундах свысока...

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    7615    0    vasilev2015    21    

Альтернативная стратегия управления блокировками

Производительность и оптимизация (HighLoad) v8 v8::blocking 1cv8.cf Россия Бесплатно (free)

Данная публикация освещает одну из альтернативных стратегий блокирования данных на уровне MS SQL Server, которая недоступна средствами 1С, но может быть весьма полезной. Разбирается практический пример.

20.05.2019    6838    0    zhichkin    15    

Странное потребление места на диске С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Решение проблемы постоянного роста папки %AppData%/Local/Temp.

26.04.2019    13721    0    kuzyara    12    

Включение встроенного в платформу механизма "Копии базы данных" и использование "Дата Акселератора". Новый стандартный механизм использования баз OLAP в 1С

Производительность и оптимизация (HighLoad) v8 Россия Бесплатно (free)

С версии 1С 8.3.14 в платформе появился новый функционал «Копии базы данных». В данной публикации я хочу рассказать, как включить использование данного механизма в платформе 1с и как его использовать для получения отчетов с копии базы данных, которая может быть вынесена на внешний сервер относительно текущей базы данных, а также как использовать систему «Дата акселератор», в которой база данных целиком размещена в оперативной памяти рабочего сервера кластера серверов «1С:Предприятия».

25.04.2019    13133    0    Elf1k    27    

5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

В этой статье мы разберем механизм использования конфигурации "Анализ технологического журнала" на практике, и всего через 15 минут работы вы получите функциональный, удобный инструмент мониторинга проблем производительности базы 1С.

18.04.2019    27755    0    ivanov660    77    

Как разбить базу на файлы и не сойти с ума

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Разбиение базы данных 1C на файлы и последующее сопровождение. Нюансы, грабли и прочее.

06.04.2019    14988    0    YPermitin    30    

Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

В связи с санкциями и другими событиями сейчас все более и более актуальна тема перевода ПО компаний на отечественное и свободное программное обеспечение. Одной из самых востребанных СУБД на рынке на данный момент является PostgreSQL - надежная, высокопроизводительная и хорошо масштабируемая СУБД, которая является прямым конкуретном таким крупным компаниям с их топовыми продуктами, как Oracle, IBM и Microsoft. Однако каждый, кто переходит на PostgreSQL, сталкивается с трудностями, прежде всего с настройкой и производительностью. Не обошли проблемы с производительностью "слоника" и меня. Предлагаю вашему вниманию перевод статьи "How a single PostgreSQL config change improved slow query performance by 50x" автора Pavan Patibandla, которая мне помогла улучшить производительность PostgreSQL.

18.03.2019    15042    0    w.r.    23