Стал обращать внимание на следующие вещи.
1) Производительность компьютеров растет. Увеличивается частота процессора, память. Сейчас на компьютерах не редкость SSD. При этом растет скорость работы файловой 1С локально, а вот скорость работы по сети остается прежней. На старом и на новом железе загрузка сети в диспетчере примерно одинакова. И составляет 15%-20%.
2) Скорость работы 1С зависит от скорости сети:
У меня на ноуте при формировании отчета загрузку сети в диспетчере показывает: WiFi в районе 7Мбит/с, по витой паре — 15Мбит/с. Т.е. примерно теже 15% от 54 и 100 соответственно.
Приходилось работать с файловой базой по гигабитной сети. Ни каких цифр здесь не приведу, но ощущения от работы 1С намного лучше.
Из этих наблюдений ясно, что сеть — это узкое место.
Стал я пробовать оптимизировать сетевой стек netsh int tcp set global autotuninglevel=disabled и т.д.
Вносил изменения в реестр LargeSystemCache, DisablePagingExecutive, NtfsDisableLastAccessUpdate, NtfsDisable8dot3NameCreation, EnableOplocks, OplocksDisabled и т.д.
Пробовал работать через сетевую папку и сетевой диск.
Но особого увеличения производительности не было.
В результате поисков и экспериментов обнаружил, что формат базы 8.2.14 и размер страницы 4К.
Получить информацию о формате БД можно, запустив команду:
"C:Program Files1cv88.3.11.2867incnvdbfl.exe" -i D:Base1S81Cv8.1CD
Изменил формат базы на 8.3.8 и размер страницы на 32К:
"C:Program Files1cv88.3.11.2867incnvdbfl.exe" -с -p 32K D:Base1S81Cv8.1CD
Результат очень положительный. Отчет на ноуте формируется в 2-3 раза быстрее. Загрузка сети по WiFi — 32 Мбит/с, по витой паре более 50 Мбит/с.
Все замеры производились на толстом клиенте — конфигурации на обычных формах.
Мои наблюдения по управляемым формам:
Как минимум при переходе с 8.2.14 на 8.3.8-8К ничего не меняется. Как максимум может дать прирост производительности. У меня на веб-сервере перепроведение документов прошло на 20% быстрее. При этом процессор был более нагружен, чем при 8.2.14.
Дальнейшее увеличение размера страницы может дать отрицательный результат.
Про формат 8.3.8 можно почитать на ИТС:
https://its.1c.ru/db/metod8dev#content:5924:hdoc
Цитата:
"В новом формате (версии "8.3.8") появились следующие возможности:
- Уменьшен размер и оптимизирована структура заголовка с метаинформацией в файле 1Cv8.1CD. Это позволяет существенно снизить число операций чтения файла при открытии базы данных и, тем самым, заметно ускорить время старта и начала работы программы.
- Теперь можно настраивать размер внутренней страницы файла данных. Это размер порции данных, в которых хранится информация и которыми обменивается программа с файловой системой. Предыдущий формат файловой базы данных (версии "8.2.14") поддерживал единственный размер внутренней страницы файла – 4Кб. Новый формат по умолчанию использует размер страницы 8Кб, но позволяет его менять в диапазоне от 4Кб до 64Кб.
Наибольший эффект от использования нового формата файловых баз данных ожидается в следующих сценариях:
- "холодный" запуск программы,
- работа с файлами базы данных по локальной сети,
- работа с сильно фрагментированной базой данных,
- использование дисковых подсистем с невысокой производительностью.
При создании новых файловых баз данных рекомендуется использовать настройки формата базы по умолчанию (версия формата "8.3.8", размер страницы файла 8Кб). Если Вы используете базу данных, созданную в предыдущих версиях платформы, и наблюдаете недостаточно высокую производительность при старте и во время работы программы, то рекомендуется сконвертировать базу данных на новый формат файла."
Как видим из статьи, формат 8.3.8 дает нам весьма любопытные и интересные возможности.
P.S.
Перед любыми изменениями формата БД не забываем делать архивы.
Пробовать и экспериментировать лучше на копии.
Для тех кто хочет попробовать оптимизировать работу Windows прикрепил два файла:
win7net.cmd — сетевой стек, в Win10 запускать в PowerShell под админом.
Win7_1C.reg — твики реестра.
В файлах ряд параметров дублируется.
Ссылка на публикацию, где также затрагивается производительность 1С8:
//infostart.ru/public/964062/
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
А что вас остановило, почему не 64Кб ?
Если будете и дальше экспериментировать на рабочей базе (подумайте!),
можете посмотреть MTU (Maximum Transmission Unit) для Ethernet, например, составляет 1500 байтов.
Если у вас получится что-то интересное (), обязательно напишите об этом.
(1) Мне больше не надо. Значения 16-32 вполне устроят.
А поставить веб-сервер, не? Тонкий клиент через веб-сервер работает быстрее файловой по сети.
(3) Пока еще не все конфигурации на УФ работают.
(3)
Цитата:
Начиная с версии платформы «1С:Предприятие» 8.3.8 появилась поддержка нового формата файловых баз данных (включая работу в режиме совместимости с предыдущими версиями). Новый формат файловых баз данных предназначен для ускорения процесса открытия и работы с информационной базой, поэтому, начиная с версии платформы 8.3.9, новый формат используется по умолчанию при создании новых файловых баз данных.
В новом формате (версии «8.3.8») появились следующие возможности:
Уменьшен размер и оптимизирована структура заголовка с метаинформацией в файле 1Cv8.1CD. Это позволяет существенно снизить число операций чтения файла при открытии базы данных и, тем самым, заметно ускорить время старта и начала работы программы.
Теперь можно настраивать размер внутренней страницы файла данных. Это размер порции данных, в которых хранится информация и которыми обменивается программа с файловой системой. Предыдущий формат файловой базы данных (версии «8.2.14») поддерживал единственный размер внутренней страницы файла – 4Кб. Новый формат по умолчанию использует размер страницы 8Кб, но позволяет его менять в диапазоне от 4Кб до 64Кб.
Наибольший эффект от использования нового формата файловых баз данных ожидается в следующих сценариях:
«холодный» запуск программы,
работа с файлами базы данных по локальной сети,
работа с сильно фрагментированной базой данных,
использование дисковых подсистем с невысокой производительностью.
При создании новых файловых баз данных рекомендуется использовать настройки формата базы по умолчанию (версия формата «8.3.8», размер страницы файла 8Кб). Если Вы используете базу данных, созданную в предыдущих версиях платформы, и наблюдаете недостаточно высокую производительность при старте и во время работы программы, то рекомендуется сконвертировать базу данных на новый формат файла.
(6) + Думаю для web доступа производительность тоже улучшится.
Сконвертировать при помощи утилиты cnvdbfl.exe?
Например это
интересует дефрагментация базы. По вашему мнению, следует ли проделывать какие либо манипуляции при каждом обновлении платформы?
(8) Да cnvdbfl.exe. Пример есть в публикации.
Можете использовать графическую оболочку для cnvdbfl.exe в указанной вами публикации.
(3)
Тонкий клиент и без веб-сервера довольно бодро работает по сети. Насколько я понял, в статье речь идет о толстом клиенте и неуправляемых формах, там да, есть проблемы, поэтому исследование интересное. Правда уже неактуальное, хотя кому-то и пригодится.
(8) Новые базы Розницы 2.2, ЗУП 3.1, ЗИКГУ 3.1 вполне существуют на формате 8.3.8 и ни каких манипуляций с ними делать не надо.
(10) Почему не актуально? Не соглашусь.
(5) Не увидел упоминание вида клиента, подумал про тонкий. Ну толстый по сети использовать это еще то себе решение, я бы однозначно менял схему в сторону RDP (знаю про лицензии, но и этот вопрос решаем, только тссс), хотя бы потому что стабильность повысится.
(10) Тонкий клиент файловой базы по сети работает неплохо? Это где у вас так? Через веб-сервер (именно в файловой) работает быстрее, чем просто по сети.
(13)
Полностью согласен.
Тонкий клиент боле менее работает только если локально и один пользователь. И все равно хуже чем веб.
Это опять же говорит о том, что сеть — узкое место.
(12)
А сколько их осталось, конфигураций не на управляшках?
Это опять же говорит о том, что сеть — узкое место.
Для тонкого клиента сеть не является узким местом. Проводили как-то исследования, для файловой базы в терминале и тонкого по сети разница в пределах погрешности измерений.
(13)
Много где, местами и через интернет поверх VPN работает. Разницы между тонким и веб на современных конфигурациях особо не видно. Разве что если связь совсем плохая, через 3G, тогда да.
А работа в режиме тонкого клиента + двойной горизонт DNS позволяют работать с одной и той же базой в списке как по локалке в офисе, так и через VPN за ее пределами без лишних телодвижений для бухгалтера.
(16)
(15)
Коллега, не обессудьте, но что-то мне подсказывает, что Вы свистите. Из субъективного опыта скажу, что разница ощутима, также разработчики платформы, сотрудники 1С на партнерском форуме это явно утверждали, и предлагали работать через веб-сервер, так как есть проблемы с производительностью при работе по сети (пруфы искать очень лень). Но если исследовали, то может сделаете статью с измерениями?
(15)
Уходят ЗУП 2.5, ЗИКГУ1.0, Розница 1.0, а остальные есть и на УФ и на обычных.
УТ10, БГУ1, Камин 3.0-3.5, КА, УПП, БП2.0.
(15)
Конфигурацию сети, компов, сервера не скажите?
Какая конфигурация 1С? Размер БД?
(19) + А какой формат БД? И размер страницы?
Что заставляет использовать БП 2.0? Тройка вылизана, переход простой и безболезненный.
КА и УПП в файловом? Ну это надо быть знатным
извращенцемэстетом.Остается БГУ, УТ 10 и Камины, да и то УТ — скорее всего тоже клиент-сервер.
(17)
Пруфы? Будут вам пруфы. Начнем отсюда:
В режиме тонкого клиента на клиенте поднимается серверная среда, а сама БД используется как удаленная СУБД. Трафик там небольшой, можете посмотреть сами, пропускная сети роли здесь не играет. Несколько тонких клиентов — несколько серверных сред, но, по прежнему одна СУБД. Вот здесь и выплывают проблемы разделения доступа и блокировок.
Веб-клиент создает серверную среду на веб-сервере, одну на всех. Теперь у нас одна среда — одна СУБД, но все запросы обрабатываются одним клиентом. По очереди. При большом количестве клиентов и их интенсивной работе упремся в производительность модуля веб-сервера (читай: одного тонкого клиента).
Для двух-трех клиентов это может и будет незаметно, но вешать всю сеть на веб-клиента явно не стоит. Плюс хорошие аппетиты к оперативке, которая не освобождается сразу по завершении сеанса (так как от CGI схемы ушли к аналогу FastCGI).
Ну так и два-три клиента по сети с файловой нормально работают, а больше — там уже смотреть надо.
(17)
Сделаем, как раз будет, чем в праздники заняться.
(19)
Какая конфигурация 1С? Размер БД?
Раз пошла такая пьянка, сделаю статью на праздниках.
(22) Ждем
(21)
Проблема возникает именно в том, что нужно из бд доставить данные на серверную среду, чтобы обработать, при веб-сервере по сети гуляют только запросы и ответы для клиента. Код самой платформы делает это не очень оптимально, плюс надо делать это не через очень быструю сеть (будем рассматривать самый бюджетный 100 мбит/с). С трафиком кстати есть интересные подводные камни, к теме это не относится, просто пример. Если анализировать трафик между сервером 1С и сервером MS SQL (пусть это две разные машины), то загрузка сети будет маленькая, и многие администраторы не увидят проблемы в ней, но если расширить ширину канала, то будет эффект в производительности (есть статья на хабре об этом)
(21)
Тут как раз таки серверная среда одна, и расположена обычно на том же диске, что и файл бд, соот-но работа с диском намного быстрее работы по сети, ну и не нужно тягать данные через сеть на клиента, ему отдадим, грубо говоря, картинку. А то что оно обрабатывается последовательно, не вижу проблем, в файловой в принципе проблемы с блокировкой всей таблицы, узкое место именно бд, так как модифицировать файл по сети затратней модификации этого же файла оттуда где он лежит.
(21)
Будет интересно почитать.
(21)
Я бы вопрос поставил: что заставит перейти с БП 2.0, если она жива и обновляется? Сидят еще даже на Бухгалтерии 7.7 и тоже ни куда не собираются переходить.
(21)
Почему остается?
Я же говорю все конфигурации дублируются на обычных и управляемых формах. Кроме ЗУП, ЗИКБУ, Розницы. Т.е. конфигураций примерно одинаковое количество.
(25)
Я же говорю все конфигурации дублируются на обычных и управляемых формах. Кроме ЗУП, ЗИКБУ, Розницы. Т.е. конфигураций примерно одинаковое количество.
Я не вижу практического смысла в использовании БП 2.0 когда есть 3.0, тем более, что двойку обслуживают по остаточному принципу.
Остается то, что переносить долго, дорого или сложно (технически, организационно и т.д.) — это бюджетка, там свои тараканы, Камины и пожалуй УТ. Все остальное можно использовать на управляшках, тем более, что преимуществ у них более чем достаточно (тот же тонкий клиент, веб-сервер и т.д.).
(24)
Это так, но узкое место там не в сети. Да, можно расширить канал и, возможно, производительность на участке БД — серверная среда увеличится, но сможет ли платформа получить от этого выгоду — иной вопрос. Мы же рассматриваем производительность клиента в комплексе, а не по отдельным участкам. Какая разница, выполнится мой запрос за 0,1 с или 1 с, если последующая обработка результата займет, скажем, 10 с?
поддержу. работа через вебсервер или рдп. все остальное от лукавого.
(26)
Что понимается под обработкой результата? Работа с данными серверной средой? Работа с БД абсолютно всегда занимает огромное количество времени, будь то сервер 1С, либо файловая база, ибо тут самая непроизводительная часть — диск. Данные с бд эмуляция сервера получит, поместит их в память, и обработает, а основные проблемы при параллельной обработке данных заключаются в том, что данные используются одни и те же (10 клиентов* будут по очереди пытаться заблокировать таблицу регистра и модифицировать файл бд по не самой быстрой сети). Между тем, если это будет делать кто-то один, проблем с параллельностью не будет, будет очередь, да, но мы работаем с диском напрямую (в случае веб-сервера). Думаю Вам известны методы оптимизации 1С, где проведение документов просто выстраивали в очередь, из-за проблем с блокировками, и это работало. Приходим в итоге к классическому спору, «что быстрее»: центральный процессор обрабатывает информацию быстро, но в один поток, графический процессор может делать параллельно много мелких операций, но если с данными параллельно работать не получается, он проигрывает в производительности.
* Утрирую про 10 клиентов
По моему, прирост скорости от увеличения размера страницы вы увидите только для файловой базы, лежащей на дисковых носителях (HDD). Для твёрдотельных накопителей (SSD) прироста не будет.
(27) когда в базе два пользователя, то РДП дороже настраивать, чем оставить всё как есть
Можете ли для полноты картины сделать аналогичные замеры для базы, лежащей на ram-диске?
(29) Я поставил новые компы с SSD, а прироста скорости работы по сети нет. Локально можно сказать летает. Почему так?
(31) Я нет. Может кто-нибудь сделает.
По управляемым формам:
Как минимум при переходе с 8.2.14 на 8.3.8-8К ничего не меняется. Как максимум может дать прирост производительности. У меня на веб-клиенте перепроведение документов прошло на 20% быстрее. При этом процессор был более нагружен, чем при 8.2.14.
Дальнейшее увеличение размера страницы может дать отрицательный результат.
(30) когда был фрилансером много раз(а точнее всегда) убеждался что даже два пользователя по сети по share это ужас.
я как-то на фрилансе столкнулся с комедийной ситуацией. Офис фирмы был размещен в 4хкомнатной квартире. евроремонт все дела. одна комната была полностью под серверную. серверная стойка. 3-4 мощных сервака, 1000 мегабит в пределах офиса. и одна бухбаза на два компьютера по шаре.она постоянно рушилась. приходилось ее chdbfl-ить постоянно. месяца три на рдп уговаривал перейти. уговорил. только после перестали вызывать на ремонт базы.
(14) А если тонкий клиент через веб-сервер ?
(37) Так об этом и говорили.
(35)
100мбит сеть , БП 2, 3 пользователя = нормальная работа
(21)
Где обещанное исследование?
(31) Замеров не делал, но юзаю RAM-диск для обработки клиентских баз.
Так вот от простого переноса файла базы в оперативу субъективно не меняется ничего (читай прирост <20%).
Пришлось перенаправить туда же профиль пользователя (отдельно Temp и LocalAppData не вышло), тогда разница стала ощутимой.
Во вложении скрипты, инициализирующие RAM-Drive для 1С.
Cсылки из временного профиля в рабочий вычисляются в контексте Одмина, но можно прописать статику в первые 3 строки Env.cmd.
После запуска Setup.cmd с повышенными привилегиями создается диск Z:, с него все и запускать.
(41) Локально?
(42) Разумеется, это приблуда из разряда Temp.
Для организации постоянного хранения оно даже в страшном сне не привидится. Тут однозначно RAID с большим кешем и батарейкой. По-сути то же самое, и по сети дает выигрыш, клиенты оценили.
Все одно где возможно надо ставить Апач и раздавать файловые через него. Пока только непонятно как управлять отдельными базами — ручные перезагрузки и падения сразу для всех. Сервер 1С стоит как 1,5 минимальных RAID-контроллера, так что 80% конфигураций — файлы через WEB.
(43) Что-то я не совсем пойму как работа организована.
(41)
Т.е. работа происходит локально. А с другой стороны:
(43)
Или на каждом компе ram-диск?
(44) Сообщение 43 про аппаратный RAID, а 41 про локальный RAM-drive для локальной одноразовой обработки баз. Это не части одного решения.
RAID с гигибайтным защищенным кешем дает производительность сравнимую с RAM-диском, и обладает достаточной надежностью для стационарной раздачи в сеть.
(41) Вот это интересно, почему профиль пользователя так помогает производительности?
Я когда тестировал такой режим файловым монитором, вроде не находил каких то значимых обменов с диском кроме как с базой и TEMP папкой.
Не исследовали почему перенос профиля так сильно влияет?
p.s.
То же не впечатлил RAM диск, а тут вон оно что оказывается. Надо протестировать, спасибо.
(47)
Там находится кэш. Больше причин не вижу.
(47) Основной трафик идет в LocalAppData, так и есть. Просто, как я написал выше, переназначение переменных LocalAppData и Temp контекста приложения не решили проблему полностью — платформа продолжала насиловать профиль на жестком диске. Разбираться не стал, а переназначил все что есть — помогло.
ЗЫ: Всегда пажалиста.
Надо будет выложить полный инструментарий, когда приберу там бардак, может пригодится кому…
(45) общая стоимость перечисленного оборудования превысила стоимость организации rpd и тем более web-сервера )
интересно, что у вас за конфа на 8.3.8 еще….
Файловая база по сети напрямую (не через web или rdp) — это прямой путь к краху базы.
Если через web, все операции с базой выполняются на одном компьютере (web — нужно на компьютере с базой разворачивать).
Кроме быстродействия, главная причина использования — надежность.
Сбои в сети и на других компьютерах не будут валить базу.
А если прямой доступ (каждый компьютер пишет напрямую в файл базы по сети), то объективно надежность обратно пропорциональна количеству компьютеров, работающих с базой. И локальная сеть тоже свой вклад внесет в уменьшение надежности.
Сварщик поблизости начнет работать и каюк базе…
(0)Хорошая статья для тех кто не
хочетленитсязабывает смотреть в ИТС.(52)
Уже лет 10 слышу эти песни и все это время 90% клиентов работают именно так(с толстым клиентом вообще не было варианта с web, и rdp и sql стоят очень дорого, не считая стоимости сервера еще) вроде ничего, живы, здоровы.
(53)
Мне статья на ИТС попадалась на глаза не раз.
Но почему-то я не заострял внимание на нее.
Хотя там сказано:
«Уменьшен размер и оптимизирована структура заголовка с метаинформацией в файле 1Cv8.1CD. Это позволяет существенно снизить число операций чтения файла при открытии базы данных и, тем самым, заметно ускорить время старта и начала работы программы.»
«Наибольший эффект от использования нового формата файловых баз данных ожидается в следующих сценариях:
«холодный» запуск программы,
работа с файлами базы данных по локальной сети,
работа с сильно фрагментированной базой данных,
использование дисковых подсистем с невысокой производительностью. »
Т.е. прямым текстом говорится, что улучшена работа с файловой базой.
Поэтому статья еще для тех кто не внимательно читает или не обращает внимание на ИТС.
Рад буду если кому-нибудь моя статья помогла.
(2)
🙂 а системе «надо» 🙂