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

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

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

Блокировка дедлок взаимоблокировка запрос оптимизация неоптимальность производительность план исполнения система сбора и анализа информации по производительности работы баз данных Microsoft

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

 

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

Способ ловли был выбран следующий:  раз в десять секунд делаем снимок select * from master..sysprocesses во времянку, обрабатываем (оставляем инфу по blocked <>0 и процессам, которые сами не заблокированы, но фигурируют в blocked - источники блокировок, headblockers). Выходит что-то вроде //tf21.ru/public/193674/.

Ловля автоматических блокировок:

 

 
 пример раз - блокировка на исполняющемся запросе

 

Подготовка данных (в тестовой бд, или в tempdb)

CREATE TABLE _test(a int, b int, c int)

declare @i int = 0, @j int = 0

while @i < 120 begin

  set @j = 0

  while @j < 120 begin

    INSERT INTO _test(a, b, c) VALUES (@i, @j, 100)

    set @j = @j +1;

  end

  set @i = @i +1;

end


В первом окне запускаем

select count(distinct t1.a) from _test t1 with(updlock) inner join _test t2 on 1=1 inner join _test t3 on 1=1 option(maxdop 1)


Во втором окне запускаем (пока в первом запрос еще исполняется)

select count(distinct t1.a) from _test t1 with(updlock)


И в третьем окне мониторим наши блокировки запросом

select spid, sqltxt = cast(st2.text as varchar(max)), *

from

  master..sysprocesses sp

  left join master.sys.dm_exec_requests er

  on sp.spid = er.session_id

  outer apply sys.dm_exec_sql_text (er.sql_handle) st2

where

  sp.dbid = 2  -- если tempDB, иначе поменять

  and

   (0=1

      or ( sp.spid > 50 and sp.blocked not in (sp.spid,0) )

      or ( exists (select * from master..sysprocesses sp2 where sp2.blocked = sp.spid ) )

    )


Наблюдаем что-то похожее на


 

Видно, что сессия 53 блокирует сессию 54, видно текст блокирующего запроса, статус блокирующего запроса (runnable) и ожидание (SOS_SCHEDULER_YIELD - процессора не хватает, да еще и maxdop зажат). Ну и табличную блокировку видно (TAB) в tempDB (2)

Понятная и прозрачная ситуация.

 
 пример два - блокировка на спящем сеансе

Несколько видоизменяем первый пример

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

begin tran
   select sum(t1.a)  from _test t1 with(updlock) option(maxdop 1)
--commit tran

Во втором окне - все то же

select count(distinct t1.a)  from _test t1 with(updlock)

Выявляющий блокировки запрос в третьем окне теперь показывает что-то вроде

Не очень информативно - не видно исполнившийся запрос

Модифицируем выявляющий запрос вот так

select 
	sqltxt_pred = cast(st1.text as varchar(max)),
	sqltxt = cast(st2.text as varchar(max)), 
	*
from 
	master..sysprocesses sp 
	left join master.sys.dm_exec_requests er 
    on sp.spid = er.session_id
	outer apply sys.dm_exec_sql_text (sp.sql_handle)  st1
	outer apply sys.dm_exec_sql_text (er.sql_handle)   st2
where
	sp.dbid = 2 
	and
	(0=1
		or	( sp.spid > 50 and sp.blocked not in (sp.spid,0) )
		or	( exists (select * from master..sysprocesses sp2 where sp2.blocked = sp.spid )  )
	)

Теперь картинка гораздо информативней

 

 

Таким образом, из master..sysprocesses можно вытащить и текст исполняющегося в настоящий момент запроса, и текст всего пакета.

Собственно, примерно тоже самое можно сделать и с помощью DMV (most_recent_sql_handle в sys.dm_exec_connections и sql_handle sys.dm_exec_requests).

 

Но, задача была  не "следить непрерывно за консолью и при появлении блокировок выяснять - кто автор", а "анализ блокировок за период с ранжированием источников (headblockers)".

Значит, кроме фиксации spid, blocked,  sqltxt_pred, sqltxt требуется 
1. обработать текст запроса как в https://kb.1c.ru/articleView.jsp?id=76 (Листинг fn_GetSQLHash.. но предпочтительней делать на C# или C++, t-sql все же не лучший выбор для обработки строк)
2. собрать сведения из техжурнала 1С (событие <eq property="name" value="dbmssql"/>) и состыковать со снимками блокировок 

 
 примерно так

 Настройка ТЖ вида 

 <log history="2" location="D:\Server1C\logsLong">
        <event>
            <eq property="name" value="dbmssql"/>
            <gt property="duration" value="10000"/>
        </event>
        <property name="all"/>
    </log>

выдает файлы примерно такого содержимого:

00:16.1966-58122,DBMSSQL,3,process=rphost,p:processName=СклУпр,t:clientID=3208,t:applicationName=BackgroundJob,t:connectID=44967,SessionID=29950,Usr=Фоновое__Обмен,Trans=0,dbpid=457,Sql='INSERT INTO #tt13 (_Q_001_F_000RRef, _Q_001_F_001RRef) SELECT DISTINCT
T1._Reference5235_IDRRef,
T1._Fld6417RRef
FROM _Reference5236_VT6415 T1 WITH(NOLOCK)
WHERE T1._Fld6419 = 0x01',Rows=0,RowsAffected=68785,Context='
ОбщийМодуль.РегламентныеЗадания_Обмен.Модуль : 134 : Результат = ПолучитьРезультатВычисления(Выражение,,,СтруктураВозврата);
    ВнешняяОбработка.ВыполнениеКоманд.МодульОбъекта : 1022 : РезультатыЗапроса = ДанныеПоЗапросу.ВыполнитьПакет();'

Имя файла \\SERV1\Server1C\logsLong\rphost_565304\19062412.log

Для связи с конкретной строкой дерева блокировок берем: 

 - датувремя события (имя файла 19062412.log + первая строка 00:16.1966 = 2019.06.24 12:00:16 ) и  длительность 58122 (в данном случае это 5 секунд для 8.2, для 8.3 было бы в микросекундах) - дерево должно укладываться в период "датавремя - длительность" - "датавремя"

 - dbpid=457  - должно соответствовать spid = 457 (или session_id =  457 - если берем дерево не из sysprocesses, а запросом из DMV)

 - имя сервера 1С, с которого взят лог ТЖ (в примере это SERV1) - должно соответствовать hostname строки дерева

 - ID рабочего процесса (из rphost_565304 следует id = 565304)  - должно соответствовать hostprocess

 


3. записать снимок в бд - вместе с датой-временем снимка, текстом запроса и контекстом 1С

И далее просто написать запрос, группирующий по fn_GetSQLHash от текстов запросов (исполняющегося и предыдущего исполненного в данной сессии). И чем суммарно больше жертв - тем больше рейтинг источника блокировок (он же "headblocker", он же "виновник", он же "причина".. кто как обзывает)

Вот ссылка на реализацию (свежая версия - с ловлей блокировок)

 

Ниже на видео - самый простой случай - долго исполняющийся запрос.
Длительный сканирующий запрос заблокировал регламентное задание переиндексации, переиндексация заблокировала далее кучу сеансов (до 80 в пике)

 

//tf21.ru/upload/iblock/ac8/ac85c0adb5c12a26c1d28d1df809cbfb.gif

Подробней:

В верхней части указывается sql-сервер и период (26 апреля  от полуночи до 4 утра были проблемы на WorkSQL)

Первая таблица (выделено синим) содержит источники блокировок за указанный период на искомом сервере. Источники блокировок (headblockers) упорядочены по весу - сверху наиболее тяжелые. В качестве веса (выделено красным) - количество заблокированных сессий суммарно за период. Т.е. если за 4 часа зафиксировано три дерева блокировок, в которых одна сессия блокирует пять жертв - то вес у данного сочетания "sql исполнился = sql исполняется" (выделено оранжевым) равен 15. Отсюда можно примерно вычислить время простоя жертв суммарно (деревья фиксируются раз в 10 секунд - значит, время простоя жертв = 15*10 сек ).  Кнопка "заполнить подробно" (выделено зеленым) заполняет нижнюю таблицу - с уже конкретными деревьями блокировок (на удивление, в c# нет стандартного аналога "дерева значений" из 1С.. пришлось изобразить что-то похожее вручную). Деревья можно разворачивать и просматривать информацию о жертвах.

В данном случае видно, что все деревья начинаются с "Жукова Наталья" (позже нашел, что она запускала - запрос из консоли отчетов), она блокирует job переиндексации рабочей бд, переиндексация блокирует далее всех (ну, не всех - но многих).

Подобные проблемы излечиваются чаще оптимизацией длительных запросов (в инструменте реализован переход от дерева блокировки к плану запроса), реже разрывом или устранением транзакции (если явная) / выносом кода из транзакции проведения/записи,  еще реже  - если это сложные случаи вроде "блокировки через переиндексацию" - рассматриваются индивидуально. 

 
 отступление про переиндексацию (ALETR INDEX .. REBUILD / REORGANIZE)

1С просто и незатейливо советует sp_msforeachtable N'DBCC DBREINDEX (''?'')' (или уже есть более свежая статья?).  Microsoft настойчиво рекомендует схему "avg_fragmentation_in_percent > 5% and < = 30% - REORGANIZE, > 30% - REBUILD". На infostart.ru светится "10%-30%", "5%-30%"

И практически на всех рабочих серверах, кои мне доводилось видеть - работает то самое 5%-30% - в виде версии от Микрософт, или скрипты шведского товарища Ola Hallengren, или что-то самописное на том же принципе. Реже встречается  sp_msforeachtable. На тестовых серверах, как правило, чаще метод "мы забили на регламентное обслуживание".. 

Для мелких баз с хорошими технологическими окнами - Ola Hallengren самое то. Работает по ночам, есть не просит.
Но вот для террабайтных высоконагруженных, работающих "24/7/почти 365" - все далеко не так радужно.
Вот с  чем сталкивался:
 - Само обращение к sys.dm_db_index_physical_stats  даже с ''LIMITED'' - весьма неплохо съедает память (буферпул) sql-сервера. Далее возможны задержки непричастных запросов на физ чтениях, пока буферпул опять наполняется "нормальными" данными
 - Ошибки вида Msg 9002, The transaction log for database '...' is full due to 'ACTIVE_TRANSACTION'. - иной раз не лезет индекс в данное админом пространство под лог
 - Ошибки вида Msg 9002, The transaction log for database '...' is full due to 'LOG_BACKUP' - и, соответственно, реплики на резервных серверах могут становиться сильно неактуальными... Даже без данных завалов из-за массивных переиндексаций может быть отставание реплик в AlwaysOn

 - И, самое болезненное - собственно, блокировки на REBUILD.  Особенно для редакций Standart  - нет with(online = on) и тем более WAIT_AT_LOW_PRIORITY, сам ребилд идет в один поток (и коль заблокирует кого - то надолго). И даже в версии Enterprise с with(online = on) - блокировки все равно в наличии! Будили ночью, любовался. Собственно, в документации оно вполне отражено.  

Обычный сценарий блокировок под для Standart - некий кривоватый запрос (даже вне транзакции, с хинтами with(nolock)) блокирует alter index..rebuild , далее alter index блокирует всех.  Пробовал бороться с теми самыми "кривоватыми запросами" - легион их. Пробовал писать джоб, убивающий "кривоватые запросы", мешающие переиндексации - работает.. но однажды оно убило весьма важный процесс - отключил. Перенастроил джоб для "самых важных баз", чтобы он убивал саму реиндексацию - аналог WAIT_AT_LOW_PRIORITY ( MAX_DURATION = 1 MINUTES, ABORT_AFTER_WAIT = SELF ) - работает... но, понятное дело - не идеал.

Т.е. стандартная модель переиндексации понемногу перестает устраивать. 
Вот и Brent Ozar еще в 2012 сомневался  - а тогда еще не было широкого распространения ssd.
В настоящий момент думаю в сторону "реиндексации того, что в текущий момент сидит в оперативке (в буферпуле) - с целью минимизации размера индекса (и память освободим, и чтений меньше)".. также понемногу задираю пороги ("5-30" веду к "40-50") и отслеживаю изменение скорости типовых  запросов - посмотрим, что будет..

Опять-таки, Микрософт тоже ощущает, видимо, данную проблему.. Появление WAIT_AT_LOW_PRIORITY в MS SQL Server 2014 и RESUMABLE=ON в MS SQL Server 2017 как бы намекает. Жаль только, что все это не для standart (enterprise дорогой и в наличии далеко не на всех серверах). 

 

 

 

 

Случай посложнее - когда блокировка висит на спящей сессии (поле "sql исполняется" пустое).

Сделан искусственно кодом 

НачатьТранзакцию();
запрос = Новый Запрос;    
запрос.Текст = " ВЫБРАТЬ С.Ссылка ИЗ Документ.СборкаПродукции КАК С ГДЕ С.Дата > &Дата ДЛЯ ИЗМЕНЕНИЯ Документ.СборкаПродукции";
запрос.УстановитьПараметр("Дата", ТекущаяДата()-60*60*2);
рез = запрос.Выполнить();
выборка = рез.Выбрать();
Предупреждение("ждем.."); 
ОтменитьТранзакцию();

По REPEATABLEREAD видно, что конфигурация в автоматическом режиме, ДЛЯ ИЗМЕНЕНИЯ трансформировалось в UPDLOCK.

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

Чего только не находилось за последние несколько лет в транзакциях проведения документов или записи набора регистров:

  - Предупреждение() или Вопрос() - это самое любимое

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

  - разнообразные файловые операции

  - обращения к другим базам через com-объекты

  - обращения к другим базам посредством Новый COMОбъект("ADODB.Connection")  (ага, а на соседнем сервере уже запрос через то самое ADODB... тоже висит на блокировке! и такое было..) 

 - работа с ftp

 - обращение к web-сервису

 - запуск на исполнение сторонних программ

  

Отдельно стоит упомянуть эскалацию блокировок на уровне sql-сервера. Неважно, на спящей или на running/runable сессии возникли блокировки - стоит смотреть на поле waitresource (или wait_resource из sys.dm_exec_requests).  Если там TAB: (Object()) - то скорее всего мы нарвались на эскалацию. Чаще всеж стоит поправить прочитавший таблицу запрос - с большой  вероятностью он кривой и сканирующий .. но иногда можно и выключить эскалацию на уровне таблицы. Если будете выключать - это небезопасно, пару раз у меня вылезала нехватка оперативки для sql-сервера при реструктуризации такой таблицы (саму идею эскалации ведь не просто так придумали).

 

 

Итого.

По сообщениям пользователей вида "мы зависли" определялось наличие/отсутствие деревьев блокировок, при наличии - почти всегда обнаруживалась явная причина. И устранялась. Плюс еженедельно просмотр статистики по блокировкам за 7 дней + тоже поиск причин и устранение. И так несколько лет.

В итоге получилось, что несколько конфигураций в автоматическом режиме работают "почти нормально", "почти без блокировок", но есть несколько "но":

 - куча случаев вида "запрос к небольшой табличке внезапно стал сканирующим и блокирующим".. и отладить всю эту мелочь - никакого времени не хватит.

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

 - много программистов непрерывно добавляют новый / модифицируют старый код, стоит ошибиться в запросе - любом запросе - в транзакции популярного (часто проводимого) документа - и имеем коллапс рабочей бд (да, нагрузочное тестирование релизов - хорошая идея, но его почти нет)

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

 

 

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

Второстепенные бд так и перевели.

Основная база данных, надо отметить, уже к тому моменту подбиралась ко второму терабайту и тысяче пользователей, и работала "почти 24"/7.

Споткнулись уже на первом пункте. Остановить разработку нельзя, и точка. Много времени разработчиков потратить на переход в управляемый режим - тоже нельзя. "Потихоньку, в свободное от срочного/важного время".

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

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

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

Нет, мы "перед тем, как" все протестировали, даже с подобием нагрузочного теста (как оказалось позже - подобие было "не очень")

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

Если точнее - источниками блокировок были спящие (sleeping) после выполнения запросов вида 

SELECT T1._Период, T1._UseTotals, T1._ActualПериод, T1._UseSplitter, T1._MinПериод
FROM _РегистрНакопления.ОстаткиТоваров(НастройкиХраненияИтоговРегистраНакопления) T1
WHERE T1._RegСсылка = @P1

А технологический журнал, с предусмотрительно настроенным 

<log location="C:\LOGS\TLOCKS" history="4">
  <event>
      <eq property="Name" value="TLOCK"/>
      <gt property="duration" value="5000"/>
  </event>
  <event>
      <eq property="Name" value="TTIMEOUT"/>
  </event>
  <event>
      <eq property="Name" value="TDEADLOCK"/>
  </event>
   <property name="all"/>
</log>

в итоге выдавал по тем спящим сессиям  либо длительный TLOCK, либо TTIMEOUT

 
 откуда взял, что именно "по тем спящим сессиям"?

Каждые десять секунд - обращение к рабочему кластеру 1С через V83.COMConnector и запись снимка сеансов рабочей бд "консоли серверов 1С" в sql-базу. Таким образом, можно связать session_id на sql=сервере с сеансом, соединением и пользователем рабочей бд. Понятное дело, если соединение с субд висело достаточно долго.  

Есть еще один способ связать session_id с сеансом/соединением, но он опасен и детально не исследован, и про него я, пожалуй, здесь не напишу.

Т.е. первая сессия блокировала вторую на уровне sql-сервера, а вторая блокировала первую на уровне 1С-сервера управляемой блокировкой. Управляемые  блокировки в первой итерации мы не добавляли, это были .. управляемые блокировки при записи наборов регистров.

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

 

Соответственно, для нормального разбора проблем фиксацию деревьев блокировок надо модернизировать - добавив управляемые блокировки из техжурнала. Рядом с полем blocked сделать поле blocked_by_ls, и перестроить дерево с его учетом. Если вы имеете в бд снимок блокировок на уровне sql-сервера, снимок сеансов нужной базы из "консоли серверов 1С" и загруженные в sql-таблицу файлы техжурнала с TLOCK - то это возможно. Не сказать, что точность получается идеальная - но для работы вполне хватает. 

Ниже иллюстрация подобной ситуации (не связанная непосредственно с началом перехода в "автоматический и управляемый" - тех картинок уж нет, увы..):

 
 картинка с ресурсами и видео

 

 

Говорова Светлана запускала "очень важную обработку" и "висела и вылетала" - ниже видно, в чем было дело.

 

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

А далее.. планомерный пообъектный перевод.

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

Далее берем регистр Б... в документах, которых двигают только А и Б - можно менять режим.. И до победного конца.

Процесс при этом может занимать годы.

 

А что же потом?

В полностью управляемом режиме блокировки на уровне sql-сервера (даже в read committed snapshot) не исчезают на 100%.  Так что непрерывный мониторинг необходимо продолжать.  Пишите свою систему, используйте сервис Гилева или ПерфЭксперт, или мою систему.

 

 
 а что есть кроме фиксации моментальных снимков деревьев блокировок?

 1. как минимум System Monitor и счетчик  SQL Server: Locks \ Average Wait Time (ms)

 2. eXtended Events и событие blocked_process_report - если есть возможность менять настройки sql-сервера ( blocked process threshold ).. более точная штука, чем деревья, но есть пара отрицательный момент.. блокировки ловит отлично, но деревья предоставляют кое-какие возможности и помимо ловли блокировок. пока расшифровывать не буду.

 3. eXtended Events и событие Lock:Acquired - покажет, на каких таблицах и у каких пользователей были проблемы. Но вытащит источники блокировок отсюда сложно. Данные за период такой трассы очень хорошо коррелируют с данными в деревьях блокировок.

дополняйте..

 

 

 

 

38

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

Избранное Подписка Сортировка: Древо
В этой теме еще нет сообщений.
Оставьте свое сообщение

См. также

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

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

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

22.10.2019    2642    EugeneSemyonov    10       

Перенос данных УПП 1.3 => ERP 2 (ЕРП) / УТ 11 / КА 2.х (обработка переноса документов, остатков и справочников из "1С:Управление производственным предприятием, ред. 1.3" в ERP / УТ 11 / КА 2). Обновлен до УПП 1.3.127.х, КА 2.4.10.х и ERP 2.4.10.х! Промо

Обработка позволяет переносить из УПП 1.3 в ERP 2 документы за выбранный период и остатки. Типовая обработка от фирмы 1С документы не переносит. Также исправлены ошибки типовой обработки. При выходе новых релизов обновление высылается бесплатно в течение года. Разработка будет полезна фирмам-франчайзи, которые периодически выполняют такой перенос данных для заказчиков. Вы можете один раз приобрести обработку переноса, и потом бесплатно получать обновления при выходе новых релизов конфигураций 1С.

29700 руб.

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

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование данных 1С

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

13.09.2019    4595    Repich    4       

1С:Предприятие через Интернет. 1С:Fresh Промо

Ведение бухгалтерского и налогового учет, сдача отчетности, управление бизнесом из любой точки мира. Привычные программы «1С» через Интернет без приобретения коробочных программ.

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

Статья Системный администратор Программист Нет файла v8 Linux Бесплатно (free) Администрирование данных 1С Zabbix

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

10.09.2019    9070    Sloth    11       

Перенос документов и справочников ERP 2 / КА 2 / УТ 11 => БП 3.0 Промо

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

19700 руб.

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

Отчеты и формы Системный администратор Программист Внешний отчет (ert,erf) v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

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

31.08.2019    4129    93    YPermitin    7       

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

Статья Программист Нет файла v8 Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

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

19.07.2019    5053    Филин    12       

Cashback 35% при покупке 1С лицензий на счет INFOSTART.RU с 27.11 по 04.12 Промо

Оформляете заказ на 1С лицензии или конфигурации. Получаете 35% от стоимости на счет в профиле INFOSTART.RU. Выбираете сервисы и продукты на сумму кэшбэка.

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

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

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

02.07.2019    6830    igordynets    119       

Онлайн-интенсив "Бизнес-процессы для подготовки к экзамену 1С:Специалист по платформе" 12 декабря 2019 г. Промо

На интенсиве будут рассмотрены все теоретические вопросы, связанные с устройством механизма бизнес-процессов – это необходимо для успешной сдачи экзамена 1С:Специалист по платформе. Также, в качестве практического примера, будет решена задача, аналогичная экзаменационной.

777 рублей

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

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

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

27.06.2019    5661    YPermitin    16       

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

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

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

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

Новый раздел на Инфостарте - Electronic Software Distribution Промо

Инфостарт напоминает: на нашем сайте можно купить не только ПО, связанное с 1С. В нашем арсенале – ESD-лицензии на ПО от ведущих вендоров: Microsoft, Kaspersky, ESET, Dr.Web, Аскон и другие.

  • Низкие цены, без скрытых платежей и наценок
  • Оперативная отгрузка
  • Возможность оплаты с личного счета (кешбек, обмен стартмани на рубли и т.п.)
  • Покупки идут в накопления для получения скидочных карт лояльности Silver (5%) и Gold (10%)

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

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

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

13.06.2019    8364    Repich    117       

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

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

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

13.06.2019    3271    slayer-ekb    10       

Подборка программ для взаимодействия с ЕГАИС Промо

ЕГАИС (Единая государственная автоматизированная информационная система) - автоматизированная система, предназначенная для государственного контроля за объёмом производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции. Инфостарт рекомендует подборку проверенных решений для взаимодействия с системой.

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

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

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

28.05.2019    9366    ivanov660    5       

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

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

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

21.05.2019    5120    vasilev2015    21       

1СПАРК РИСКИ. Сервис оценки благонадежности контрагентов. Промо

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

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

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

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

20.05.2019    4482    zhichkin    15       

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

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

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

29.04.2019    14672    comol    198       

Готовые переносы данных из различных конфигураций 1C Промо

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

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

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

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

26.04.2019    11273    kuzyara    12       

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

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

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

25.04.2019    9299    Elf1k    27       

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

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

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

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

18.04.2019    19790    ivanov660    68       

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

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

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

06.04.2019    10092    YPermitin    29       

Очный семинар по регулярному менеджменту Александра Фридмана "Вы или Хаос", 12 декабря 2019 г. , Санкт-Петербург Промо

Семинар по регулярному менеджменту от Александра Фридмана для собственников, первых лиц и топов. Технология управленческого планирования, комплексного управления временем и другими ресурсами, выполнением поручений, делами, информацией, контактами (встречи-звонки-почта).

от 11000 до 29000 рублей

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

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

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

18.03.2019    10902    w.r.    23       

Простое программное решение проблем с блокировками SQL 17

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

Описание одного из способов программного решения проблемы блокировок при проведении документов в клиент-серверной 1С.

06.03.2019    6628    dmitrydemenew    38       

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

Производительность сервера 1С и фоновые задания 63

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

В падении производительности сервера 1С зачастую виноваты не регламентные / фоновые задания, они выполняют полезную работу. Но задания нельзя оставлять «наедине» с базой.

05.02.2019    11939    user715208    38