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

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

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

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

 

Меня зовут Репников Олег. Я работаю в компании «Вымпелком» – владелец торговой марки «Билайн». На слайде написана моя должность, чтобы вы настроились, что у нас все крупное, все по-взрослому, и должности у нас тоже большие.

 

 

О чем я буду говорить? Кратко на слайде написал. Мы поговорим о компании, я расскажу про архитектуру, о том, как мы информируем себя о сбоях системы, о том, что мы используем «Центр контроля качества», про Grafana и про замеры производительности.

 

О компании «Билайн»

 

 

Компания Вымпелком – владелец торговой марки Билайн. 

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

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

 

Немного цифр.

 

 

На слайде показан график количества пользователей в базе в течение одного дня. Он начинается от 2000 и достигает пика на 8000. Так как у нас салоны расположены от Камчатки до Калининграда, то количество пользователей растет постепенно – пользователи просыпаются, заходят в систему, а в 10-11 часов утра система достигает пика количества пользователей. И когда засыпает Дальний Восток, Сибирь – пользователи постепенно выходят.

 

 

Количество транзакций лучше всего мерить чеками. У нас есть два основных показателя – это количество пробитых чеков и количество принятых платежей. Этот график показывает количество пробитых чеков в минуту. В пике у нас примерно 200-250 чеков в минуту.

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

 

 

И последняя картинка – это наш график SQL-сервера. На нем видно количество ядер, количество памяти и относительная нагрузка.

 

Архитектура «крупными мазками»

 

 

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

Слева application-сервера – 6 application-серверов и один сервер, который обслуживает различные HTTP и веб-сервисы. Application-сервера расположены в двух ЦОДах, которые находятся в разных концах Москвы. У нас есть третий ЦОД, который находится в Ярославле, мы пытались его использовать – поставить на нем application-сервера, но, к сожалению, сетевая задержка оказалась слишком велика, она уже чувствовалась. Поэтому оба ЦОДа у нас находится в Москве – три application-сервера в одном ЦОДе, и три application-сервера в другом ЦОДе. Два сервера центральных, остальные сервера рабочие. Фоновые задания у нас выделены на отдельный сервер, а пользователи обслуживаются оставшимися пятью серверами.

А справа на слайде показана структура SQL-кластера. Он построен из 4-х нод. Две ноды работают в режиме Synchronous commit (то есть, до тех пор, пока транзакция не закоммитится на обоих серверах, она не завершится). И вторые два сервера работают в асинхронном режиме (Asynchronous commit). 

 

Информирование о сбоях

 

 

Мы используем собственную самописную систему информирования о сбоях.

Почему мы не стали использовать промышленную систему – Zabbix, Nagios и пр.? Естественно, что у нас в компании есть крупная корпоративная система мониторинга, которая обслуживается большим количеством сотрудников, вендор этой системы нас поддерживает и т.д. Но, так как у нас обслуживаются десятки тысяч вышек, на каждой из которой есть железное оборудование, подключенное к системе мониторинга, то здесь включаются различные корпоративные правила. То есть, для того, чтобы войти в корпоративную систему мониторинга, нужно выполнить ряд требований, которые мы на старте проекта выполнить не могли. И когда мы пришли и сказали: «Мы хотим мониторить нашу систему», нам сказали: «Напишите метрики, которые вы хотите мерить, и недели через две мы их включим в свою систему мониторинга». Но на тот момент мы еще сами не знали, что мы хотим мониторить. Понятно, что нагрузку на процессор, нагрузку на память, количество транзакций и т.д. – это было очевидно, это стандартные метрики. Но есть ряд метрик, про которые мы не знали, будем мы их мониторить или нет. 

Поэтому три года назад мы начали «колхозить» – разрабатывать собственную систему мониторинга. Она у нас полностью самописная, собирается из различных модулей, которые пишутся на C#. Кроме этого мы, естественно, используем «Центр контроля качества». 

Как сейчас работает наша система мониторинга?

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

