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

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

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

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

Кто мы и что мы делаем?

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

Кроме того, у нас есть несколько патентованных решений, работающих в связке с MS SQL и 1С.  Это распределение нагрузки между несколькими серверами и СУБД, ускорение запросов на лету, онлайн-репликация с минимальной задержкой, в том числе и «active-active» (когда в обеих базах можно изменять данные и проводить документы). То есть, мы немножко разбираемся в том, как работает 1С и как работает MS SQL.

Часто мы видим какие-то странные вещи, какие-то необъяснимые ситуации. О паре таких вещей и о том, что из этого следует, хотелось бы сегодня рассказать.

Распределенные взаимоблокировки

Немного определений. Что такое взаимоблокировка?

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

Дедлок или взаимоблокировка – это «уроборос» из транзакций, закольцованная блокировка.

 

 

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

 

 

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

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

 

 

Как я сказал, и MS SQL, и 1С умеет определять взаимоблокировки. SQL умеет нам показывать вот такие красивые графы.

 

 

Здесь видны и ресурсы, и кого в итоге оборвали. И в принципе удобно в этом разбираться. 1С тоже не отстаёт. Если мы включаем технологический журнал, у нас там есть специальное событие TDEADLOCK. Мы тоже видим дедлоки, поэтому можем в принципе раскрутить. 

 

 

Мы в своей работе используем нашу систему PerfExpert, которая показывает блокировки и дедлоки в виде “графов” или “деревьев”. Расскажу, как это работает.

 

 

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

Необычный инцидент

Однажды я расследовал сложный инцидент, странные блокировки. Выглядело это примерно также – как какое-то огромное дерево ожиданий. Проблема в том, что блокировки были долгими, длились минутами и непонятно из-за чего. Причем эта условная блокирующая «120-ая сессия» даже процессор не использовала, ничего не делала. Что-то странное происходило.

 

 

В какой-то момент я сопоставил данные 1С и SQL. На слайде в верхней части показаны данные по SQL. Это сессии, которые в данный момент работали. Внизу – те же самые сессии с точки зрения 1С. Вверху мы видим номера подключений SPID, внизу те же самые SPID’ы. То есть это одни и те же пользователи на 1С и на SQL, но с разных точек зрения.

 

 

По сути, это одно и то же, но что мы здесь видим? У нас есть 79-ая сессия, которая блокирует 152 на уровне SQL. А если мы посмотрим на 1С, мы увидим, что все ровно наоборот: 79 ждет 152. Вот и дедлок. Но он у нас развалился на две части. Одна половина дедлока произошла на SQL, а вторая половина – на 1С.

Ни одна из систем – ни 1С, ни SQL – не понимает, что это дедлок. Каждая из них думает, что это просто обычное ожидание. И мы не увидим ни красивого графа в xml, ни события TDEADLOCK в техжурнале.

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

Почему такие взаимоблокировки случаются? 

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

Первый вариант – мы просто забыли наложить управляемую блокировку. Это больше актуально для старых конфигураций, начиная с 8.0, которые давно и долго переделывались, и в какой-то момент переписывались под управляемые блокировки. Конечно, есть guidelines (руководства), но остаются нюансы, про которые все забывают.

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

  1. Мы сразу удаляем движение, накладываем блокировку на SQL, все работает нормально. 

  2. Параллельно у нас проводится другой документ (красная транзакция). Он проводится по всем правилам, то есть там программист накладывает управляемую блокировку, пытается записать данные и попадает на блокировку на уровне сиквела. Ждем. 

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

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

 

 

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

Поехали! 

  1. Проводим первый документ из нашего файлообмена. Накладываем управляемую блокировку. 

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

  3. Первый документ из обмена пишет данные в SQL. И в этот момент у нас возникает эскалация блокировок. 

Что такое эскалация? Есть такой механизм в SQL server: когда сиквел видит большое число блокировок или когда ему не хватает памяти для блокировок, он принимает решение о том, что вместо того, чтобы управлять большим роем каких-то мелких страничных единичных блокировок, он может взять одну большую, но на всю таблицу. (В документации механизм подробно описан в старой статье и вскользь упоминается в более актуальной версии)

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

Итак, мы попадаем на эскалацию блокировок. Синяя транзакция у нас записывает документ. Она не знает о том, что у нас заблокируется таблица, ей все равно. Она записала, пошла дальше. Красная сессия пытается записать данные, попадает на заблокированную таблицу, ждет. Пока еще ничего страшного. 

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

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

 

 

Что делать?

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

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

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

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

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

Предел аппаратных ресурсов

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

Какой самый простой и быстрый выход из ситуации? Всегда можно попытаться откупиться от этого запроса железом. То есть покупаем ssd, добавляем оперативной памяти, процессоров, ядер, частоты. В принципе это понятно, потому что облака уже не то что на пороге стоят, они уже давно по-хозяйски сидят в гостинной, они уже везде. И вместо того, чтобы следить 2 часа за программистом и потом ждать окна для обновления конфигурации, гораздо проще и быстрее кликом мышки накинуть еще 100 гигабайт оперативной памяти и потом пытаться не вспоминать, какой счет придет за хостинг.

Собственно, первая реакция была – нарастить железо. Но потом мы схватились за калькулятор и начали считать, но не цены, а байты. И что мы видим?

У нас есть 392 миллиона чтений, а сиквел читает данные всегда по 8 килобайт, страницами. То есть 392 миллиона чтений это почти 3 терабайта данных.

 

 

Смотрим дальше. У нас на проблемном сервере стояла память DDR3. Читаем её спецификации: эта память может дать максимальный поток 19 гигабайт в секунду, это предел шины.

 

 

Берем калькулятор, делим 3 терабайта на 19 гигабайт и получаем те самые 2,6 минуты. Это то, что мы и видели. Получается, сколько сейчас не добавляй ssd, оперативки, чего-то ещё, мы нисколько этот поток не ускорим. Мы уперлись в потолок.

 

 

Еще одна плохая новость, что этот предел, 19 гигабайт, эта шина делится на всех. И даже если одному пользователю повезло, и он захватил всю шину, и он ждет 2,6 минуты вместо 10, как обычно, это просто означает, что эти 2,6 минуты все остальные пользователи ждут, пока он освободит шину. Они вообще ничего делать не могут. То есть страдают все.

И единственный выход, поскольку железо не поможет, – надо ждать программистов и оптимизировать запрос. Другого выхода здесь нет. Так – при помощи трассы и калькулятора и без вкладывания денег в железо – мы заранее поняли, что нужно сразу переходить к оптимизации.

Что объединяет эти два кейса?

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

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

 

 

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

Спецификации DDR3 SDRAM взяты в Википедии https://ru.wikipedia.org/wiki/DDR3_SDRAM

В презентации использовались иконки www.flaticon.com  (CC-BY 3.0)

**************************************************************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2018 EDUCATION. Больше статей можно прочитать здесь.

Приглашаем вас на новую конференцию INFOSTART EVENT 2019!

50

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

Комментарии
Избранное Подписка Сортировка: Древо
1. capitan 1338 19.07.19 17:51 Сейчас в теме
Надеюсь что не скоро достигну предела DDR3 SDRAM )
А так все логично- Порядок бьёт класс
Отличное подтверждение этой фразы.
Если писать код изначально хорошо, можно на многие грабли и не наступать
Интересно что при поиске англоязычного эквивалента Порядок бьёт класс выводится
Football is a simple game; 22 men chase a ball for 90 minutes and at the end, the Germans win.
)
2. Repich 361 19.07.19 22:13 Сейчас в теме
Странно, мне даже в голову не приходило оптимизировать запрос увеличением железа не посмотрев сначала на код.
Fox-trot; +1 Ответить
8. Филин 115 22.07.19 10:21 Сейчас в теме
(2) Ну я и не говорил, что заливать проблему железом -- правильный путь.

Да и вообще смысл этого случая -- не показать, как ловко можно оперативкой ускорить плохой запрос, а наоборот, продемонстрировать предел такой "оптимизации"
A_Max; gallam99; +2 Ответить
3. acanta 75 19.07.19 23:21 Сейчас в теме
Добавление памяти решает проблему объединения доработанных конфигураций.
Если около часа идёт только сравнение метаданных, а тестирование базы проходит за 20-25 минут, то какие могут быть претензии к СУБД ? Это даже близко не хайлоад.
Только неумение дорабатывать конфигурации вероятно.
Конфигурации с расширениями надеюсь менее требовательны к железу.
4. YPermitin 6341 20.07.19 12:32 Сейчас в теме
(0) Отличный доклад и статья. +
5. Dach 284 20.07.19 16:57 Сейчас в теме
Прошу прояснить и уточнить терминологию в статье:

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


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

Еще, в том же духе:

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


Что значит "не закрыл"? Как надо "закрывать"? О чем речь? Надо ли "закрывать", если у документа свойство "Удаление движений = удалять автоматически при отмене проведения"? Вот честно, с 1С уже много лет работаю, ни разу никакую отмену проведения дополнительными блокировками "закрывать" не приходилось.

Я то смысл понял на самом деле и звучит он так:

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

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

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

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

Ну и насчет неочевидности.

Вот прекрасная статья: https://infostart.ru/public/202199/

Автор - издатель известного курса по оптимизации производительности.

Так что про "закрывать" непонятно.
7. Филин 115 22.07.19 10:19 Сейчас в теме
(5)
Прошу прояснить и уточнить терминологию в статье:


Ок, по пунктам:

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

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

что значит, "не закрыл"?
-- значит, не убедился, что управляемая блокировка будет установлена (им самим или платформой)

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

Надо ли закрывать если у документа свойство <...>
--см. выше, закрывать не надо, но помнить, про то, что управляемая блокировка есть, необходимо.

ни разу никакую отмену проведения дополнительными блокировками "закрывать" не приходилось
-- я тоже видел такие ситуации от силы пару раз. Именно поэтому доклад называется "неочевидные проблемы" и именно поэтому хотелось рассказать о любопытном случае, чтобы коллеги потом меньше ломали голову.
6. PerlAmutor 47 20.07.19 18:34 Сейчас в теме
Сколько не расследовал причин тормозов и долгого выполнения чего-то - в большинстве случаев виновником был 1С (платформа, кривой код программистов 1С). Памяти не хватало по причине утечек памяти из-за цикличных ссылок в той же БСП, в самой платформе. В раздутых метаданных ролей. Дорогущий сервер - постоянно "холодный", а работа идет со скрипом.

Кстати сам SQL сервер от Microsoft тоже сюрпризы приподносит. Простая ситуация - в базе одна... база. Есть процедура использующая CTE и временные таблицы. Из таблицы в 1 млн строк - создает таблицу на 30 млн строк. Ограничение по памяти выставлено в 30Гб. Первый запуск процедуры выполняется 30 минут и заполняет память до 25Гб. Второй запуск процедуры (после удаления всего что она нагенерила) - 5 часов. Память SQL сервером не освобождается. Если после каждого запуска процедуры перезапускать SQL сервер, то процедура всегда выполняется за 30 минут (чистка процедурного кэша, обновление статистики не помогает, добавление индексов к таблице усугубляет ситуацию еще больше)...

Был один случай недавно. Пользователи Windows XP жаловались на долгий запуск 1С, который долгим стал после перехода на новую платформу. Первая мысль - если XP, значит мало ресурсов, значит слабые компьютеры, надо модернизировать. Вторая мысль - но раньше у них проблем ведь не было?

Причина оказалось в том, что админы порезали прохождение пакетов протокола SMB1 (netbios), чтобы предотвратить распространение вируса типа WannaCry. А ходить пакеты перестали именно в ту подсеть, где располагался новый сервер под новую платформу. В XP в этом случае идет 2-х минутная задержка, после чего идет использование другого протокола (более защищенного). Выяснилось все это только с помощью настроенного ТЖ на стороне клиента. С другими программами на той же машине таких проблем нет. Стало быть дело в механизме создания защищенного соединения на стороне 1С.
user890287; +1 Ответить
9. Филин 115 22.07.19 10:27 Сейчас в теме
(6) Мой опыт как минимум 6 последних лет работы в Софтпоинт с обращениями заказчиков говорит о том, что проблемы могут быть где угодно -- и на 1С, и на СУБД, и на уровне железа... И ваш последний пример отлично это иллюстрирует (и, кстати, ложится в тему статьи). Действительно, первая реакция в таком случае -- это обвинить во всех проблемах обновленную платформу. Хотя более глубокая причина лежит в другой плоскости, в настройках сети.
10. PerlAmutor 47 22.07.19 18:48 Сейчас в теме
(9) Только это не проблема сети, а то как ведет себя 1С при таких настройках, с другим софтом проблем нет.
Вот еще один пример - есть виртуалка на Hyper-V, в момент снятия бэкапа средствами Volume Shadow Copy возникают проблемы с таймаутом на драйвере диска. При этом менеджер кластера - зависает совсем не надолго. Агент кластера видит, что завис менеджер кластера и его.... убивает. При этом 1С не предоставляет никаких настроек для увеличения времени ожидания отклика менеджера и т.д. Другой софт реагирует адекватно, ничего не падает и не завершается.
11. YanSergey 23.07.19 16:56 Сейчас в теме
(10)
При этом 1С не предоставляет никаких настроек для увеличения времени ожидания отклика менеджера и т.д



Есть настройки запуска службы агента, которые вероятно Вам помогут, посмотрите

https://its.1c.ru/db/v8311doc#bookmark:cs:TI000000119

