Методика похудения для 1С – 100%

Публикация № 1701763 28.07.22

Администрирование БД - Свертка базы

Администрирование Партицирование Сжатие Удаление Данных Свертка

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

Какой вес опасен для здоровья  базы? Большая не значит с лишним весом

 

 

У людей все просто – оптимальный вес вычисляется как соотношение роста и веса, + используются дополнительные показатели (возраст, пол …) для определения индекса массы тела. Калькулятор роста веса Конечно, всем не угодишь – например, культуристы могут возмутиться.

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

База имеет оптимальный размер, если:

  • В ней содержатся только данные, которые входят в период оперативной доступности данных для  учета.
  • Данные обеспечивают необходимую детализацию в периоде оперативной доступности данных
  • Сроки восстановления базы укладываются в целевые сроки восстановления (Recovery Time Objective) и согласуются с Business continuity planning
  • Допустимые простои на обслуживание согласно Business continuity planning
  • Стоимость хранения данных устраивает бизнес
  • Подготовка тестовых баз с реальными данными не требует больших усилий

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

Оперативную доступность можно пояснить на примере: допустим, у вас есть займ, сделка с датой поставки и датой оплаты. Очевидно, чтобы производить расчеты с периодом действия займа, или датой оплаты\ поставки эта операция должна быть доступна – даже если сама дата операции была 3 года назад. То же самое относится к амортизации основных средств, где важна дата приема основного средства, период действия. Хороший пример - период регистрации\период действия в 1С Зарплата и кадры.

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

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

Объем обрабатываемых данных за 1.5 года создает объем данных 5 Терабайт для базы 1С (включая детальные сделки\трансферы\проводки 1С и т.д.) на MS SQL 2019 с учетом мероприятий по обслуживанию индексов и устранению фрагментации. Размер сжатого бэкапа 0.5 Терабайт

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

Буфер сообщений (за периметром 1С) из шины данных RabbitMQ  – 3 терабайта каждые 2 месяца

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

 

Временные метрики

 

Мероприятие

Время

Время полного бэкапа

2 часа 30 минут

Время полного восстановления с сети

1 час – 1 час 30 минут

Время копирования бэкапа в резервный ЦОД по WAN с задержкой 60мс

3-4 часа

Перестроение одного индекса по самой большой таблице

2-3 часа

 

 

 

 

 

Временные окна

 

Зарезервированный период времени

 

Пн-Пт 6.00-11.00

Импорты операций\изменений поступивших с 0.00 до 6.00 ,пересчеты за предыдущие три дня

Пн-Пт 13.00-15.00

Импорты  и пересчеты с учетом текущего дня

Пн-Пт 9.00-22.00

Работа пользователей в разных часовых поясах

Пн-Пт с  22.00 – 1.00

Резервное копирование

Пн-Вс  с 1.00- 4.00

Импорты за предыдущие сутки, обновление агрегатов

Сб 6.00 – 16.00

Пересчет недели

Вс

Свободно для регламентных операций

 

Самые большие таблицы

В колонке Reserved можно видеть полный размер с данными и индексами

 

Table Name

# Records

Reserved (KB)

Data (KB)

Indexes (KB)

Unused (KB)

dbo._InfoRg19541

2 129 006 521

935 854 848

330 776 488

605 006 384

71 976

dbo._InfoRg18843

2 249 531 309

868 625 224

404 594 224

463 926 136

104 864

dbo._InfoRg18800

474 701 158

464 440 080

237 170 176

226 214 496

1 055 408

dbo._InfoRg18860

210 648 091

364 976 152

161 322 160

202 245 752

1 408 240

dbo._InfoRg19155

213 300 609

288 223 232

147 725 760

139 103 120

1 394 352

dbo._InfoRg17958

950 225 249

272 452 928

112 304 896

160 024 808

123 224

dbo._AccRg640

173 846 826

216 363 688

114 061 808

100 367 624

1 934 256

dbo._AccRgED677

719 075 121

210 720 168

85 568 344

124 133 600

1 018 224

dbo._InfoRg17039

370 016 366

187 902 208

38 467 072

149 404 080

31 056

dbo._Document16379

124 261 741

157 270 936

87 645 272

69 585 416

40 248

dbo._InfoRg17540

465 538 086

130 361 760

48 378 552

81 972 648

10 560

dbo._InfoRg19532

319 591 053

117 715 648

36 970 224

80 632 544

112 880

dbo._AccumRgAgg1efff3h18432

35 654 182

113 249 992

16 904 528

96 339 088

6 376

dbo._Document16378

44 003 768

109 851 688

58 681 312

50 688 960

481 416

dbo._InfoRg19498

85 023 186

109 818 320

29 883 608

79 798 344

136 368

dbo._Document17199

75 350 013

96 437 040

50 024 488

46 376 920

35 632

dbo._AccumRg16920

55 665 218

72 446 544

34 478 320

36 183 960

1 784 264

dbo._Document17554

46 735 956

61 361 048

30 128 088

31 202 152

30 808

 

Зарезервированное время, не всегда используется полностью, но  в пиковых нагрузках приходится выходить за границы. Финансовый\Управленческий учет с высокой детализацией требует ресурсов и создает объемы. Из таблиц видно, что работа построена довольно плотно, и даже вклинится с регламентными процедурами не так просто

 

Обслуживание для plus size  модели

 

 