Что значит спамит?

В случае если система мониторинга видит, что в 1С не пробито ни одного чека, хотя чеки должны пробиваться, она напишет сообщение – в RocketChat, в SMS, в почту. Если через минуту она увидит, что чеки так до сих и не поступают, она напишет еще одно сообщение. И так будет происходить до тех, пока мы систему не починим. Это приводит к тому, что в случае серьезных аварий, которые длятся час, в почте творится полный хаос, потому что все заспамлено. Правильно так делать или неправильно – сложно сказать. Меня, как руководителя техподдержки, такая система устраивает, она не дает расслабляться. 

 

 

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

  • Первое слово в теме сообщения – ALARM (может быть либо ALARM, либо SUCCESS – либо ошибка, либо все хорошо). Следующее слово Check показывает, что мы мониторим чеки.

  • Далее – 13:18. Avg 142 (average – среднее значение). Это означает, что на 13 часов 18 минут среднее значение чеков за последний месяц было равно 142. 

  • *current 0* – это означает, что за текущую минуту чеков было 0.

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

  • Period 30 days – за какой период берется статистика.

  • Threshold 44 – при каком значении система будет срабатывать. Если количество чеков больше 44, система не сработает. Если меньше, то система сработает. Это значение мы подбирали опытным путем, потому что пытались избежать ложных срабатываний. Например, когда среднее значение в эту минуту за последний месяц – 10 чеков, то если пробили 7, не понятно – авария ли это? Поэтому подбирали опытным путем. 

Что мы мониторим?

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

  • Отсутствие платежей.

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

 

Центр контроля качества

 

 

Про «Центр контроля качества»

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

«Центр контроля качества» мы не использовали, так как писали свою систему мониторинга. Но в один прекрасный день мы запустили проект ЦКТП с 1С, и ребята из ЦКТП сказали, что одно из условий работы в проекте – это использование конфигурации «Центр контроля качества». 

Оказалось, что «Центр контроля качества» даже чем-то похож на Zabbix. Там есть агент, который будет собирать информацию – его можно поставить на свои сервера и на рабочие станции. Этот агент умеет собирать из коробки различную статистику, которая нам интересна. Он умеет по умолчанию собирать дампы rphost и т.д. (те самые дампы, в которые иногда падает платформа, и которые нам нужно передать нашему партнеру 1С-Рарус и фирме «1С», чтобы они смогли найти причины). Все это умеет делать «Центр контроля качества». Казалось бы, ерунда, настроим и будем собирать ту информацию, которая нужна. Но, к сожалению, оказалось, что «Центр контроля качества» очень сложен в настройке. Точнее, он неинтуитивно понятен. 

Мне повезло – дело в том, что, после того как мы запустили проект ЦКТП, у меня в скайпе появился разработчик «Центра контроля качества». Я задавал ему кучу глупых вопросов, и примерно через месяц мы, наконец, настроили систему так, чтобы она собирала все нужные нам данные. Наверное, если бы я внимательно прочитал документацию, я справился бы самостоятельно, но документацию обычно читают, когда уже все сломалось.

Я рекомендую настраивать «Центр контроля качества» на крупных системах, потому что, немного помучившись, вы сможете собирать много нужной информации. И это хорошо, если она вам не пригодится – потому что, если вам пригодилась информация из «Центра контроля качества», то значит, у вас произошла какая-то авария, и вы пытаетесь разобраться в ее причинах. Поэтому мы ЦКК поставили, полгода в нее не заходили, а потом через полгода, когда у нас происходит какая-то авария, мы смотрим, что изменилось с момента последней аварии.

Итак, для чего мы используем «Центр контроля качества»?

  • С помощью «Центра контроля качества» мы собираем доступность серверов – у нас на всех серверах установлены агенты ЦКК и, соответственно, мы собираем информацию об их доступности. 

  • Мы собираем основные метрики – такие, как ЦПУ, память, нагрузка на диск.

  • Мы собираем метрики SQL, такие, как количество дедлоков и количество таймаутов. 

  • Кроме этого, есть отличная возможность развернуть в контролируемой базе веб-сервис, вызывая который, можно в «Центре контроля качества» писать любые метрики, которые интересны. 

  • «Центр контроля качества» служит у нас базой данных для хранения всех наших метрик. Потому что, кроме того, что мы хотим эти показатели мерить, мы хотим эту информацию где-то хранить – мы ее записываем в ЦКК. Мы меряем количество управляемых блокировок, произошедших за час, среднее время дедлоков. Хранить эту информацию нужно, потому что если пользователи вдруг начали жаловаться, всегда можно зайти, посмотреть, что изменилось за последний час, за последний день, за последние полгода.

 

 

Кроме того, мы используем «Центр контроля качества» как CMDB. 

Здесь указаны все наши сервера, все наши площадки – у нас есть тестовая площадка для разработчиков, есть площадка для нагрузочного тестирования, есть боевая площадка. 

Я не разработчик, я больше администратор, девопсер. И когда разработчики просили поднять SQL-базу для тестирования (нужно было что-то потестировать, а на файловой базе не получалось) у нас была большая проблема, потому что через полгода этих баз становилось 50, и разобраться в них было нельзя – нужны они или не нужны. А с тех пор, как мы стали сначала заводить базу в CMDB и только после этого отдавать ее в разработку, у нас более-менее установился порядок, потому что в CMDB можно прописать, кому принадлежит база, до какого времени ее хранить и прочее.

Что мы не используем в «Центре контроля качества»?

  • В «Центре контроля качества» мы не используем работу с инцидентами, потому что у нас есть своя корпоративная система.

  • И мы не используем графики – я за это долго боролся с 1С, потому что графики в 1С вырвиглазные. Вроде они что-то поправили в последних релизах платформы, но мы к тому времени уже договорились с ними, что в качестве графиков используем Grafana (благо, она настраивается за полтора часа и в пятой версии умеет поддерживать MS SQL).

 

 

Вот как раз Grafana. Здесь видны измеряемые показатели – это всего лишь 4 графика, на самом деле их гораздо больше. 

Видно, как отражается нагрузка на ЦПУ, на Application-сервера, чеки, платежи и количество продаж в кредит – это тоже один из показателей, который нам достаточно важен.

 

Почему мы не используем Apdex, и как мы измеряем SLA

 

 

Немного про Apdex

С Apdex в терминологии 1С (когда мы что-то складываем и делим на 4, и в итоге получаем какую-то цифру, которую показываем бизнесу и говорим, что это – хорошо, нормально или плохо) у меня отношения не сложились изначально.

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

Мы используем 1С-ные замеры, по которым у нас меряются ключевые операции. На данном слайде у нас 9 ключевых операций, на самом деле их порядка 40. 

Все эти замеры мы выводим в Grafana, и, глядя на график, в случае аварии можно определить момент ее начала. Например, на графике видно, что до 8 часов утра показатели не очень хорошие – это связано с тем, что в это время работает Дальний Восток и Сибирь, а сервер у нас находится в Москве, каналы связи не идеальные, код не идеальный, большое количество серверных вызовов. Поэтому до 8 часов утра показатели не самые лучшие. Но после 8 часов утра, когда просыпается Москва, графики выравниваются.

Красные линии, которые видны – это показатели, к которым мы стремимся. Это то, о чем мы договорились с бизнесом, что мы стараемся не нарушать эти показатели. Формально – это те самые замеры Apdex, но саму итоговую цифру мы не смотрим. 

 

Замеры производительности основных операций

 

 

Вот такая рассылка у нас приходит ежедневно. Здесь – два графика. Сейчас их приходит порядка 40. Рассылка отправляется на ключевого заказчика от бизнеса, на меня и на ведущих администраторов системы.

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

 

Мониторинг журнала регистрации

 

 

Кратко – про мониторинг журнала регистрации. 

