Setitle, для 100 пользователей покупать внешнюю полку это должна быть веская причина и ей точно не может быть база данных 1С
мне вообще не понятно зачем брать СХД ради СХД - у вас что в сервере места нет?
сервер мне кажется лучше будет Intel R1304WFTYSR
а в качестве диска под базу 1.6Tb Samsung PM1725b (MZWLL1T6HAJQ), можно посмотреть PM1735
под бэкапы можете взять mx500 2tb
970 или 980 вы скорее всего не воткнете, но даже если будет разъем, то скорее как диск под ОС юзайте
NNS, вы если будете делать по своему, то снова херня получится
pci разъемы есть в любой материнке, не делайте мозг
другое дело если у вас одноюнитовый корпус, то может так оказаться, что вставлять надо под углом 90 градусов через райзер карту
S3500 мало чем отличаются от EVO, такие же убогие диски
sata покупать не надо, надо что я говорю
возьмите какую то другую модель, в особенности sata/sas и результат я не гарантирую
а пока суть до дело, уберите старый регламент по индексам, запустите отдельно скрипт, замерьте его время, если выполнится за пару часов, то заносите в расписание
NNS, что и требовалось доказать
в нормальный сервер вы воткнули диски от домашнего компа, при интенсивной записи скорость естественно западает
самый просто вопрос - денежный, лучше всего воткнуть intel p4610 1.6 tb
но раз вы хотите бесплатно, тогда вам нужно отказаться от слепого перестроения всех индексов подряд без разбору - это ненужная работа
перестраивать нужно только те индексы которые сильно дефрагментировались
поищите скрипты типа https://gist.github.com/KotegBegemoteg/d224be2683b...
только я советую сделать более строгий порог : всё что меньше 30% дефрагментировано вообще не трогать, также не трогать таблицы где меньше 10000 строк, а полноценный ребилд делать только для индексов за 60%
после этого думаю проблем с временем не останется
NNS, по поводу теста - собственно результат теперь показывает более менее достоверный- 421 на запись может быть как раз либо ухудшением из-за рейд 1, либо некоторой степенью остатка места на диске (trim скорее всего шедулером делается самой ОС)
но благодаря тому что вы подключили диск через контроллер с кэшем, то замаскировали следующую проблему: диски Samasung EVO при длительной записи (например ребилде индексов в базе) могут значительно проседать в момент пробития их кэша.
Серия PRO дороже серии EVO в некоторых ситуациях до двухкратной разницы в силу преимущества двухкратно больше перезаписываемого объема. Серия EVO использует технологию TurboWrite. Серия PRO это технологию не использует.
У серии EVO когда "кэш" TruboWrite забивается под завязку, то скорость записи резко падает и значительно медленее чем у PRO. У серии PRO такого падения не происходит.
Для домашних пользователей серия EVO предпочтительней, так как тяжело в одиночку пробить кэш. Для баз данных субд где устойчивая постоянная запись наиболее критичный фактор серия PRO даст однозначно преимущество при наличии таких вещей как перепроведении документов за месяц в базе данных.
Мы лично pro диски используем под базы с небольшим количеством пользователей, а диски evo отлично подходят для бэкапов.
В вашем случае из-за контроллера со своим кэшем ситуация будет происходить когда сначала кэш контроллра будет пробит, а потом кэш диска. Ловить такое тяжело, но эта одна из гипотез почему регламенты то быстро то медленно идут.
Ждем что покажет Ваш хронометраж.
NNS, вы что не знаете какой размер кэша у контроллера? ну сделайте тест на 4000 Mb . Если размер кэша меньше, то тест выдаст более достоверный результат. Вряд ли у файлы баз меньше чем кэш контроллера.
"Я продолжаю лупить все базы потому что не умею писать скрипты" При чем тут скрипты. Вы что не можете воспользоваться мастером регламентных заданий несколько раз? Пишите для каждой базы персональное задание. Не надо ставить "все базы".
включите для всех ваших баз асинхронное обновление статистики
ALTER DATABASE YourDatabaseName SET AUTO_UPDATE_STATISTICS_ASYNC ON
GO
YourDatabaseName - имя конкретной базы
Сделайте хронометраж, смотрите куда уходит время больше всего. Проверку целостности баз уберите из ежедневного регламента.
NNS, ваши показания на счет дисков не очень бьются с тестом
у диска заявлено 500 мб/с на чтение а у вас 950? рейд 1 не ускоряет, а немного замедляет диски )
далее, я же несколько раз написал про параллельные расписания, нет вы продолжаете лупить "все базы"
у вас там небось и копии баз есть, и прочий мусор и он зря статистикой обсчитывается
далее, пока по хронометражу, если у вас только одна база обсчитывается 20 минут, а остальные выполняются быстро, то чисто математически не набегает 8 ночных часов
у меня складывается ощущение что вы доносите информацию с искажениями
про проверку целостности - отдельная песня, нахрена ее так часто делать, делайте раз в месяц отдельным расписанием вообще
также в регламент на ночь есть смысл добавить скрипт maxdop=4, а с утра ставить maxdop=1
NNS, ну вы половину ответа на свой вопрос уже знаете - вам нужно разрулить обсчет статистики в базах
первое что бросается в глаза - это нетипичное имя приложения - вы как вызываете этот самый регламент?
второе - обычно при обсчете статистики присутствуют ожидания CXPacket, у вас maxop=1?
третье - как у вас настроен регламент, вы полностью во всех баз обсчитываете все таблицы подряд с полным сканированием что ли?
включите для всех ваших баз асинхронное обновление статистики
ALTER DATABASE YourDatabaseName SET AUTO_UPDATE_STATISTICS_ASYNC ON
GO
также для вашей базе вручную выполните exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'
он должен пролетать для небольших баз очень быстро
напишите за сколько выполнился у вас
если он выполняется десятками минут, то надо выполнить тест дисков
ставлю пиво что вы "раскурчили" диски и они на запись выдают СУЩЕСТВЕННО меньше чем заявлено у вендора, скачайте www.gilev.ru/wp-content/uploads/2017/01/CrystalDis... и сделайте скриншот с результатов теста, в нормальном состоянии по линейной записи диск пишет 500 МБ/c . У Вас и 250 не выдает, я прав?
NNS, у вас на скриншотах нет задач, выполняющихся больше 10 минут
если брать среднеарифметическое, то чтобы уложиться за 8 ночных часов регламенты одной базы должны выполняться порядка 20 минут
не рассматривайте выполнение регламентов в куче, а проанализируйте каждый в отдельности
если у вас нормальные NVMe диска типа intel p4600, то все регламенты должны проходить за час
если у вас старые SAS/SATA диски, то регламенты по обсчету статистики могут идти долго
особенно потому что когда происходит расспараллеливание запросов к дискам, на них начинаются очереди и вместо ускорения получается ухудшение, визуально его можно наблюдать в мониторе производительности диспетчера задач по долгим откликам дисков, если посмотреть на типы ожиданий скуля, то отчасти подтверждается суммарными весами
т.е. вам не просто надо создать параллельные задания на обслуживания, но и один раз вживую пронаблюдать отклик системы в момент выполнения таких заданий, не топят ли диски ваши регламенты
планы обслуживания должны быть параллельные, а не один общий, и количество одновременных планов надо подбирать вручную следя за поведением железа
Вопрос то какой? Почему создали последовательный план действий и он выполняется последовательно? Ну так вы сказали ему так работать.
1С действительно не при чем. Любая хорошая операция должна потреблять как можно меньше ресурсов, а не больше. Если задача положить сервер - сделайте для каждой базы данных отдельный экземпляр скуля, там сделайте свой регламент, при чем чтобы по времени эти регламенты стартовали одновременно. Дурное дело не хитрое.
И да, 1С вполне многопоточна. Разные сеансы работают на разных ядрах. А если руки растут откуда надо то можно и фоновики запрограммировать, а асинхронные вызовы.
Вам не абстрагироваться надо, а четко формулировать решаемую задачу. И не выдуманную, а с практической пользой.
NNS, ещё раз внимательно прочтите исходный пост
чем больше занято ресурсов, тем меньше шансов у системы будет сразу начать выполнять новую операцию - чем выше загруженность, т.е. занятость, тем выше вероятность попасть в очередь на ожидания этих самых ресурсов
скорость одного конкретного потока - операции будет определять способность оборудования выполнять количество микроопераций в единицу времени
для процессора таковым является частота процессора, чем выше частота, тем больше микроопераций способен выполнить процессор
если какая то конкретная операция утилизирует ВСЕ ресурсы, то это очень плохая операция хотя бы потому что вторую такую вы одновременно с первой уже запустить не сможете
линуксовые и штраф дают сильный, и они полноценно настраиваются только через командную строку, там нужно править схему электропитания обязательно
KVM в паре с CentOS можно настроить лучше других по скорости, но это всё равно скорее всего будет хуже VMWare - последние явно глубже разобрались в причинах замедлений и предоставляют больше возможностей для тюнинга
также не малозначимым фактором имеет распознавание железа и наличия качественных драйверов
на разном оборудовании виртуализация может вести себя по разному
например долгое время Турбобуст 3 в линуксе не поддерживался для интеловых процессоров, или не полноценно распознавались свежие NVMe диски
мне вообще не понятно зачем брать СХД ради СХД - у вас что в сервере места нет?
сервер мне кажется лучше будет Intel R1304WFTYSR
а в качестве диска под базу 1.6Tb Samsung PM1725b (MZWLL1T6HAJQ), можно посмотреть PM1735
под бэкапы можете взять mx500 2tb
970 или 980 вы скорее всего не воткнете, но даже если будет разъем, то скорее как диск под ОС юзайте
про диски вам надо знать
www.gilev.ru/dwpdssd
www.gilev.ru/nvmeraid