1с не использует ресурсы процессора
Обновлено: 07.07.2024
Есть ли способы заставить 1С использовать оба ядра процессора при своей работе, само собой речь идет о клиентской части, а не о серверной. Покупаешь новые компы в контору, типа современные Intel Core 2 Duo, и чё толку, старые пни серии D на 3Ггц работают быстрее чем какой нить E7200 (2*2,53) т.к. при работе клиентского приложения используется только 50% мощности. ОБИДНО.
УПП перепроведение документов. одно ядро в 100% загрузка второе в нольцелых хрен десятых.
так они же последовательно должны проводится в хронологическом порядке
Ставьте порядочные игрушки - станет легче переносить несправедливость.
8.0 или 8.1? Нельзя никак. Только переписывать платформу под многопоточность, а оно вообще не впилось 1С.
Что ты хочешь от платформы, которая начиналась создаваться в 2000 году.
Дак вот 8.1 свежая платформа, мир катится к многоядерности, 3, 4, скоро будет 8 а 1С так и будет карячится на одном. И чё мне дадут два экземпляра, быстрее будет формироваться один и тот же отчет в двух экземплярах, бред. Обидно ссу@%9(0/. :((
Да может кто то может опровергнуть и сказать что 8.2 будет поддерживать многоядерность?
Может и бред скажу: В диспетчере можно указать для процесса какой процессор использовать - а "программно" что нельзя? Запустил два экземпляра на разных процессорах. Один экземпляр одну последовательность восстанавливает, а другой экземпляр - другую последовательность. Сиди смотри и наслаждайся :)
Я думаю, от 8.х никакой поддержки многоядерности ждать не приходится. Хотя бы свой сервер причесали.
я его ставил, но кроме как показ процессов и установки приоритета для них я там ничего не нашел. Хотя заявлено было что может помочь в распределении нагрузки. Может не нашел опцию.. И почему ты говоришь что частично?
Ага запускаеш одинаковые отчёты на разных ядрах и делаеш ставки какой быстрее обработает =)
такие компы - для висты спецом. одно ядро она использует, другое - прикладные программы ;)
оптимизируйте сервер, клиент/сервер, толку будет больше
как вариант я согласен, но всё же проблема решается лишь частично. Взять ту же УТ, формируешь большой отчет, данные обрабатываются на сервере, тут вопросов нет, но вот когда проводится Расчет ширины колонок отчета, опять же клиентское приложение грузит одно ядро своей системы и порой продолжительное время. Это не вариант. Так можно дойти и до виртуализации на сервере и терминальных соединениях.
Почему какой то WinRAR умеет грузить ядра грамотно, а система корпоративного уровня которая рвётся в сегмент ERP, CRM, MRP и т.д. не умеет этого делать
Учи мат. часть. ИМХО вряд ли многие вещи можно на потоки раскидать в 1С, прально тебе говорят, оптимизируй сервер приложений и сервер БД - больше толку будет. Многоядерность по настоящему гуд: для нормальных игр и приложений обработки видео, 3D и т.д. (ну и ессно на серверах :)
точно! Виста любит по диску пошарится - то ли ищет что-то, то ли индексирует :-)
Кто тебе сказал, что WinRAR грамотно грузит ядра? ПРоцессор грузит - операционна система :)
было бы неплохо запускать ОбработкуОжидания на дркгом ядре - тем более когда она выполняет фоновые действия, а не с текущей открытой формой
Я могу с уверенностью сказать что WinRAR при работе использует оба ядра системы, насколько грамотно он их использует я утверждать не возьмусь, и то что в момент работы winrar-a процы грузит система тоже не буду доказывать но в диспетчере загрузка ложится на процесс winrar-a. Вот тут я вообще не соглашусь.
суть задачи архиватора позволяет задействовать все процессоры системы. 1С-ка на компе пользователя это каким образом может сделать? Что касается сервера, то на кластере можно создать несколько процессов и привязать каждый процесс к нужному ярду. Без проблем.
Не я писал платформу 1С поэтому я на этот вопрос не отвечу, и в мат части по распараллеливанию вычислительных процессов я не силён, т.к. в этой области программирования не работал. Но ведь явно что во время работы приложения можно распараллелить чась вычислений и действий. Или я не прав? Что касается сервера я уже говорил что не всё что выполняется системой 1С можно выполнить на сервере, можно лишь грамотно перенести ряд кода выполняться на сервере.
следует заметить, что далеко не каждую задачу можно эффективно распараллелить. Тем более - для грамной реализации параллельных вычислений почти зачастую приходится полностью перерабатывать алгоритмы.
> Но ведь явно что во время работы приложения можно распараллелить чась вычислений и действий. Или я не прав? какие вычисления вы предлагаете распараллелить?
а вот это - замечательное заблуждение. даже 3.80 рар не загружает многопроцессорную систему на 100%, а только на 100/кол-во процессоров(ядер)% - а что там график загрузки показывает - это фигня полная.
"во время работы приложения можно распараллелить чась вычислений и действий". да, при условии, что они логически независимы друг от друга
> и в мат части по распараллеливанию вычислительных процессов я не силён, т.к. в этой области программирования не работал. > Но ведь явно что во время работы приложения можно распараллелить чась вычислений и действий.
Т.е. все утверждают в невозможности такого решения а порой и в отсутствии необходимости, я так понял? как тогда ты объяснишь вот это
Лично у меня на 7-10 компах параллельно обрабытываются данные (фоном) в 1С которые не относятся к действиям пользователя - вот они как раз бы неплохо шли на 2м ядре :-)
Я ищу объяснение почему этого не может сделать компания 1С, а не я. Если те кто в этом больше понимает утверждает, что это сделать физически сложно и неоправданно, то вопрос снят с обсуждения и тема закрыта.
во! придумал! при запуске 1с - по оле запускай второй сеанс от робота для текущего пользователя - а у него - обработки ожидания, апи для управления какое-нить намути. таким образом даже 7.7 работать будет на 2 ядра
1с это может сделать. более того, сервер 1с 8.1 может использовать сколько хочешь ядер (т.н. кластер серверов). а зачем это клиенту - фиг знает.
Распараллелить удачно можно только независимые вычисления, так как в противном случае оба процессора будут ждать друг друга. Что касается 1С, то логичным видится только реализация интерфейсной части на одном процессоре, а вычисления на другом, так как распараллеливание вычислений по обращениям в базу данных - очень нетривиальная вещь. Кстати, вполне вероятно, что интерфейсная часть 1С и работает на другом процессоре, только она потребляет очень мало ресурсов и невидна. И прежде, чем говорить о процессорах, надо поговорить о многопоточности - 1С изначально однопоточное приложение. При использовании многопоточности при работе со встроенным языком возникнет масса сложностей даже с реализацией процесса отладки приложения. Сейчас же программист 1С прекрасно представляет, что у него происходит в программе и в какой последовательности выполняется.
В файлсерверной базе запустил первый попавшийся отчет (Диаграмма ганта). Грузятся оба ядра. 1-е 40-50%, 2-е 50-60%. Но это файл-сервер. Тут есть что распараллелить. В большинстве отчетов и обработок проведения на клиентской части клиент-сервера как правило распараллеливать нечего.
Ну вот если взять SQL, он же умеет распараллеливать свою работу. Почему например 1С при выполнении того же запроса не может параллельно выбирать данные из разных таблиц задействую вычислительную мощность всей системы. Вообщем ладно, если это всё не просто и только причинит вред, пусть работает как работает. Как в анекдоте про папу программиста: "Сын приходит к отцу, тот сидит трудится над каким то кодом проги - Сын: папа а почему солнце всходит и заходит всходит и заходит - Папа: А ты проверял? - Сын: Да - Папа: Тогда ничего не трогай, главное что проверял и работает
А ты попробуй запусти отчет который занимает много страниц на том же клиент-сервере. При выборке данных у тебя на серваке будет грузится оба ядва, а вот при непосредственном выводе отчета будет грузится клиент и засеки сколько. Тока в отчет добавь группировок что бы листов 100 было
Не обратил внимания как ты обозвал архитектуру "файл-сервер", такой организации не бывает по определению :) Либо файловая версия либо клиент-серверная
А кто сказал, что не может? Запусти два 1С-а, выполни в каждом из них по запросу, затем собери вместе и покажи отчет. И будет у тебя полное распараллелирование и использование обоих ядер. И ты сам будешь разделять работу и указывать процессорам, кому что делать.
А как же взаимовыручка? :-) Микрософт и прочие SQLи тоже жить хочут. Нельзя ж все под себя грести.
Почему этого нет на уровне платформы а не на уровне клиентских приложений, я если уж на то пошло могу вообще обойтись без запросов через 1С, можно юзать и прямые запросы к скулю. Вопрос то не в том как сделать это через жопу
Дисциплинированные у вас пользователи однако. Типа работают на компе тока в 1С и в одном экземпляре :))). А вот у нас наоткрывают кучу приложений (а могут ещё и терминального клиента заюзать) и жалуются типа всё тормозит. Та квот к чему я: если бы они работали на многоядерной системе они наверное ещё и фильмы параллельно смотрели без особого ущерба производительности. Мне всё таки кажется деньги потрачены не совсем зря.
если честно на пользователей мне было похер когда задавал этот вопрос, порой когда надо выполнить самому что либо объемное в 1С, сидишь и ждёшь, готов выключить вообще всё лишь бы 1С выполняла обработку быстрее. Дак ведь хрен.
сервер 1С тоже умеет распараллеливать свою работу. Любой сервер распараллелить очень легко - по триду на клиента. ты бы учебник какой по информатике почитал. Бывает такая архитектура, еще как бывает. Применительно к 1С - та самая файловая БД, к которой обращаются много пользователей одновременно.
"по определению" ? Поспорим об определениях? Внесите в студию определение, которому противоречит в како-либо части .
А вот тут не факт что виновата тока 1С, возможно дисковая подсистема тормозит, может нехватка памяти.
Такие вещи должен делать не клиент, а сервер приложений.
например некий отчет проверяет (отбирает) элементы справочника по некой формуле (сложной функции) таким образом на 2х ядрах можно проверять на допустимость одновремнно 2 элемента
на сервере приложений постоянно крутиться более важная обработка загрузки и выгрузки данных, обработки (сверки) загруженных данных и т.п.
Кстати да, +1. Представил себе одинэсника который пишет многопоточный код. и подумал, что лучше не надо таких возможностей предоставлять.
И представь себе вопросы на Мисте. Типа "Написал простейший запрос. Но он грузит напрочь всю 32 ядерную систему. Объясните пожалуйста, ка пальцах, как сделать так, чтобы работали хотя бы 16 ядер".
Недавно столкнулся с необычным случаем, у заказчика отвратительно работал сервер 1с, чтобы было понятно о чем идет речь, приведу такой пример — запуск толстого клиента мог занимать десяток минут. Когда измерили тестом Гилева, то результат был ниже худшего. Посмотрев ближайшие результаты замеров других пользователей, я понял, что это не единственный случай.
Речь не идет об оптимизации, когда надо поднять на 10-20% производительность, речь идет о поиске причин низкой производительности, и её устранению. Согласитесь это несколько разные вещи. На просторах интернета множество статей как раз о повышении производительности, которые ограничиваются только настройкой сервера 1с и (или) настройкой сервера баз данных. А вот статей, рассматривающих случаи низкой производительности, особенно если причин несколько, и эти причины находятся на разных уровнях, я не встречал.
Обычно администраторы бросаются смотреть результаты мониторинга. Тот случай, с которым я столкнулся, показывал практически нулевую загрузку процессора, наличие свободной ОЗУ, отсутствие очереди у сетевого интерфейса, и только очередь к диску показывала, что не все в порядке. Пришлось устроить проверку по полной программе, это, конечно, занимает много времени, требует исключения сервера из рабочего процесса, но зато дает результат. Возможно для кого-то подобный подход недопустим, более того, некоторые считают это непрофессиональным подходом, но им я ничем помочь не смогу.
Аппаратный уровень
Звучит банально, но именно с проверки работоспособности железа стоит начать. Дело в том, что можно только догадываться о проблемах с оборудованием, если смотреть на уровне операционной системы. В моем случае, не работал один из дисков в дисковом массиве. Как ни странно жесткий диск оказался исправным и, после водворения его на место, заработал, правда пришлось подождать некоторое время, пока не синхронизируются все данные (видать давно он был отключен). Если бы всё этим и закончилось, тогда бы и не было этой статьи. На всякий случай сервер подвергся аппаратному тестированию (стресс-тесты, тест памяти, физической проверки дисков и контроллеров), которые не выявили каких-либо проблем.
Уровень операционной системы
- привести в порядок файловую систему;
- отключить ненужные службы, удалить ненужные и, самое главное, вредоносные программы;
- проверить оптимальность настроек операционной системы.
- проверке логической структуры диска;
- удалении временных и ненужных файлов;
- дефрагментации файловой системы.
Уровень служб
В моем случае сервер 1с находился вместе с сервером баз данных MS SQL на одной машине, но аппаратная конфигурация сервера вполне обеспечивала их совместную деятельность, а вот настройки этих двух служб были совсем не оптимальными. Этим настройкам посвящено множество статей, например, эта, здесь мы сфокусируем внимание только на тех, что не требуют дополнительных вложений, например, приобретение жесткого диска.
Для сервера MS SQL в каждой базе были увеличены значения параметра авторасширения базы до 500 Мб, так как базы 1С являются быстрорастущими. Также был настроен ежедневный план обслуживания, в котором кроме создания дампа базы добавлено обновление статистики, очистка процедурного кэша и дефрагментация индексов. В моем случае, это заметно уменьшило количество операций записи. В качестве дополнительных мер можно порекомендовать еженедельно производить дефрагментацию базы и реорганизации индексов.
Для сервера 1С были изменены параметры «Количество ИБ на процесс» и «Количество соединений на процесс» рабочего сервера, первый получил значение 1, а второй 25. Подобные советы больше похожи на «танцы с бубном», но они дают результат. В рассматриваемом случае изменение этих параметров привело к значительному уменьшению операций чтения-записи на сервере, и он заработал в ожидаемом режиме. Тест Гилева также подтвердил прирост производительности.
Уровень баз
Сделав замеры под рабочей нагрузкой и после выхода пользователей, я столкнулся со странным результатом — под нагрузкой тест Гилева показывал лучшие результаты, чем при простое! Было также замечено огромное количество фоновых заданий выполняемых на тестовых базах. Тестовые базы использовались сисадминами для проведения различных тестовых задач. Я попросил удалить их — и все встало на свои места. Следует ли держать тестовые базы на рабочем сервере, решать конечно вам, но лучше для этого найти какое-то другое решение, например, использовать файловый вариант.
У одной из баз не удавалось уменьшить журнал транзакций, а у другой базы не пересоздавались индексы. Для обоих случаев есть одно простое и эффективное решение. Прежде чем его описать, следует уточнить, что здесь имеет место одинаковое наименование разных объектов: базы 1С и базы MS SQL, первые могут быть не базами MS SQL, а, например, базами PostgreSQL. В свою очередь вторые не обязательно будут базами для 1С. Исходя из этого резервные копии баз 1С (dt-файл) могут быть развернуты и на других СУБД, но ни кто не запрещает вам из этой же копии развернуть на MS SQL. Снимаем резервные копии баз 1С средствами 1С, после чего удалить 1С-базы из сервера 1С, а потом создать их вновь, залив содержимое из dt-файла.
Приведя все базы в порядок, мне уже не к чему было придраться: сервер работал ровно, дисковая подсистема работала в штатном режиме, пользователи радовались быстрой работе в 1с, администраторы удивлялись как теперь быстро проходят обновления.
Заключение
Если использовать только один уровень для поиска причин низкой производительности, то можно оставить без внимания причины, лежащие на других уровнях, то есть результат будет не достигнут. Приведенный пример наглядно показывает, что причин может быть несколько, и каждая из них может лежать на своем уровне. Надеюсь, что данный материал поможет кому-то побороть проблему низкой производительности 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 включены,
режим энергопотребления сбалансированный
Для Pentium и Core на этом можно остановиться,
из Xeon еще можно выжать немного "попугайчиков"
Если не использовать Turbo boost - именно так должен выглядеть
сервер, настроенный на производительность
А теперь цифры. Напомню: Intel Xeon 5650, ramdisk. В первом случае тест показывает 23.26, в последнем - 49.5. Разница - почти двухкратная. Цифры могут варьироваться, но соотношение остается практически таким же для Intel Core.
в) Turbo Boost. Сначала надо понять, поддерживает ли Ваш процессор эту функцию, например здесь. Если поддерживает, то можно еще вполне легально получить немного производительности. (вопросы разгона по частоте, особенно серверов, касаться не хочу, делайте это на свой страх и риск. Но соглашусь с тем, что повышение Bus speed со 133 до 166 дает очень ощутимый прирост как скорости, так и тепловыделения)
Как включать turbo boost написано, например, здесь. Но! Для 1С есть некоторые нюансы (не самые очевидные). Сложность в том, что максимальный эффект от turbo boost проявляется тогда, когда включены C-state. И получается примерно такая картинка:
Обратите внимание, что множитель - максимальный, частота Core speed - красивейшая, производительность - высокая. Но что же будет в результате с 1с?
Core speed (частота), GHz
CPU-Z Single Thread
Тест Гилева Ramdisk
Тест Гилева Ramdisk
А в итоге получается, что по тестам производительности ЦПУ вариант с множителем 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, я покажу результаты изменения частоты в пределах одной линейки. Память одна и та же, но в биосе принудительно ставим меньшие частоты.
 |  |  |
