"Убираем блокировки" в 1С. Заставляем MS SQL работать как Oracle.

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

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

Включение уровня изоляции Read commited shapshot в MS SQL позволяет практически полностью избежать блокировок на уровне MS SQL при использовании управляемого режима

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

Собственно рецепт:
1) Выгоняем всех из базы
2) Открываем SQL Server Management Studio, New Query
3) Пишем:

ALTER DATABASE MyDatabase
SET ALLOW_SNAPSHOT_ISOLATION ON

ALTER DATABASE MyDatabase
SET READ_COMMITTED_SNAPSHOT ON

где "MyDatabase" естественно нужно заменить на название вашей базы данных

Для тех кому абсолютно не интересно что дальше произойдёт и как это работает - можно дальше не читать. 
Для тех, кому наоборот - очень интересно могу привести ссылки: http://msdn.microsoft.com/ru-ru/library/ms173763.aspx
и http://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.80).aspx
Собственно окончательно меня убедило в правильности данного подхода, когда нашел в официальном руководстве для разработчиков Dynamics Ax (http://crusevinaq.narod2.ru/public/spravochnik-professionala-microsoft-dynamics-ax-4.0-skachat.html
) упомянание о том что данный уровень изоляции DAX по-умолчанию включает для баз, созданных на SQL Server 2005/2008. 1С, к сожалению на момент написания данной статьи ещё этого не умеет. И мне, если честно, продвигать эту идею туда пока лень. Собственно 2 команды написать намного проще.

Что при этом изменится. Всё очень просто - часть SQL Server станет версионником. Причём в данном случае рекоммендуется всё-таки использовать SQL Server 2008, т.к. в SQL 2005 эта возможность только появилась. А сами знаете как бывает когда возможности только появляются. У тех кто понял слово "Версионник" глаза уже загорелись, вдруг вспомнился "Oracle". Хотел найти статью, которая бы объяснила чем отличается версионник от блокировочника, но как-то не сложилось.

Обясню в 2 словах: мы хотим списать с остатков 1 Ручку, которая на складе всего одна, и сосед наш тоже этого жутко хочет:
Вместе жмём на кнопку "Провести". Мы на тысячную долю секунды быстрее.

Уровень изоляции везде READ COMMITED

Как сработает блокировочник:
 
- читаем остатки мы, и блокируем их
- читает остатки сосед - ждёт пока отпустим
- записываем остатки
- читает остатки сосед , ну и уже понятно, получает отказ

Как сработает версионник:

- Читаем остатки
- Читает остатки сосед (!!!!!!!) 
- Записываем остатки
- Сосед записывает остатки, естественно дождавшись пока мы запишем

В чём разница? А в том что во втором случае сосед прочитает версию данных которая была зафиксирована до их измененеия. Концептуальному уровню READ COMMITED это всё удовлетворяет. Были прочитаны зафиксированные данные, просто прочитаны данные, которые были зафиксированы ранее. Таким образом, незафиксированных в транзакции данных мы не прочитаем, что немловажно. НО ведь в данном случае мы спишем 2-ю ручку в "-". Да - спишем, конечно если не наложим управляемую блокировку
речь о которых пойдёт в следующем посте. Потому что уровень изоляции READ COMMITED 1С использует только при наличии управляемых блокировок. При этом поддерживается на уровне СУБД только логическая целостность данных, а о своих "заморочках" программисты должны позаботиться сами, с чем я лично не могу не согласиться.

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

Как было отмечено выше, включение версионирования возможно только для уровня изоляции READ COMMITED. А этот уровень изоляции используется при включенных управляемых блокировках. При автоматических блокировках чаще всего уровень изоляции SERIALIZABLE - поэтому включение данной опции для автоматического режима несущественно повысит производительность, поэтому настоятельно рекоммендуется их включить, если этого ещё не сделано. Если не вдаваться в подробности включение управляемых блокировок в любой конфигурации не займёт более 3-4 часов работы квалифицированного программиста. Конечно в случае когда они включаются осмысленно и осознанно, а не простым слодованием методике, описанной на ИТС. В следующей статье я опишу как это проще всего сделать.

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. drkhaired 50 27.09.11 11:33 Сейчас в теме
Вопросик, если вы этот режим использовали, на сколько увеличивается размер файла данный на скуле?
2. comol 4548 27.09.11 12:44 Сейчас в теме
Размер базы практически не увеличивается - чуть tempdb вырос средний рабочий размер, но около 1 ГБ - незначительно. там ведь просто вместо таблицы блокировок ещё и версии данных рабочие сохраняются. Но по завершении транзакции они ведь "сливаются" в одну.
82. AlexO 130 08.11.12 17:44 Сейчас в теме
(2)
вообще непонятно, откуда вы взяли, что
Как сработает версионник:
- Читаем остатки
- Читает остатки сосед (!!!!!!!)
- Записываем остатки
- Сосед записывает остатки, естественно дождавшись пока мы запишем

а ситуация
- Читаем остатки
- Записываем остатки - Читает остатки сосед (!!!!!!!)
- что, невозможна?
Да даже и ваш пример - что тогда записывает сосед в базу, если вы уже записали свои данные, а сосед о них даже и не узнал?
pbahushevich; +1 1 Ответить
3. ZergKRSK 28.09.11 12:00 Сейчас в теме
7. comol 4548 28.09.11 12:53 Сейчас в теме
4. Rego1337h 28.09.11 12:14 Сейчас в теме
(0) Не совсем понял зачем это нужно, если в управляемом режиме блокировки до SQL Server вообще не доходят? Ими занимается Менеджер блокировок на сервере 1С.
6. comol 4548 28.09.11 12:52 Сейчас в теме
(4) Meatgrinder, Ещё как доходят... просто уровень изоляции другой - Read commited. т.е. пока одна транзакция изменяющая данные не зафиксируется другая не прочитает данные ни при каких условиях. Но при этом прочитать их всё-таки сможет. В управляемом режиме просто дали самим программистам рулить когда читать с блокировкой, а когда без блокировки... но при записи ничего не изменилось... а в 90% случаев и эти блокировки тоже не нужны.
5. fishca 1191 28.09.11 12:36 Сейчас в теме
(0) Если мы при списании с остатка избавимся от блокировки, то каким образом потом в 1С мы сможем проконтролировать остатки, не очень понятно. Как раз при одновременном списании разными пользователями, насколько я понимаю, блокировка просто необходима.
Krimskiy_xan; +1 Ответить
8. comol 4548 28.09.11 12:57 Сейчас в теме
(5) fishca, Да, необходима, только SQL сервер к ней не имеет никакого отношения - блокировка управляемая. Для автоматического режима конечно эта статья мало пользы принесёт. Подробнее по управляемый писал: http://comol.livejournal.com/1013.html
9. ctpayc 28.09.11 13:02 Сейчас в теме
На мой взгляд прирост производительности мы получим только при условии, что у нас в транзакциях есть большие долго выполняющиеся запросы, и нам при этом не важно повторяемость чтения. Рассмотрим на примерах. Работа идет естественно в управляемых блокировках.

1. Мы читаем остатки, потом делаем движение, хотим чтобы остатки не стали отрицательными, единственный вариант - установить управляемую блокировку (в данном случае исключительную, чтобы не получить дедлок). В итоге все плюсы от версионника теряем, так как остальные транзакции встанут на уровне менеджера блокировок 1С. Уточню, что даже если мы поставим разделяемую блокировку, то плюсы мы все равно потеряем, так как запись в управляемых блокировках все равно не сможем провести.

2. Мы делаем маленький запрос, потом запись, при этом не блокируем данные управляемой блокировкой. Что же произойдет? На время выполнения запроса, никакая другая транзакция записать данные не сможет (блокировка на уровне SQL без данной настройки), после выполнения запроса, но еще до записи блокировка READ COMMITED на прочитанные данные будет уже снята. Тем самым группа отдельных запросов внутри транзакции нам сильно мешать не будет. Итого вероятность того, что запись данных попала на чтение этих же данных в транзакции, да еще и без установки управляемой блокировки. И сравниваем с накладными расходами MS SQL для поддержания версионника. Спорный плюс.

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

4. Рассмотрим рекомендуемый ныне фирмой 1С метод контроля остатков (и не только 1С, но и Microsoft). Сначала пишем, потом проверяем, если что отменяем. В таком случае в самом начале будет установлена управляемая исключительная блокировка, и нам будет совершенно все равно какая блокировка установлена на уровне SQL.

