1с тормозит сервер не нагружен

Обновлено: 07.07.2024

УТ 11. SQL экспресс.
На сервере крутится 2 базы, УТ 11 и БП.
БП вроде работает нормально. А вот УТ просто жутко тормозит.

Работает 5 пользователей.
Жуткие тормоза при создании и проведении документов.
В файловом варианте база летает.

Перезапуск агента сервера не помогает.
Временное облегчение приносит ТиИ базы.
Но это на сутки, а то и меньше.

ну и да - попробуйте заменить экспресс на нормальный (например девелопер попробуйте)
(1) Клиент жлоб) Чем меньше тем лучше. )))))
(2) Так там же вроде ни как не влияет?
1 гб оперативы и 1 физический проц/4 ядра. размер базы 10 гигов.
(0) Ну так и делайте ТиИ базы ежесуточно.
Или попробуйте понять почему оно приносит облегчение.

(8) делать ТИИ ежедневно не вариант

(0) не настроены регламенты SQL, угадал ?

Так, совсем не понял.
Посмотрел сейчас в Скуль менеджере.
Там база весит 36 гигабайт о_0!
При этом работает. Хотя у экспресса же ограничение на 10 гигов.
Как такое возможно?
(9) А что это тогда стоит?
Клиент говорил что не покупал скуль.
Крякнутый что ли?:)))
(12) Почему. Может и экспресс.
Просто у экспресса нет sql agent и регламенты надо выполнять снаружи, например батником по расписанию.
(11) Может это лог разросся.
(13) реиндексация, обновление статистики, очистка процедурного кэша.

(9) Мне казалось что у какого-то нового SQL Express есть Agent, я не уверен. Но sqlcmd есть в любом случае.

(10) Ну значит разбираться почему ТиИ помогает и делать это же но например средствами SQL.

(11) Что в данном случае называется словом база?

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

Тормоза начинаются когда процесс sql отжирает полностью одно ядро. Как понять чем вызвано?

(15) в SQL менеджере, в свойствах "Размер" )))

(16) поставь менеджмент студио или настрой техножурнал на сбор долгих сапросов. будь мужиком уже
(16) пиши тогда уже на какой операционке оно установлена и действительно ли там 64 бит у 1С-ного сервера. И где там устанавливают ограничения на число rphost
(17) Эххх
Я так сказать там пытаюсь разобраться за спасибо. По старой памяти.
так хочется по быстрому отделаться)))
(22) Разница проявляется на обработке больших объёмов данных - тупо для 32-битного 2 Гб - предел.
(22) в прямом. если упирается в скуль, то разрядность сервера 1с никак не влияет
Кстати, а сколько ограничение памяти для SQL Express ?
(25) Три будет, если "магический ключ" включили при загрузке.
(27) ну так кто мы такие, чтобы запрещать кому-то его включать?

SQL Server 2012 Express Edition — является бесплатной версией SQL Server, идеально подходящей для разработки и развёртывания в настольных системах, в веб и малых серверах приложений. Новой возможностью Express версии SQL Server 2012 является SQL Server Express LocalDB. Это облегченная версия Express, которая имеет все программные функции, запускается в пользовательском режиме, быстро устанавливается, не требует настройки и имеет низкие системные требования.

Недавно столкнулся с необычным случаем, у заказчика отвратительно работал сервер 1с, чтобы было понятно о чем идет речь, приведу такой пример — запуск толстого клиента мог занимать десяток минут. Когда измерили тестом Гилева, то результат был ниже худшего. Посмотрев ближайшие результаты замеров других пользователей, я понял, что это не единственный случай.
Речь не идет об оптимизации, когда надо поднять на 10-20% производительность, речь идет о поиске причин низкой производительности, и её устранению. Согласитесь это несколько разные вещи. На просторах интернета множество статей как раз о повышении производительности, которые ограничиваются только настройкой сервера 1с и (или) настройкой сервера баз данных. А вот статей, рассматривающих случаи низкой производительности, особенно если причин несколько, и эти причины находятся на разных уровнях, я не встречал.
Обычно администраторы бросаются смотреть результаты мониторинга. Тот случай, с которым я столкнулся, показывал практически нулевую загрузку процессора, наличие свободной ОЗУ, отсутствие очереди у сетевого интерфейса, и только очередь к диску показывала, что не все в порядке. Пришлось устроить проверку по полной программе, это, конечно, занимает много времени, требует исключения сервера из рабочего процесса, но зато дает результат. Возможно для кого-то подобный подход недопустим, более того, некоторые считают это непрофессиональным подходом, но им я ничем помочь не смогу.

Аппаратный уровень