Этот мониторинг мы прикрутили за неделю. Как это работает? Мы в журнал регистрации пишем только ошибки. Глазами его читать тяжело, так как ошибок большое количество, поэтому мы делаем следующее – мы парсим журнал регистрации, группируем его по событиям и выводим в RocketChat (правая картинка).

Дальше – что должен сделать администратор системы или проблем-менеджер, который занимается задачей? 

  • Он видит конкретную ошибку и заводит на нее дефект в системе багтрекинга.

  • После этого он прописывает в «Центре контроля качества» запись, что на конкретную строку заведен конкретный номер дефекта, после чего эта строка перестает выходить в мониторинге. 

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

 

Примеры проблем, при решении которых нам помог мониторинг

 

 

История первая – о внезапном повышении производительности. 

2 сентября мне приходит на почту график, в котором я вижу такую картинку. Я вижу, что у меня по какой-то причине резко выросла производительность. Если раньше при нажатии на кнопку «Применить акции» продавец ждал 10-15 секунд, то сейчас стал ждать 5 секунд. 

Когда производительность резко увеличивается, а ты ничего не делал, это пугает больше, чем, если она ухудшилась. Это значит, что ты перестал контролировать ситуацию. Мы полдня разбирались, в итоге догадались спросить у техподдержки, что они делали. И оказалось, что вчера закончился срок действия 600 акций. Всего у нас действующих акций 800, 600 из них закончили свой срок действия. Соответственно, все видно на графике. Чем больше акций – тем хуже производительность.

Какие мы сделали выводы? 

  • Что у нас есть проблема с акциями, нам нужно оптимизировать код.

  • И второй вывод – что бизнесу надо как-то донести, что 800 акций – это плохо. Давайте попытаемся обойтись 200, а лучше 10. За это сейчас идет битва уже на административном, а не на техническом уровне.

 

 

Вторая история – моя любимая. 

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

На верхнем графике показано количество создаваемых временных таблиц – видно, что каждые 15 минут у нас создается большое количество временных таблиц. Очевидно, что работает какой-то регламент, который каждые 15 минут что-то создает, из-за чего мы проваливаемся по дисковой подсистеме и получаем провал по производительности на основной системе. Нашли регламентное задание, которое создает порядка 50 тысяч временных таблиц, завели дефект, отдали разработчикам, сказали: «исправляйте». Они исправили, но стало еще хуже, пики стали еще выше. 

Мы вообще перестали что-либо понимать – полтора месяца искали причину, не могли найти. В итоге завели инцидент и отправили его на системных администраторов – людям, которые занимаются железом. Говорим: «Ребята, мы уже все перепробовали, не можем понять причину». Через 15 минут приходит ответ: «Да у нас там баг в процессоре, он под высокой нагрузкой каждые 15 минут засыпает. Мы вам сейчас в биосе это отключим, он перестанет засыпать». В итоге они отключили засыпание, и все нормализовалось. Я сейчас уже не помню, как называется этот баг, не помню, как называется режим энергосбережения, который отключается в биосе, но суть была в том, что мы искали вообще не в том месте, где нужно. 

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

 

Планы

 

 

Какие у нас планы?

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

  • Хотим поставить агентов «Центра контроля качества» на всех клиентов. Потому что агент «Центра контроля качества» – это прикольная штука, которую можно использовать, в том числе, для решения проблем. Смотреть, например, что после выхода релиза на клиентах резко выросла нагрузка ЦПУ. Для 8000 клиентов это ничем кроме как агентом ЦКК не посмотришь. Либо агента Zabbix ставить. 

  • И собираемся использовать мобильный клиент. Это к мониторингу не относится, просто хотел похвастаться.

 

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

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

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

Выбрать мероприятие.

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

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. mbreaker 1333 16.09.19 16:04 Сейчас в теме
Хм... должность как должность...
Коротко и понятно: "начальник ОКиПСДДРСДДпУЗБпРИ"
2. Repich 492 16.09.19 17:57 Сейчас в теме
(1) Кровавый энтерпрайз на уровне отдела кадров )
3. metmetmet 77 19.09.19 04:49 Сейчас в теме
Спасибо за статью. Всегда интересно читать про большие системы.
Есть вопросы по анализу журнала регистрации.
Журнал регистрации в каком формате хранится?
Анализ журнала регистрации выполняется прямыми обращениями к файлам или с помощью методов платформы?
4. Repich 492 19.09.19 14:48 Сейчас в теме
Мы используем старый формат ЖР, который хранится в виде текстовых файлов. Анализ делаем средствами платформы (методом ВыгрузитьЖурналРегистрации()
5. user1270459 29 11.01.20 19:56 Сейчас в теме
"Мы хотим сделать автоматический парсинг технологического журнала"

Посмотрите публикацию
"https://infostart.ru/public/1112132/"
Там как раз это дело автоматизировано и мониторится
Оставьте свое сообщение

См. также

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

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

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

30.10.2017    27936    0    MrWonder    42    

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

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

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

24.05.2020    3914    0    DataReducer    22    

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

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

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

18.05.2020    1177    0    Aleksey.Bochkov    3    

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

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

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

06.04.2020    8686    0    YPermitin    0    

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

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

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

22.04.2015    39414    0    Gilev.Vyacheslav    1    

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

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

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

03.04.2020    2638    0    feva    14    

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

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

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

31.03.2020    9555    0    informa1555    21    

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

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

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

31.03.2020    2248    0    vasilev2015    9    

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

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

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

22.01.2014    65749    0    yuraos    112    

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

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

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

20.03.2020    3501    0    vasilev2015    21    

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

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

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

18.03.2020    5197    0    kaliuzhnyi    43    

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

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

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

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

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

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

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

17.02.2020    6975    0    Evil Beaver    13    

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

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

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

23.01.2020    5357    0    darkdan77    59    

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

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

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

23.01.2020    6621    0    Kaval88    26    

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

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

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

19.02.2013    53245    0    Gilev.Vyacheslav    46    

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

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

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

19.12.2019    8718    0    ivanov660    16    

Ускорение типовой 1С

Журнал регистрации v8 1cv8.cf Абонемент ($m)

Упрощаем журнал регистрации.

5 стартмани

09.12.2019    9219    2    Mari_Kuznetzova    48    

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

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

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

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

11.02.2013    29178    0    gallam99    19    

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

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

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

14.10.2019    15188    0    YPermitin    28    

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

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

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

10.09.2019    16329    0    Sloth    24    

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

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

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

09.09.2019    7390    0    2tvad    17    

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

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

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

03.11.2012    41305    0    madmpro    32    

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

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

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

31.08.2019    9042    2    YPermitin    7    

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

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

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

19.07.2019    7969    0    Филин    12    

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

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

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

16.07.2019    8453    0    fhqhelp    0    

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

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

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

02.07.2019    9997    0    igordynets    119    

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

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

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

27.06.2019    8913    0    YPermitin    16    

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

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

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

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

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

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

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

13.06.2019    11409    0    Repich    117    

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

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

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

13.06.2019    5298    0    slayer-ekb    10    

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

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

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

11.06.2019    21362    0    dmurk    144    

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

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

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

28.05.2019    16608    0    ivanov660    9    

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

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

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

21.05.2019    7239    0    vasilev2015    21    

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

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

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

20.05.2019    6484    0    zhichkin    15    

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

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

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

29.04.2019    19861    0    comol    198    

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

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

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

26.04.2019    13322    0    kuzyara    12    

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

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

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

25.04.2019    12385    0    Elf1k    27    

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

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

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

18.04.2019    26234    0    ivanov660    77    

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

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

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

06.04.2019    14206    0    YPermitin    30    

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

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

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

18.03.2019    14237    0    w.r.    23    

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

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

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

06.03.2019    8268    0    dmitrydemenew    38    

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

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

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

05.02.2019    16709    0    user715208    38