Взгляд на ошибки и платформу через призму HI-Load

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

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

нагрузочное тестирование переход на 8.3 отказоустойчивый кластер

Поговорим об ошибках в целом и их влиянии на Hi-Load системы в частности. Может ли тут помочь платформа 1С? (да и должна ли в принципе?) Немного про сам Hi-Load на примере крупной БД. PS Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.

Всем привет!

Я уже второй раз выступаю на конференции Infostart. В первый раз, это было в 2014 году, я выступал от компании «Деловые линии». Но в том же году весь ИТ-департамент «Деловых линий» был выделен в отдельное юридическое лицо BIA Technologies, и «Деловые линии» стали нашим основным заказчиком.

Итак, Hi-Load.

HI-Load бывает разный. В википедии вообще написано, что HI-Load – это просто высокая нагрузка и всё.

Договоримся на берегу, что буду говорить только о Hi-Load, отвечающих двум аспектам:

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

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

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

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

Оба этих аспекта сочетаются в информационной системе нашего основного Заказчика.

Поэтому давайте про саму систему. Кратко.

 

  • Это – самописная конфигурация на платформе 1С.
  • В базе одновременно работает более 3000 пользователей в 129 городах России.
  • Режим работы круглосуточный.

На стороне сервера СУБД показатели следующие:

  • MS SQL 2014
  • Среднее число запросов 35'000 в секунду, пиками до 50'000.
  • Больше 10'000 транзакций в секунду, пиками до 30'000.
  • Нагрузка на процессор меньше 15%, пиковая до 40%.

Суммарный размер базы более 9 ТБ. Из них:

  • Чуть меньше половины занимают регистры сведений.
  • На втором месте – регистры накопления.

Интенсивность работы:

  • В сутки записывается и перепроводится (включая создание новых) более миллиона документов;
  • Справочников – порядка 380 тысяч;
  • И ежедневно пользователи формируют около 300 тыс. отчетов.

Повторюсь, это показатели за сутки. Режим работы 24 на 7, но почти 80% этой нагрузки приходится на 12-ти часовой промежуток времени. Примерно с 9 утра до 9 вечера.

Про платформу.
Используемая платформа: 1С 8.3.10

 

Переходу на 8.3 предшествовал достаточно длительный проект по нагрузочному тестированию, который мы провели совместно с центром корпоративной технической поддержки (ЦКТП) от 1С. Это тестирование мы проводили практически год.

Целью нагрузочного тестирования было:

  • Добиться стабильной работы платформы и базы;
  • Понять, выдержит ли вообще железо такие нагрузки – может быть, нам потребуется менять сервера, конфигурацию;
  • Оценить перспективы роста (и для бизнеса в том числе).
  • Понять, что будет с базой в ближайшие 3-5 лет.

 

В чем состояло само тестирование?

  • На протяжении 8 часов 10 тысяч виртуальных пользователей должны были работать в системе;
  • При этом итоговый APDEX должен быть на уровне «отлично».
  • И никто из этих пользователей не должен аварийно завершить работу.
  • Также отделом тестирования проводились еще и пользовательские (функциональные) тесты,

На скриншоте вы можете видеть 15 тысяч пользователей – это реальный скриншот с проведения теста. 15 тысяч – потому, что помимо 10 тысяч виртуальных пользователей были COM-соединения и работал фоновые задания. У нас такая специфика работы, что мы для построения отчетов подключаемся к копии базы по COM-коннекту. Поэтому нам важно было удостовериться, что кластер выдержит работу еще и с большим количеством COM-коннектов.

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

Из интересно отмечу сам процесс перехода с 8.2 на 8.3.
Нам сказали: «Ребята, надо снять режим совместимости с 8.2, но пользователи могут не работать только один час, а дальше – пожалуйста, будьте любезны предоставить доступ».

Что было для этого сделано?

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

  • Настроили обмен из рабочей базы 8.2 в эту копию 8.3. Обмен шел порядка двух суток. В планах обмена было около миллиарда изменений.
  • Когда база 8.3 актуализировалась, мы просто переназначили ярлыки. Для пользователей это было буквально за 5 минут и все – они стали работать дальше.

Кому интересно, описание железа, использованного на проекте, есть на сайте 1С http://v8.1c.ru/expert/cts/cts-330-001.htm
 

 

Возвращаемся к теме HiLoad.
В чем же особенности при такой высокой интенсивности работы?

 

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

Например:

  • 3 тыс. пользователей;
  • у каждого третьего раз в секунду срабатывает обработчик ожидания;
  • В этом обработчике выполняется запрос, который потребляет 0.1 секунды CPU.

Соответственно, для того, чтобы вам обеспечить работоспособность этого потока запросов, вам нужен сервер минимум на 100 ядер. При этом он все равно будет загружен на 110% и работать не сможет (формула немного утрированная, но суть отражает верно).

Что мы делаем для того, чтобы снизить эту чувствительность? Мы буквально тюнингуем самые частовыполняемые запросы, добиваемся максимальной эффективности и минимального потребления ресурсов.

Периодически снимаем трассу всех запросов – собираем не долго, буквально 10-15 минут. За одну секунду такого сбора в трассе получается порядка одного гигабайта данных. Мы группируем эти запросы, "вырезая" имена временных таблиц, смотрим, какие из них самые часто выполняемые и самые «тяжелые». Решаем, что с самыми «тяжелыми» запросами делать дальше – переписать либо попробовать вообще от них отказаться.

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

 

 

Вторая проблема, которую я хочу отметить, – это "Рост".

  • За счет того, что бизнес развивается;
  • Увеличивается документооборот;
  • Увеличивается количество пользователей;
  • Усложняется сам учет.

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

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

Перефразируя цитату про бэкапы: «Вы либо УЖЕ параноик, либо ЕЩЁ НЕ параноик». Конечно, в хорошем смысле этого слова))

Про резервирование и отказоустойчивость.

Придерживаемся следующих принципов:
- кластеризация СУБД и 1С;
- наличие «холодного» и «горячего» резерва;
- запас прочности по железу, как СУБД так и серверов 1С.

Как это выглядит в жизни на примере кластера СУБД:

Кластер СУБД собран из трех серверов, за кластеризацию отвечает windows server failover cluster. На одном из серверов рабочая база, на другом вторичный узел репликации AlwaysOn. Это типовая возможность MS SQL Server. База - реплика доступна только на чтение.

У заказчика эта копия отдельно подключена к серверу 1С и в неё можно интерактивно зайти, сформировать отчет, найти нужную информацию. С обычными (толстыми) формами это делается достаточно просто, а вот с управляемыми формами будут проблемы. При их открытии в первый раз платформа пытается сделать запись в таблицу _SystemSettings и получает от сиквел-сервера ошибку.

В копию AlwaysOn, по СОМ соединению, подключаются отчеты, которые пользователь формирует в рабочей базе. А сам запрос отчета выполняется в копии, тем самым распределяя нагрузку.

Третий сервер кластера СУБД сейчас просто в резерве, но долгое время там также была копия базы, только реплика делалась средствами 1С. Это тот же механизм на планах обмена, что использовался при переходе на 8.3.

Что эта схема позволяет сделать?

  • При проблемах на рабочем сервере (например, у вас планка памяти сгорела или еще что-то), Windows Failover Cluster Server просто мигрирует вашу базу данных на другой сервер:

  • Второй момент – если у вас проблема с самой базой данных (например физическое повреждение дисков), тогда можно в качестве рабочей базы использовать базу Always On:

 

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

 

 

 

А это уже кластер 1С – он состоит из 5 серверов. Его основные особенности:

  • На центральном сервере мы отказываемся от rphost (эта особенность у нас сохранилась еще со времен 8.2).
  • Отдельный сервер отдан под фоновые задания. Их у нас тоже достаточно много.
  • И оставшиеся три сервера отданы под пользователей. Там не только пользователи – там все, кроме фоновых.

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

Такая схема позволяет нам защищаться от ошибок и пользователей, и разработчиков, и, в том числе, от ошибок железа.

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

 

Текущие реалии таковы, что сейчас модно говорить об Agile и DevOps. Почему это модно?

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

Основным принципом становиться высокая скорость разработки при приемлемом уровне качества. Повторюсь, ПРИЕМЛИМОЕ качество… Т.е. у вас не будет ни идеальной, ни близкой к ней архитектуры. 
Плюс к этому, если на очередной итерации доработок заказчик, вдруг, меняет курс партии на 180 градусов, вы, как исполнитель, должны быстренько переобуться и так же быстренько всё переделать.
Вывод простой, вероятность просчетов и ошибок повышается. Это не хорошо и не плохо, просто к этому надо быть готовыми. И тот же DevOps уделяет внимание возможности быстро "фиксить" ошибки.
И что меня постоянно смущает, так это отношением к косякам и ошибкам..
И то возникающее недоумение, когда ты говоришь «Я вот это сделал так, потому, что текущая архитектура уже устарела» или «Мне нужен такой то функционал для решения ошибок и просчетов». Первая реакция, которая обычно следует: «Что? Нет! Это не кошерно! Просто всё перепишите заново.». 
Ну не бывает так в жизни. В жизни вы всегда ищите компромисс. Используя тот же принцип – обеспечить работоспособность минимальными затратами.
 

Про ошибки я хотел бы отдельно заметить две важных вещи, два основных мифа:

  • Идеальной архитектуры не бывает. Если она и бывает, то только в какой-то конечной замкнутой неразвивающейся среде (возможно, даже никому уже давно не нужной).
  • Второй момент – все ошибаются. Ошибки – это нормально. Перефразируя доктора Хауса – все «косячат», это наша с вами человеческая природа. И к этому надо быть готовым.

 

Хотелось бы поговорить про то, чего нам не хватает со стороны платформы 1С на таких масштабных проектах. На слайде перечислены «хотелки» из реальных кейсов, из попыток решить какие-то конкретные задачи, какие-то проблемы. На самом деле все уже придумано и давно есть во взрослых СУБД.

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

Отдельные из этих пунктов – холиварные, возникают из-за «бурления масс». Например:

  • Использование хинтов в запросах;
  • Или возможность создавать индексы произвольной структуры.

Основной довод против – всё, что надо, в платформе уже есть, надо просто всё это знать и уметь. 
И самые главные: «НАДО было думать раньше!» «Вы пытаетесь исправить костылем чей то косяк…» фу-фу-фу…

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

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

Заключение

Лично от меня. Отдельная огромная просьба к компании 1С – пересмотреть свое лицензионное соглашение в части использования средств СУБД.

Вместо того, что бы всем сообществом открыто рассматривать опыт применения тех или иных механизмов СУБД, учиться на ошибках друг друга, получать подсказки от разработчиков платформы… 
Вместо этого сообщество начинает обрастать секретами Полишинеля, каждый копается в своем муравейнике и изобретает свой велосипед. Это не полезно ни для бизнеса, ни для платформы 1С:Предприятие.
Мое мнение, текущее соглашение мешает развитию 1С:Предприятие, особенно на масштабных и сложных проектах.

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

Спасибо за внимание!

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

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

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

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

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

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. qwinter 619 18.06.18 13:47 Сейчас в теме
Я что то пропустил и 1С все таки решили сделать возможность делать свои индексы? Где можно почитать?
2. Sergey.Noskov 1138 18.06.18 14:38 Сейчас в теме
(1) Не пропустили. Это только мои ожидания.
3. qwinter 619 18.06.18 15:09 Сейчас в теме
(2) (( Жаль. Ожидания этого далеко не только у вас.
6. Sergey.Noskov 1138 18.06.18 18:10 Сейчас в теме
(3) вот и надо чаще про это говорить.
4. grumagargler 649 18.06.18 17:25 Сейчас в теме
Интересное подтверждение того, что могут существовать противоположные подходы одновременно. По своему опыту: терпимость к ошибкам приводит к загниванию системы, особенно в больших проектах, где ошибки стоят дороже, чем наличие функционала (не сталкивался, чтобы большие компании постоянно стресовали новым функционалом, обычно чем больше, тем всё инертней). Уже не говоря о технических долгах, которые всегда приходится отдавать с процентом. А хороший код всегда проще изменить под модифицированное заказчиком требование, чем плохой. Не раз проводил эксперимент, предоставляя программистам больше времени на задачу - качество при этом существенно не меняется. Те, кто пишет хорошо - делает это еще лучше, а те, что говорят, дайте больше времени - так и продолжают делать ошибки.
8. Sergey.Noskov 1138 19.06.18 13:38 Сейчас в теме
(4) А кто говорит про терпимость к ошибкам? Я точно не говорил. Речь лишь о том, что они неизбежны. И, что самое интересное, для бизнеса наличие функционала сейчас, но с тех.долгом, выгоднее, чем функционал без оного, но через пол года.

По поводу инертности - объемы прироста функционала не снижаются.
starik-2005; +1 Ответить
5. Glebis 11 18.06.18 17:42 Сейчас в теме
- Возможность задавать в запросах свои имена временных таблиц СУБД.

Почему бы просто не добавлять дополнительное поле с уникальным строковым идентификатором в каждую временную таблицу под одним и тем же именем?
9. Sergey.Noskov 1138 19.06.18 13:40 Сейчас в теме
(5) нужна повторяемость текста запроса, для использования одного скомпилированного плана запроса.
7. Serg O. 186 19.06.18 12:35 Сейчас в теме
Дастиш фантастиш...
база 9 ТЕРРА-байт ?! сколько серверов? этаж или здание?
нам такое только в страшных снах и то не снилось

прямая поддержка ЦКТП... бюджет такой же... в этажах или зданиях мерялся...
это нам даже в лучших снах не снилось

APDEX 0,99 - это значит заниженные требования
или пора повышать требования...
если 0,94-0,95 макс.было на 5-ку
10. Sergey.Noskov 1138 20.06.18 16:52 Сейчас в теме
(7)
APDEX 0,99 - это значит заниженные требования
Обоснуйте.
17. triviumfan 16 06.11.18 17:02 Сейчас в теме
(10) Приведите хотя бы несколько примеров целевого времени самых популярных ключевых операций.
А то я могу задать открытие формы в 10с, запись в 20, а проведение в 30. Для меня клиента это может быть норм требованием.
apdex будет стремиться к 1.
19. Sergey.Noskov 1138 08.11.18 13:59 Сейчас в теме
(17)
А то я могу задать открытие формы в 10с, запись в 20, а проведение в 30
а смысл, что бы обмануть себя? Пользователи и Заказчик молчать не будут - если тормозит, то ответ "проблемы не видим, апдекс отличный" никто не примет. АПДЕКС, в первую очередь, делается тех, кто занимается эксплуатацией и поддержкой этой системы. И к значению апдекса должно быть доверие.
У нас есть три операции с целевым временем больше 10 секунд, но они объективно длительные.
АРМ Call центра. Входящие 8800 3,00
АРМ Call центра. Оповещение о приходе груза 3,00
Ввод нового контрагента запись элемента 2,00
Выдача накладной 2,00
Групповая выдача: Список накладных по контрагенту 3,00
Запись документа задание группе пользователей 2,00
Запись документа Звонок 2,00
Запись документа Служебная записка 2,00
Запись контрагента 2,00
Проведение выгрузки машины 24,00
Проведение выданной накладной 5,00
Проведение загрузки машины 20,00
Проведение заявки экспедитора 3,00
Проведение приемной накладной 4,00
Проведение рейса автодоставки 12,00
20. triviumfan 16 08.11.18 14:19 Сейчас в теме
(19) Ну вот, что и требовалось доказать. Где-то видел (в каких-то курсах), что на открытие 1с, запись 2с, на проведение 3с. А у вас вон чего.
Слышал, что целевое время зависит от заказчика.
Стырено

К примеру, для него проведение рейса может и 20с приемлемо, поэтому apdex по сей операции будет стремиться к 1, а на самом деле какой-нибудь Вася там кривой запрос написал и все ок.
22. Sergey.Noskov 1138 08.11.18 15:02 Сейчас в теме
(20) тут нет открытий, запись - только две операции связанные с контрагентами (обе кстати 2с как и в придуманных кем то нормах), остальное - проведение документов (Запись документа Звонок и т.п. это по факту проведение), опять таки большинство операций 3с из "тех самых норм".
АПДЕКС не характеризует идеальность системы. А целевое время не равно идеальному.
И да, пользователь должен подтвердить, что вот эта скорость работы его целиком устраивает.
Не вижу противоречий. Только вот что именно Вы доказали совсем не понятно)
23. triviumfan 16 08.11.18 15:46 Сейчас в теме
(22) Я ссылался на "Проведение рейса автодоставки 12,00".
Ладно, проехали, на самом деле мне просто завидно, ведь у нас apdex 0.7+ (но и оборудование старое) :)
24. Sergey.Noskov 1138 08.11.18 19:16 Сейчас в теме
(23) пользователи при этом сильно жалуются? Показатель 0.7 у нас приравнивается к недоступности услуги и вызывает большой поток жалоб.
25. triviumfan 16 08.11.18 20:40 Сейчас в теме
(24) В том то и прикол, что им всё равно (да и железо вот:xeon x5650, 24гб озу, ~70 юзеров, УТ11)
26. triviumfan 16 08.11.18 21:38 Сейчас в теме
(25) а нагрузочный тест гилёва TPC-1C выдаёт 11 баллов. Очень подозрительно...
27. Sergey.Noskov 1138 09.11.18 12:33 Сейчас в теме
(25) вообще это странно. Пользователям, особенно если их под 100 человек, обычно не всё равно. Возможно они привыкли или считают такую скорость нормальной.
11. zinal 45 20.06.18 17:25 Сейчас в теме
С моей колокольни, в наибольшей степени платформе 1С:Предприятие не хватает поддержки партиционирования таблиц (вероятно, на вашем слайде это "сегментирование").
Другой важный вопрос вопрос - допустимость ручного (на стороне СУБД) управления размещением данных на разных устройствах, тут действительно может быть противоречие с условиями лицензионного соглашения 1С.
Причём технически коду 1С совершенно всё равно, в каком табличном пространстве (файле) лежит какая таблица.
Sergey.Noskov; +1 Ответить
13. Sergey.Noskov 1138 21.06.18 13:51 Сейчас в теме
(11) именно это и подразумевалось
12. Serg O. 186 21.06.18 05:59 Сейчас в теме
(42)
(10)сравните средне-арифметич. Время выполнения и время ожидания apdex, если они различаются в разы... Значит время в оценке apdex можно еще уменьшить. Неплохо бы еще оценить средне-квадратичное отклонениние и сделать время ожидания apdex =среднее + ср.кв.отклонение или меньше и тогда уже искать apdex,, как анализ дисперсии
Конечно не спорю 0,99 это афигительно круто...
15. DonAlPatino 140 27.06.18 15:36 Сейчас в теме
А можно вопрос про Always on. Все-таки 1С гарантирует что транзакции платформы на уровне сервера приложений один-в-один превратятся в транзакции SQL сервера? Не может ли быть ситуация что из-за падения скажем основного SQL Server в момент проведения документа на резервном он окажется "полупроведенным"? Где бы подробно про разбор такой ситуации почитать? На ИТС как-то в основном про транзакции на сервере приложений и что все будет хорошо.
18. Sergey.Noskov 1138 08.11.18 08:39 Сейчас в теме
(15)Always on технология не 1С, это функция MS SQL Server. Транзакционная целостность сохраняется, "полупроведение" принципиально не возможно.
16. asemenyuk 29.06.18 14:38 Сейчас в теме
Добрый день!
В реализованной у Вас схеме, Центральный сервер 1С никаким образом не зарезервирован. Как поведет себя кластер 1С, если Центральный сервер 1С (тот что без rphost) станет недоступен? Какие ограничения будут наложены на схему в случае его недоступности? Интересуют реальные факты тестирования данного события.
21. Sergey.Noskov 1138 08.11.18 14:25 Сейчас в теме
(16) Добрый день!
Если центральный сервер 1С станет недоступным, то и система станет недоступной, все пользователи завершат работу аварийно и не смогут зайти.
Вероятность этого есть всегда, но она тем меньше, чем больше разгружен центральный сервер. Если с центрального убрать клиентские сессии, фоновые задания, полнотекстовый поиск, журнал регистрации и использовать флаг "менеджер под каждый сервис", то риск потери сервера крайне низкий, по сути он равен риску невосстановимого отказа физической машины.
Отказоустойчивость мы использовали в нагрузочном тесте на 10'000 пользователей. Первые тесты показали наличие проблем - кластер работал не стабильно, пользователи "падали", апдекс проседал с 0.99 до 0.94. В последних релизах 8.3.10 работало уже лучше, производительность снижалась заметно меньше (апдекс падал до 0.97).
Планируем в следующем году протестировать свежие версии платформы и будем принимать решение по результатам.
28. acanta 74 28.04.19 14:56 Сейчас в теме
В запросе 1с для динамического списка нет возможности ограничить методами языка запросов количество записей в результате и их диапазон?
Это касается только журналов или вообще любых списков?
Оставьте свое сообщение

См. также

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

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

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

30.10.2017    27946    0    MrWonder    42    

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

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

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

24.05.2020    4138    0    DataReducer    22    

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

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

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

18.05.2020    1202    0    Aleksey.Bochkov    3    

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

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

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

06.04.2020    8734    0    YPermitin    0    

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

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

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

22.04.2015    39440    0    Gilev.Vyacheslav    1    

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

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

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

03.04.2020    2658    0    feva    14    

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

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

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

31.03.2020    9630    0    informa1555    21    

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

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

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

31.03.2020    2268    0    vasilev2015    9    

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

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

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

22.01.2014    65774    0    yuraos    112    

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

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

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

20.03.2020    3531    0    vasilev2015    21    

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

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

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

18.03.2020    5229    0    kaliuzhnyi    43    

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

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

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

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

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

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

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

17.02.2020    7005    0    Evil Beaver    13    

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

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

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

23.01.2020    5367    0    darkdan77    59    

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

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

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

23.01.2020    6633    0    Kaval88    26    

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

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

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

19.02.2013    53270    0    Gilev.Vyacheslav    46    

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

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

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

19.12.2019    8760    0    ivanov660    16    

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

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

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

22.10.2019    6288    0    EugeneSemyonov    11    

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

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

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

14.10.2019    15222    0    YPermitin    28    

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

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

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

11.02.2013    29190    0    gallam99    19    

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

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

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

13.09.2019    8007    0    Repich    5    

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

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

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

10.09.2019    16364    0    Sloth    24    

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

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

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

09.09.2019    7410    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    41316    0    madmpro    32    

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

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

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

31.08.2019    9058    2    YPermitin    7    

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

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

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

19.07.2019    7990    0    Филин    12    

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

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

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

16.07.2019    8474    0    fhqhelp    0    

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

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

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

02.07.2019    10018    0    igordynets    119    

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

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

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

27.06.2019    8923    0    YPermitin    16    

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

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

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

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

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

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

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

13.06.2019    11419    0    Repich    117    

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

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

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

13.06.2019    5309    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    21399    0    dmurk    144    

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

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

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

28.05.2019    16652    0    ivanov660    9    

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

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

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

21.05.2019    7249    0    vasilev2015    21    

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

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

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

20.05.2019    6493    0    zhichkin    15    

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

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

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

29.04.2019    19916    0    comol    198    

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

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

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

26.04.2019    13338    0    kuzyara    12    

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

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

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

25.04.2019    12409    0    Elf1k    27    

Копия базы 1С для отчетов. Или как выжить с тяжелой отчетностью

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

Способы создания копии базы 1С для отчетов. Бэкапирование, репликация, AlwaysOn и другие страшные слова.

22.04.2019    13829    0    YPermitin    49    

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

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

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

18.04.2019    26287    0    ivanov660    77    

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

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

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

06.04.2019    14240    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    14263    0    w.r.    23    

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

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

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

06.03.2019    8282    0    dmitrydemenew    38