Всем привет.
Коллеги, имеется база ERP 380гб
Насколько понимаю, что типовые описанные планы обслуживания (рекомендации) в интернете больше склонны к базам небольших объемов данных...ну или ошибаюсь...
Поэтому, поделитесь пожалуйста проверенными планами обслуживания баз 1С больших объемов (в виде ссылки на статью (проверенные вами), свои личные настройки мб по месту работы и т.п.)?
Сколько времени у вас занимают ваши планы обслуживания? (речь о базах 350гб+)
У нас например обновление статистики выполняется 1,5 часа...
Большая просьба не рассказывать, что 350 гб это еще не много и т.п.)
поделитесь пожалуйста проверенными планами обслуживания баз 1С больших объемов
Все сводится к периодичности, а рецепт всегда олинаковый:
1. Обновление статистики. Чем больше данных добавляется, тем чаще ее надо обновлять. Раз в час, например. Можно только по тем таблицам, куда активно инсёртят. Выполняется достаточно быстро, особенно если не по всем таблицам.
2. Реиндексация. Просто приводит индекс в порядок. Выполняется тоже не сильно долго. Раз в сутки.
3. Перестроение индекса. Приводит в порядок сами данные. Эта операция уже достаточно длительна. Раз в неделю в выхи, когда на сервере минимум активности.
4. Ну и стандартные бэкапы и шринки лога.
На сколько я знаю, ничего нового за последние 30 лет в этом плане не придумали.
Ну и стандартное:
1. Максимальная производительность в схеме управления питанием.
2. К черту виртуалки! Они жрут 10-55%, а иногда у особо умных товарищей с ограничением ресурсов могут иметь замедление в 100500% (цифра реально близка, т.к. встречал ситуацию, когда скорость при открытии документа с НДФЛ на 10к челов замедлялась с 10 секунд до 30 часов, и да, я не ждал 30 часов - я просто экстраполировал по замеру производительности).
3. 4-8 файлов темпдб (от ядер проца).
4. Разделение файлов лога, базы и темпдб по отдельным физическим носителям.
5. Остальное - баловство, ну кроме рефакторинга кода запросов и кода вообще.
6. Рефакторинг кода запросов и кода вообще.
при правильной настройке особо ничем от физического отличаться не будет
Будет. В среднем тесты на гикбенче говорят, что все, что на виртуалках (при чем независимо от того, что это за виртуалки), работает примерно в 2 раза медленнее.
И кажется, что вот с фига-ли, ибо же аппаратная виртуализация и все такое бла-бла-бла... А у современных процессоров частотная лесенка туды-сюды, кеш там-сям, ожидание доступа к банкам памяти и DMA-каналам тут и там, в итоге даже аппаратная виртуализация на задачах случайного большого кода, занимающего много памяти, которая не влезает в кеш команд, резко начинает двигать производительность во-первых в сторону стоковых частот, а, во-вторых, в сторону того, что в процессоре вдруг стало половина кеша, ибо часть кеша юзается на код обслуживания виртуальной инфраструктуры.
Но, как бы, все нужно не на словах, конечно, говорить, а на практических кейсах. И они показывают, что есть много узких мест виртуализации, поэтому она хороша при нарезании на микросервисы небольших приложений, но очень плохо работает с монолитом, требующим очень большой скорости обработки в потоке. 1С - это тот самый монолит. А микросервисы ща народ научился в докер оборачивать, который теряет сильно меньше.
(7) Да, согласен, на виртуализацию затрачиваются некоторые ресурсы. Но говоря об отличии виртуального и физического сервера я по большей части имел в виду то, что пользователи той же 1С не заметят разницы если у сервера достаточно ресурсов чтобы обслуживать например, 3 сервера виртуальных 1С (допустим до 100 пользователей). Выделять всю железку на один сервер, который будет использовать только 30% ресурсов этого сервера думаю расточительно.
Если же мы имеем, допустим, высоконагруженный сервер 1С с 1000 пользователями которому необходимо все 100% ресурсов, то тогда конечно нет смысла резать его на виртуалки, выделить полностью под одну задачу, возможно даже потребуется несколько серверов физических с объединением в кластер.
Поэтому тут вопрос решается исходя из задачи. Где-то есть в них смысл и даже необходимость, где-то нет.
Иначе не было бы AWS, Azure, GC. Да и популярного 1С-Fresh тоже )
(8) 10 пользователей файловой базы заметили. Тест Гилева показал 2х кратное падение индекса. Админу показали - он убрал виртуалку, хотя мы и не требовали, только попросили настроить, что бы было как на физическом сервере.
Информационные базы прикладных решений — разворачиваются в кластере серверов 1С:Предприятия и публикуются на веб-сервере. Это главный прикладной компонент подсистемы Фреш, с которым непосредственно работают пользователи.
(12) Там может быть виртуалка, а может и не быть. На ней можно и веб-сервер развернуть, и вообще в докер упаковать. Просто заплатишь штраф за виртуализацию - и все.
(5) День добрый. А скрипт не подскажете, как отловить активно изменяемые таблицы, чтобы статистику по ним обновить? Как по отдельно взятой таблице обновить знаю, а вот отловить нужные таблицы - это уже вопрос.
Фишка в том, что рам-диск не всегда быстрее того же NVME. Причина проста - кеш. Юзая рам-диск, ты отказываешься от кеша. Но есть секрет: можно всю инфраструктуру работы с рам-диском поручить ядру, на котором не выполняется 1С и SQL. Но и тут ограничения в 2 канала памяти, если это не сервак или сервак с двумя планками памяти из 16-ти (да, любят у нас такое). А есть еще интерлив - когда память с двух планок распределяется чередуясь друг с другом. В общем все упрется в пропускную способность памяти, т.к. если писать на диск, то ты копируешь буфер на диск, дальше диск сам, а если в память, то ты копируешь буфер в другой буфер, в итоге упираешься в скорость копирования памяти (условные 30ГиБ/с на хорошем компе). При этом все приложухи, которым нужна память, упираются в эти 30 ГиБ/с, а это 1С+SQL+RAM-DISK+OS+... И уже вроде не так все и хорошо. Вот если каналов памяти много и пропускная способность памяти действительно офигенная (200 GiB/s), то смысл действительно появляется. Ну или рам-диск на видеокарте делать - там пропускная способность у меня до 499GiB/s. Правда PCI-E даже 4.0 и даже х16 - это всего лишь 32 гига/с, т.е. медленнее, чем память, но быстрее, чем NVME.
(4)
Чем больше база, тем меньше желание ее дергать. Тем более не всегда есть окна для этого. Query Store хотя бы позволяет выбирать оптимальный план запроса в тяжелых случаях.
Из дополнительного, есть маленький, но полезный утиль https://github.com/sergiisyrovatchenko/SQLIndexManager Может понравится больше чем штатные средства.
Скрипт из статьи применяю на 400 ГБ базе, и на куче мелких до 100 ГБ, если базы на ссд, то до 2ч отрабатывает, если на обычных дисках (рейд, естественно) то до 4-5 часов занимает регламент. https://infostart.ru/public/256292/