Такие размеры базы налагают определенные условия на мероприятия по обслуживанию:

  1. Нужно забыть регламентных заданиях обновления статистики SQL  это долго, хорошо жить с флагом трассировки-Т2371 - он изменяет порог обновления статистики на более частый. Если его не включить – вставка\обновление нескольких миллионов записей уже искажает статистику и влияет на запросы . Формально считается, что он не влияет на SQL 2016 - 2019 но есть нюансы
  2. Вы должны быть внимательны к режиму совместимости вашей базы даже, если вы ее перенесли на SQL Server 2019 . Напр. при переносе базы c SQL 2008 на SQL  2019 по умолчанию ставится режим совместимости с 2008. Во много это определяется изменившимся режимом оптимизатора в котором Microsoft видимо не уверен. Я бы тоже был осторожен при таком кардинальном изменение кардинальности см тут Улучшенная кардинальность в MS SQL
  3. Раз в полгода нужна переиндексация НЕкластерных  индексов с наибольшей фрагментацией. В 1С напр. много обновляющихся(insert, delete)  таблиц (напр. итоги)  в которых растет фрагментация. В такой базе как наша это позволяет выиграть 3 - 4 сотни гигабайт за мероприятие . Для эффективности используйте ALTER INDEX <Index_Name> ON dbo.<Table_Name> REBUILD WITH (SORT_IN_TEMPDB = ON). Это предотвратит рост размера файловой группы, ведь ее потом трудно сжать обратно не смотря на свободное место.
  4. После свертки остатков и удаления лишних данных проведите реиндексацию кластерных индексов. С фрагментацией и перестройкой кластерных индексов сложнее – фактически нужно место равное размеру таблицы, но это решаемо

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

Программист 1С в этом случае должен трансформироваться минимум в Эксперта 1С по технологическим вопросам, а в идеале знать в совершенстве Performance and tuning из сертификации DBA. 1С это всего лишь удобный инструмент для генерации запросов, как сыграешь на нем, так и будет работать.

Анонс: В целом детали управления слоном в клетке ЦОД это отдельная статья, поскольку избыточного места равного размеру базы почти никогда нет. Сложностей добавляет структура таблиц\индексов 1С которые генерируют метаданные.

 

Снижение веса как стиль жизни

 

 

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

Удаление миллионов – дорого и долго.

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

Если вы решили ускорить удаление, делая это напрямую через SQL Server  в цикле DELETE TOP 1000 FROM 1CTable, вас ожидает две проблемы:

  1. В Цикле в один поток это будет медленно.
  2. Распараллелить данный оператор на уровне SQL это прямой путь к блокировкам. Еще в MS SQL (Transact SQL) нет хороших средств распараллелить ваш код кроме механизма Jobs.

Если кто-то хочет сделать просто DELETE * FROM 1CTables – оцените влияние объемов на Transaction log и Вы много поймете в архитектуре СУБД.

Анонс: Вообще делать часть кода на MS SQL (Transact SQL ) это плохая затея, несмотря на кажущуюся эффективность. Тема для отдельной статьи.

Даже если вы все-таки удалили миллионы этим способом, MS SQL на этом не закончил – вы там обнаружите … призрака

Выглядит он так

 

 

Это процесс очистки фантомных записей MS SQL. Забавно, что не только 1С умеет “помечать” на удаление, но и MS SQL, см. Ghost clean up guide

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

Reorganize and rebuild indexes

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

Партицирование миллионов  - дешево и сердито.

Для больших таблиц современные СУБД (MS SQL 2019 в Standard edition) предлагают механизм партицирования. Напр периодический регистр сведений можно партицировать по дате,  а потом:

  1. Данные старых партиций сохранять в архив
  2. Удаление старых данных  в одной партиции производить операцией TRUNCATE TABLE WITH (PARTITIONS(N)), быстро, без фрагментаций и других неприятных последствий описанных выше;

Подробнее можно почитать тут: Партицированные таблицы

И инструкция с примером тут: Пример создания партицированных таблиц

Казалось бы, вот хорошее решение, но проблемы кроются в деталях:

  1. Партицирование возможно только по одной Partitioning column, т.е. использовать составной ключ для партицирования типа (Разделитель данных, Дата) которые часто используются в типовых конфигурациях невозможно
  2. Partition column должна присутствовать во всех индексах таблицы иначе вы сможете делать только DML операции, но не DDL TRUNCATE TABLE WITH (PARTITIONS(N));
  3. Многие метаданные 1С напр, Регистр бухгалтерии по структуре состоит из нескольких таблиц, его партицировать невозможно. Т.е. в общем случае возможность эффективного использования партицирования должна быть заложена на уровне платформы, а этого нет.
  4. Партицирование позволяет быстро удалить данные партиции, используя TRUNCATE TABLE WITH (PARTITIONS(N)); но не позволяет быстро поместить в архив и это сужает применение партицирование для узких задач. Напр хранение данных буфера сообщений для RabbitMQ, это сильно облегчает жизнь, но не решает общую проблему быстрого снижения веса.

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

  1. Переключение идет только в рамках той же файловой группы, мы не можем сделать  SQL бэкап отдельно партиции с ее индексами. Только бэкап всей базы или файловой группы
  2. Бэкап можно сделать только через стандартную утилиту копирования таблиц MS SQL BCP , которая не сжимает данные и работает медленней чем SQL Backup на уровне экстентов

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

 

Методика похудения для 1С – 100%

 

 

«Я беру камень и отсекаю всё лишнее.» - так творил шедевры Микеланджело, но это было долго.

