Тормоза на файловой базе - как избежать (из недавнего опыта). Файловый или клиент-серверный? 1с файловый и клиент серверный вариант
С ростом организации и с увеличением количества пользователей информационной базы 1С Предприятие в локальной компьютерной сети возрастает нагрузка на главное хранилище информационной базы - сервер. Поэтому рано или поздно перед руководителем и IT-специалистом компании может возникнуть вопрос: как обеспечить быструю, безопасную и работоспособную систему с наименьшими финансовыми затратами?
Для начала необходимо выбрать способ организации корпоративного автоматизированного компьютерного комплекса на платформе 1С Предприятие 8. Платформа 1С поддерживает два варианта работы: файловый и клиент-серверный. И в том, и в другом случае все прикладные решения работают абсолютно одинаково.
Файловый вариант работы 1С предназначен для работы одного или нескольких пользователей в локальной сети. При этом все данные информационной базы (конфигурация, база данных, административная информация) располагаются в одном файле - файловой базе данных, разработанный специально для прикладных решений 1С Предприятия 8.
Преимущества файлового режима работы
- Оптимален для небольшого количества пользователей (до 5-ти)
- Простота установки и эксплуатации системы
- Для работы с информационной базой не требуются дополнительные программные средства кроме операционной системы и 1С Предприятие 8
- Снижен риск нарушения целостности данных при сбоях компьютеров и локальной сети.
- Простое создание резервных копий путем простого копирования файла информационной базы.
Работа в файловом варианте возможна как напрямую, непосредственно с файлом базы данных, так и через веб-сервер, если используются клиентские подключения по протоколу HTTP или HTTPS.
Клиент-серверный вариант работы 1С предназначен для использования в отделах, рабочих группах или в масштабе предприятия. Он реализован на основе трехуровневой архитектуры «клиент-сервер»:
Клиентское приложение - Кластер серверов 1С Предприятия - Сервер базы данных
В клиент-серверном варианте информационная база хранится в одной из поддерживаемых СУБД: Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database. К ней по мере необходимости обращается клиентское приложение через кластер серверов 1С Предприятие.
В системе 1С Предприятие 8 существует три клиентских приложения или клиента (программа, работающая у пользователя) с различными возможностями: толстый клиент, тонкий клиент, веб-клиент.
Толстый клиент позволяет реализовывать полные возможности 1С Предприятия 8 в плане разработки, администрирования и исполнения прикладного кода. Однако он не поддерживает работу с информационными базами через интернет, требует предварительной установки на компьютер пользователя и имеет довольно внушительный объем дистрибутива.
Проблема
На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая?
Затем обычно идет «флуд» на несколько десятков страниц.
Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд.
В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнениях.
Мы предлагаем разбить вопрос на несколько:
1. Работает ли файловый вариант быстрее в операциях «монопольного характера», когда его деятельность не зависит от других пользователей в базе?
Под «монопольным характером» мы будем понимать одного активного (работающего) пользователя в информационной базе.
2. Работает ли файловый вариант быстрее в многопользовательском режиме, когда пользователи активно конкурируют за ресурсы (например при проведении реализации товаров обращаются массово к остаткам на складе)?
3. Насколько существенна разница в скорости между файловым вариантом и клиент-серверным с точки зрения бизнеса?
Что на самом деле
Таблица №1. Сравнение файлового и клиент-серверного варианата 1С
| Файловая 1С | Клиент-Серверная 1С | |
| Максимальный размер одной таблицы | 4 gb | ~сотни терабайт |
| Размер на практике когда возникают «тормоза» в 1С при достижении объема базы данных | ~16 G b | ~500-1500 Gb |
| Количество пользователей с комфортной работой 1С | 3-10 (далее мешают табличные блокировки) | 300-700 человек (далее обычно нужно покупать более мощное железо и оптимзировать код еще раз) |
| Функции, отъедающие ресурсы, которые бы могли бы потрачены на лучшую производительность | нет |
транзакционная целостность данных, логирование операций для дальнейшего анализа, функции повышения параллельности работы пользователей |
| Дополнительные преимущества | простота (так как мало функций) | обслуживание данных (например резервное копирование) без остановки работы пользователей |
| Минимальная область блокировок | На уровне таблиц (требуется меньше ресурсов) | На уровне записей (требуется больше ресурсов) |
| Стоимость владения (условно) | Маленькая | Существенно больше чем файловая |
| Наличие промежуточного слоя между клиентом 1С и субд | нет | Сервер 1С |
Ответ на первый вопрос: Работает ли файловый вариант быстрее в операциях «монопольного характера», когда его деятельность не зависит от других пользователей в базе — с вероятностью 99% файловый вариант работает быстрее (при условии его возможности не ограничиваются неудачным железом и не достигаются максимальные возможности файлового варианта)!.
Не верьте нам на слово — проверьте сами. Возьмите (подробное описание здесь ) и убедитесь сами (проверьте сначало в файловом варианте, затем клиент-серверном).
Если Вы не верите тесту, то протестируйте подходящую для проверки по вашему мнению операцию также в файловом и клиент-серверном варианте. Мы рекомендуем за основу взять например «закрытие месяца» на базах размером до 4х гигабайт (иначе на файловом варианте может достигнуто ограничение по размеру).
Понятно, если у Вас закрытие месяца в файловом варианте не возможно, то обсуждать преимущества файлового варианте для Вас нет смысла, Вы согласны?
Возникает еще один промежуточный вопрос:
А насколько файловый вариант быстрее клиент-серверного в цифрах?
Ответ на этот вопрос куда интересней и практичней. Наш тест и практика показывают:
- на среднестатитических операциях на соизмеримых объемах данных почти в 2 раза быстрее
- на среднестатитических операциях когда объемы данных начинают превышать объем доступной оперативной памяти и увеличивая интенсивность подкачи — до 3-4х раз быстрее — это как раз пример закрытия месяца
Однако важно понять что такое «среднестатистическая» операция. Оказывается, что операции, которые оперируют данными в оперативной памяти в клиент-серверном варианте не проигрывают, а иногда даже выигрывают у файлового варианта !
Однако таких операций мало и они не показательны. Основную нагрузку составляют операции, фактически обращающиеся к дисковой подсистеме на чтение, и что особенно важно — на запись данных.
Причем даже безобидный отчет при построении тоже может писать данные, ну например в служебную базу данных tempdb в случаи использования MS SQL Server.
При выполнении запроса в файловом варианте нет посредника данных в виде Сервера 1С, т.е. на один сегмент прохождения запроса меньше. Логично, что если например выполнять «работу без посредников» она всегда быстрее «работы с посредниками».Кроме того, существенная часть функционала на стороне СУБД тоже фактически является «посредниками» — они нужны например не только выполнения запросов, но чтобы обеспечить лучшую параллельность для работы других запросов — например максимально скрупулезно наложить блокировки на используемые данные, чтобы не заблокировать «лишнего» как это делает файловый вариант. Наложить блокировку на всю таблицу проще, так как это одна запись с информацией о блокировке, а наложить блокировки на тысячи строк — это на порядке больше дополнительных записей, но что еще важнее это существенно больше затрачиваемых ресурсов (процессора, памяти, а иногда и места на диске).
Другими словами, клиент-серверный вариант требует больше ресурсов чем файловый для одной и той же работы по объему .
Отсюда следствие — на одном и том же компьютере можно сделать В МОНОПОЛЬНОМ РЕЖИМЕ больше работы в файловом варианте, чем в клиент-серверном (в том же монопольном режиме) .
В итоге вроде как клиент-серверный вариант может сделать меньше работы, требует больше ресурсов, а где же «профит», почему он используется практически везде?
Поможет ответить нам второй вопрос нашей статьи: работает ли файловый вариант быстрее в многопользовательском режиме, когда пользователи активно конкурируют за ресурсы (например при проведении реализации товаров обращаются массово к остаткам на складе)?
В таблице номер №1 мы видим такие существенные недостатки файлового варианта как маленький размер баз данных — на большинстве предприятие базы данных 1С занимают десятки-сотни гигабайт. Но еще важнее, что файловый вариант накладывает избыточные блокировки (лишние), что существенно снижает возможность параллельной работы пользователей.
Итак, для пример на предприятии работает 100 пользователей 1С. В день для ровного счета предположим что каждый пользователь вводит равномерно в течении всего дня 10 документов, а каждая табличная часть содержит 10 строк.
Мы получаем простую арифметику — 100 х 10 х 10 =10 000 строк вводится в информационную систему в течения дня.
Для простоты понимания условимся что каждый пользователь работает с уникальными данными, и другие пользователи с друг другом не пересекаются ни табличной части документа, ни по составу реквизитов.
В клиент-серверном варианте это сработает. Документы проведутся параллельно.
Зная избыточность блокировок файлового вариант давайте посчитаем, что будет если одновременно 100 пользователей в файловом варианте будут вводит в систему первый документ в этот день, но нажмут проведение кнопки одновременно.
Мы знаем что по умолчанию длительность таймаута блокировки 20 секунд. Теоретически можно предположить что кроме первого пользователи все последующие будут друг друга ждать по 20 секунд и затем проводить свои документы. Суммарное ожидание составит 100 пользователей х 1 документ х 20 секунд = 2000 секунд ожидания. Чувствуете — это полчаса простоя пользователей.
На практике все еще печальней, люди не роботы, они не видят когда система заблокирована или вероятность проведения документа будет высокой, поэтому они просто констатируют что вводить данные в систему не возможно из-за постоянных блокировок. Или проще, на практике в файловом режиме предприятие «встанет».
Но даже если представить что на предприятие пришел потрясающий программист и написал программу так, что попытки будут выполняться постоянно автоматически эти полчаса простоя никуда не денуться.
Более того, при попытке 2,3 документы угубят картину и за день даже при идеальном коде файловый вариант «накопит» 100 пользователей х 10 документов х 20 секунд = 20000 секунд ~ 5 c половиной часов простоя.
5 часов — эта фора клиент-серверного варианта. Даже не важно с какой скоростью в каждом потоке в клиент-серверном варианте они будут вводиться. Важнее что они вводятся, а в файловом варианте в это время происходят ожидания на избыточных блокировках.
Поскольку помимо избыточных блокировок еще есть необходимые блокировки, сформулируем понятие производительности заново.
С точки зрения бизнеса производительность — это количество работы за день сделанной всеми 100 пользователями, а не одним монопольно. Поэтому бизнесу важнее сколько в итоге будет введено данных в систему суммарно всеми пользователями. Оценивая производительность коллектиной работы — файловый вариант в десятки-сотни раз проигрывает клиент-серверному варианту .
И снова призываем не верить нам на слово. Возьмите 1С:Стандартный Нагрузочный Тест http://v8.1c.ru/expert/etp.htm или разработайте свой коллективный тест и убедитесь сами с достоверности наших утверждений.
Если у вас возникли вопросы по выполнению теста или его результатам, то можно обсудить их на форуме .
Возможно Вы также захотите приобрести 1С:КИП, обратите внимание на особенности .
Теперь ответим на третий вопрос:Насколько существенна разница в скорости между файловым вариантом и клиент-серверным с точки зрения бизнеса?
Файловый вариант несильно опережает клиент-серверный вариант в монопольном режиме и очень существенно проигрывает в многопользовательском режиме.
Но надо понимать, что у бизнеса есть и другие задачи, которые практически всегда стоят выше по приоритету, а именно отказоусточивость, бесперебойная работа, надежность и стабильность. Работа сервера в отказоусточивом кластере требует дополнительных расходов на зеркалирование данных. Таким образом всегда должен быть баланс между различными задачами: производительность, надежность, безопасность и т.п.
Файловый вариант не имеет механизмов контроля целостности данных. Например, если произойдет сбой в сети при передачи данных, или отключится свет, то в файловом варианте что то успеет записаться, а что нет. Целостность данных будет разрушена. В клиент-серверном варианте в подобных случаях просто произойдет откат незавершенной транзакции, и неполных данных в систему не попадет, целостность данных будет сохранена.
Т.е. мало того, что чем выше количество пользователей в системе,тем больше файловый вариант будет проигрывать клиент-серверному, так еще процедуры восстановления данных в случаи сбоя превращают файловый вариант в абсолютно проигрышный вариант .
А теперь надо задать «правильный вопрос»:
4. Почему возник вопрос оценить разницу в скорости файлового и клиент-серверного варианта?
Таже переписка и флуд на форумах начинаются с того, что спрашивающий имеет проблемы с производительностью в клиент-серверном варианте.
Но вместо изучения причин, которые спровоцировали проблему в клиент-серверном варианте, он обнаруживает что в файловом варианте такой проблемы нету. Его не беспокоит что проблема может быть в «посреднике», который отсутствует в файловом варианте.
Правильный ответ заключается в том что неважно насколько быстрее файловый или клиент-серверный вариант, а важно что именно вызывает замедления в каждом КОНКРЕТНОМ случае. Слово ПРОИЗВОДИТЕЛЬНОСТЬ опасное, так как на самом деле его надо расписывать в виде списка операций в системы, которые в совокупности и формируют это производительность. Надо рассматривать каждую операцию, начиная с той, которая создает наибольший вклад в замедления.
Вообщем то этим мы профессионально и занимаемся уже много лет успешно.
Мы готовы бесплатно посмотреть конкретную операцию, которая медленно работает, оценить стоимость ее решения. Если сроки и цена Вам подходят, то мы ускоряем операцию, и если она достигает обозначенных Вами условий, то только в этом случаи Вы оплачиваете наши работы.
1С бывает — файловая, серверная и веб. Чем они отличаются?
Какие бывают варианты установки 1С
Итак, 1С делится на платформу и конфигурации. Что к чему, мы неоднократно разбирали в предыдущих выпусках.
На основе конфигурации 1С мы создаем базу данных. База данных содержит справочники и документы, которые вносят пользователи.
На январь 2010 года существуют три варианта работы 1С:
- файловая 1С
- сетевая 1С (сервер 1С и клиент 1С)
- веб 1С (тонкий клиент 1С).
Также дополнительные варианты:
- для разработчиков
- для использования веб сервисов 1С или веб расширения 1С.
Бывает файловая 1С и сетевая 1С, каждая из них нужна в своем случае, поэтому сказать однозначно, что сетевая 1С лучше файловой 1С — не правильно.
Файловая 1С
Самый старинный вариант работы 1С. База данных находится в папке на жестком диске компьютера.
Папка с файлами базы может быть как на диске Вашего компьютера, так и на любом публичном диске локальной сети (такие публичные диски также называют «шара»).
В этом случае платформу 1С достаточно установить на компьютеры пользователей.
Сетевая 1С
Также называют «клиент-серверная 1С». Это значит, что нужно установить отдельно «клиент 1С» и отдельно «сервер 1С».
База данных хранится в специальной программе для управления базами данных.
Программы для управления базами данных, которые поддерживаются 1С: Microsoft SQL, Postgre SQL, Oracle (последнюю поддерживает только 1С 8.2).
В этом случае часть платформы 1С устанавливается на сервер – «сервер 1С». Там же ставят программу управления базами данных. На компьютеры ставят платформу 1С и специальный компонент «Доступ к серверу 1С».
Тонкий клиент 1С (управляемое приложение 1С)
Самый новый вариант. В этом случае, дополнительно к клиент-серверному варианту, требуется веб-сервер. Веб-сервера, которые поддерживаются 1С: Microsoft IIS, Apache.
На сервере ставят «сервер 1С», программу управления базами данных, веб-сервер, компонент «расширение веб-сервера 1С».
На компьютерах пользователей можно использовать два варианта:
Вариант 1: не ставить ничего – использовать любой обычный браузер.
Вариант 2: установить «тонкий клиент 1С».
Пример работы через с 1С через веб-браузер можно посмотреть здесь.
Это реальная база 1С, которая установлена на сервере в компании 1С.
Дополнительный вариант – для разработчиков
Когда над разработкой конфигурации 1С работает одновременно группа разработчиков, необходимо установить дополнение – хранилище 1С SQL.
По умолчанию одновременно с конфигурацией может работать только 1 программист. Хранилище позволяет вести коллективную разработку.
Хранилище необходимо ставить на сервер или использовать в качестве сервера хранилища один из компьютеров разработчиков.
Дополнительный вариант – веб сервисы 1С и веб расширение 1С
Например у Вас в офисе учет ведется на 1С:Предприятии. Также у Вас работает веб-сайт. Вы хотели бы, чтобы веб-сайт динамически брал определенные данные из 1С. Это можно сделать с помощью Web-сервисов. Это дополнительный компонент платформы 1С. Он входит в платформу, необходимо установить эту галочку.
Web-расширение – альтернативный механизм Web-сервисов – появился раньше.
Чем сетевая 1С лучше файловой 1С
1) В файловой версии база данных находится в одном файле. Размер файла в теории может быть ограничен FAT. Правда сложно представить сегодня операционную систему на FAT – везде используется NTFS.
2) Механизм работы с файлом базы данных в 1С значительно упрощен по сравнению с SQL. В частности она хуже работает при увеличении размера файла или количества пользователей («начинает тормозить»).
Поэтому, когда речь идет про три-пять пользователей и небольшую базу – это исключительно файловая версия. База от 4Гб и более 10 пользователей – можно подумать. Еще больше – однозначно клиент-сервер.
Для обучения нам конечно же достаточно файловой версии.
Установка платформы 1С
Фото Алены Туляковой, ИА «Клерк.Ру»
В статье указаны основные ошибки, которые совершают начинающие администраторы 1С, и показаны способы их решения на примере теста Гилева.
Основная цель написания статьи — чтобы не повторять очевидные нюансы тем администраторам (и программистам), которые еще не набрали опыта с 1С.
Вторичная цель, если у меня будут какие-то недочеты, — на Инфостарте мне это укажут быстрее всего.
Неким стандартом "де факто" уже стал тест В. Гилева . Автор на своем сайте дал вполне понятные рекомендации, я же просто приведу некоторые результаты, и прокомментирую наиболее вероятные ошибки. Естественно, что результаты тестирования на Вашем оборудовании могут отличаться, это просто для ориентира, что должно быть и к чему можно стремиться. Сразу хочу отметить, что изменения надо делать пошагово, и после каждого шага проверять, какой результат это дало.
На Инфостарте подобные статьи есть, в соответствующих разделх буду ставить на них ссылки (если пропущу что-то - просьба подсказать в комментариях, добавлю). Итак, предположим у вас тормозит 1С. Как диагностировать проблему, и как понять кто виноват, администратор или программист?
Исходные данные:
Тестируемый компьютер, основной подопытный кролик: HP DL180G6, в комплектации 2*Xeon 5650, 32 Gb, Intel 362i , Win 2008 r2. Для сравнения, сопоставимые результаты в однопоточном тесте показывает Core i3-2100. Оборудование специально взял не самое новое, на современном оборудовании результаты заметно лучше.
Для тестирования разнесенных серверов 1С и SQL, сервер SQL: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.
Для проверки 10 Gbit сети использовались Intel 520-DA2 адаптеры.
Файловая версия. (база лежит на сервере в расшаренной папке, клиенты подключаются по сети, протокол CIFS/SMB). Алгоритм по шагам:
0. Добавляем на файловый сервер тестовую базу Гилева в ту же папку, что и основные базы. С клиентского компьютера подключаемся, запускаем тест. Запоминаем получившийся результат.
Подразумевается, что даже для старых компьютеров 10 летней давности (Pentium на 775 socket) время от нажатия на ярлык 1С:Предприятие до появления окна базы должно пройти меньше минуты. (Celeron = медленная работа).
Если у Вас компьютер хуже, чем пентиум на 775 socket с 1 гб оперативной памяти, то я Вам сочувствую, и комфортной работы на 1С 8.2 в файловой версии Вам будет добиться тяжело. Задумайтесь или об апгрейде (давно пора), или о переходе на терминальный (или web, в случае тонких клиентов и управляемых форм) сервер.
Если компьютер не хуже, то можно пинать администратора. Как минимум — проверить работу сети, антивируса и драйвера защиты HASP.
Если тест Гилева на этом этапе показал 30 "попугаев" и выше, но рабочая база 1С все равно работает медленно - вопросы уже к программисту.
1. Для ориентира, сколько же может "выжать" клиентский компьютер, проверяем работу только этого компьютера, без сети. Тестовую базу ставим на локальный компьютер (на очень быстрый диск). Если на клиентском компьютере нет нормального ССД, то создается рамдиск. Пока, самое простое и бесплатное — Ramdisk enterprise .
Для тестирования версии 8.2 вполне достаточно 256 мб рамдиска, и! Самое главное. После перезагрузки компьютера, с работающим рамдиском, на нем должно быть свободно 100-200 мб. Соответственно, без рамдиска, для нормальной работы свободной памяти должно быть 300-400 мб.
Для тестирования версии 8.3 рамдиска 256 мб хватит, но свободной оперативной памяти надо больше.
При тестировании нужно смотреть на загрузку процессора. В случае, близком к идеальному(рамдиск), локальная файловая 1с при работе загружает 1 ядро процессора. Соответственно, если при тестировании у вас ядро процессора загружено не полностью — ищите слабые места. Немного эмоционально, но в целом корректно, влияние процессора на работу 1С описано . Просто для ориентира, даже на современных Core i3 с высокой частотой вполне реальны цифры 70-80.
Наиболее часто встречающиеся ошибки на этом этапе.
- Неправильно настроенный антивирус. Антивирусов много, настройки для каждого свои, скажу лишь то, что при грамотной настройке ни веб, ни касперский 1С не мешают. При настройках "по умолчанию" - может отниматься примерно 3-5 попугаев (10-15%).
- Режим производительности. Почему-то на это мало кто обращает внимания, а эффект - самый весомый. Если нужна скорость - то делать это обязательно, и на клиентских и на серверных компьютерах. (Хорошее описание у Гилева . Единственный нюанс, на некоторых материнских платах если выключить Intel SpeedStep то нельзя включать TurboBoost).
Включать режим производительности можно (и желательно) в двух местах:
- через BIOS. Отключить режимы C1, C1E, Intel С-state (C2, C3,C4). В разных биосах они называтся по разному, но смысл один. Искать долго, требуется перезагрузка, но если сделал один раз - потом можно забыть. Если в BIOS все сделать правильно, то скорости добавится. На некоторых материнских платах настройками BIOS можно сделать так, что режим производительности Windows роли играть не будет. (Примеры настройки BIOS у Гилева). Эти настройки в основном касаются серверных процессоров или "продвинутых" BIOS, если Вы такое у себя не нашли, и у вас НЕ Xeon - ничего страшного.