/pingPeriod <время> /pingTimeout <время>
12. PerlAmutor 47 23.07.19 22:20 Сейчас в теме
(11) Эта настройка работает только для рабочих процессов, агент сервера (ragent) не пытается пинговать менеджер клстера (rmngr), а просто его убивает, если тот решил "подвиснуть" на пару секунд. Настройка pingTimeout уже давно стоит и суммарное время там больше минуты. Не действует она на менеджер, хоть тресни.
Оставьте свое сообщение

См. также

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

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

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

19700 руб.

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

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

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

13.09.2019    4590    Repich    4       

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

Перенос позволяет загрузить в УТ 11 / КА 2 / ERP 2 документы за выбранный период, справочную информацию и остатки по счетам бух. учета. Переносятся остатки денежных средств, взаиморасчетов, остатки товаров и материалов на складах. Переносятся девятнадцать основных видов документов за выбранный период и вся нормативно-справочная информация. Есть фильтр по организации. Если нужно переносить что-то дополнительно, то обычно бесплатно дорабатываю правила (перед покупкой согласуйте необходимые доработки).

29700 руб.

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

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

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

10.09.2019    9044    Sloth    11       

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

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

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

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

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

31.08.2019    4095    93    YPermitin    7       

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

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

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

16.07.2019    4570    fhqhelp    0       

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

Переносятся документы за выбранный период, справочная информация и остатки по счетам бух. учета в программу УТ 11 / КА 2 / ЕРП 2 (ERP). Переносятся все возможные виды операций ввода остатков на нужную дату. Есть отбор по периоду переноса документов и фильтр по организации, доступен выбор даты ввода остатков. Если нужно переносить что-то дополнительно, то обычно бесплатно добавляем это в перенос . Смотрите видеодемонстрацию со звуком - советами по переносу и рекомендациями настройки программ.

29700 руб.

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

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

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

02.07.2019    6824    igordynets    119       

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

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

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

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

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

27.06.2019    5634    YPermitin    16       

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

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

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

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

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

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

777 рублей

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

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

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

13.06.2019    8357    Repich    117       

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

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

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

13.06.2019    3265    slayer-ekb    10       

Вакансия Программист, аналитик, эксперт 1С Промо

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

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

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

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

28.05.2019    9339    ivanov660    5       

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

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

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

21.05.2019    5109    vasilev2015    21       

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

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

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

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

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

20.05.2019    4470    zhichkin    15       

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

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

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

29.04.2019    14664    comol    198       

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

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

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

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

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

26.04.2019    11271    kuzyara    12       

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

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

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

25.04.2019    9290    Elf1k    27       

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

Уже более 100 компаний приобрели перенос и выполнили переход на УТ 11 / КА 2 / ERP 2 с помощью нашей разработки! Обработка перехода с УТ 10.3 на УТ 11 / КА 2 / ERP 2 позволяет перенести не только остатки на указанную дату (как типовой перенос), но и все возможные документы за выбранный период. При выходе новых релизов этих программ оперативно выпускаем обновление обработки. Предоставляем техническую поддержку. Можем сделать бесплатный тестовый перенос!

29700 руб.

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

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

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

18.04.2019    19781    ivanov660    68       

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

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

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

06.04.2019    10076    YPermitin    29       

Перенос данных КА 1.1 => ERP 2 (ЕРП) (обработка переноса документов, остатков и справочной информации из "1С:Комплексная автоматизация, ред. 1.1" в "1С:ERP Управление предприятием, ред 2"). Обновлен до КА 1.1.115.х и ERP 2.4.10.х Промо

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

29700 руб.

Как одно изменение конфигурации 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    10893    w.r.    23       

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

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

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

06.03.2019    6620    dmitrydemenew    38       

Перенос данных КА 1.1 / УПП 1.3 => БП 3.0 (перенос остатков, документов и справочников из "1С:Комплексная автоматизация 1.1" / УПП 1.3 в "1С:Бухгалтерия 3.0"). Обновлен до версий КА 1.1.115.х, УПП 1.3.127.х! Промо

Разработка позволяет перенести остатки по всем счетам бух.учета в программу "1С:Бухгалтерия предприятия 8", ред. 3.0 на выбранную дату начала ведения учета. Также переносятся документы за период и вся необходимая справочная информация. Правила оперативно обновляю при выходе новых релизов. Рассылка обновлений правил бесплатно в течение 12 месяцев. Есть видеодемонстрация проведения переноса данных. Конфигурации при использовании обмена остаются полностью типовыми. Перенос данных возможен в Бухгалтерию 3.0 версии ПРОФ, КОРП или базовую.

24700 руб.

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

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

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

05.02.2019    11934    user715208    38