Почему долго грузится и подтормаживает 1С?

Question

[Евгений]

Есть сервер 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 и переносить туда систему или Базу?

Answer 1

[АртемЪ]

Почему долго грузится и подтормаживает 1С?

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

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

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

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

Антивирус отключил, помогло не сильно.

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

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

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

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

файл логов 0,5Гига

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

База и система на разных логических дисках, но на одном физическом.

Жуть! Админа стоит расстрелять для профилактики.

Comments

[Евгений]

prntscr.com/gq7b1m
А если в списке заданий назначить пользователя, то это только при входе под ним оно будет выполняться?

[АртемЪ]

Евгений, Да.

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

[buzina_v_ogorode]

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

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

[Дмитрий Кинаш]

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

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

[АртемЪ]

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

[buzina_v_ogorode]

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

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

[АртемЪ]

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

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

[АртемЪ]

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

[Евгений]

buzina_v_ogorode,

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

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

[buzina_v_ogorode]

АртемЪ,

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

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

[buzina_v_ogorode]

АртемЪ,

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

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

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

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

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

[АртемЪ]

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

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

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

[АртемЪ]

buzina_v_ogorode,

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

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

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

[buzina_v_ogorode]

Евгений,

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

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

[АртемЪ]

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 с такой нагрузкой не справляется.

Как где все таки затык?
В дисках или в процессоре?

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

Answer 2

[buzina_v_ogorode]

1С очень требовательна к частоте процессора.
Оперативки можно было и поменьше взять. И ядер процессора - поменьше.
А вот частоту процессора - максимум, что можно за эти деньги.

Answer 3

[Константин]

для пользователей установите блокировку регламнтных заданий
/AllowExecuteScheduledJobs –Off /SchJobDn Y
гляньте как будет)

Answer 4

[Антон Антон]

выключите DFSS. Если аппаратный рэйд с батарейкой и включенным кэшем на запись, то ssd не поможет.

Comments

[sim3x]

Укажите в ответе, какие минусы у аппаратного рейда

Спасибо

[АртемЪ]

Антон Антон:

выключите DFSS

Реально полезный совет. Хотя DFSS вроде в 2012 сервере появился.
А вот с рэйдом непонятно, можно поподробнее?

[Антон Антон]

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

[sim3x]

Антон Антон,
Что произойдет при поломке железки рейда через 10 лет?

[Антон Антон]

sim3x, я хз. Достаются диски, ставятся в аналогичный контроллер и продолжается работа. У меня есть еще работающие с 2007 года контроллеры. Но есть у меня подозрение, что не раз к тому моменту сервер будет проапгрейжен. Или вы думаете, что ссд не подвержены поломкам? В 2012 году проводили эксперимент по переводу файловых баз на ССД. По гарантии за пару лет раз пять поменяли диски. Сейчас, конечно, все лучше, но на 10 лет работы под нагрузкой я бы не рассчитывал.

[АртемЪ]

Антон Антон:

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

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

[sim3x]

Антон Антон, ок
А как достать аналогичный контроллер, когда его уже как Х лет никто не выпускает, фирма продана, а даташиты и схемы никто не выложил?

Answer 5

[effko32]

систему оставьте на обычном hdd, базу перенесите на ссд.