В СУБД есть более простой способ - «Я беру все нужное и ничего лишнего». В этом нам поможет утилита BCP, которая позволяет выгрузить и загрузить данные таблицы в Native формате.  Допустим, мы  хотим оставить в базе данных данные оборотов в регистре бухгалтерии, только за 2022 год

  1. Сворачиваем остатки своей процедурой и фиксируем их под регистратором Документ.СворачиваниеОстатков на 31.12.2021
  2. Выгружаем через BCP данные из таблиц проводок включая проводки за 2022 год включая проводки Документ.СворачиваниеОстатков
  3. Делаем Truncate всех таблиц регистра бухгалтерии
  4. Отключаем все индексы регистра бухгалтерии кроме кластерных
  5. Загружаем через BCP данные сохраненные в пункте 2) обратно
  6. Включаем, выключенные индексы регистра бухгалтерии
  7. Пересчет итогов

Далее примеры скрипта для некоторых таблиц и индексов регистра бухгалтерии

Детально про BCP можно почитать тут:  Утилита BCP

 

П 1

_RecorderTRef = 0x00004248 документ регистратор остатков

П 2

bcp "SELECT * FROM [%2].[dbo].[_AccRgED677] WHERE _Period > CONVERT(datetime, '%3 %4', 120) OR _Period = CONVERT(datetime, '%3 %4', 120) AND _RecorderTRef = 0x00004248" queryout %5\_AccRgED677.bcp -a 16384 -b 10000 -S %1 -d %2 -N -T -e %5\_AccRgED677_unload_error.log -o %5\_AccRgED677_unload_report.log

П 3

sqlcmd -S %1 -d %2 -Q "TRUNCATE TABLE [%2].[dbo].[_AccRgED677]" -o %5\_AccRgED677_truncate_report.log

П 4

sqlcmd -S %1 -d %2 -Q "ALTER INDEX _AccRgED677_ByRecorder_RNN ON [%2].[dbo].[_AccRgED677] DISABLE"

sqlcmd -S %1 -d %2 -Q "ALTER INDEX _AccRgED677_ByExtDim_RR ON [%2].[dbo].[_AccRgED677] DISABLE"

П 5

bcp [%2].dbo.[_AccRgED677] IN %5\_AccRgED677.bcp -a 16384 -b 10000 -h "TABLOCK" -S %1 -E -N -T -e %5\_AccRgED677_load_error.log -o %5\_AccRgED677_load_report.log

П 6

sqlcmd -S %1 -d %2 -Q "ALTER INDEX _AccRgED677_ByRecorder_RNN ON [%2].[dbo].[_AccRgED677] REBUILD"

sqlcmd -S %1 -d %2 -Q "ALTER INDEX _AccRgED677_ByExtDim_RR ON [%2].[dbo].[_AccRgED677] REBUILD"

П 7

Пересчет итогов

 

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

Есть один принципиальный момент – это сортировка загружаемых данных – она должна соответствовать сортировке кластерных индексов , от этого зависит фрагментация кластерного индекса и скорость. Далее цитата из ссылки про bcp

«The sort order of the data in the data file. Bulk import performance is improved if the data being imported is sorted according to the clustered index on the table, if any. If the data file is sorted in a different order, that is other than the order of a clustered index key, or if there is no clustered index on the table, the ORDER clause is ignored. The column names supplied must be valid column names in the destination table. By default, bcp assumes the data file is unordered. For optimized bulk import, SQL Server also validates that the imported data is sorted.»

Минус у такой методики один – невозможность в BCP делать сжатые бэкапы таблиц. Размеры *.bcp файлов получаются большими, при том, что там только данные без индексов

Дальше одни плюсы

  1. Место для *.bcp файлов может быть где угодно, на любых носителях и сетевых дисках
  2. Время только тратится на выгрузку и загрузку
  3. Можно параллельно выгружать\загружать разные таблицы увеличивая общую скорость
  4. Сразу решатся вопрос с фрагментацией , а ее нужно решать при любых вариантах
  5. Можно использовать сложные выборки для актуальных данных учитывая даты оплаты и поставки.

Для большей скорости Вам нужно использовать большие размеры пакетов в BCP (параметр -a_ ) .

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

Анонс:  Увеличить широту пропускания сети либо технологиями Teamed Lan либо используя сетевые карты  с технологией RDMA. В целом настройка сети это тема отдельной статьи

Анонс: Практическая реализация подсистемы очистки это хорошая тема для отдельной статьи.

 

Коллективная ответственность за вес базы, мифы и реальность?

 

 

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

  • FrontOffice (где заключаются сделки, контракты, оформляются продажи)
  • BackOffice (где производятся взаиморасчеты, отражается работа по контрактам и закрытие продаж)
  • Финансовый  учет
  • Управленческий учет

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

  1. Во-первых, это все нужно обработать в регламентное время на всех уровнях без ночных смен сотрудников
  2. Во-вторых, хранить на избыточных RAID, которые тянут за собой много другой ИТ инфраструктуры

 

И этот момент хорош для внедрения агрегирования операций хотябы на уровне BackOffice – Фин\Упр учет иначе в потоке данных потонут все ИТ отделы, и это хорошая мотивация. Агрегация это непростой вопрос, поскольку она должна обязательно позволять обратную расшифровку и обновятся при изменениях задним числом.

Анонс: Варианты агрегации с расшифровкой это тема отдельной статьи.

Теперь можно подвести итоги:

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. МихаилМ 28.07.22 16:58 Сейчас в теме
Феодальное мышление в ит автору мешает.
непонятно кто автор: админ бд или программист.
как автор допустил такие времена резервирования-восстановления.
автор рассмотрел базы не как админ , а как прикладник.
дискового пространства должно быть как грязи.
похоже бд смешанного типа олап-олтп. это и удобство и проблема.



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

посмотрел размер таблиц - база микроскопическая - несколько гигабайт. обычно проблемы начинаются с стократ большего.
kser87; Gilev.Vyacheslav; Светлый ум; palsergeich; Ilia_Bastrykin; +5 Ответить
3. 1CUnlimited 84 28.07.22 17:53 Сейчас в теме
(1)
(1)
посмотрел размер таблиц - база микроскопическая - несколько гигабайт. обычно проблемы начинаются с стократ большего.

Непонятно какая у Вас функциональная роль на работе (менеджер, программист , администратор?) , но с цифрами невнимательны
Пример самая большая таблица с индексами которую я привел - 935 854 848 Кб это 892 Гб .
А цифры это важно, для всех
И там только топ таблиц.
Времена резервирования - восстановления не допускаются , а согласовываются. Напр фронт и бэк требуют короткого времени восстановления поэтому в MS SQL применяют Always on , а в Oracle stand by database на резервном сервере.
Для Фин,Упр учета где всеравно идут пересчеты Т-3 политика более либеральна.
Когда решение с горизонтальным маштабированием по нагрузке см предыдущую https://infostart.ru/1c/articles/1683197/ решение типа Always on потребует хорошего пространства для хранения архиво transaction log (ms sql ) или redo log (oracle)
Кстати по поводу
(1)
дискового пространства должно быть как грязи.

оно недешевое у HP даже если это HDD , а почему некоторые компании выбирают брендовое а не сборку РФ вендоров это управленческий вопрос. Хотя я мне нравится сервис\и надежность HP пусть оно было недешево.
А капиталистический подход как раз требует чтобы ИТ директор снижал всеми силами cost ownership иначи RAID на всех не напасешься.
14. redfred 01.08.22 07:53 Сейчас в теме
(3)
Напр фронт и бэк требуют короткого времени восстановления поэтому в MS SQL применяют Always on , а в Oracle stand by database на резервном сервере


Погодите, а как соотносится восстановление и Always on?
17. 1CUnlimited 84 01.08.22 12:50 Сейчас в теме
(14) always on это не просто реплика это способ восстановления после сбоя https://docs.microsoft.com/ru-ru/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-ver16
Чем то напоминает standby database у oracle


"Первичная реплика делает базы данных-источники доступными для соединений с клиентами для чтения и записи. первичная реплика отправляет записи журнала транзакций каждой базы данных-источника в каждую базу данных-получатель. Этот процесс, называемый синхронизацией данных, происходит на уровне базы данных. В каждой вторичной реплике кэшируются записи журнала транзакций (фиксируется журнал), а затем эти записи применяются в соответствующей базе данных-получателе. Синхронизация данных выполняется между базой данных-источником и каждой подключенной базой данных-получателем независимо от остальных баз данных. Поэтому приостановка или сбой базы данных-получателя не затрагивает другие базы данных-получатели, а приостановка или сбой базы данных-источника не затрагивает остальные базы данных-источники."
18. redfred 01.08.22 14:49 Сейчас в теме
(17) Ну, грубо говоря, это RAID для базы. А RAID, как известно, не бэкап. Т.е. если кто-то поудаляет документы на мастере, они точно так же поудаляются на репликах, разве нет? И где тут короткое время восстановление, про которое вы пишете, если всё равно придется поднимать полноценный бэкап?
24. 1CUnlimited 84 01.08.22 16:50 Сейчас в теме
(18) Восстановление до нужной Recovery point (времени в прошлом) делают на практике только, если был непоправимый сбой (напр медленно падал диск с bad блоками, которые развалили таблицы бд) . Из за пользователя который поудалял что нибудь - такое будут делать только в случае временной выгоды (ведь нужно еще всех уговорить переввести данные от Recovery point till now) и отсуствия конфликтов интересов (напр. с клиентом).
Always on в асинхронном режиме по сути равен Standby database в Oracle и можно управлять запаздыванием в асинхронности.
У microsoft и oracle решения на эту тему похожи, но картинки у Oracle интересне см
https://www.oracle.com/a/tech/docs/cloud-maa-overview.pdf
20. nicxxx 241 01.08.22 15:58 Сейчас в теме
(1)Глаза режет. Сначала научитесь писать грамотно по-русски, используя знаки препинания и нужные падежи.
2. МихаилМ 28.07.22 17:35 Сейчас в теме
"см мою старую статью на эту тему http://selis76.narod.ru/matnetw1.html#bookmark1"
статья недописанная - только введение.
4. 1CUnlimited 84 28.07.22 17:56 Сейчас в теме
(2)
Там если по содержанию слева прокликать все выводится, я когда то написал ее в WebMaker нужно освежить.
5. Virikus 59 28.07.22 19:34 Сейчас в теме
Немного непонятно сколько времени занимает копирование данных за 2022 год и обратно. Если таблица большая, значит полчаса на это не хватит, а при таких объемах технологическое окно как правило не более полчаса в сутки. И тут секционирование более выгодно смотрится. Там можно спокойно удалять старые данные в процессе работы пользователей.
1CUnlimited; +1 Ответить
6. 1CUnlimited 84 28.07.22 20:09 Сейчас в теме
(5) Мы можем обеспечить себе технологическое окно в воскресенье 100% + субботу если необходимо. Скорость копирования зависит от носителя + скорость сети куда копируешь. Еще заметьте при таком способе через BCP , сохраняется меньше данных чем удаляется.
Не помню точных цифр но полную свертку остатков по регистру бухгалтерии с удалением лишнего + пересчет делали часов за 6

Но если технологические окна очень маленькие, то да секционирование без вариантов. Просто в 1С все всеравно все не секционируешь (банально документ с табчастью или регистр бухгалтерии), как следствие делать систему 24\7 на основе 1С бессмысленно с точки зрения архитектуры.
9. Virikus 59 29.07.22 16:27 Сейчас в теме
(6) Тогда не совсем понятно на какую группу статья расчитана, если у вас есть технологическое окно в часть субботы и воскресенья, то спокойно можно делать delete с отбором, никто все равно не мешает. Для небольших предприятий с большими базами так даже удобней, скрипты будут проще и контроль за ними требует меньше подготовки от специалиста. Даже удалять можно в 100 потоков, если отключить табличные и страничные блокировки и отбор накладывать например по неделе.

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