Итог: почти все плюсы съест менеджер управляемых блокировок 1С. Теперь, прежде чем "нарушать лицензионное соглашение" :), стоит оценить насколько часто в вашей конфигурации встречается вариант 3. В итоге накладные расходы не перекроют ожидаемый эффект? В типовых конфигурациях, по-моему, вообще не имеет смысла данная настройка, если у вас собственная самописная конфигурация, то может быть. А вообще вам поможет только замер производительности в первом и втором случае. Потому тест центр в руки - генерируем нагрузку, смотрим ЦУПом время ожидания на блокировках SQL, ЦУПом же анализируем общее время выполнения запросов. Только этот эксперимент даст вам ответ на вопрос: "А стоит ли?".

Ради эксперимента проведу замер производительности в обоих случаях в разрабатываемой сейчас мною конфигурации, потом напишу результаты. Но сейчас, стадия промежуточная между тестами, так что недели через 2 только смогу.
LordKim; khaoos; oaf_is; speshuric; Spacer; +5 Ответить
89. ZLENKO 04.04.13 11:29 Сейчас в теме
(9) Если контролировать остатки по "старой методике" и устанавливать управляемую блокировку в начале проведения документа, то выигрыш от управляемых блокировок в целом очень сомнителен в обоих случаях (и версионника и блокировщика).
Если не сразу устанавливать блокировку (или вообще не устанавливать явно) управляемую блокировку то выигрыш от управляемых блокировок только в случае идеальной конфигурации с контролем остатков по "новой методике" и отсутствием явной записи наборов в регистр. Иначе в случае блокировщика получаем deadlock из-за разного порядка записи в регистры, что гораздо хуже простого ожидания на блокироке.
Кроме того в обоих в обоих случаях получаем deadlock в случае блокировщика из-за того что MS SQL сам принимает решение что блокировать, в отличие от сервера приложений который использует "правильную" блокировку.
Так что при всем богатстве выбора, другой альтернативы нет - только версионник может повысить параллельность работы пользователей настолько, насколько это в принципе возможно.
10. speshuric 1210 28.09.11 13:15 Сейчас в теме
Кучка ошибок.

Как сработает блокировочник:

- читаем остатки мы, и блокируем их
- читает остатки сосед - ждёт пока отпустим
- записываем остатки
- читает остатки сосед , ну и уже понятно, получает отказ

Как сработает версионник:

- Читаем остатки
- Читает остатки сосед (!!!!!!!)
- Записываем остатки
- Сосед записывает остатки, естественно дождавшись пока мы запишем
Показать


Это не так.
В первом случае никакого "ждёт пока отпустим" (на READ_COMMITTED) нет. И никакого "ну и уже понятно, получает отказ" тоже нет. Если и понадобится ждать (окончания обновления данных, непример), то просто дождётся. Ну или не дождётся.
Во втором случае "сосед" должен отвалиться с ошибкой. Версионник сделан так чтобы "пишущие" транзакции не мешали читающим транзакциям и читающие не мешали пишущим. В блокировочнике даже читающие могут мешать читающим, но на более высоких уровнях изоляции.

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

1. Версионный режим работы может не подойти, т.к. у версионника есть свои специфичные конфликты обновления, которых нет с read committed (http://msdn.microsoft.com/ru-ru/library/ms188277.aspx).
2. Нет разницы - для всех или не для всех уровней изоляции используется READ_COMMITTED_SNAPSHOT, всё равно есть риск существенной нагрузки на tempdb (которая и так часто становится узким местом). Но что лучше - непредсказуемые эксалации для READ_COMMITTED или убитая tempdb для READ_COMMITTED_SNAPSHOT - это конечно же отдельный вопрос.

Самое главное. READ_COMMITTED_SNAPSHOT очень-очень-очень нужен чтобы отчет, который делается долгое время оперировал консистентным набором данных, причем не ставя колом всю остальную работу. А в 1С отчеты делаются с грязным чтением, поэтому все эти приседания просто не нужны. А для параллельного проведения обычного READ_COMMITTED и управляемых блокировок зачастую хватает.
LordKim; Rego1337h; khaoos; anderson; Ish_2; +5 Ответить
11. comol 4548 28.09.11 23:34 Сейчас в теме
(10) speshuric,
В первом случае никакого "ждёт пока отпустим" (на READ_COMMITTED) нет


Ну оооочень популярное заблуждение :). Если бы наши администраторы БД кроме чтения теории иногда ещё ставили простенькие эксперименты жизнь была бы намного легче :). Ничего не хочу сказать про теорию и работу может DB2.. но MS SQL делает так: В момент чтения Read Commited Кратковременно пытается наложить S блокировку Звучит конечно не очень, но происходит именно так - проверяйте :))) Как раз в это время и ждёт..

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

Версионный режим работы может не подойти, т.к. у версионника есть свои специфичные конфликты обновления, которых нет с read committed (http://msdn.microsoft.com/ru-ru/library/ms188277.aspx).
по русски это называется "баян" :). Давно всё читали - ни с чем не противоречит. Dynamics Ax ставит Shapshot по умолчанию - это уже о чём то да говорит :).

READ_COMMITTED_SNAPSHOT очень-очень-очень нужен чтобы отчет, который делается долгое время оперировал консистентным набором данных, причем не ставя колом всю остальную работу
Хотел бы я посмотреть на того программиста, который отчеты в транзакции выполняет :)))

А для параллельного проведения обычного READ_COMMITTED и управляемых блокировок зачастую хватает.
- повезло вам если хватает... а вот когда у вас 300+ юзеров и логика контроля остатков включает контроль резервов, товара в пути, заказов и прочих хитростей... я бы посмотрел как вам хватило бы READ COMMITED
12. Ish_2 1062 29.09.11 09:09 Сейчас в теме
(11) :
Как сработает блокировочник:

- читаем остатки мы, и блокируем их
- читает остатки сосед - ждёт пока отпустим
- записываем остатки
- читает остатки сосед , ну и уже понятно, получает отказ


Что значит "получает Отказ" ?
Понятнее другое :

- читаем остатки мы, и блокируем их (конструкция "Для Изменения" в запросе)
- читает остатки сосед - ждёт пока отпустим
- записываем остатки и "отпускаем"

- или сосед читает изменившиеся остатки , и в модуле проведения определяется возможно ли проведение при изменившихся остатках.
- или для соседа время ожидания завершения нашей транзакции истекло и сосед получает "отказ".
13. comol 4548 29.09.11 10:33 Сейчас в теме
(12) Ish_2, Под "блокируем" в данном случае я понимаю "начинаем изменять"... надо было наверное рисунок сделать - поленился :). Конструкция "для изменения" тут не много не о том, т.к. я пишу про уровень изоляции Read commited, а "для изменения" будет "repeatable read".

Сосед конечно не читает остатки а "предпринимает попытку чтения". Собственно за коммент спасиб, действительно придётся чуть подправить чтобы было понятнее...
14. hogik 437 29.09.11 16:28 Сейчас в теме
(12)
"- читаем остатки мы, и блокируем их (конструкция "Для Изменения" в запросе)"©
Наоборот - блокируем, а потом читаем. Иначе блокировка не имеет смысла.
15. Ish_2 1062 29.09.11 16:34 Сейчас в теме
(14) Конечно.
В своем варианте я попытался максимально сохранить текст цитаты.
17. comol 4548 29.09.11 17:55 Сейчас в теме
(14) hogik, Господа, я вообще не о том, я выразился так просто... "читаем и начинаем изменять", только бы найти к чему придраться :)
18. comol 4548 29.09.11 17:55 Сейчас в теме
(14) hogik, Хотя вообще спасибо - поправлю чуток раз можно понять по другому
126. LordKim 08.06.18 13:51 Сейчас в теме
(12)
конструкция "Для Изменения"

Вроде как в управляемом режиме не работает, только для автоматического...
20. speshuric 1210 29.09.11 18:41 Сейчас в теме
(11)
В момент чтения Read Commited Кратковременно пытается наложить S блокировку

А то ж! Конечно! Как же без неё родимой, а вдруг кто-то решил удалить данные, пока мы читаем? Но у вас же 2 читающие транзакции в READ_COMMITTED, обе накладывают S блокировочку. Кто кого ждёт? Смотрим в доку, http://msdn.microsoft.com/ru-ru/library/ms186396.aspx - Shared совместима с Shared.