- Панель управления - Электропитание - Высокая производительность. Минус - если ТО комптютера давно не проводилось, он будет сильнее гудеть вентилятором, будет больше греться и потреблять больше энергии. Это - плата за производительность.
|
Это - настройки по умолчанию. В BIOS C-state включены, режим энергопотребления сбалансированный | ![]() |
|
В BIOS C-state включены, режим высокой производительности Для Pentium и Core на этом можно остановиться, из Xeon еще можно выжать немного "попугайчиков" | ![]() |
|
В BIOS C-state выключены, режим высокой производительности. Если не использовать Turbo boost - именно так должен выглядеть сервер, настроенный на производительность | ![]() |
А теперь цифры. Напомню: Intel Xeon 5650, ramdisk. В первом случае тест показывает 23.26, в последнем - 49.5. Разница - почти двухкратная. Цифры могут варьироваться, но соотношение остается практически таким же для Intel Core.
Уважаемые администраторы, вы можете как угодно ругать 1С, но если конечным пользователям нужна скорость - необходимо включать режим высокой производительности.
в) Turbo Boost. Сначала надо понять, поддерживает ли Ваш процессор эту функцию, например . Если поддерживает, то можно еще вполне легально получить немного производительности. (вопросы разгона по частоте, особенно серверов, касаться не хочу, делайте это на свой страх и риск. Но соглашусь с тем, что повышение Bus speed со 133 до 166 дает очень ощутимый прирост как скорости, так и тепловыделения)
Как включать turbo boost написано, например, . Но! Для 1С есть некоторые нюансы (не самые очевидные). Сложность в том, что максимальный эффект от turbo boost проявляется тогда, когда включены C-state. И получается примерно такая картинка:

Обратите внимание, что множитель - максимальный, частота Core speed - красивейшая, производительность - высокая. Но что же будет в результате с 1с?
А в итоге получается, что по тестам производительности ЦПУ вариант с множителем 23 впереди, по тестам Гилева в файловой версии - производительность с множителем 22 и 23 одинаковая, а вот в клиент-серверной - вариант с множителем 23 ужас ужас ужас (даже, если C-state выставить на уровень 7, то все равно медленнее, чем с выключенным C-state). Поэтому рекомендация, проверьте оба варианта у себя, и выберите из них лучший. В любом случае, разница 49,5 и 53 попугая - достаточно значительная, тем более это без особых усилий.
Вывод - turbo boost включать обязательно. Напомню, что недостаточно включить пункт Turbo boost в биосе, надо еще посмотреть и другие настройки (BIOS: QPI L0s, L1 - disable, demand scrubbing - disable, Intel SpeedStep - enable, Turbo boost - enable. Панель управления - Электропитание - Высокая производительность). И я бы все-таки (даже для файловой версии) остановился на варианте, где c-state выключен, хоть там множитель и меньше. Получится как-то так...

Достаточно спорным моментом является частота памяти. Например вот частота памяти показывается как очень сильно влияющая. Мои же тесты - такой зависимости не выявили. Я не буду сравнивать DDR 2/3/4, я покажу результаты изменения частоты в пределах одной линейки. Память одна и та же, но в биосе принудительно ставим меньшие частоты.
![]() | ![]() | ![]() |
И результаты тестирования. 1С 8.2.19.83, для файлового варианта локальный рамдиск, для клиент-серверного 1С и SQL на одном компьютере, Shared memory. Turbo boost в обоих вариантах выключен. 8.3 показывает сопоставимые результаты.
Разница - в пределах погрешности измерений. Я специально вытащил скрины CPU-Z чтобы показать, что со сменой частоты меняются и другие параметры, те же CAS Latency и RAS to CAS Delay, что нивелирует изменение частоты. Разница будет тогда, когда физически будут меняться модули памяти, с более медленных на более быстрые, но и там цифры не особо значительные.
2. Когда с процессором и памятью клиентского компьютера разобрались, переходим к следующему очень важному месту - сети. Про тюнинг сети написаны многие тома книг, есть статьи на Инфостарте ( , и другие), здесь я на эту тему заострять внимание не буду. Перед началом тестирования 1С просьба убедиться, что iperf между двумя компьютерами показывает всю полосу (для 1 гбит карточек - ну хотя бы 850 мбит, а лучше 950-980), что выполнены советы Гилева . Потом - самой простой проверкой работы будет, как это ни странно, копирование одного большого файла (5-10 гигабайт) по сети. Косвенным признаком нормальной работы на сети в 1 гбит будет средняя скорость копирования 100 мб/сек, хорошей работы — 120 мб/сек. Хочу обратить внимание, что слабым местом (в том числе) может быть и загруженность процессора. SMB протокол на Linux достаточно плохо параллелится, и во время работы он вполне спокойно может «скушать» одно ядро процессора, и больше не потреблять.
И еще. С настройками по умолчанию windows клиент лучше всего работает с windows server (или даже windows рабочая станция) и протоколом SMB/CIFS, linux клиент (debian, ubuntu остальные не смотрел) лучше работает с linux и NFS (с SMB тоже работает, но на NFS попугаи выше). То, что при линейном копировании вин-линукс сервер на нфс копируется в один поток быстрее, еще ни о чем не говорит. Тюнинг debian для 1С - тема отдельной статьи, я к ней еще не готов, хотя могу сказать, что в файловой версии получал даже немного бОльшую производительность, чем Win вариант на этом же оборудовании, но с postgres при пользователях свыше 50 у меня пока еще все очень плохо.
Самое главное, о чем знают "обжегшиеся" администраторы, но не учитывают начинающие. Есть очень много способов задать путь к базе 1с. Можно сделать servershare, можно 192.168.0.1share, можно net use z: 192.168.0.1share (и в некоторых случаях такой способ тоже сработает, но далеко не всегда) и потом указывать диск Z. Вроде бы все эти пути указывают на одно и то же место, но для 1С есть только один способ, достаточно стабильно дающий нормальную производительность. Так вот, правильно делать надо так:
В командной строке (или в политиках, или как Вам удобно) - делаете net use DriveLetter: servershare. Пример: net use m: serverbases. Я специально подчеркиваю, НЕ IP адрес, а именно имя сервера. Если сервер по имени не виден - добавьте его в dns на сервере, или локально в файл hosts. Но обращение должно быть по имени. Соответственно - в пути к базе обращаться к этому диску (см картинку).

А теперь я на цифрах покажу, почему именно такой совет. Исходные данные: Карты Intel X520-DA2, Intel 362, Intel 350, Realtek 8169. ОС Win 2008 R2, Win 7, Debian 8. Драйвера последние, обновления применены. Перед тестированием я убедился, что Iperf дает полную полосу (кроме 10 гбит карточек, там получилось только 7.2 Gbit выжать, позже посмотрю почему, тестовый сервер еще не настроен как надо). Диски разные, но везде SSD(специально вставил одиночный диск для тестирования, больше ничем не нагружен) или рейд из SSD. Скорость 100 Mbit получена путем ограничения в настройках адаптера Intel 362. Разницы между 1 Gbit медь Intel 350 и 1 Gbit оптика Intel X520-DA2 (полученной путем ограничения скорости адаптера) не обнаружено. Максимальная производительность, турбобуст выключен (просто для сопоставимости результатов, турбобуст для хороших результатов добавляет чуть меньше 10%, для плохих - вообще может никак не сказаться). Версии 1С 8.2.19.86, 8.3.6.2076. Цифры привожу не все, а только самые интересные, чтобы было с чем сравнивать.
|
100 Mbit CIFS Win 2008 - Win 2008 обращение по ip адресу |
100 Mbit CIFS Win 2008 - Win 2008 обращение по имени |
1 Gbit CIFS Win 2008 - Win 2008 обращение по ip адресу |
1 Gbit CIFS Win 2008 - Win 2008 обращение по имени |
1 Gbit CIFS Win 2008 - Win 7 обращение по имени |
1 Gbit CIFS Win 2008 - Debian обращение по имени |
10 Gbit CIFS Win 2008 - Win 2008 обращение по ip адресу |
10 Gbit CIFS Win 2008 - Win 2008 обращение по имени |
|
| 11,20 | 26,18 | 15,20 | 43,86 | 40,65 | 37,04 | 16,23 | 44,64 | |
| 1С 8.2 | 11,29 | 26,18 | 15,29 | 43,10 | 40,65 | 36,76 | 15,11 | 44,10 |
| 8.2.19.83 | 12,15 | 25,77 | 15,15 | 43,10 | 14,97 | 42,74 | ||
| 6,13 | 34,25 | 14,98 | 43,10 | 39,37 | 37,59 | 15,53 | 42,74 | |
| 1С 8.3 | 6,61 | 33,33 | 15,58 | 43,86 | 40,00 | 37,88 | 16,23 | 42,74 |
| 8.3.6.2076 | 33,78 | 15,53 | 43,48 | 39,37 | 37,59 | 42,74 |
Выводы (из таблицы, и из личного опыта. Касается только файловой версии):
- По сети можно получить вполне нормальные цифры для работы, если эту сеть нормально настроить, и правильно прописать путь в 1С. Даже первые Core i3 вполне могут давать 40+ попугаев, что достаточно неплохо, причем это не только попугаи, в реальной работе разница тоже заметна. Но! ограничением при работе нескольких (больше 10) пользователей уже будет выступать не сеть, тут 1 Гбит еще хватит, а блокировки при многопользовательской работе (Гилев).
- платформа 1C 8.3 в разы требовательнее к грамотной настройке сети. Базовые настройки - см Гилев , но учтите, что влиять может все. Видел ускорение от того, что деинсталлировали (а не просто отключали) антивирус, от убирания протоколов типа FCoE, от смены драйверов на более старую, но microsoft certified версию (особенно касается дешевых карточек типа асусов и длинков), от убирания второй сетевой карточки из сервера. Очень много вариантов, настраивайте сеть вдумчиво. Вполне может быть ситуация, когда платформа 8.2 дает приемленые цифры, а 8.3 - в два или даже больше раз меньше. Попробуйте поиграться с версиями платформы 8.3, иногда получается очень большой эффект.
- 1С 8.3.6.2076 (может и более поздние, точную версию еще не искал) по сети все-таки настроить попроще, чем 8.3.7.2008. Добиться от 8.3.7.2008 нормальной работы по сети (в сопоставимых попугаях) получилось всего несколько раз, повторить для более общего случая не смог. Сильно не разбирался, но судя по портянкам от Process Explorer там запись не так идет, как в 8.3.6.
- Несмотря на то, что при работе на 100Мбит сети график ее загруженности небольшой, (можно сказать что сеть свободная), скорость работы все равно гораздо меньше, чем на 1 гбит. Причина - задержки (latency) сети.
- При прочих равных условиях (хорошо работающей сети) для 1С 8.2 соединение Intel - Realtek медленнее на 10%, чем Intel-Intel. А вот realtek-realtek вообще могут дать резкие проседания на ровном месте. Поэтому, если есть деньги - лучше везде держать сетевые карточки Intel, если денег нет - то Intel ставить только на сервер (ваш К.О.). Да и инструкций по тюнингу интелевых сетевых карточек в разы больше.
- Настройки антивирусов по умолчанию (на примере drweb 10 версии) отнимают около 8-10% попугаев. Если настроить как надо (разрешить процессу 1cv8 делать все, хоть это и не безопасно) - скорость такая же, как и без антивируса.
- Линуксовым гуру НЕ читать. Сервер с samba это здорово и бесплатно, но если на сервер поставить Win XP или Win7 (а еще лучше - серверные ОС), то в файловой версии 1с будет работать быстрее. Да, и samba и стек протоколов и настройки сети и многое многое другое в debian/ubuntu хорошо тюнингуется, но делать это рекомендуется специалистам. Нет смысла ставить линукс с настройками по умолчанию и потом говорить, что он медленно работает.
- Достаточно неплохо проверять работу дисков, подключенных через net use, с помощью fio . По крайней мере будет понятно, или это проблемы с платформой 1С, или с сетью/диском.
- Для однопользовательского варианта не могу придумать тесты (или ситуацию) ,где была бы видна разница между 1Гбит и 10 Гбит. Единственное, где 10Гбит для файловой версии дал результат лучше - это подключение дисков по iSCSI, но это тема отдельной статьи. Все-таки считаю, что для файловой версии 1 Гбит карточек достаточно.
- Почему при 100 Мбит сети 8.3 работает заметно быстрее 8.2 - не понимаю, но факт имел место быть. Все остальное оборудование, все остальные настройки абсолютно одинаковые, просто в одном случае тестируется 8.2, а в другом - 8.3.
- Не тюнингованный NFS win - win или win-lin дает 6 попугаев, в таблицу включать не стал. После тюнинга 25 получил, но нестабильно (разбег в измерениях больше 2 единиц). Пока не могу дать рекомендации по использованию windows и NFS протокола.
Терминальный сервер. (база лежит на сервере, клиенты подключаются по сети, протокол RDP). Алгоритм по шагам:
- Добавляем на сервер тестовую базу Гилева в ту же папку, что и основные базы. С этого же сервера подключаемся, запускаем тест. Запоминаем получившийся результат.
- Точно так же, как и в файловой версии, настраиваем работу процессора. В случае терминального сервера - процессор вообще несет на себе основную роль (подразумевается, что нет явных слабых мест, типа нехватки памяти или огромного количества ненужного ПО).
- Настройка сетевых карточек в случае терминального сервера практически не влияет на работу 1с. Для обеспечения "особого" комфорта, если у вас сервер выдает больше 50 попугаев можно поиграться с новыми версиями RDP протокола, просто для комфорта работы пользователей, более быстрого отклика и скроллинга.
- При активной работе большого количества пользователей (а здесь уже можно пробовать и 30 человек на одну базу подключить, если постараться) очень желательно поставить SSD диск. Почему-то считается, что диск не особо влияет на работу 1С, но все тесты проводят с включенным на запись кэшем контроллера, что неправильно. Тестовая база маленькая, она вполне помещается в кэш, отсюда и высокие цифры. На реальных (больших) базах все будет совершенно по другому, поэтому для тестов кэш отключен.
|
Raid 10 4x SATA 7200 ATA ST31500341AS | Raid 10 4x SAS 10k | Raid 10 4x SAS 15k | Одиночный SSD | Ramdisk | Ramdisk |
Включен кэш RAID контроллера |
|
| 21,74 | 28,09 | 32,47 | 49,02 | 50,51 | 53,76 | 49,02 | |
| 1С 8.2 | 21,65 | 28,57 | 32,05 | 48,54 | 49,02 | 53,19 | |
| 8.2.19.83 | 21,65 | 28,41 | 31,45 | 48,54 | 49,50 | 53,19 | |
| 33,33 | 42,74 | 45,05 | 51,55 | 52,08 | 55,56 | 51,55 | |
| 1С 8.3 | 33,46 | 42,02 | 45,05 | 51,02 | 52,08 | 54,95 | |
| 8.3.7.2008 | 35,46 | 43,01 | 44,64 | 51,55 | 52,08 | 56,18 |
- Включенный кэш RAID контроллера нивелирует всю разницу между дисками, цифры одинаковые и для сата, и для сас. Тестирование с ним для небольшого объема данных бесполезно и не является каким-то показателем.
- Для платформы 8.2 разница в производительности между SATA и SSD вариантами - более чем в два раза. Это не опечатка. Если во время теста на САТА дисках смотреть на монитор производительности. то там явно видно "Активное время работы диска (в%)" 80-95. Да, если включить кэш самих дисков на запись скорость вырастет до 35, если включить кэш рейд контроллера - до 49 (независимо от того, какие диски тестируются в данный момент). Но это - синтетические попугаи кэша, в реальной работе при больших базах никогда не будет 100% write cache hit ratio.
- Скорости даже дешевых ССД (я тестировал на Agility 3) вполне хватает для работы файловой версии. Ресурс записи - другое дело, тут смотреть надо в каждом конкретном случае, понятно, что у Intel 3700 он будет на порядок выше, но там и цена соответствующая. И да, я понимаю, что при тестировании SSD диска я тоже тестирую в бОльшей степени кэш этого диска, реальные результаты будут меньше.
- Самым правильным (с моей точки зрения) решением будет выделить 2 ССД диска в зеркальный рейд для файловой базы (или нескольких файловых баз), и ничего больше туда не помещать. Да, при зеркале ССД изнашиваются одинаково, и это минус, но хотя бы от ошибок электроники контроллера хоть как-то застрахованы.
- Основные плюсы ССД дисков для файлового варианта появятся тогда, когда будет много баз, и в каждой по несколько пользователей. Если баз 1-2, и пользователей в районе 10, то и SAS дисков хватит. (но в любом случае - смотреть на загрузку этих дисков, хотя бы через perfmon).
- Основные плюсы терминального сервера - у него могут быть очень слабые клиенты, и настройки сети на терминальный сервер влияют гораздо меньше (опять ваш К.О.).
Если же и тест Гилева показываем маленькие цифры, и у вас и процессор с высокой частотой, и диски быстрые, то вот тут администратору надо брать как минимум perfmon, причем с записью всех результатов куда-нибудь, и смотреть, наблюдать, делать выводы. Однозначных советов не будет.
Клиент-серверный вариант.
Тесты проводил только на 8.2, т.к. на 8.3 все достаточно серьезно зависит от версии.
Для тестирования выбирал разные варианты серверов и сети между ними, чтобы показать основные тенденции.
|
1С: Xeon 5520 SQL: Xeon E5-2630 |
1С: Xeon 5520 SQL: Xeon E5-2630 Fibre channel - SSD |
1С: Xeon 5520 SQL: Xeon E5-2630 Fibre channel - SAS |
1С: Xeon 5650 SQL: Xeon E5-2630 |
1С: Xeon 5650 SQL: Xeon E5-2630 Fibre channel - SSD |
1С: Xeon 5650 SQL: Xeon E5-2630 | 1С: Xeon 5650 = | 1С: Xeon 5650 = | 1С: Xeon 5650 = | 1С: Xeon 5650 = | 1С: Xeon 5650 = | |
| 16,78 | 18,23 | 16,84 | 28,57 | 27,78 | 32,05 | 34,72 | 36,50 | 23,26 | 40,65 | 39.37 | |
| 1С 8.2 | 17,12 | 17,06 | 14,53 | 29,41 | 28,41 | 31,45 | 34,97 | 36,23 | 23,81 | 40,32 | 39.06 |
| 16,72 | 16,89 | 13,44 | 29,76 | 28,57 | 32,05 | 34,97 | 36,23 | 23,26 | 40,32 | 39.06 |
Вроде все интересные варианты рассмотрел,если что-то интересует еще - пишите в комментария, постараюсь сделать.
- САС на СХД работает медленнее, чем локальные ССД, даже несмотря на то, что у СХД большие размеры кэша. ССД и локальные и на СХД для теста Гилева работают с сопоставимой скоростью. Какой-то стандартный многопоточный тест (не только записи, а всего оборудования) кроме нагрузочного 1С из ЦУП я не знаю.
- Смена сервера 1С с 5520 на 5650 дала практически удвоение производительности. Да, конфигурации серверов не совпадают полностью, но тенденцию показывает (ничего удивительного).
- Увеличение частоты на сервере SQL конечно дает эффект, но не такой, как на сервере 1С, MS SQL сервер отлично умеет (если его об этом попросить) использовать многоядерность и свободную память.
- Смена сети между 1С и SQL с 1 гбит на 10 гбит дает примерно 10% попугаев. Ожидал большего.
- Включение Shared memory эффект все-таки дает, хоть и не 15%, как в статье описано. Делать обязательно, благо это быстро и просто. Если кто-то при установке дал серверу SQL именованный инстанс, то для работы 1С имя сервера надо указывать не FQDN (будет работать tcp/ip), не через localhost или просто ServerName, а через ServerNameInstanceName, например zz-testzztest. (Иначе будет ошибка СУБД: Microsoft SQL Server Native Client 10.0: Поставщик общей памяти: Не найдена библиотека общей памяти, использующаяся для установки соединения с SQL Server 2000 . HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr: SQLSTATE=08001, state=1, Severity=10, native=126, line=0).
- для пользователей меньше 100 единственный смысл для разнесения на два отдельные сервера - это лицензия на Win 2008 Std (и более старые версии), которая поддерживает только 32 Гб ОЗУ. Во всех других случаях - 1С и SQL однозначно надо ставить на один сервер и давать ему побольше (хотя бы 64 Гб) памяти. Давать MS SQL меньше 24-28 Гб ОЗУ - неоправданная жадность (если Вы думате, что у Вас этой памяти ему хватает и все нормально работает - может Вам и файловой версии 1С бы хватило?)
- Насколько хуже работает связка 1С и SQL в виртуальной машине - тема отдельной статьи (подсказка - заметно хуже). Даже в Hyper-V все не так однозначно...
- Сбалансированный режим производительности - это плохо. Результаты вполне кореллируют с файловой версией.
- В многих источниках написано, что отладочный режим (ragent.exe -debug) дает сильное понижение производительности. Ну понижает, да, но 2-3% я бы не назвал значительным эффектом.
Симптомы пациента и анамнез:
Работа нескольких пользователей по сети с одним и тем же файлом (базой данных) включает механизм сетевой блокировки. Это заставляет систему тратить драгоценное время на выявление открытых сессий записи, и соответственно разрешение конфликтов.
Основные признаки работы блокировок:
- быстрая работа пользователя с базой по сети в монопольном режиме и крайне медленная - при одновременной работе нескольких пользователей
- быстрая работа пользователя с локальной базой на сервере и медленная - по сети
- обращения к файловой системе чуть менее 10 мбайт/сек
Итак, мне досталась задача - сделать так, чтобы в 1С могли одновременно работать целых три пользователя! Смешно, не так ли?
Все шуточки я забыл, когда увидел, с чем предстоит иметь дело: "сервер" в лице обычного офисного компьютера и два ноутбука.
Счастье было бы неполным, если бы не замечательные операционные системы - на компьютере и на одном ноутбуке Windows 7, на другом - Windows 8.
При попытке одновременно провести документы на ноутбуках один тупил около минуты, а второй вылетел из 1С с текстом ошибки "не удалось заблокировать таблицу...".
Запуск 1С на ноутбуке - это отдельное шоу, длившееся порядка 3 минут!
На многих ресурсах сталкивался с советом перейти на работу в терминальном доступе. К сожалению, Windows 7 не позволяет штатными средствами превратиться в сервер терминалов - максимум одно активное подключение. При этом остальные сеансы не прекращаются, можно переподключиться под другим пользователем - "выкинув" при этом предыдущего пользователя, но не завершив его сеанс. Поэтому следует перенести 1С на серверную ОС, где таких ограничений нет. Клиент на свой страх и риск решил проблему вместо этого с помощью сторонней утилиты Windows7_SP1_RDPhack.
Но на этом приключения не закончились. Даже в терминальном подключении остались значительные тормоза. Вновь меня выручили всемогущие поисковики. Ниже даны советы по ускорению файловой 1С, которым я последовал:
1. Отключить использование протокола сети IPv6 , настроить адресацию на "старом" IPv4.
2. Добавить процессы 1С в исключения брандмауэра Windows, а также в исключения антивируса, либо отключить их вовсе (более рискованно, но простой тест показал увеличение скорости перепроведения документов при отключенном антивирусе Avast в разы !)
3. Запустить индексацию полнотекстового поиска в 1С либо выключить его вовсе
4. Запустить Тестирование и исправление базы, проверку утилитой ChDbfl
5. Запустить в конфигурации пункт Проверка конфигурации (если конфигурация не типовая, это может быть полезным). По результатам проверки конфигурации она волшебным образом уменьшилась в размерах почти на треть. Что уж и как до меня обновляли приходящие программисты - особо не вникал, но факт налицо.
6. Отключить ненужные функциональные опции.
7. Настроить права пользователям. (Этот и предыдущий советы показались глупостью, до тех пор, пока я не понаблюдал за отрисовкой управляемых форм при открытии списка документов. Чем меньше лишнего в управляемом интерфейсе - тем, как правило, быстрее он работает)
8. Запустить пересчет итогов и восстановление последовательности (значительный прирост может быть только в случае, если долгое время итоги не восстанавливались)
9. Указать "Скорость соединения - низкая" в настройках списка баз (это особого результата не дало, разве что отключились картинки у подсистем:))
После выполнения всех этих шагов файловая база 1С заработала на порядок шустрее. Запускаться стала максимум секунд за 10, а скорость перепроведения документов увеличилась в среднем в 12 раз.
Возможно, эта небольшая статья пригодится и вам, если вдруг понадобится ускорить файловую базу 1С.
P.S: А запустить файловую 1С, используя сетевой доступ к общей папке - все же нереально, т.к. даше самый шустрый твердотельный диск, оперативная память и процессор уткнутся в сетевые блокировки, и работа более одного пользователя будет фактически невозможна. Речь идет конкретно о конфигурации УТ 11.1. Самописные небольшие конфигурации вполне могут работать весьма быстро даже в файловом варианте.
Дополнения из комментариев к публикации:
Дефрагментация диска с файловой базой
Свертка базы (может оказаться полезной, если база большого объема, например, за несколько лет). У клиента база была достаточно молодая, поэтому свертка была нецелесообразна.
Модернизация аппаратной части - более быстрый винчестер, новый свитч, процессор, и т.д.
Установить на веб-сервер , доступ с помощью тонкого клиента. Тут мнения разделились. Кто-то говорит, в разы быстрее, кто-то - что ускорения не отмечено.