Подход конечно интересный, но судя по таблице у вас там в основном регистры сведений. Может стоит немного архитектуру поменять? Например хранить буфер сообщений не 2 месяц, а например 3 дня или сколько вам необходимо, для разбора обращений. Или выгружать часть данных в сторонние системы, а по мере надобности через web, http их получать. 5Tb конечно база не маленькая, но и не такой прямо великий размер, чтобы создавались большие неудобства для работы с ней.
10. 1CUnlimited 84 30.07.22 07:24 Сейчас в теме
(9) к bcp мы пришли именно на удалении движений регистра бухгалтерии после свертки средствами 1с. Весь цикл еле укладывался в выходные и запаса на рост данных не было. Bcp сразу много проблем решает.
Вы не можете растянуть удаление после свертки остатков на несколько техно окон. Тоже для регистров опер учета
Регистры сведений/документв можно чистить порционно по выходным с распарралеливанием.
Но потом Вам нужно большое тех окно на устранение фрагментации
Вы еще бонусом получаете мощную обработку для создания тестовых баз
Те у кого маленькие окна должны в архитектуре закладывать обслуживание бд частями что кстати bcp метод позволяет
Есть еще один момент связанные обьекты напр по ведущему измерению - обычным удалением это будет еще дольше
По поводу удаления в 100 потоков вы просто посмотрите на waits
P S буфер это просто sql база вне 5тб 1с. Там xml запросы и скорость импорта обеспечивается. Он партицирован
Как нибудь про него отдельную статью напишу
11. 1CUnlimited 84 30.07.22 07:31 Сейчас в теме
(9) Статья прежде рассчитана на тех кто хочет знать техпределы 1с и кому надоела неповоротливая база :)
7. the1 1105 28.07.22 21:58 Сейчас в теме
5Tb! Мое почтение)) Максимум 100Гб база, которую обслуживал. Ну и один раз видел базу в 1.5Тб =)
NeLenin; smit1c; 1CUnlimited; +3 Ответить
8. 1CUnlimited 84 28.07.22 23:20 Сейчас в теме
(7) Импортозамещение скоро сделает большие размеры баз 1C частым являением :)
METAL; SergeyTerentyev; NeLenin; Krotov_Valery; the1; +5 Ответить
12. CheBurator 3073 30.07.22 19:26 Сейчас в теме
" в целевые сроки восстановления (Recovery Time Objective) и согласуются с Business continuity planning"
Business continuity planning - синонима на вменяемом русском не нашлось?
13. 1CUnlimited 84 31.07.22 15:04 Сейчас в теме
(12) термины это не только слова это еще методика / решения которую разрабатывают за бугром . Поэтому стараюсь приводить их в исходном виде чтобы было проще найти. Когда Россия будет ИТ лидером
мы сможем насаждать свои термины как со спутником
15. Nikola23 653 01.08.22 10:35 Сейчас в теме
Партицирование таблиц средствами платформы обещали в 23м релизе.
Может быть будет полезным, может нет для задачи урезания БД.
Будем посмотреть.
16. 1CUnlimited 84 01.08.22 11:55 Сейчас в теме
(15)а есть ссылки на источники? Просто для регистра сведений и справочников 1с может это сделать без изменения структуры таблиц, а для остальных метаданных уже придется фундаментально менять
21. nicxxx 241 01.08.22 16:04 Сейчас в теме
(16) "Управление табличными пространствами базы данных (возможность размещения части БД на самом быстром диске) "
https://wonderland.v8.1c.ru/blog/obnovlyen-plan-zadach-na-versiyu-8-3-23-platformy-1s-predpriyatie-4/
23. kembrik 3 01.08.22 16:38 Сейчас в теме
(21) Так партицирование немного про другое, нет?
CRE ATE   TABLE bigtable_y2021m03 (   
    CHECK (created_at >= '2021-03-01'::DATE AND created_at < '2021-04-01'::DATE) 
  ) INHERITS (bigtable);
CRE ATE   TABLE bigtable_y2021m04 (    
    CHECK (created_at >= '2021-04-01'::DATE AND created_at < '2021-05-01'::DATE)  
  ) INHERITS (bigtable);


Вот тут партицирование - третий квартал отдельно, четвертый отдельно - к Airflow раздельно прикрутили и наслаждаемся

А то что 1С в 23 платформе предлагают - условно говоря отдельные таблички, скажем бинарники с содержимым файлов в отдельные БД вынести
29. 1CUnlimited 84 02.08.22 11:37 Сейчас в теме
(23)

(23)
Вот тут партицирование - третий квартал отдельно, четвертый отдельно - к Airflow раздельно прикрутили и наслаждаемся


Делить таблицы с Airflow итересная вещь, с точки зрения автоматизации скриптов. Но непонятно как 1С будет иметь доступ к таким таблицам. Ведь в теории можно их во view объединить с именем таблицы 1С, но оно будет неполноценно для всех операций
(могу только для MS SQL утверждать, Postgres не изучал)
https://docs.microsoft.com/en-us/sql/relational-databases/views/modify-data-through-a-view?view=sql-server-ver15

Партицирование реализовано по более продвинутой идеологии (кратко с примером тут)

https://habr.com/ru/post/464665/?ysclid=l6bx25fkez388567642
25. 1CUnlimited 84 01.08.22 16:59 Сейчас в теме
(15)
(21) Я тут погуглил по термину ""Управление табличными пространствами базы данных" и нашел свежее
https://wonderland.v8.1c.ru/blog/segmentatsiya-dannykh/?ysclid=l6at8zdglq290137106
Короче это банальное разделение таблиц и индексов по разным файловым группам, и к партицированию вообще не имеет отношение.
27. nicxxx 241 02.08.22 05:52 Сейчас в теме
(25) (23) Киберпанк, который мы заслужили :)
Пусть хоть это будет...
evgeniti; 1CUnlimited; +2 Ответить
35. evgeniti 08.08.22 18:00 Сейчас в теме
(27) когда-нибудь будет всё в 1с. И свистелки и прочие п..ремудрости.
19. Velifer 01.08.22 15:54 Сейчас в теме
Тю, я б ваши 5 терабайт за ночь свернул бы готовым отлаженным за 7 лет решением и методикой с контролем ссылок, без какого либо битья

Простой минимальный, конфа любая, целостность базы полная, таблицы - любые

Но есть люди принципиальные - тратят месяцы своего времени и на порядки большие деньги компании, чтобы сделать свой велосипед, сначала моноколесо, потом трехколесный, потом четыре колеса ... в общем, проходя все ошибки предшественников
22. redfred 01.08.22 16:21 Сейчас в теме
(19) Где можно почитать про ваше решение?
26. Velifer 01.08.22 18:39 Сейчас в теме
(22) Если интересно, напишите в личку.
Но вообще я много про свои методики рассказываю и не один год.
Сейчас я минимум одну новую базу в месяц сворачиваю, от 80 Гб до нескольких терабайт

Всегда укладываюсь при этом в технологическое окно

Также несколько лет разрабатываю решения для разделения и слияния баз 1С

Например, вы хотите выделить некоторые организации в отдельный узел РБД или просто продать часть бизнеса и отдать базу.
Я это делаю за 30-40 минут

Или наоборот, хотите сделать слияние распределенной базы. Я это делаю обычно за ночь.
Решения проверенные, так что всем желающим могу помочь :)
Светлый ум; +1 Ответить
36. evgeniti 08.08.22 18:40 Сейчас в теме
(26) Глядишь, придет время и можно будет в менеджере пакетов выбрать пакет MegaChistka авторства топикстартера, вашей или чьей-нибудь ещё и каждый сможет свернуть 100 тб базу.
28. olexandrit 02.08.22 11:01 Сейчас в теме
(26) Добрый день! Где можно почитать про Вашу методику? Спасибо.
30. 2tvad 68 03.08.22 23:05 Сейчас в теме
Странно. Если у вас это торговые операции, то маржа вполне должна позволить поставить очень хорошее оборудование.

Хотя я сталкивался с тем, что дилинговые операции тянули в бухгалтерию.

А вы не пробовали решить задачу от обратного, т.е. создавать базу на каждый год, путём переноса справочников и остатков?
31. 1CUnlimited 84 04.08.22 09:10 Сейчас в теме
(30) обрудование очень хорошее. Еще в 14 году raid из 2 тб ssd и 5 тб hdd и все HP. Новый кластер 2021 года еще лучше.
Просто учитывать приходилось операции 4 систем и никто не хотел давать direct access для расшифровок из системы источника даже внутри компании. Это для крупных ит систем не просто.
Перенос в новую базу сложнее -нужно все подсистемы сворачивать и резать одновременно. А так это можно делать по частям. В файловых группах появится свободное место. Да самим группам shrink file будет сделать проблематично изза разбросанных экстентов, но достаточно держать базу в фиксированном размере и этого достаточно
32. 2tvad 68 04.08.22 14:21 Сейчас в теме
(31) Еще в 14 году raid из 2 тб ssd и 5 тб hdd и все HP.

У меня домашний сервер - 8 дисков sas в 6 рейде + ssd nvme PCI RAID 0 под базы. Ну это под меня одного =)

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

перенос вам нужен только справочников и остатков. Сворачивать и резать не обязательно.
33. 1CUnlimited 84 04.08.22 16:12 Сейчас в теме
(32)
(32)
перенос вам нужен только справочников и остатков. Сворачивать и резать не обязательно

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

И не сравнивайте серверные SSD и домашние SSD они очень разные. При тех IOPS которые у нас за 8 лет ни один не вылетел, а на персоналках падают регулярно
- просто посмотрите картинку не самого лучшего и ценники
https://buy.hpe.com/emea_europe/en/options/drives-storage/solid-state-drives/storage-solid-state-drives/hpe-msa-1-92tb-sas-12g-read-intensive-sff-2-5in-m2-3yr-wty-ssd/p/r0q47a
34. kser87 2265 05.08.22 17:06 Сейчас в теме
37. kembrik 3 09.08.22 17:05 Сейчас в теме
(29) У нас задача немного не такая. Есть управленческий регистр накопления, который в 1С хранить нет необходимости да и незачем. Есть симулякр создание движения по этому регистру "как нам надо"

В Postgres создаем мастер-таблицу и к ней дочерние партиции наследованием (inherits), в 1c сервис со справочником, где СКД-шки к нужным данным с периодом "между".

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

Но вот касательно к теме "похудения" наш вариант отношения не имеет, у нас задачи чуть другие)
1CUnlimited; +1 Ответить
Оставьте свое сообщение

См. также

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

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

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

22.04.2015    45929    Gilev.Vyacheslav    1    

Workaround me в 1С/MS SQL и не только, системный подход к созданию костылей

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

Workaround свидетельствует о невозможности решить проблему "правильным путем" и вызывает чувство стыда. Но практика показывает, что способность решать проблемы через workaround является порой единственным способом решить проблему в разумное время. А победителей, как говорят, не судят, так почему бы не создавать workaround по системе?

15.08.2022    307    1CUnlimited    0    

Ускорим проведение в 1С:Управление холдингом

HighLoad оптимизация Запросы v8 УХ Бесплатно (free)

В 1С:Управление холдингом есть "нехороший" запрос, который съедает значительную часть времени проведения документов. Если его подправить, то проведение заметно ускорится.

10.08.2022    3175    sapervodichka    37    

Миссия невыполнима. Общие реквизиты разделители против временных таблиц

HighLoad оптимизация Механизмы платформы 1С v8 1cv8.cf Бесплатно (free)

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

05.08.2022    810    1CUnlimited    0    

Видеодемонстрация применения Теста-центра для нагрузочного тестирования конфигураций Промо

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

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

16.09.2012    36977    Aleksey.Bochkov    29    

Экспертный взгляд на оптимизацию производительности на примере исправления и декомпозиции запроса

HighLoad оптимизация Технологический журнал Мониторинг Запросы v8 ERP2 УТ11 КА2 Бесплатно (free)

Еще один интересный пример оптимизации производительности ERP. Описываем решение проблемы подробно по шагам.

20.07.2022    2798    ivanov660    17    

Экспертный кейс. История расследования одного небыстрого закрытия месяца в 1C:ERP. Пример неочевидных путей расследования в виде детективной истории

HighLoad оптимизация Механизмы платформы 1С Запросы v8 ERP2 Бесплатно (free)

В данной статье хотим рассказать об одном нашем непростом расследовании, в котором удалось собрать сразу несколько проблем на разных уровнях инфраструктуры заказчика и изначальной методологии ведения учета. Само расследование в какой-то момент стало напоминать детективную историю, с роялями в кустах, ошибками платформы, странным поведением пользователей и магическим поведением хорошо знакомых механизмов. Но мы реалисты, поэтому все проблемы были выявлены и устранены ;)

11.07.2022    3923    it-expertise    27    

Производительный режим работы RLS

HighLoad оптимизация Роли и права v8 8.3.14 8.3.6 8.3.8 ERP2 БП3.0 КА2 Бесплатно (free)

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Каждый из режимов имеет свои преимущества и недостатки относительно другого. Основные из них будут рассмотрены в данном материале.

14.06.2022    2813    Neti    6    

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

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

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

22.01.2014    70681    yuraos    112    

Любовь. Быстродействие. 1С

HighLoad оптимизация v8 Бесплатно (free)

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

26.05.2022    2870    vasilev2015    20    

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

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

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

24.05.2022    2994    avolsed    15    

Исправляем проблемы производительности в конфигурации ERP - 7 примеров

HighLoad оптимизация v8 ERP2 УТ11 КА2 Бесплатно (free)

Злободневные примеры поиска и исправления проблемных мест в конфигурациях ERP/УТ/КА на СУБД Postgres.

23.05.2022    3245    ivanov660    25    

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

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

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

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

Заметки эксперта. Расследование длительного выполнения отчета “Движение ТМЦ и затрат в производстве” (1С:ERP 2)

HighLoad оптимизация v8 ERP2 Бесплатно (free)

Кратко: в ходе проведения нагрузочного тестирования “1С:ERP 2” под ОС Linux на СУБД Postgres выявлено существенное замедление формирования отчета “Движение ТМЦ и затрат в производстве” - до 60 минут. После проведенного расследования и точечной корректировки СКД в отчете, без изменения бизнес-логики результатов его работы, работа отчета была ускорена в 80 раз - средний показатель формирования составил 30 секунд.

19.05.2022    1602    it-expertise    19    

Тестирование - игровое моделирование

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

Мы рассмотрим подход к тестированию с применением элементов искусственного интеллекта

25.04.2022    1047    ivanov660    0    

Несколько слов про платформенный механизм оптимизации RLS

HighLoad оптимизация v8 Бесплатно (free)

Смотрим, как работает платформенный механизм оптимизации RLS, сравним поведение на разных СУБД MS SQL, Postgres 11,13,14.

07.04.2022    2932    ivanov660    21    

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

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

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

19.02.2013    62410    Gilev.Vyacheslav    46    

Почему после обновления Бухгалтерии в марте 2022 года отчеты стали такими медленными

HighLoad оптимизация v8 v8::БУ БП3.0 БУ Бесплатно (free)

Статья раскрывает причину, почему время формирования отчетов после обновления Бухгалтерии в марте 2022 сильно увеличилось. И рассказывает, как можно исправить ситуацию.

05.04.2022    3707    DBOdin_Lab    30    

Экспертный кейс. Расследование фатального замедления времени расчета себестоимости в 1С:ERP 2

HighLoad оптимизация Механизмы типовых конфигураций Запросы v8 ERP2 Бесплатно (free)

При выполнении нагрузочного тестирования информационной системы на базе 1С:ERP для одного из клиентов с целью оценки возможности миграции системы на PostgreSQL и Astra Linux мы столкнулись с неприемлемым увеличением времени выполнения расчета себестоимости. Строго говоря, сценарий тестирования закрытия месяца не был выполнен вообще – он не укладывался в таймаут выполнения теста, 24 часа. По прошествии 18 часов всё ещё шло выполнение операции «Распределение затрат и расчет себестоимости». Более 16 часов выполнялся подэтап “Расчет партий и себестоимости. Этап. Расчет себестоимости: РассчитатьСтоимость”. Всё это время выполнялся запрос, который в текущей инфраструктуре клиента (СУБД MS SQL Server) выполняется чуть более 3 минут на аналогичных данных.

25.03.2022    3886    it-expertise    92    

Экспертный кейс. Расследование деградации производительности системы. Проведение документа “Поступление товаров и услуг” (1С:ERP 2)

Механизмы платформы 1С Запросы HighLoad оптимизация v8 ERP2 Бесплатно (free)

В ходе проведения нагрузочного тестирования одним из наших клиентов была выявлена сильная деградация производительности системы в целом и, в частности, выполнения ключевой операции “Проведение документа поступление товаров и услуг” в течение выполнения теста. Согласно данным подсистемы БСП “Оценка производительности”, время выполнения ключевой операции “Проведение документа поступление товаров и услуг” возрастало в процессе тестирования с 15-20 секунд в начале тестирования до 150-200 секунд в его финале.

02.03.2022    3205    it-expertise    47    

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

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

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

11.02.2013    38691    gallam99    19    

Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками

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

Рассмотрим по шагам процесс обнаружения, анализа и решения проблемы производительности на примере базы ERP, сравним отличия в работе Postgres и MS SQL.

28.02.2022    8604    ivanov660    18    

Ускорение работы конфигуратора 1С с большими прикладными решениями

HighLoad оптимизация v8 Бесплатно (free)

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

13.01.2022    5991    stg2005    105    

Ошибка производительности при проведении этапа 2.2 в ERP 2.4 и ERP 2.5

HighLoad оптимизация v8 ERP2 Россия Бесплатно (free)

Хочется поделиться одним подводным камнем, с которым могут встретиться другие пользователи ERP. Искал решение в интернете, но ничего похожего не нашел. Поэтому решил создать эту тему.

06.12.2021    1318    Rokky78    6    

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

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

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

03.11.2012    45854    madmpro    32    

Повышение производительности веб-сервисов. Переиспользование сеансов

WEB HighLoad оптимизация v8 Бесплатно (free)

Повышение производительности веб-сервисов. Переиспользование сеансов. Практическая реализация.

20.10.2021    3309    sorter1    2    

Оптимизация проведения документов списания партий в УПП 1.3

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

Почти в каждой конфигурации УПП 1.3 (возможно, и в УТ 10.3) есть медленный запрос, тормозящий проведение документа списания. Данная публикация раскрывает места вызова данного запроса и приводит пример оптимизации. Пример показывает результаты проведения документа «Реализация товаров и услуг», но метод работает и для других документов списания партий.

09.09.2021    1063    info1i    5    

Смотрим запросы 1С через Microsoft SQL Profiler по следам ошибок разработчиков, приводящих к проблемам производительности

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

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

07.09.2021    8646    ivanov660    26    

Свернуть базу и не свернуть себе шею

Свертка базы v8 1cv8.cf Бесплатно (free)

Текст из серии «Письма клиентам», на тему «Свёртка информационной базы»

18.08.2021    15349    1c-intelligence    78    

Адекватный параллелизм в 1С

HighLoad оптимизация v8 Бесплатно (free)

Параллелизм ускоряет выполнение тяжелых регламентных операций на СУБД, но может негативно влиять на работу многопользовательских учетных систем. О том, как анализировать влияние параллелизма и настраивать его для MS SQL и PostgreSQL, рассказал ведущий разработчик компании ООО МКК «Ваш Инвестор» Вадим Фоминых.

13.08.2021    8679    Shmell    7    

Распространенные ошибки разработчиков, приводящие к проблемам производительности

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

Рассмотрим примеры ошибок, анализ, исправление и мероприятия по недопущению подобного в будущем. Всего будет 18 примеров.

02.08.2021    13231    ivanov660    77    

Parameter sniffing и генерация планов для разработчиков 1С

HighLoad оптимизация v8 Бесплатно (free)

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

01.06.2021    12242    vasilev2015    17    

Поиск причин блокировок СУБД

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

Расследование блокировок СУБД. Статья написана по мотивам вебинара Виктора Богачева.

28.04.2021    7068    vasilev2015    13    

Тонкости эксплуатации, плюшки и особенности Postgres Pro Enterprise

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

В ходе онлайн-встречи INFOSTART MEETUP Novosibirsk Руководитель ИТ из компании ИнфоСофт Антон Дорошкевич поделился с коллегами тонкостями и опытом работы с Postgresql для 1С. 

22.04.2021    5329    a.doroshkevich    5    

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

HighLoad оптимизация v8 Бесплатно (free)

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

24.03.2021    6534    AlexKriulin    37    

Соединение вложенными циклами

HighLoad оптимизация v8 Бесплатно (free)

Nested loops и отсутствующие индексы. Статья написана по мотивам вебинара Виктора Богачева.

12.03.2021    4300    vasilev2015    22    

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

HighLoad оптимизация v8 Бесплатно (free)

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

09.02.2021    1338    pashamak    2    

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

HighLoad оптимизация v8 Бесплатно (free)

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

18.12.2020    4681    zhichkin    11    

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

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

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

07.10.2020    6345    ivanov660    13    

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

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

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

02.10.2020    6230    Iaskeliainen    16    

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

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

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

14.09.2020    2430    capitan    25    

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

HighLoad оптимизация v8 Бесплатно (free)

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

20.07.2020    3114    Филин    7    

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

HighLoad оптимизация v8 Бесплатно (free)

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

18.05.2020    2971    Aleksey.Bochkov    4    

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

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

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

06.04.2020    20912    YPermitin    0    

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

HighLoad оптимизация v8 Бесплатно (free)

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

03.04.2020    11403    feva    15    

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

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

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

31.03.2020    17412    informa1555    35    

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

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

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

31.03.2020    4299    vasilev2015    12