По версионнику. В вашем сценарии ошибки времени выполнения не будет. Я перепутал с уровнем изоляции Snapshot, в чём каюсь. В Snapshot транзакция второго участника отвалится из-за изменения данных, но это уже отдельная история. Кстати, а зачем вы разрешаете оба режима и SNAPSHOT, и READ_COMMITTED_SNAPSHOT?
Вообще, посмотрев внимательно, я считаю, что в случае, если у нас read committed или read committed snapshot (и нет управляемых блокировок), то сценарий "читает 1, читает 2, записывает 1, записывает 2" одинаково приводит к неконсистентным данным.

Read committed snapshot может помочь не в такой простой схеме, а в случае, когда в продолжительной транзакции есть запись данных в начале транзакции. Примерно так:
1. Считаем записи в таблице А
2. Записываем запись в таблицу А
3. Думаем о жизни, сущем и всё такое (42 секунды)
4. Записываем запись в таблицу Б

Пусть 1-й участник выполнил первые 2 пукнта, а 2-й только начал транзакцию. В блокировочнике 2-й ждёт потому что 1 наложил блокировку (X) на всю таблицу. В версионнике 2-й прочитает то состояние, которое было на момент начала транзакции. С одной стороны, да, ускорение, с другой - я совершенно не уверен, что все механизмы 1С адекватно переживут такое изменение поведения.
Поэтому, то что "Dynamics Ax ставит Shapshot по умолчанию" говорит лишь о том, что MS протестировала внутренние механихмы аксапты на то, что они будут работать ожидаемым образом. А вот 1С такого вроде не заявляла.

Хотел бы я посмотреть на того программиста, который отчеты в транзакции выполняет :)))
Вообще-то большинство специалистов по базам данных в ужасе от того, что в 1С все отчеты потенциально показывают шлак. При более-менее интенсивном проведении документов отчеты по остаткам реально почти всегда (ну или через раз) показывают шлак. Вот это и есть "oracle-way", когда вроде и отчеты консистентные (по крайней мере есть момент времени, на который, например, существовали такие остатки), и изменения не ждут отчетов. А read uncommmitted по сути - удел неудачников.

повезло вам если хватает... а вот когда у вас 300+ юзеров и логика контроля остатков включает контроль резервов, товара в пути, заказов и прочих хитростей... я бы посмотрел как вам хватило бы READ COMMITED
Давайте не будем меряться размерами. Я встречал ситуации, когда READ COMMITED не хватит, но именно поэтому считаю, что для 500-1000 пользователей в 1С это не самая большая проблема. И, если и проблема, то решаемая. Для диагностики можно применить такой запрос:
select wait_type, waiting_tasks_count, wait_time_ms, max_wait_time_ms, signal_wait_time_ms
from sys.dm_os_wait_stats
where wait_time_ms + signal_wait_time_ms<>0
order by wait_time_ms + signal_wait_time_ms desc

Если ожидания установки блокировок (чаще всего LCK_M_X, LCK_M_S для режима управляемых блокировок) держатся "в топе" (если не считать всякие SLEEPы и т.п.), тогда, конечно, надо бы постараться их уменьшить, но если там какой-нибудь PAGEIOLATCH_SH или CXPACKET, то решать надо совершенно другие проблемы.
MSChe; alexscamp; Rego1337h; babys; hogik; +5 1 Ответить
90. ZLENKO 04.04.13 11:41 Сейчас в теме
(20)
Вообще, посмотрев внимательно, я считаю, что в случае, если у нас read committed или read committed snapshot (и нет управляемых блокировок), то сценарий "читает 1, читает 2, записывает 1, записывает 2" одинаково приводит к неконсистентным данным.

Такой же самой неконсистентности мы можем добиться в обычной ситуации если документ2 проводится "задним числом" - движения документа1 никак не будут учитывать уже имеющихся движений документа1. Так что такая "неконсистентность" - вполне нормальная ситуация для базы на 1С.
Там где надо избежать такой неконсистентности в оперативном режиме работы - надо применять проверки после записи набора записей.
91. ZLENKO 04.04.13 11:58 Сейчас в теме
(20) Как я и предполагал - решать надо проблему deadlock...
wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms
REQUEST_FOR_DEADLOCK_SEARCH 40398 202203630 5189 202203630
XE_TIMER_EVENT 6739 202203816 30090 202202668
LAZYWRITER_SLEEP 5483819 404171462 11881043 103247
CXPACKET 122645427 196576331 47939 8810348
LOGMGR_QUEUE 1784647 202133531 6221089 84946
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 50428 202153506 4179 150

Ну и как я ее решу адекватно в УПП ? Написать свою новую версию УПП ? :-)
Проще вернуться в режим автоматических блокировок и уменьшать время транзакций при проведении оптимизацией кода.
Но ранее у меня вся оптимизация кода в УПП упиралась в длительную запись (именно запись) регистров партионного учета и длительный запрос чтения остатков по счету по плану счетов. Сейчас правда после аутсорсеров есть что оптимизировать... Палками кидать в меня не нужно по поводу проведения партий в онлайне - заказчику партии нужны именно в онлайне. Хотя конечно было бы неплохо разработать отдельный механизм для учета того, что они учитывают при помощи партий, но пока что переубедить их не удалось.
95. abe 15.04.13 18:25 Сейчас в теме
(91)
Как я и предполагал - решать надо проблему deadlock...
wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms
REQUEST_FOR_DEADLOCK_SEARCH 40398 202203630 5189 202203630



REQUEST_FOR_DEADLOCK_SEARCH - не говорит о том, что проблема в дедлоках

Occurs while the deadlock monitor waits to start the next deadlock search. This wait is expected between deadlock detections, and lengthy total waiting time on this resource does not indicate a problem.

http://technet.microsoft.com/en-us/library/ms179984.aspx
16. dkprim 5 29.09.11 17:34 Сейчас в теме
интересная и полезная статья :) ждем продолжения :)
19. comol 4548 29.09.11 17:57 Сейчас в теме
(16) dkprim, Как часто пишут "что бы вы хотели прочитать в продолжение"... Я ещё часто как SSIS пользоваться рассказывал... думаю вот эту http://comol.livejournal.com/2159.html тему тут развить...
21. comol 4548 30.09.11 10:30 Сейчас в теме
по крайней мере есть момент времени, на который, например, существовали такие остатки
Улыбнуло и пользователь конечно записал время нажатия на кнопочку с точностью до милисикунды :))))))


Но у вас же 2 читающие транзакции в READ_COMMITTED
Я уже писал выше - не читающие под "блокируем" я понимаю - "начинаем изменять", т.е. накладываем X блокировку.

и нет управляемых блокировок
- смысла тогда думать дальше нет даже :).

3. Думаем о жизни, сущем и всё такое (42 секунды)
не поверите... вот это 1С ооочень часто делает, да ещё намного больше чем Dynamics Ax

А вот 1С такого вроде не заявляла.
да... и ещё дооолго не заявит, пока дойдёт руки - не до этого им сейчас :).

И, если и проблема, то решаемая.
Да решаемая... улучшением Hardware, оптимизацией запросов... куча затрат на время и деньги, вместо одного простого способа мы её так и решали...

Если ожидания установки блокировок (чаще всего LCK_M_X, LCK_M_S для режима управляемых блокировок) держатся "в топе"
то пользователи бегут к вам и "бьют по морде". Можете уже не успеть решить :))))
22. speshuric 1210 30.09.11 11:06 Сейчас в теме
comol пишет:
Я уже писал выше - не читающие под "блокируем" я понимаю - "начинаем изменять", т.е. накладываем X блокировку.

Я запутался. Вот ваша схема, по которой, как вы пишите, работает 1C с точки зрения MS SQL:
Уровень изоляции везде READ COMMITED

Как сработает блокировочник:

- читаем остатки мы, и блокируем их
- читает остатки сосед - ждёт пока отпустим
- записываем остатки
- читает остатки сосед , ну и уже понятно, получает отказ

Если у нас READ_COMMITТED, то перед первым шагом мы накладываем блокировку S, которая мешает другим транзакциям наложить X, но не S, а после первого шага снимаем её. Если мы говорим про управляемый режим, то при этом, на самом деле 1С наложит упр. блокировку на документ, на наборы движений и на разрезы итогов по существующим движениям. Но мы смотрим работу MS SQL и поэтому про упр. блокировки пока забыли.
На втором шаге - всё повторяется, опять наложили и сняли S блокировку (кого и где мы тут ждём, если, например, оба документа новые?). Даже если чтение 1-го шага еще не окончено, то ничего нам тут не мешает.
На третьем шаге, кстати, первая транзакция должна подождать, пока не снимется S блокировка с итогов регистра накопления. Перед началом изменения на этом шаге MS SQL Server выставляет X блокировки на удаляемые/создаваемые записи. Если таких записей много (более 5000), то блокировка может быть эскалирована до большей. После окончания изменения данных блокировка остаётся висеть до конца транзакции, поэтому ни S, ни X уже никто не навешает.
Четвёртый шаг ждёт окончания транзакции и делает свои движения, аналогично шагу 3.

Еще раз - кто и кого ждёт на втором шаге этой схемы?
23. speshuric 1210 30.09.11 11:23 Сейчас в теме
Улыбнуло и пользователь конечно записал время нажатия на кнопочку с точностью до милисикунды :))))))
Вы смейтесь, смейтесь. Сегодня как раз отличный день для этого - последний день месяца. Если в базе идёт интенсивное проведение, то с грязным чтением возможна следующая проблема:
Предположим пользователь запустил отчет по остаткам денег в кассе за 2 сентября. 1С преобразует запрос к виртуальной таблице регистра в запрос по двум таблицам - по итогам на последнюю дату системы (3999 год) с ограничением по измерениям и по движениям со 2 сентября по последнюю дату системы с теми же ограничениями по итогам. Затем из итогов отнимает приход и прибавляет расход, чтобы получить верные остатки на 2 сентября. При этом из-за грязного чтения вполне возможна ситуация, когда MS SQL прочитает данные из таблицы итогов и из таблицы движений рассогласованно. Чаще всего это, конечно, проявляется при получении итогов на начало месяца в конце месяца или за начало предыдущего месяца, когда итоги еще не расчитаны. Директор видит отрицательный остаток по кассе, медленно офигевает, зовёт кассира и главбуха, они говорят: "это всё кривая 1С"... Вопрос - что сказать 1Снику, когда его позовут объяснить, нахрена заплачено $N за систему, которая в принципе не умеет выводить остатки отличные от текущих?
aegoncharov; +1 Ответить
24. comol 4548 30.09.11 11:54 Сейчас в теме
(23) speshuric,
Ну уже радует что в логике работы 1с вы разбираетесь, но ситуация конечно надуманая. Если в момент построения отчета В открытом периоде кто-то проводил такой не хилый документ списания по кассе, который, допустим, ещё и не провёлся а откатился в итоге то кассир получит отрицательную сумму но на текущий момент времени, а не на закрытый период. И как любой здоровый человек построит отчет ещё раз. Но ведь на то это и открытый период чтобы в нём что-то постоянно менялось :). Беда 1С именно в этом... в том что в принципе работа задним числом разрешена, и есть понятие "открытого периода". Поэтому логика отчетов вполне подходит... под логику системы. Описанное поведение как раз "укладывается" в мозгу бухгалтера, а вот "нельзя изменять проведённые документы"... как-то не очень укладывается :)

А что касается отчетов... я наверное об этом ещё статью напишу. Посмотрел я на это дело в Dynamics - там отчетов нет - "используйте Reporting Services" А вы его видели? Степень его убогости... и там всё тот же Read Uncommited, кстати :)))
ZLENKO; German; +2 Ответить
28. speshuric 1210 30.09.11 13:43 Сейчас в теме
(24)

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

Сегодня 30.09.2011. Итоги в базе данных расчитаны до 31.08.2011.
Остаток на 01.11.3999 - 50 рублей. Каждый день с 02.09.2011 по 29.09.2011 есть по 100000 документов в день. Половина - приходы на 1000 рублей, половина - расходы на 1000 рублей.
Очевидно, что реальный остаток на начало дня 02.09.2011 - те же самые 50 рублей.
Дальше такой процесс:
1. Наш гипотетический директор запустил отчет по остаткам по кассе, чтобы посмотреть остаток на начало дня 02.09.2011.
2. MS SQL Server получил запрос, скомпилировал, построил план. План примерно такой, что нужно взять таблицу итогов, отфильтровать по кластерному индексу по периоду данные на 01.11.3999, получив из неё поле ресурса суммы, взять часть таблицы движений (опять же по кластерному индексу) от 02.09.2011 00:00:00 до 01.11.3999 00:00:00, при этом поле ресурса суммы взять с минусом для прихода и с плюсом для расхода. После получения всей этой выборки (на самом деле не после, а по мере выборки данных, но не суть) просуммировать поле ресурса суммы, сгруппировать как написано в запросе и выкинуть нулевые итоги, если они есть. Блокировок никаких нет.
3. Запрос начал выполняться по плану, все недостающие в памяти экстенты поставлены в очередь на чтение с диска и быстро-быстро прочитаны данные по итогам (там всего-то сотни или тысячи записей, а движений миллионы)
4. Кассир Людочка проводит новый документ "приход 1000 рублей". Сегодняшней датой. Неоперативного проведенияу неё, конечно, нет. Остатков контролировать не надо (это же приход).
5. MS SQL проводит документ: создаёт запись документа, изменяет данные в таблице итогов за 01.11.3999 (увеличили на 1000 руб), создаёт запись регистра накопления (приход на 1000 руб). Всё это, конечно, с учетом блокировок MS SQL и 1С.
6. Запрос отчета директора наконец-то добрался до тех страниц, в которых лежат сегодняшние данные. У него получилось 28*50000 расходов по 1000 рублей, 1 400 000 000 рублей за период, которые надо прибавить к конечному остатку 50 руб и 28*50000+1 приход по 1000 рублей, т.е. 1 400 001 000, которые надо вычесть из начального остатка. Итого 50 + 1400000000 - 1400001000 = -950 рублей.
7. Директор удивлён. Ведь он же тщательно выстроил бизнес-процессы, чтобы кассир мог проводить только оперативно, а выручка сдавалась в конце дня. Ведь он потратил 10 млн рублей только на лицензии 1С (а еще MS, а еще пришлось технику брать, еще за внедрение, за обучение...) и всего-то хочет узнать остаток в кассе на 2 сентября. Что сказать директору?
aegoncharov; WarAn; kylux; +3 Ответить
30. comol 4548 30.09.11 17:47 Сейчас в теме
(28) speshuric, Да, думаю чисто гипотетически такая ситуация возможна, чтобы записи в таблицах итогов и движений были рассинхронизированы, хотя может в платформе и есть какой-то механизм проверки их синхронности. На практике удавалось воспроизвести? Вы представляете сколько всего так должно совпасть чтобы эту ситуацию получить? А повторное секундное нажатие кнопки сразу "исправляет проблему". А все более-менее важные отчеты в 1С делают по закрытому периоду, а там соответственно уже посчитаны итоги и текущие "телодвижения" на них не влияют.
31. comol 4548 30.09.11 17:49 Сейчас в теме
(28) speshuric, Кстати, ваше вот это сообщение ещё раз убеждает в том что моя статья "в тему" для 1с.

Как говорится "Если нет разницы - зачем платить больше" :)))
33. hogik 437 30.09.11 22:02 Сейчас в теме
(24)
"и там всё тот же Read Uncommited"(с)
Имеют полное право. ;-) Естественно, при соответствующей этому схеме базы данных и системе "логических" блокировок на уровне платформы.
"...Reporting Services" А вы его видели? Степень его убогости"(с)
ОНИ уделяют больше внимание содержанию информации, а не внешней форме её представления. И у НИХ не возникает "проблем" подобных (28) сообщению. ОНИ об этом, в первую очередь, думают. А МЫ все "бантики" изображаем...
(30)
"...чисто гипотетически такая ситуация возможна, чтобы записи в таблицах итогов и движений были рассинхронизированы,"(с)
Реально будет возникать очень часто.
"...может в платформе и есть какой-то механизм проверки их синхронности."(с)
Есть. ;-) На уровне управления блокировками ручками.
"На практике удавалось воспроизвести?"(с)
Для этого не требуется воспроизведения на практике. Достаточно знать и понимать организацию схемы базы данных и логики её обработки.
"...представляете сколько всего так должно совпасть чтобы эту ситуацию получить?"(с)
Достаточно совпадения двух событий, как это описано в (28).
"повторное секундное нажатие кнопки сразу "исправляет проблему".(с)
Но, для этого пользователь должен знать, что эта "проблема" возникла. Или давить на кнопку несколько раз для подтверждения достоверности информации. Ну, или запускать отчет в монопольном режиме.
"все более-менее важные отчеты в 1С делают по закрытому периоду"(с)
А отчет "по остаткам по кассе"(с) и есть "более-менее" важный. И подобных отчетов, требующих 100% достоверности - много. И не по закрытому периоду.
(31)
"убеждает в том что моя статья "в тему" для 1с"(с)
Т.е. если есть бардак, то второй бардак не сильно усугубит первый. Да. Есть такой взгляд на жизнь АСУП. И имеет название - "раздолбайство". ;-)
Эх. Пожалуй, и на эту стать поставлю "минус". :-(
P.S. Олег. Бардак надо не плодить, а устранять. И это редко получается двумя нажатиями кнопки мышки...
35. comol 4548 30.09.11 23:44 Сейчас в теме
(33) hogik, Уже писал, не буду дальше спорить

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

Согласен с одним:

если есть бардак, то второй бардак не сильно усугубит первый
это обычно называют - функционал системы удовлетворяет потребностям бизнеса и не содержит избыточности :). только 1С может нормально жить там где ни какая "срьёзная" западная система не выживет :).
36. hogik 437 01.10.11 00:10 Сейчас в теме
(35)
Олег.
И я соглашусь с Вашим согласием. :-)
Именно, поэтому, лично я, и не использую 1С-ы для АвтоМехАнизации своей конторы.
Желаю Вам успехов в борьбе приумножении бардака.
Думаю, на этом наши с Вами беседы можно закончить.
93. ZLENKO 04.04.13 12:14 Сейчас в теме
(33) В бизнесе важен не порядок, а наличие конкурентных преимуществ. 1С как раз дает (при умелом использовании) возможность создать в ней эти преимущества, приближая возможности системы к потребностям бизнеса. Те, кому важен порядок и есть много лишних денег, ставят SAP :-)
25. comol 4548 30.09.11 11:58 Сейчас в теме
(23) speshuric,
Еще раз - кто и кого ждёт на втором шаге этой схемы?


"читаем остатки мы, и блокируем их" читать как "читаем остатки и начинаем их изменять" - это на "причьем языке". Управляемый режим - "точку останова" поставили после "update" но до "Commit". Так наверное будет понятнее... правда не многим...
26. speshuric 1210 30.09.11 12:03 Сейчас в теме
Да решаемая... улучшением Hardware, оптимизацией запросов... куча затрат на время и деньги, вместо одного простого способа мы её так и решали...
Т.е. вы готовы променять целостность данных на производительность системы? Вы заказчиков/работодателей/коллег об этом, надеюсь, уведомили? Мне лично проще убедить заказчиков в затратах на новый сервер, чем в том, что база может быть в рассогласованном состоянии.
> Если ожидания установки блокировок (чаще всего LCK_M_X, LCK_M_S для режима управляемых блокировок) держатся "в топе"
то пользователи бегут к вам и "бьют по морде". Можете уже не успеть решить :))))
Тот способ, который я предложил вообще - не предназначен для выявления проблемы "здесь и сейчас". sys.dm_os_wait_stats накапливает данные с момента запуска MS SQL Server. Для оперативного предоствращения описанного производственного травматизма эффективнее счетчики производительности, КИП, алерты MS SQL Server.
27. comol 4548 30.09.11 13:18 Сейчас в теме
(26) speshuric,
вы готовы променять целостность данных на производительность системы
Знаете о нарушении целостности данных речь здесь не идёт... это вам любой специалист по СУБД скажет, а вот что касается мнения заказчиков... я об этом писал уже в другой статье. Для Газпром-а скорее всего такой вариант не подойдёт т.к. "теоретически возможна" рассогласованность данных, но дело в том что сама 1С это в принципе "рассогласованность данных" с точки зрения к примеру любителей Oracle, у которых шок и муражки по коже от того что я предлагаю.

Тот способ, который я предложил вообще - не предназначен для выявления проблемы "здесь и сейчас"

Т.е. "вы предпочитаете запереться и подождать"? :))))
29. speshuric 1210 30.09.11 15:01 Сейчас в теме
(27)
comol пишет:
Т.е. "вы предпочитаете запереться и подождать"? :))))

Нет, ни в коем случае. Я предлагаю пользоваться инструментами по назначению.
92. ZLENKO 04.04.13 12:03 Сейчас в теме
(26)
Т.е. вы готовы променять целостность данных на производительность системы? Вы заказчиков/работодателей/коллег об этом, надеюсь, уведомили? Мне лично проще убедить заказчиков в затратах на новый сервер, чем в том, что база может быть в рассогласованном состоянии.

Компания 1С это делает (меняет производительность на целостность) уже много лет, контролируя остатки только при оперативном проведении :-) Так что хуже чем есть точно не станет :-)
32. f_fobos 30.09.11 19:17 Сейчас в теме
Кто-нибудь пробовал сделать рекомендуемое на MS SQL Server 2005? Каковы результаты, проблем не возникло?
34. comol 4548 30.09.11 23:41 Сейчас в теме
(32) f_fobos, Как бы уже полгода работают 300+ пользователей в УТ, никаких конфликтов никаких блокировок. 50 пользователей в бухгалтерии спокойно работают даже во время восстановления последовательности. Я же просто так не стал бы писать. Это конечно не у меня - это в знакомой организации, я же лицензионного соглашения не нарушаю :).
37. oaf_is 01.10.11 17:02 Сейчас в теме
Вопрос от делитанта:
1.Для управляемых блокировок придется переписать модули проведения всех документов/записи регистров? и перетаскивать доработки при обновлениях?
2. Есть примеры для ЗУПА?
3. Где почитать про идеи как допиливать модули проведения?

Пы.Сы. Как я понял, режим изменения блокировок распространяется на всю базу, а не конкретные объекты1С или физическиеТалицыБД . Потому и вопросы.:(

Пы.Сы.1 хотелось бы определить: "А стоит ли оно тогО?" в моей конкретной ситуации.
38. comol 4548 02.10.11 15:05 Сейчас в теме
(37) oaf_is, Как раз в ответ на ваш вопрос вторая статья: http://infostart.ru/public/91880/
1) Ничего не нужно "допиливать" практически 1 - 2 места где производится контроль остатков нужно управляемую блокировку поставить, и то только в случае если включен контроль отрицательных остатков
2) В последней версии ЗУП-а управляемый режим стоит
3) в статье выше... ну или в журнале у меня... главная идея - это не сложно. Практически любая конфигурация переделывается на управляемый режим минут за 30. Нужно найти места где блокировки на самом деле нужны (контроль остатков) и там их поставить, либо как в математике: доказать что не нужны
aniks3000; +1 1 Ответить
39. Djonny 15.10.11 18:19 Сейчас в теме
Полезная статья! побольше про MS SQL хотелось бы узнать!
40. Sunhare 3 09.12.11 09:21 Сейчас в теме
42. electronik 23.04.12 17:29 Сейчас в теме
Интересно интересно но кто протестировал как ето работает на практике, на сколько % увеличется база????7
43. comol 4548 23.04.12 18:22 Сейчас в теме
(42) electronik, А интересно с чего база должна увеличиться? Это лишь изменение транзакционных блокировок а не структуры хранения данных.
44. Duo78 24.05.12 15:38 Сейчас в теме
Это кстати нарушает лицензионное соглашение с 1С
45. comol 4548 24.05.12 16:40 Сейчас в теме
(44) Duo78, +1 нарушает :). Но я же этого в работе никогда не использовал, да и материал только в ознакомительных целях. Чисто академически выяснить чем версионник поможет. Может 1С на уровне платформы как-нибудь всё-таки сделают поддержку.
46. Циник 03.07.12 23:56 Сейчас в теме
Список изменений в 8.3

Работа с СУБД. Управляемые блокировки.- При работе с Microsoft SQL Server версии 2005 и выше, используется режим управления версиями строк, если конфигурация использует режим управляемых блокировок. Используется уровень изоляции транзакций READ_COMMITED_SNAPSHOT. При чтении данных вне транзакций используется согласованное чтение. - Реализованные изменения приводят:
К уменьшению блокировок и взаимоблокировок при выполнении запросов, работающих в транзакции;
Исчезновению ошибок при выполнении запросов вне транзакции над часто модифицируемыми прикладными объектами;
Получению согласованных результатов отчета вне транзакции на момент выполнения отчета.

Выходит, все таки, истина была на стороне автора.
47. hogik 437 04.07.12 00:38 Сейчас в теме
(46)
"истина была на стороне автора"(с)
Подтверждает обратное. ;-)
Для полноценного использования "Read commited shapshot"(с) требуются изменения в платформе. А не просто написание "двух команд"...
48. comol 4548 04.07.12 00:52 Сейчас в теме
(47) hogik, На самом деле автор просто пообщался с коллегами из 1С и наконец то согласовали сделали, что эти 2 команды будет "писать платформа", других изменений не будет, т.к. необходимые изменения уже были внесены при организации поддержки СУБД версионников (Postgre и Oracle). Да собственно можете профайлером посмотреть и убедиться :).
49. hogik 437 04.07.12 00:58 Сейчас в теме
(48)
Не буду с Вами спорить. ;-)
Но, хоть это прочтите из (10) сообщения:
"1. Версионный режим работы может не подойти, т.к. у версионника есть свои специфичные конфликты обновления, которых нет с read committed ..."(с)
50. comol 4548 04.07.12 01:25 Сейчас в теме
(49) hogik, Ну да, и Oracle "глупые ребята" писали :). Конечно есть особенности и чудес не бывает, при записи ничего не выигрываем. Но на чтении в транзакции версионник экономит время в большинстве случаев, поэтому версионники всё-таки ценятся больше ИХМО.
51. hogik 437 04.07.12 01:56 Сейчас в теме
(50)
Олег (comol).
У нас с Вами получаются очень длинные и бесполезные разговоры. Я всегда пытаюсь в разговоре определиться О ЧЕМ мы разговариваем, а потом уже сыпать аргументами.
В текущем обсуждении я не отрицаю преимущества "версионники"(с). Я, вообще, не обсуждаю этот инструмент.
Я утверждаю, что:
"Для полноценного использования "Read commited shapshot"(с) требуются изменения в платформе. А не просто написание "двух команд"..."(с).
Понимаете, суть моего высказывания направлена на Ваше утверждение "написать две команды и всё будет хорошо". А это не так. Ну, чуть-чуть сложнее всё оказывается... ;-)
52. comol 4548 04.07.12 09:51 Сейчас в теме
(51) hogik, Да я уже понял спорить с вами без вариантов. Ну так в академических целях ещё раз попробую:
3 предпосылки:
1) Версионники в общем случае предпочтительнее блокировочников (чтение внутри транзакции меньше блокировок вызывает). Собственно самая спорная предпосылка, но в (51) вы с этим согласились.
2) Read commited shapshot включается для базы 2-мя командами (можете проверить :) ).
3) Read commited shapshot включает функционал версионирования для MS SQL (на уровне изоляции Read commited)

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

В любом случае дальнейшую дискуссию продолжать бесполезно - публикация утратила свою актуальность с выходом 8.3. Все перейдут и сниму публикацию. Уже вторая которая утратила актуальность, это радует - работают в 1С
54. hogik 437 04.07.12 16:34 Сейчас в теме
(52)
"спорить с вами без вариантов"(с)
Олег (comol).
Спорить с любым человеком "без вариантов", если собеседники не определились О ЧЕМ они спорят (разговаривают). Пожалуйста, перечитайте мою фразу (позицию, мнение) из (47) сообщения. И сравните со своими ответами. Темы обсуждения РАЗНЫЕ...
53. fishca 1191 04.07.12 10:37 Сейчас в теме
http://v8.1c.ru/overview/release_8_3_1/
теперь и в платформу включили данную возможность
55. seakuban 11 12.07.12 22:07 Сейчас в теме
Из партнерской базы знаний на сайте 1С:
----
Одно из важных нововведений SQL2005 является <версионность>, т.е <пишущие> транзакции НИКОГДА не блокируют <читающих> транзакций. Для этого достаточно выполнить <ALTER DATABASE xxx SET READ_COMMITTED_SNAPSHOT ON> и база данных превращается в "версионную". Это нововведение позволит забыть проблемы "блокировок по таймауту" с которыми наша компания встречается ежедневно в виде обратной связи от 30 одновременно работающих пользователей. Мы рискнули и развернули БД на SQL2005, но режим "версионности" не включали.
--
Вопрос: включение версионности БД решит нам проблему "блокировок по таймауту" или для полноценного использования этого нововведения Вам нужно делать изменения в платформе ?
---
Ответ:
Нет, включение версионности не изменит поведения платформы. Использовать "версионность" SQL2005 не планируется.
56. comol 4548 13.07.12 15:49 Сейчас в теме
(55) seakuban,
Ну всё правильно:
- проблему так называемых "блокировок по таймауту" (интересно что под этим имели ввиду) вам версионность не решит. Решит только исправление аппаратного девайса ("hands") программистов :).
- Включение версионности действительно не изменит поведения платформы. А если вдруг у вас ещё и автоматические блокировки, то в принципе ничего не изменит :).
57. seakuban 11 13.07.12 20:26 Сейчас в теме
название статьи - "Убираем блокировки" в 1С. Заставляем MS SQL работать как Oracle.
---
Цитата из текста статьи - "Включение уровня изоляции Read commited shapshot в MS SQL позволяет практически полностью избежать блокировок на уровне MS SQL при использовании управляемого режима"
--
Сопоставляем с (55) ... и?
58. comol 4548 15.07.12 18:12 Сейчас в теме
(57) seakuban, "Убираем блокировки" - значит делаем его версионником - там не блокировки, там "конфликт возврата ресурса" это называется вроде... так что с названием всё хорошо :))).

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

Естественно если deadlock-ов у вас нет, а есть timeout на ожидание то тогда нужно начинать конечно не с подобных статей... а с Чтения Дейта и Радченко :), а так же рассуждений о смысле жизни :)
59. seakuban 11 15.07.12 19:34 Сейчас в теме
(58)
Еще раз! Из ответа 1С разве не следует явно что поведение платформы не изменится? А значит блокировки (применительно к 1С) - останутся.

"В вашем случае опять же речь идёт о "взаимоблокировках". Потому как таймаут можно только так получить... " Хм, вы правда считаете, что блокировки могут быть только deadlock'овыми?))))) Неудачная попытка блокировки завершившаяся ввиду окончания выделенного таймаута - вполне обычная вещь в 1С 7.7, и вполне возможная в 1С 8.

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

И - это не у меня. Прочтите внимательно (55). Это из партнерского FAQ. Данный вопрос я не задавал.
60. comol 4548 16.07.12 12:24 Сейчас в теме
(59) seakuban, К сожалению трудно объяснить что-то когда вы не понимаете о чём речь в принципе. Человек который писал обращение на форум соответственно тоже не очень понимал что он спрашивал :). Блокировки бывают разные, некоторые зависят от платформы, некоторые нет... поэтому "поведение платформы не изменится" в сущности ни о чём не говорит

Самое интересное что на партнёрском форуме указанного сообщения не нашел :).

В 1С 7.7 конечно timeout без deadlock-а было нормальной ситуацией. Но в 1С 8 за такой таймаут нужно "руки программисту отрывать"... Я естествнно только про 1С 8 пишу, потому как 1С 7.7 система в сущности однопользовательская и ей "уже ничего не поможет" :).
65. Aleksey.Bochkov 21.09.12 16:56 Сейчас в теме
(55) seakuban, но в 8.3 все же реализовали поддержку этого режима..
цитата из C:/Program Files (x86)/1cv8/8.3.1.538/docs/ru/V8Update.htm

Работа с СУБД. Управляемые блокировки.
Как стало
При работе с Microsoft SQL Server версии 2005 и выше, используется режим управления версиями строк, если конфигурация использует режим управляемых блокировок. Используется уровень изоляции транзакций READ_COMMITED_SNAPSHOT. При чтении данных вне транзакций используется согласованное чтение.
Результат изменения
К уменьшению блокировок и взаимоблокировок при выполнении запросов, работающих в транзакции;
Исчезновению ошибок при выполнении запросов вне транзакции над часто модифицируемыми прикладными объектами;
Получению согласованных результатов отчета вне транзакции на момент выполнения отчета.
61. hogik 437 16.07.12 15:53 Сейчас в теме
(0)
"Хотел найти статью, которая бы объяснила чем отличается версионник от блокировочника, но как-то не сложилось."(с)

Опубликовано: 16.07.2004
Исправлено: 13.03.2005
http://www.rsdn.ru/article/db/yukonvers.xml
62. comol 4548 16.07.12 16:40 Сейчас в теме
63. comol 4548 16.07.12 16:47 Сейчас в теме
(61) hogik, Прямо так же в своё время проверял.. запросы. отладчик, sp_lock... вовремя бы попалась статья. было бы проще...

P.S. SQL Server 2005 оказывается Yukon называли :)
64. d_control 3 30.07.12 11:57 Сейчас в теме
Каким образом можно отключить работу версионника?
Обратным? или как-то иначе?
66. kilokilo 18 28.09.12 03:26 Сейчас в теме
Стоит добавить, что такой режим работы приводит к значительному повышению нагрузки на диск с tempdb.. и на загрузке процессора тоже сказывается.

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

В нашем случае - tempdb - нагрузка выросла в пиках до 2х раз.
Процессор стал грузиться на 20-30% больше (2процессора х 4ядра).

Средняя нагрузка на процессор была 35%, в пиках до 80% (среднее по минуте). Когда стало до 100% - стало невозможно работать..

На сервере - 4 основных базы (Зарплата, Документооборот, Бухгалтерия, Самописная - на базе бухгалтерии).
Основная нагрузка идет от документооборота (Екатеринбург, Документооборот-Проф).
Пользователей - до 150 одновременно..
67. comol 4548 28.09.12 09:00 Сейчас в теме
(66) kilokilo, Ну это не для кого не секрет... версионники всегда дают бОльшую нагрузку на железо... за удовольствие нужно платить... процессорное время очень дешевый ресурс. С дисками сложнее нагрузка на tempdb это вцелом "болезнь" 1С. Поэтому проще положить tempdb на IO accelerator и смириться :).
68. Slon1c 02.10.12 14:09 Сейчас в теме
неплохая статья...1с тоже на месте не стоит, а про такой режим еще в 2011 году на эксперте по тех.платформе задавались вопросы.
69. comol 4548 02.10.12 14:25 Сейчас в теме
(68) Slon1c, Собственно я и задавал :)... потом списывался... потом ещё на партнёрском народ тему поднимал, со ссылкой сюда. Видимо обратили наконец внимание.
70. Slon1c 02.10.12 15:37 Сейчас в теме
(69)Slon1c
Понятно "откуда ноги растут" :)
71. JohnyDeath 299 07.11.12 17:02 Сейчас в теме
В статье MSDN есть следующее:
Параметр READ_COMMITTED_SNAPSHOT должен быть выключен в базах данных tempdb, msdb и master.

У вас без этого всё получилось?
72. kilokilo 18 07.11.12 17:29 Сейчас в теме
(71) JohnyDeath,
Ну про tempdb - это и так можно додуматься :)

На самом деле, принципиально - это не важно - включен он там или нет - работать будет. Но работать будет медленнее - версионирование съедает дополнительные ресурсы. А толку от этого никакого не будет..

Там это не к чему, так как к временной таблице одновременно доступ имеет только один породивший таблицу артефакт/объект/запрос..
74. JohnyDeath 299 08.11.12 09:06 Сейчас в теме
(72), (73) Прочитав статью МСДН, мне подумалось, что это не будет работать вообще, пока не включен аналогичный режим в мастере и темдб
75. comol 4548 08.11.12 12:32 Сейчас в теме
(74) JohnyDeath, нее.. в tempdb по сути не нужно особо версионирование... в мастере точно не нужно... а в msdb по-моему если включите, то новые БД уже будут создаваться с версионированием... так что там можно включить...
73. comol 4548 07.11.12 18:01 Сейчас в теме
(71) JohnyDeath, особенно он важен в msdb и master :))). Да, получилось. Тупо запустил 2 отладчика в management studio и проверил, а то и самому не верилось сперва. Действительно считывает версию...
76. AlexO 130 08.11.12 12:41 Сейчас в теме
comol, что-то я не въ\ехал:
Убираем блокировки

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

Так а разница какая - что в первом случае 1С не догадалась изначально с рождением 8-ки пользовать управляемые блокировки?
Тогда причем тут "заставляем SQL работать как Oracle"? :)
77. comol 4548 08.11.12 13:17 Сейчас в теме
(76) AlexO, Я вопроса не понял... вообще версионник имеет смысл в 1С только при управляемых блокировках. При управляемых блокировках тоже есть транзакции и блокировки на уровне СУБД. Версионники при чтении внутри транзакций дают выигрышь...
78. AlexO 130 08.11.12 15:27 Сейчас в теме
(77)
вообще версионник имеет смысл в 1С только при управляемых блокировках

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

Так и кто будет переводить на управляемые блокировки конфы? :)
79. comol 4548 08.11.12 15:38 Сейчас в теме
(78) AlexO,

работа в 1С В ПРИНЦИПЕ возможна только при наличии каких-либо блокировок


Спасибо КЭП ;)

Так и кто будет переводить на управляемые блокировки конфы? :)


Вообще перевести на управляемые блокировки даже самую убогую конфу - дело нескольких дней максимум. Не говоря уже о том что все конфигурации 1С уже на управляемых блокировках
80. AlexO 130 08.11.12 16:25 Сейчас в теме
(79)
дело нескольких дней максимум

да? это как и перевод типовых на УФ - за неделю? :)
Не говоря уже о том что все конфигурации 1С уже на управляемых блокировках

Где?
Если вы про "управляемый режим" - так он и так включен в свойствах конфы, и, если не ошибаюсь, "включение уровня изоляции" как раз и есть эта галочка "Режим управления блокировкой данных", - т.е. вы предлагаете включить то, что и так "включено" в типовых?
Но, как я помню, управляемые блокировки потому и "управляемые", что управляет им не 1с-платформа (аналогии не напрашивается на слова "1с платформа не управляет..."?), а устанавливается для всех и каждого из объектов блокировка, прописывается РежимБлокировкиДанных, и отслеживается блокировка/разблокировка по всей стротгости закона всей конфе до самых до окраин.
Вот и спросил - кто сие делать будет? :)
85. comol 4548 09.11.12 09:46 Сейчас в теме
(80) AlexO, Без обид, но вам честно нужно чуть подробнее ознакомиться с предметной областью, которую мы пытаемся обсуждать...
- УФ никак не связаны с управляемыми блокировками
- Вы не совсем правильно понимаете разделение блокировок на блокировки СУБД и блокировки Сервера 1С. В случае управляемых блокировок существуют и те и другие
- Вы не совсем правильно понимаете смысл версионирования данных, и принципов его использования (в случае контроля остатков накладывается блокировка уровня сервера 1С и версионник не используется).
81. babys 83 08.11.12 16:57 Сейчас в теме
Всё ниже изложенное является моим ИМХО и не требует комментариев :)

1.
Заставляем MS SQL работать как Oracle
. Ну всё же низзя так сделать, ну не будет MS работать как Oracle, априори.

2. comol, всё что вы понаписали верно только отчасти, какой части, RTFM.

3. Не забываем параметры 1211 и 1224 MS SQL, и помним что эскалация блокировок существует не только для записи, но и для чтения.

4. Размер "locks" для эскалации блокировок неявно присутствующей на сервере 1С установлен равной 20000 записей. По крайней мере мне о другом не известно.
86. comol 4548 09.11.12 09:47 Сейчас в теме
(81) babys, Конечно не будет :). Просто если в названии статьи написать про версионник наверное было бы жестоко :)
83. KillHunter 7 08.11.12 18:22 Сейчас в теме
нормальная дискуссия, тока кто нибудь тестировал работоспособность базы, например при размере 200 ГБ, станет ли она быстрее работать?
84. babys 83 09.11.12 08:36 Сейчас в теме
(83) KillHunter, на чтении, а на записи ???? Дело в том, что автор пытается все существующие проблемы 1С и связки 1С+SQL переложить только на SQL. Возможно есть решение проблемы в переходе на 8.3?
87. comol 4548 09.11.12 09:51 Сейчас в теме
(83) KillHunter, "при правильном проектировании производительность решение не зависит от объёма базы". Могу только сказать что Dynamics Ax работает в этом режиме. Базы аксапты я видел и более 200 ГБ. У меня 80 Гб было с этим режимом... быстрее стало, но естественно только в тех разделах учета где массовое проведение...
88. ZLENKO 03.04.13 19:57 Сейчас в теме
Интересно какая будет ситуация в случае если конфигурация переведена на управляемый режим блокировок и база переведена в режим версионирования, управляемые блокировки явным образом в коде не устанавливаются:
1) Документ1 записывает данные в Регистр1
2) Документ2 читает данные из Регистра1
3) Документ1 записывает данные в Регистр2

На шаге 2) Документ2 получит данные из Регистра 1 с учетом движения Документ1 или нет ?
Т.к. неявная транзакция при проведении Документ1 еще не завершена...

Для меня было открытием что при базе MS SQL в режиме блокировочника на шаге 2 получаем ошибку блокировки, т.к. блокировка наложена записью в регистр Документом1. Я предполагал что блокировка будет снята после записи набора в Регистр1 и он будет доступен для чтения. Но я ошибался :-( Блокировка сохраняется до конца проведения документа, т.е. до окончания транзакции более верхнего уровня.

А еще больше огорчило что MS SQL накладывает блокировки по своему усмотрению и блокировки на уровне сервера приложений не возникает, а на уровне MS SQL возникает deadlock :-(

Вобщем режим версионника - единственный нормальный вариант повышения параллельности работы пользователей в 1С. В режиме блокировочника на практике проблема в принципе не решается :-( либо не получаем выигрыша либо еще хуже от дедлоков становится. Хотя в теории это возможно :-)
94. ZLENKO 06.04.13 08:49 Сейчас в теме
Автору статьи респект и уважуха. Даже не знаю что бы я делал без этой статьи...
96. ZLENKO 08.08.13 16:55 Сейчас в теме
Судя по "тишине" в комментариях проблемы с блокировками особо никого не "парят". Странно...
97. Yashazz 3737 14.08.13 18:20 Сейчас в теме
(96) Как показывает мой опыт, большинство "одинэснегов" при упоминании таких страшных слов, как Repeatable Read или Snapshot, делает круглые глаза и явно ничего не понимают. Им показали, как теперь надо делать, на курсах вдолбили, экзаменом проверили - вот и марш кропать управляемые блокировки с явным объявлением, в дело и не в дело.
98. ZLENKO 23.10.13 17:44 Сейчас в теме
(97) У меня сложилось впечатление, что на ИС есть всего несколько человек, которые не входят в это "большинство". Печально...
99. Алексей777 64 05.02.14 09:44 Сейчас в теме
Хочется спросить у ребят теоретиков, а на практике Вы ускоряли что-либо? Запускаю в работу 5-ть пользователей на проведение каждым из них всех документов за месяц по разным организациям в совершенно типовой 1С, платформа 8.2.16.362, УПП, у меня нет самописных управляемых блокировок - все типовое, Правда, база весит уже 20 гб, это mdf, включен режим Full - почти каждый документ при проведении у каждого пользователя выдает dead lock. И это нормально? Нет. Включаем предложенные автором режимы и все становится хорошо - люди работат могут.
Slikolia; timurhv; ZLENKO; +3 Ответить
Оставьте свое сообщение

См. также

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

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

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

30.10.2017    31244    MrWonder    42    

Решение нестандартных проблем производительности на реальных примерах

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

На екатеринбургском Infostart Meetup выступил с докладом архитектор ИС центра разработки ФТО Александр Криулин. Он поделился с коллегами кейсами нестандартных проблем производительности и рассказал о способах их решения.

24.03.2021    2792    AlexKriulin    36    

Долгое воспроизведение звука по RDP с удаленной машины

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

При воспроизведении короткого звука в 38 Кб, сигнализирующего об успешном сканировании, порою происходило подвисание примерно в 5 секунд.

09.02.2021    547    pashamak    2    

Highload-оптимизация 1С: теория и практика на примере консолидированной отчетности группы "Магнит" и розничной аптечной сети "Магнит"

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

Тема оптимизации 1С на больших данных бесконечная и всеобъемлющая, поскольку на производительность влияет целый ряд факторов – количество пользователей, данных, транзакций, неоптимальные запросы и т.д. Об инструментах для локализации проблем производительности и практических кейсах оптимизации рассказал Алексей Олейник, руководитель сектора автоматизации отчетности МСФО компании «Информационные технологии Магнит».

11.01.2021    15285    user662404_itlexusss    14    

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

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

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

22.04.2015    42316    Gilev.Vyacheslav    1    

Анализ блокировок СУБД: таблица изменений плана обмена 1С

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

Практический пример анализа типичной проблемы ожидания на блокировках СУБД, возникающих при использовании планов обмена 1С. Сервер СУБД: Microsoft SQL Server.

18.12.2020    2090    zhichkin    5    

Анализ проблем производительности по динамике мониторинга RAS 1C

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

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

07.10.2020    3991    ivanov660    12    

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

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

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    4633    Nykyanen    16    

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

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

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

22.01.2014    68278    yuraos    112    

Тест скорости работы мобильной платформы 1С

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

С помощью этого приложения вы можете измерить производительность своего устройства, используя для этого мобильную платформу 1С:Предприятие. Набор действий теста полностью повторяет аналогичный тест для стационарных ПК, поэтому результаты сравнимы.

14.09.2020    1541    capitan    25    

Описание почти всех событий технологического журнала

Технологический журнал v8 Бесплатно (free)

Краткое описание событий технологического журнала с примерами. Все для быстрого старта.

19.08.2020    16365    YPermitin    30    

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

Технологический журнал v8 1cv8.cf Бесплатно (free)

Корректируем классификацию ошибок ТЖ в процессе работы для конфигурации мониторинг производительности

17.08.2020    686    ivanov660    0    

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

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

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

21.06.2013    58270    Антон Ширяев    117    

SQL для 1С: пишем правильно, красиво, сложно

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

Многие программисты боятся работать с Null, считая, что от этих данных в запросах нужно избавляться. О том, как с помощью Null-полей в запросе решать востребованные в учете задачи по выборке данных, на конференции Infostart Event 2019 Inception рассказал ведущий разработчик ГК WiseAdvice Дмитрий Дудин.

14.08.2020    12324    dmurk    31    

Нестандартные блокировки при работе с OLAP-нагрузкой

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

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

20.07.2020    2341    Филин    7    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

В статье обсудим пример практической настройки конфигурации «Мониторинг производительности» для автоматической классификации ошибок по группам/кластерам на данных текстов описания ошибок. Используем механизм векторной модели текстов и косинусное сходство между ними.

25.06.2020    3333    ivanov660    13    

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

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

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

19.02.2013    57373    Gilev.Vyacheslav    46    

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

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

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

24.05.2020    9249    DataReducer    22    

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

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

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

18.05.2020    2433    Aleksey.Bochkov    4    

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

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

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

06.04.2020    13769    YPermitin    0    

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

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

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

11.02.2013    32333    gallam99    19    

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

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

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

03.04.2020    6297    feva    15    

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

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

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

31.03.2020    14697    informa1555    35    

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

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

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

31.03.2020    3470    vasilev2015    10    

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

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

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

03.11.2012    44956    madmpro    32    

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

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

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

20.03.2020    5996    vasilev2015    27    

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

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

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

18.03.2020    7975    kaliuzhnyi    44    

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

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

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

17.02.2020    12014    Evil Beaver    13    

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

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

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

23.01.2020    6974    darkdan77    59    

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

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

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

23.01.2020    9113    Kaval88    26    

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

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

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

19.12.2019    13577    ivanov660    20    

Весёлые картинки о работе 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    8246    EugeneSemyonov    11    

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

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

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

14.10.2019    19816    YPermitin    31    

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

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

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

13.09.2019    9653    Repich    5    

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

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

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

10.09.2019    20346    Sloth    30    

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

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

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

09.09.2019    9388    2tvad    17    

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

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

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

19.07.2019    9370    Филин    12    

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

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

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

16.07.2019    11219    fhqhelp    0    

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

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

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

02.07.2019    11992    igordynets    120    

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

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

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

27.06.2019    10350    YPermitin    17    

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

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

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

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

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

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

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

13.06.2019    13178    Repich    117    

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

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

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

13.06.2019    6143    slayer-ekb    10    

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

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

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

11.06.2019    27759    dmurk    146    

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

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

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

28.05.2019    22340    ivanov660    11