| 800 | 1066 | 1333 | |
| 48,54 | 49,50 | 50,51 | |
| 1с 8.2 файловый вариант | 49,50 | 49,50 | 49,02 |
| 49,02 | 49,02 | 49,50 | |
| 36,76 | 36,76 | 37,04 | |
| 1с 8.2 клиент-сервер | 37,04 | 37,04 | 36,50 |
| 36,23 | 36,76 | 36,76 |
2. Когда с процессором и памятью клиентского компьютера разобрались, переходим к следующему очень важному месту - сети. Про тюнинг сети написаны многие тома книг, есть статьи на Инфостарте (1, 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. Цифры привожу не все, а только самые интересные, чтобы было с чем сравнивать.
Вот что показывает накопленная статистика по тесту TPC-1C
Вот некоторые соображения по полученному графику.
1) Результаты показаны только для клиент-серверного варианта (ведь он используется в основном).
2) Результаты собраны за несколько лет от тысячи участников теста, а не выполнены одним человеком.
5) На результат влияет множество компонент, а не только процессор
6) Многие присылали результаты, не настроив оптимально среду
7) Для некоторых моделей процессоров результатов слишком мало, поэтому ошибки вроде пункта 6 могут сильно исказить общее мнение. Например очень мало результотов для E5-2687W.
ВЫВОД КОТОРЫЙ МНЕ КАЖЕТСЯ ОЧЕВИДЕН: Зависимость скорости одного потока 1С:Предприятие сильно зависит от частоты процессора.
Например для самой популярной серии процессоров E5-2600 самые дорогие E5-2687W, E5-2690 и самые быстрые.
Умышленно выбрал один из популярных процессоров E5-2650 чтобы продемонстрировать разброс значений теста.
Т.е. процессор это хорошо, это потенциал сервера, но его еще надо реализовать. Т.е. и так частота не самая высокая, так еще и среда, в которой 1с работает не настроена.
Предлагаю посмотреть не на мой тест, а на тест процессора (сторонний, что похожее на флопсы).
Но я еще не ответил, а что же делать тем, у кого много пользователей, скажем 400.
Далеко не все задачи однопоточные. Более того, далеко не все задачи используют небольшие обмьемы.
Читайте также: