В базе «Бухгалтерии предприятия КОРП 3.0» закрытие месяца занимало больше трёх часов. Почти всё это время уходило на перепроведение 40 тысяч документов. Регламентные операции после перепроведения выполнялись за 32 секунды.
База принадлежит розничной сети. Объём — около 70 ГБ, одна организация, большой поток поступлений по эквайрингу. Используется PostgreSQL под Linux, платформа 1С:Предприятие 8.3.27, оценка МПЗ по ФИФО. Во время перепроведения сервер 1С с 14 ядрами в основном использовал одно ядро.
Начали с проверки PostgreSQL: чтение с диска, временные файлы, блокировки, состояние таблиц и индексов. По результатам замеров основная задержка оказалась в проведении документа «Поступление на расчётный счёт». Для большинства поступлений по эквайрингу типовой код запрашивал остаток задолженности, хотя в проверенном варианте учёта результат запроса не менял суммы по счетам и субконто.
Разработали два расширения:
Расширение 1 - «Оптимум» исключает из запроса строки платежа, для которых остаток не нужен.
Расширение 2 - «Независимость» исключает из повторного проведения часть уже проведённых поступлений по эквайрингу. Для каждого расширения заданы отдельные условия применения; ниже разобраны и сами условия, и результаты сверки движений.
На полном мае получили следующие результаты:
|
|
|
|
|
|
|
|
|
|
|
|
Эти три замера выполнены ночью в одной базе. Перед каждым запуском последовательность нарушали одним и тем же документом. Для серии использовали второй сервер СУБД: 4 ядра, 31 ГБ памяти, synchronous_commit = off. Сервер приложений 1С оставался тем же. Условия серии существенны для сравнения: приведённое время нельзя напрямую переносить на другой сервер или на закрытие при работающих пользователях.
Что выполняется при закрытии месяца
Первым этапом помощник закрытия запускает обработку ГрупповоеПерепроведениеДокументов. Она обрабатывает документы от момента нарушения последовательности до конца месяца.
В разобранном коде это одно фоновое задание. Обработка последовательно обходит месяцы, организации и документы. Документы выбираются в порядке Дата, Ссылка; для каждого вызывается Записать(РежимЗаписиДокумента.Проведение). Состояние документа в последовательности ДокументыОрганизаций записывается отдельной транзакцией. Перед перепроведением регламентные операции отменяются, после успешного завершения выполняются заново.
Если один из документов не проводится, восстановление последовательности не завершается и до регламентных операций закрытие не доходит. Поэтому перед длительным запуском имеет смысл отдельно разобрать известные ошибки проведения.
В этой базе в последовательность входят 38 видов документов из 55. Организация одна, поэтому распределение работы по организациям здесь ничего не даёт. Произвольно разделить документы между фоновыми заданиями тоже нельзя: проведение использует остатки, сформированные предыдущими документами, в том числе для ФИФО и взаиморасчётов. Для параллельного выполнения пришлось бы менять алгоритм и отдельно проверять зависимости между документами. Настройки числа рабочих процессов такой задачи не решают.
Параллелизм PostgreSQL в исследованном запросе также не помог. Отдельный SELECT выполнялся с тремя параллельными рабочими процессами, а тот же запрос в составе INSERT INTO pg_temp … SELECT — без них. Именно в такую конструкцию в данном случае преобразовывался запрос 1С с ПОМЕСТИТЬ. На запросы этого класса приходилось 86 % времени СУБД при перепроведении.
Проверили и типовой механизм отложенного проведения — настройку «Расчёты выполняются при закрытии месяца». При его использовании расчёты с контрагентами выполняются пакетом по договорам, вместо запроса задолженности при проведении каждого платёжного документа.
В исследованной конфигурации доступность механизма проверяет функция ПроведениеСервер.ИспользуетсяОтложенноеПроведение. В нашей базе проверка возвращала Ложь из-за способа оценки МПЗ: используется ФИФО, а требуется оценка по средней. Менять учётную политику ради ускорения перепроведения мы не стали. Кроме того, изменение этой настройки затрагивает проверку актуальности данных учёта, поэтому включать её только для эксперимента без разбора последствий не следует.
На какие документы уходило время
В типовом варианте перепроведение мая заняло 3 ч 06 мин 21 с. Обработано 40 398 документов, среднее время — 277 мс на документ. Распределение по основным видам документов:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Время по видам документов оценивали по журналу регистрации, используя моменты начала транзакций. Точность этих отметок — одна секунда. Для отдельного документа такой способ непригоден, но на нескольких тысячах документов позволяет оценить распределение времени. На стенде за июль результат был похожим: 39 807 документов за 2 ч 22 мин, доля поступлений на расчётный счёт — 59 %.
После этого сузили сбор данных до проведения банковских документов. По pg_stat_statements выделили дорогой шаблон запроса, через auto_explain получили его план, а по свойству Context технологического журнала нашли вызывающий код 1С:
Документ.ПоступлениеНаРасчетныйСчет.МодульОбъекта
УчетВзаиморасчетов.ПодготовитьТаблицуВзаиморасчетовПогашениеЗадолженности
УчетВзаиморасчетов.ПолучитьОстаткиЗадолженности
На прицельном прогоне двух дней запрос выполнился 1 327 раз, в среднем примерно за 140 мс. На него пришлось около 70 % времени СУБД этого прогона. Возвращалась одна строка, но для её получения план обрабатывал одну строку итогов и 19 797 строк движений. Число обращений к страницам буферов на одно выполнение — 102 436. Данные находились в кэше; основная работа выполнялась на процессоре.
В коде 1С это обращение к виртуальной таблице остатков регистра бухгалтерии Хозрасчетный с отбором по организации, контрагентам и договорам:
|ПОМЕСТИТЬ втОстатки
|ИЗ РегистрБухгалтерии.Хозрасчетный.Остатки(
| &МоментВремениОстатков,
| Счет В (&СчетаКонтрагентыДоговоры),
| &ВидыСубконтоКонтрагентыДоговоры,
| Организация = &Организация
| И Субконто1 В (&Контрагенты)
| И Субконто2 В (&Договоры)) КАК Остатки
Почему запрос обрабатывает столько движений
В исследованном плане остаток на момент документа рассчитывался от месячного итога с учётом движений между документом и концом месяца. При обычном вводе текущих документов таких последующих движений немного. При перепроведении закрытого месяца ситуация другая: для документов начала месяца приходится обрабатывать почти все движения договора за месяц.
Для одного договора эквайринга получили такое количество движений после момента выписки:
|
|
|
|
|
|
|
|
|
|
|
|
На этот договор приходились 19 555 из 21 474 июльских поступлений на расчётный счёт — около 91 %. Каждое поступление снова запрашивало остаток по тому же договору. При такой структуре данных суммарный объём обработки приближается к квадратичному по числу движений договора: для очередного документа повторно просматривается значительная часть месячного набора.
Этим объясняется и распределение времени по декадам. В мае среднее проведение выписки занимало 358 мс в первой декаде, 304 мс во второй и 249 мс в третьей. К концу месяца проведение ускорялось, поскольку после момента документа оставалось меньше движений.
Для каких платежей остаток не меняет результат
У поступлений по основному договору эквайринга проводка — Дт 51 Кт 57.03. В расшифровке платежа указано автоматическое погашение задолженности, счёт расчётов совпадает со счётом авансов, аналитика по документам расчётов отсутствует.
Типовой алгоритм получает остаток и делит платёж на погашение задолженности и аванс. Однако в этом случае обе части записываются на один счёт с одинаковыми субконто. Результат запроса определяет разбиение суммы на строки, но после свёртки проводок суммы по счетам и аналитике совпадают.
Это наблюдение относится к конкретному набору условий. Само по себе совпадение счёта расчётов со счётом авансов ещё не даёт основания пропускать запрос для любых платежей.
Что показала проверка PostgreSQL
Параллельно с разбором кода проверили, нет ли ограничений на стороне СУБД. Для этого использовали четыре прогона апреля, включая один полный, и ночную серию мая.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
В ночной серии сервер СУБД в среднем использовал 0,55–0,86 ядра из четырёх. Пиковая загрузка рабочего процесса 1С достигала 2,6 ядра. Темп составлял 50–66 фиксаций транзакций в секунду.
По этим данным не было оснований ожидать существенного ускорения от добавления памяти, дисков или ядер. Производительность одного ядра могла повлиять на время, но основная найденная причина — повторный расчёт одного и того же вида остатков при последовательном проведении документов.
Отключение текущих итогов
Отдельно проверили флаг «Текущие» в форме «Управление итогами» регистра Хозрасчетный. В этой базе строки текущих итогов составляли около 1,9 % от числа строк периодических итогов.
При отключённом флаге на одинаковом участке первых 40 минут темп вырос с 46,7 до 54,3 фиксации в секунду, примерно на 16 %. Время самого дорогого запроса сократилось со 138 до 50–57 мс, число обращений к буферам уменьшилось примерно вдвое.
Простой пересчёт итогов при включённом флаге такого результата не дал: темп оставался на исходном уровне. При этом обратное включение текущих итогов требовало их пересчёта, который занимал 35 минут.
С учётом этого времени расчётный порог окупаемости составил около 3 ч 40 мин непрерывного перепроведения. Для одного месяца в наших условиях приём не окупался. Его можно рассматривать для более длинного периода, но только с учётом времени восстановления текущих итогов и доступного технологического окна.
Расширение «Оптимум»: отбор строк перед запросом остатков
Изменение внесено в функцию УчетВзаиморасчетов.ПодготовитьТаблицуВзаиморасчетовПогашениеЗадолженности. Перед вызовом ПолучитьОстаткиЗадолженности расширение отбирает строки расшифровки, для которых требуется остаток.
Фрагмент изменения:
#Удаление
ОстаткиЗадолженности = ПолучитьОстаткиЗадолженности(Параметры.РасшифровкаПлатежа, Реквизиты, Отказ);
#КонецУдаления
#Вставка
ОстаткиЗадолженности = ПолучитьОстаткиЗадолженности(
СтрокиТребующиеОстатков(Параметры.РасшифровкаПлатежа, Реквизиты), Реквизиты, Отказ);
#КонецВставки
Строка исключается из запроса, только если одновременно выполнены следующие условия:
- направление операции — поступление, операция не является возвратом;
- организация не применяет УСН и патент;
- нет учёта по подразделениям;
- расчёты ведутся в рублях;
- счёт расчётов — 57.03;
- счёт расчётов совпадает со счётом авансов;
- отсутствует субконто «Документы расчётов».
Разрешён только счёт 57.03: для него разобран алгоритм и проверены движения. Если после отбора строк не осталось, запрос остатков не выполняется. Не устанавливается и связанная с этим запросом блокировка регистра Хозрасчетный.
Для изменения используется &ИзменениеИКонтроль. Это позволяет обнаружить изменение заимствованной функции при обновлении конфигурации. После обновления всё равно требуется сверить типовой код и проверить расширение на новом релизе.
Результаты замеров
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
В двухдневном прогоне стенда число выполнений исключаемого запроса сократилось с 1 310 до нуля.
В полном мае расширение не изменило количество перепроводимых документов — 40 398. Среднее время документа снизилось с 277 до 192 мс. После перепроведения 15 регламентных операций выполнились за 79 секунд, ошибок не было.
Среднее время выписки по декадам стало практически одинаковым: 118, 121 и 122 мс. Зависимость от даты внутри месяца исчезла вместе с запросом остатков. Время проведения реализаций, списаний, кассовых ордеров и поступлений товаров заметно не изменилось.
Доля поступлений на расчётный счёт сократилась с 53 до 31 % времени перепроведения. Следующим по затратам участком стали реализации: около 565 мс на документ, 29 % общего времени при доле в количестве документов около 10 %. В их проведении используются остатки партий ФИФО; оснований исключать эти расчёты в рамках данной работы не было.
Сверка движений
Результат проверяли по снимкам движений. Для каждой пары «регистр — регистратор» сохраняли число строк и хэш содержимого. Выполняли два сравнения: исходных строк и проводок после свёртки по регистратору, счетам и субконто.
Построчное совпадение получили не везде. На стенде за июль проверили 213 регистров и 11 047 пар «регистр — регистратор». Отличались шесть пар, относящихся к трём выпискам. В этих документах типовой код разделял платёж на погашение и аванс, записывая две строки Дт 51 Кт 57.03 с одинаковой аналитикой. Расширение записывало одну строку на общую сумму. После свёртки различий не осталось.
Для мая сверка с эталонным закрытием охватила 212 регистров, 41 817 регистраторов и 178 089 пар. После свёртки различий также не было. В ночной серии сравнение прогона с расширением и предшествующего состояния дало 11 построчных различий, сравнение с эталоном — три. Различий после свёртки не обнаружено.
Таким образом, на проверенных данных суммы по счетам и субконто сохранились. Количество строк проводок у отдельных выписок изменилось. Это различие нужно учитывать при проверке обработок и отчётов, которые работают с отдельными строками движений.
После установки расширения следует проверить журнал регистрации. В ходе работы встречалась ситуация, когда расширение числилось активным, но из-за безопасного режима перехваты не применялись. По одной отметке активности нельзя судить о том, что изменённый алгоритм действительно выполняется.
Расширение «Независимость»: исключение повторного проведения
Первое расширение сокращает время проведения. Второе уменьшает количество документов, которые требуется провести заново при восстановлении последовательности.
Рассматривали поступления по платёжным картам без комиссии банка, с проводками только Дт 51 Кт 57.03. Для проверенного варианта документа суммы этих проводок задаются самим поступлением. Если прежнее состояние документа также удовлетворяет условиям проверки, повторное проведение не требуется для пересчёта себестоимости или распределения платежа по задолженности.
В типовом алгоритме индивидуальное проведение такого документа всё равно устанавливает состояние «проведён с нарушением последовательности». При следующем закрытии обработка возвращается к этому участку периода.
Расширение проверяет документ и его прежнее состояние. В реализованную проверку входят следующие условия:
- вид операции — поступление по платёжным картам;
- комиссия банка отсутствует в шапке и строках расшифровки;
- все проводки активны и имеют корреспонденцию Дт 51 Кт 57.03;
- сумма проводок совпадает с суммой документа;
- прежняя версия документа удовлетворяет проверке;
- дата документа не перенесена вперёд;
- имеется одна запись последовательности с состоянием «проведён в последовательности».
При индивидуальном проведении документа, прошедшего проверку, расширение сохраняет состояние последовательности. При закрытии месяца подходящие документы исключаются из повторного проведения с подтверждением их состояния. Остальные документы обрабатываются типовым алгоритмом. Решение и его причина записываются в журнал регистрации.
Полное перепроведение месяца
На двухдневном участке стенда добавление «Независимости» к «Оптимуму» сократило время с 590,2 с до 371,0 и 390,9 с в двух проверенных сборках. Дополнительное сокращение — 34–37 %. Условия независимости выполнились для 1 314 из 1 436 выписок. Время обработки выписок уменьшилось с 205 до 17 секунд.
Снимки движений на этом участке совпали построчно: различий по 14 383 парам «регистр — регистратор» не было.
В мае условиям проверки соответствовали 18 115 документов из 40 398. С двумя расширениями фактически перепроведено 22 283 документа за 1 ч 32 мин 34 с. Регламентные операции после этого заняли 71 секунду.
По отношению к типовой конфигурации время перепроведения сократилось примерно вдвое, по отношению к одному «Оптимуму» — на 28,5 %. Оставшиеся 1 721 поступление с комиссией банка проводились в среднем за 170 мс. Доля реализаций в общем времени выросла до 40 %.
Снимок после прогона отличался от снимка до прогона одной парой «таблица — регистратор», от эталонного закрытия — двумя парами. После свёртки различий не было.
Повторное проведение выписки в закрытом месяце
Отдельно проверили обычный рабочий случай: месяц уже закрыт, пользователь повторно проводит одну выписку начала месяца.
Для проверки взяли поступление по эквайрингу от 2 мая. После его повторного проведения расширение записало в журнал регистрации причину сохранения последовательности: комиссии нет, проводки только Дт 51 Кт 57.03, прежняя версия также удовлетворяет проверке.
Повторный запуск закрытия занял около четырёх секунд. Фоновое задание группового перепроведения не запускалось, документы не перепроводились, регламентные операции не пересчитывались. Все 39 186 записей последовательности мая сохранили состояние «проведён в последовательности». В снимках движений различий по 178 089 парам не было.
Четыре секунды здесь — время проверки уже закрытого месяца после одного повторно проведённого документа. Это отдельный сценарий, его нельзя сравнивать с полным закрытием как ещё один вариант ускорения расчёта. Практический результат состоит в том, что указанное действие больше не вызывает повторную обработку оставшейся части месяца.
Ограничения применения
Отмена проведения и пометка удаления обрабатываются типовым кодом. Поступления с комиссией банка из перепроведения не исключаются.
Если изменились настройки счетов или аналитики 57.03 и требуется заново сформировать движения, нужно использовать самостоятельную обработку «Групповое перепроведение». Рассчитывать в таком случае только на помощник закрытия месяца нельзя: назначение расширения как раз состоит в пропуске части уже проведённых документов.
«Оптимум» при этом сохраняет самостоятельное применение: при загрузке новых поступлений, проведении подходящих под его условия выписок с комиссией и принудительном полном перепроведении. Условия применения расширений различаются.
Как выполнялись замеры
Для оценки результата использовали журнал регистрации, технологический журнал, статистику PostgreSQL и снимки движений. Каждый источник решал свою задачу.
Журнал регистрации. По нему определяли состав обработанных документов и время завершения группового перепроведения. Длительность брали из события «Перепроведение документов — Результат операции (N мс)». Время регламентных операций учитывали отдельно.
pg_stat_statements. До и после прогона снимали накопленные показатели только по исследуемой базе. Общее время SQL вычисляли как разность сумм total_exec_time:
SELECT sum(total_exec_time) AS exec_ms, sum(calls) AS calls
FROM pg_stat_statements
WHERE dbid = (SELECT oid FROM pg_database WHERE datname = 'база');
Для общей суммы нельзя ограничиваться запросами, которые присутствуют в обоих снимках: так можно потерять запросы, появившиеся во время прогона. Сброс статистики во время измерения делает разность накопленных счётчиков непригодной для такого сравнения.
pg_stat_database. По приросту xact_commit оценивали текущий темп работы. Дополнительно фиксировали temp_files, blks_hit, blks_read и deadlocks. Фиксации в секунду использовали для сравнения одинаковых участков при неизменном алгоритме. После изменения числа перепроводимых документов этот показатель сам по себе уже не характеризует ускорение: нужно сопоставлять длительность и фактический объём работы.
Технологический журнал. Собирали события DBPOSTGRS длительностью от 20 мс, TLOCK от 1 с, а также TTIMEOUT, TDEADLOCK и EXCP. Свойство Context использовали для перехода от SQL к месту вызова в конфигурации. Планы дорогих запросов получали через auto_explain. Подробный сбор включали на ограниченное время, чтобы сам журнал не создавал заметную дополнительную нагрузку.
Снимки движений. Проверяли число строк и хэш содержимого по регистрам и регистраторам. При отличиях отдельно сравнивали проводки после свёртки. Построчные различия и различия в суммах учитывали раздельно.
При сравнении учитывали несколько особенностей прогона.
Во-первых, рабочее множество rphost в наших замерах росло около 17 минут. Для сравнения установившегося темпа использовали участки после первых 20 минут. В полную длительность перепроведения начальный участок, разумеется, входил.
Во-вторых, начало и конец месяца неоднородны по стоимости проведения. Поэтому сравнивали одинаковые периоды и одинаковый состав документов. Сопоставление первой половины одного прогона со второй половиной другого дало бы неверный результат.
В-третьих, первое и повторное закрытие различаются. В рабочей базе первое закрытие меняло движения примерно у 19 % документов и занимало примерно на 10 % больше времени. Если набор движений совпадает с уже записанным, платформа не выполняет ту же работу по его перезаписи.
Наконец, показатели времени СУБД из разных источников имеют разный смысл. На одном прогоне получили 32 % по сумме времени SQL, 44 % по опросу pg_stat_activity и 53 % по duration-all-dbms из rac. Эти значения не подменяют друг друга; сравнение «до» и «после» нужно выполнять по одной методике.
Обслуживание базы перед длительным перепроведением
В описанной серии обслуживание не было основной причиной задержки. Тем не менее при подготовке и на соседних базах встретились случаи, которые стоит учитывать отдельно.
Статистика таблиц
После восстановления базы и массового изменения движений проверяли актуальность статистики крупных таблиц регистров. Для растущих полей, в частности _Period, прежняя статистика может давать неудачную оценку числа строк.
В соседней базе после восстановления запрос остатков выполнялся за 7,5 секунды. Пробный ANALYZE двух таблиц сократил время до 1,9 мс. Это отдельный случай, а не результат оптимизации рассматриваемого майского закрытия.
Для нашей нагрузки порог autovacuum_analyze_scale_factor = 0,05 оказался слишком большим. Его снизили до 0,01 и добавили ночной ANALYZE с отбором таблиц по n_mod_since_analyze. Конкретный порог выбирали по объёму изменений в этих таблицах.
Индексы и автоочистка
Необходимость перестройки индексов проверяли через pgstattuple. Расчёт по системному каталогу показал предполагаемое разрастание 36–39 % у трёх индексов таблицы итогов. Измеренная плотность около 65 % не стала основанием для их перестройки. Другой индекс после перестройки уменьшился с 1 214 до 632 МБ.
Если перестройка действительно нужна, её следует планировать с учётом последующего массового перепроведения: до такой операции индекс может вскоре снова измениться.
Для таблиц крупнее 10 млн строк в этой базе использовали autovacuum_vacuum_scale_factor = 0,005. Для таблиц итогов регистра бухгалтерии подбирали абсолютный порог по суточному объёму изменений. Вместе с порогами проверяли autovacuum_vacuum_cost_limit и autovacuum_vacuum_cost_delay: частый запуск автоочистки не решает задачу, если ей не хватает разрешённого темпа обработки.
Что проверять при внедрении
Для повторения такой работы в другой базе прежде всего нужно подтвердить распределение времени. Если основную часть закрытия занимают реализации с ФИФО, а поступлений по эквайрингу мало, описанные изменения не дадут сопоставимого результата.
Порядок проверки у нас был следующим:
- Устранить ошибки проведения документов исследуемого периода и проверить учётную политику.
- Зафиксировать релиз конфигурации, платформу, настройки СУБД и условия запуска.
- Снять исходное время перепроведения и регламентных операций, состав документов, статистику СУБД и снимки движений.
- Проверить применение перехватов расширений по журналу регистрации.
- Повторить обработку того же периода в сопоставимых условиях.
- Сравнить длительность, количество проведённых документов, движения и состояние последовательности.
- Отдельно проверить повторное проведение документа в закрытом месяце, отмену проведения и случаи, не проходящие условия расширений.
- После завершения снять дополнительное журналирование и временные средства сбора, проверить необходимость обновления статистики таблиц.
Для ночного запуска нужно оставлять время до резервного копирования и других регламентных заданий. После прерванного закрытия следует проверить состояние регламентных операций: в наших прогонах они могли оставаться в состоянии «Выполняется» до следующего успешного завершения.
Результат и границы проверки
В этой базе основное время закрытия месяца уходило на последовательное перепроведение документов. Больше половины времени занимали поступления на расчётный счёт. В их проведении нашли повторяющийся запрос остатков по договору эквайринга, который для заданных условий учёта не менял суммы проводок после свёртки.
Исключение этого запроса сократило время полного перепроведения мая с 3 ч 06 мин до 2 ч 09 мин. Исключение подходящих уже проведённых поступлений из повторной обработки дополнительно сократило его до 1 ч 33 мин. Для сценария с повторным проведением одной проверенной выписки закрытого месяца удалось сохранить последовательность: повторный запуск помощника завершился примерно за четыре секунды без перепроведения документов.
Сверка подтвердила совпадение сумм по счетам и субконто на исследованных данных. У части документов изменилось разбиение проводок на строки. Результат относится к указанным условиям отбора, проверенным периодам и релизам; расширение списка счетов или видов операций требует отдельного разбора алгоритма и сверки движений.
Разработку расширений и замеры выполняли на 3.0.206.19. При обновлении конфигурации необходимо повторно проверить изменяемую функцию и условия применения расширений. Полный месяц с одной «Независимостью», без «Оптимума», пока не измерен. Реализации, приходные кассовые ордера, списания и оплаты картой остаются отдельными кандидатами для дальнейшего исследования.
Поставленные заказчиком цели реализованы: закрытие квартала занимает всего 5 часов вместо 10 и укладывается в ночное время, когда можно спокойно провести все документы.
Вступайте в нашу телеграмм-группу Инфостарт