Звучит банально, но именно с проверки работоспособности железа стоит начать. Дело в том, что можно только догадываться о проблемах с оборудованием, если смотреть на уровне операционной системы. В моем случае, не работал один из дисков в дисковом массиве. Как ни странно жесткий диск оказался исправным и, после водворения его на место, заработал, правда пришлось подождать некоторое время, пока не синхронизируются все данные (видать давно он был отключен). Если бы всё этим и закончилось, тогда бы и не было этой статьи. На всякий случай сервер подвергся аппаратному тестированию (стресс-тесты, тест памяти, физической проверки дисков и контроллеров), которые не выявили каких-либо проблем.

Уровень операционной системы

  1. привести в порядок файловую систему;
  2. отключить ненужные службы, удалить ненужные и, самое главное, вредоносные программы;
  3. проверить оптимальность настроек операционной системы.
  1. проверке логической структуры диска;
  2. удалении временных и ненужных файлов;
  3. дефрагментации файловой системы.

Уровень служб


В моем случае сервер 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С-сервера.

Есть сервер c ОС WinServer2008 E3-1230V2 32Гб ОЗУ, к нему подключаются пользователи через RDP.
Долго открывается сама программа и долго открываются списки накладных, СФ и т.п. В первый раз список счетов/накладных открывается 10-20сек. При повторном открытии около 2сек.
На сервере диски обычные (не SSD). по ресурсам при запуске процессор используется на 20% общая скорость чтения с дисков порядка 1-3Мб/сек.
Файл с базой 1,8Гига, файл логов 0,5Гига. База файловая(не SQL). База и система на разных логических дисках, но на одном физическом.
При запуске почему-то лезет на диск C в AppData в кеш.
Антивирус отключил, помогло не сильно.
1С УТ 8.3 одна из последних версий. Пользователей всего 4 человека.

Можно как-то ускорить? Если смысл ставить SSD и переносить туда систему или Базу?

  • Вопрос задан более трёх лет назад
  • 6082 просмотра

Jump

В данном случае явно упирается в диски.

При запуске почему-то лезет на диск C в AppData в кеш.

Основная работа идет именно с кэшированными данными, поэтому AppData просто обязан размещаться на SSD для комфортной работы.

Саму базу тоже неплохо бы положить на SSD, но не так критично, можно и на HDD.
Главное чтобы на том же HDD, кроме базы не было никаких активно используемых данных.
А то бывают случаи, что файловую базу размещают на том же диске, что и система, сам видел.

Зачем он там вообще? А если все-таки нужен, то его не отключать надо, а исключения настраивать.

1С УТ 8.3 одна из последних версий. Пользователей всего 4 человека.

Если количество пользователей в перспективе будет расти, то стоит рассматривать переход на SQL.

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

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

База и система на разных логических дисках, но на одном физическом.
Жуть! Админа стоит расстрелять для профилактики.

Jump

Суть в том что в рабочее время, когда работают реальные пользователи - все ресурсы должны тратиться на работу пользователей.
А в нерабочее время логичнее выполнять обслуживание БД и прочие регламентные задания.

Основная работа идет именно с кэшированными данными, поэтому AppData просто обязан размещаться на SSD для комфортной работы.

Кэшированные данные 1С критичны только во время старта её.
Потом скорость доступа в AppData - уже не важна.

Со всем согласен кроме выражения "файл логов удалять". В моей практике я удалял файл логов только в период перехода с файлового хранения на использование sqlite, когда чего-то там нахимичили и в одной из версий из-за логов начинали падать процессы rphost.

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

Jump

buzina_v_ogorode, Откройте монитор ресурсов и посмотрите какая нагрузка.
А нагрузка там огромная, обычный HDD не справляется даже с системой.
Поэтому что основная дисковая активность идет с кэшем, который размещен в профиле пользователя, на системном диске.

Диски, конечно, желательно получше.
Это всегда универсальный рецепт.
Где ни ляпни "нужно быстрее дисковую подсистему" - это же всегда будет правда?
[censored].

Jump

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

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

Jump

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

Только что проверял, при открытии журналов документов 1С лезет в AppData.

Если логи не нужны вообще - вы правы, их лучше отключить.

Логировние событий создает бешенную нагрузку, так что доступа к данным нет нормального?
;))))))


Откройте монитор ресурсов и посмотрите какая нагрузка.
А нагрузка там огромная, обычный HDD не справляется даже с системой.

Берешь RAMDiskNT или аналогичную утилиту по вкусу. Делаешь диск в оперативной памяти.

Перемещаешь туда БД 1С, журналы 1С. Разумеется только для теста, в боевом режиме нельзя использовать так.

Запускаешь. Ну, как ты думаешь, о Незнаюшка, - 1С будет летать, если вообще убрать проблему диска? Ведь оперативка-то побыстрее чем даже обычный SSD

Ответ не скажу. Сам проверь. Название утилиты я тебе сообщил.

Jump

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

А вот все изменения и сортировки данных, хранение промежуточных результатов осуществляются в кэше.
Там идет очень большая нагрузка на чтение и запись мелкими блоками. 1с оперирует в основном блоком в 8кб. HDD в этом случае банально не справляется.

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

Jump

Берешь RAMDiskNT или аналогичную утилиту по вкусу. Делаешь диск в оперативной памяти.
Перемещаешь туда БД 1С, журналы 1С. Разумеется только для теста, в боевом режиме нельзя использовать так.

Разумеется в этому случае система будет работать так же как и на обычном диске!
Потому что для работы с базой достаточно скорости работы обычного HDD

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


Только что проверял, при открытии журналов документов 1С лезет в AppData.

Конечно, там лежат настройки внешнего вида журнала.
Включение/отключение отображения колонок и пр.

Jump

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

По поводу дисков - у файловой 1с идет интенсивная работа с кэшем, и она будет быстро работать только в случае размещения этого самого кэша на SSD.
Кэш это все что размещается в папках -
\AppData\Local\1C\1cv8\xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
\AppData\Roaming\1C\1cv8\xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
где xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx это уникальный ID базы.

С самой БД работа идет крупными блоками, поэтому с ней справляется даже обычный HDD, разумеется при условии, что этот HDD не нагружен более ничем. Сама БД это файл 1Cv8.1CD

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


Что же делать и как это победить, и так по порядку:

Клиенты очень медленно работают с серверной версией 1С

Кроме медленной работы 1С, так же наблюдается медленная работа с сетевыми файлами. Проблема встречается при обычной работе и при RDP

netsh int tcp set global autotuning=disabled

netsh int tcp set global autotuninglevel=disabled

netsh int tcp set global rss=disabled chimney=disabled

и сеть работает без проблем

иногда оптимальным является:

netsh interface tcp set global autotuning= HighlyRestricted

вот как выглядит установка


Далее посмотрите настройки брандмауэра Windows

Настроить брандмауэр Антивируса или Windows

Как настроить брандмауэр Антивируса или Windows для работы сервера 1С (связка из Сервера 1С: Предприятие и MS SQL 2008, например).

Настройка производительности Сервера / Компьютера

Для того чтобы компьютер работал с максимальной производительностью - нужно настроить его на это:

1. Настройки BIOS

  • В BIOS сервера отключаем все настройки по экономии электропитания процессора.
  • Если есть «C1E» & обязательно ОТКЛЮЧАЕМ!!
  • Для некоторых не очень параллельных задач также рекомендуется выключить гипертрейдинг в биосе
  • В некоторых случаях (особенно для HP!) надо зайти в BIOS сервера, и ВЫКЛЮЧИТЬ там пункты, в названии которых есть EIST, Intel SpeedStep и C1E.
  • Взамен надо там же найти пункты, связанные с процессором, в названии которых есть Turbo Boost, и ВКЛЮЧИТЬ их.
  • Если в биосе есть общее указание режима энергосбережения & включить его в режим максимальной производительности (он ещё может называться «агрессивный»)


2. Настройки схемы в операционной системе - Высокая производительность


Сервера с архитектурой Intel Sandy Bridge умеют динамически менять частоты процессора.

Скачайте утилиту PowerSchemeEd.7z , распакуйте с помощь 7zip и запустите PowerSchemeEd.exe

Выберите раздел Управление питанием процессора и выставите параметры 01. Порог при питании от сети 30% и отключите 27. Переопределение ядра. как на картинке.


3. На серверах 1С и MS SQL Server использование антивирусов (даже сам факт инсталяции без включения) будет приводить к снижению производительности в виде периодических массовых замедлений и подвисаний интерфейса.

4. Совмещение ролей сервера 1С и сервера MS SQL Server дает большую производительность, особенно если использовать протокол обмена данных напрямую через память «Shared Memory».

Очень многие не недооценивают важность настройки сервера, когда роли сервера 1С и сервера СУБД совмещены на одном физическом компьютере.

Убедиться, что к примеру используется протокол Shared Memory можно следующим образом:


Обратите внимание, что в версиях платформы некоторые релизы «переключались» на протокол «именнованых каналов».

Для работы 1С Предприятие в режиме Shared Memory с SQL Server 2012 должен быть установлен NativeClient от SQL Server 2008 (backward compatibility connectivity components из дистрибутива SQL Server 2012 или отдельный пакет)

5. Отключение ненужных служб Виндовс

Одним из самых действенных способов ускорения компьютера является отключение неиспользуемых (ненужных) служб операционной системы. У ОС Windows по умолчанию включено огромное количество служб, на работу которых требуется большое количество ресурсов системы. Многие из них можно отключить без потери функциональности и снижения безопасности системы.

Какие службы можно отключить для оптимизации Windows:

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

Кэширование записей на дисках в Windows

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

Для управления кэшированием записей на диске откройте Панель управления - Диспетчер устройств.

В разделе Дисковые устройства дважды щелкните нужный диск.

Читайте также: