День добрый.
Вопрос я думаю уже платиновый, но вразумительного ответа так и не нашел.
Есть сервер. Старенький, но живой. На борту Xeon E1230, 16гб оперативки DDR3 с ECC. Мать интел, на ней есть софт рейд. Собственно еще давно сделал там 1 диск не в рейде под операционку и софт, 2 диска в зеркале под базы, 1 диск под обменник. Диски в рейде свежие WD Blue Sata 3, висят на 2х единственных 6гб портах. Диски же под хлам и систему Sata 2.
Изначально баз было штук 40, фирма оказывает консалтинговые услуги. Все базы были файловыми. В принципе пока была версия 8.2, все было суперотлично, потом с переходом на 8.3 все становилось хуже с каждым обновлением. И вот момент настал, в районе марта прошлого года, после обновлений базы стали открываться по 5 минут. Не помогало уже ничего, ни очистка кэша, ни пересчет индексов. И да, сами диски дефрагментируются по расписанию, так что это тоже не причина. Проверял скорость винтов - все гуд, в пределах нормы.
Собственно погрузившись в темные закоулки гугла, стало понятно что пришло время переходить на SQL. Прикупили MSSQL Server 12й и x64 сервер 1с. Настроил по гайдам sql и кластер, конвертировал базы, сама база на рейде, логи на диске с хламом. Отдал под sql 6гб оперативки, 9 под 1с, и гиг оставил ос. Регламентированные задачи настроил тоже.
После этих операций базы стали открываться буквально за минуту-полторы, никаких проблем.
Проблема же появилась буквально в октябре, после очередного обновления. Базы стали открываться все медленнее. Перерыл гугл, даже примерно не нашел ответа. В декабре же опять после обновления началась дичь. Во первых сервер сам начал работать натужнее, просто все даже открывается медленнее. В журнале sql сервера кучи ошибок выполнения регламентированных задач, при чем в тексте ошибки просто написано что вот на той базе споткнулся, просто потому-что. Периодически базы падают в режим восстановления и висят так по 5-10 минут. Ну и у пользователей соответственно вываливается что база не обнаружена, ошибка шаред мемори на натив клиенте sql, при этом нажав 3-4 раза повторить, все открывается, и работает без нареканий.
За праздники отрезервировал базы отдельно, в новый архив акрониса, дабы не путался с боевым. Попробовал пересоздать/переподключить базы, эффекта не дало. Но заметил такую вещь, когда кластер 1с отключен, все базы резко перестают уходить в восстановление, и работают весьма штатно, сервер вновь шустро бегает. Запускаю службу обратно, и все опять укатывается в болото.
У меня всего 3 варианта:
1. Обычные винты не вытягивают нагрузку.
2. Мало оперативной памяти.
3. Ошибки в конфигурации сервера.

Нужны ваши советы мудрые.

Открывается минуту-полторы - это капец как медленно. Здесь, вероятнее всего, время уходит на поиск ключа защиты броадкастом. Ключи защиты какие? Сколько их?

"Периодически базы падают в режим восстановления" - 1С тут ни при чем.

Нет самого важного - результатов хоть каких-нибудь замеров. У тебя поди все твои 16 гигов забиты под заявязку и процессор занят на 100%, потому и тупит всё.

постоянный переход баз в рекавери - это беда. Надо выяснять, почему это происходит. Но дело не в 1С.

(0) WD Blue - выкинуть и никогда не использовать. Или Black или Enterprise.

>> Проблема же появилась буквально в октябре, после очередного обновления. Базы стали открываться все медленнее

Мне показалось, что единственный способ оценить производительность - замерить скорость открытия интерфейса ПО. Этого недостаточно. Сейчас есть разные способы измерить и протестировать состояние дисков, скорость операций чтения и записи, шустрость оперативки и сети, "настроенность" СУБД, общую (не применительно к конкретным БД) производительность ПАК 1С, состояние тех или иных конкретных баз - апдекс и время, затрачивамое на регламентные операции.

Вот когда все это замеряно и сохранено, а потом после каких-то изменений снова замеряно и сравнено - вот тогда уже можно делать выводы

(1) опередил

(4) правильный способ оценивать производительность - эти perfmon.exe и 1совский замер производительности.
Все остальное - пальцем в небо

(6) категорически не согласен.. и что понимается под "1совский замер"?
но даже если бы так - ТС'у не только с производительностью разбираться надо, например: "В журнале sql сервера кучи ошибок выполнения регламентированных задач"

С каких пор работа с CPU-z и SMART - это пальцем в небо?

(7) CPU-z и SMART - это не инструменты для замера производительности. Это инструменты для диагностики причин падения этой производительности ПОСЛЕ того, как доказано, что производительность падает по вине CPU или HDD.

1совский замер - это 1совский замер
https://i.imgur.com/3Yfmcmy.png

(0) ...фирма оказывает консалтинговые услуги - бухобслуживание ? пользователей 3-5 ?

поставь пару SSD и вернись к файловым базам

(8) >>ПОСЛЕ того, как доказано, что производительность падает по вине CPU или HDD
т.е. (a) сначала выносим вердикт и доказываем, что некий код выполняется долго из-за нестабильной итоговой частоты процессора,
а потом уже (b) лезем в cpu-z для "диагностики причин" этого.

ок. :) интересно узнать. как на этапе (a) определишь, что "виновен" процессор и "докажешь" это без инструментов "контроля максимальной частоты процессора" (цитирую Гилева), т.е. без cpu-z и ему подобных?

(10) Очень просто. Погугли "Xeon E1230". Год выпуска. Сравни с текущим.

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

(10) почитай что-нить про perfmon и анализ производительности виндового сервера

(11) не, ну это частный случай мы же говорим об общем алгоритме

(13) Ок. Общий алгоритм: Железу >5 лет -> на свалку.

(1)

Ключ на сервер был просто пин. На клиентах тоже софтовый, на каждой машине свой.

>"Периодически базы падают в режим восстановления" - 1С тут ни при чем.
Но при выключенной службе 1с, режим восстановления не появляется, как и ошибки в регламентированных, все отрабатывается на ура.

>Нет самого важного - результатов хоть каких-нибудь замеров. У тебя поди все твои 16 гигов забиты под заявязку и процессор занят на 100%, потому и тупит всё.
Процессор занят на 20-50% скачками. Но это не показатель что он не используется полностью. Оператива почти всегда гига 4 свободно, пока не открыто баз 5-6 за раз.

(2) Я грешу на винт с логами. Хотя опять таки, смарт в норме, виктория не выявила криминала за 3 прохода, скорость в норме. И плюс, они перестают падать без 1с.

(3) Что есть. Выбирать не приходится.

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

(14) Весьма 1сный подход.

(14) Иначе (?)

(12) о чем нам спорить? по-моему, речь об дном и том же, только разными средствами. Я не фанат cpu-z. Можно тоже самое посмотреть в системном мониторе

Кстати ошибка. Xeon E1230v3

(15) попробуй у всех баз выключить регламентные задания

(17) Ок. >5 лет && Тормозит? На свалку!

(18) это даст я думаю весьма временный прирост. Со временем, без регламентированных задач, база м станет немного совсем худо.

(0) Подскажи случаем не терминальный сервер?
Вместо тонких/веб клиентов.

(21) не, вся бизнес логика на стороне клиента.

и никакой виртуализации
как и rdp

Попробуй воткнуть 1 шустрый SSD. Под систему.

(24) Нет ssd, и не будет. Денег нет. Я уже писал это выше.

(25) Эээ. Нет 5 т.р.? А зарплату хоть платят?

(26) Смотрим ссд за 5к в локалсторе. Это OCZ на 240гб. Перенос на ssd только системы - так себе прирост, нужно еще бы и базы туда залить. Смотрим сколько занимают базы с логами - около 180гб, смотрим сколько система с софтом - 50гб. Итого - 10гб остается. Смотрим процент вымирания дисков OCZ - примерно каждый 50й. Как-бы не очень картина, нужно их в зеркало хотя-бы собрать. Итого 10к. Если учесть что фирма далеко не богата, и в прошлом году сократились с 7 сотрудников до 5, и переехали в более дешевый офис, эти 10к мне никто не даст.
Не все живут в Москве. В регионах и 10к деньги, особенно если учесть что сотрудники там максимум 25к получают+премия по выработке там 5-7к.

(27) Оставь базы в покое на HDD. Ты систему ограничил 1 гиг рам. Оно свопит.

Оперативки мало

можно отключить рег. задания

(27) Поэтому ты без штанов?

(27) Вот здесь твоему безштанному коллеге уже рассказали, что с таким бизнесом делать:
https://forum.infostart.ru/forum86/topic184307/

(0) Софтверный рейд. Дальше можно не продолжать.

(29) отдал под 1с 7гб, а под sql 6гб оперативы, загрузка процессора взлетела до 100%

Платформа то хоть какая? Обновлял.

В какой-то летне-осенней 8.3.10 были дикие тормоза при скуле

(0) >>Проверял скорость винтов - все гуд, в пределах нормы.
Цифры какие по mdf и ldf?

>> 16гб
Зачем при таком объеме ОП ты перевел их в клиент-сервер? Нет денег на апгрейд, тебе какая разница, что будет дальше? Ключевая ошибка в таком паттерне поведения как у тебя, искать в таком унылом не сервере, но компьютере для игры в тетрис, какие-то проблемы с чем? с производительностью - это значит, что контора буквально оплачивает в воздух каждый час твоей работы. Весь этот сервер целиком нужно загнать на авито, выручить какие-то деньги, докупить обычный компьютер на i3 последнего поколения и ВСЕ БУДЕТ БЫСТРЕЕ. Если у них на это нет денег, ты тут причем? Работайте с тем, что есть. В конце концов, все скорее всего навернется, раз ты даже лог уже прочитать не в состоянии и понять, конкретно какая там краснота. Навернутся базы - дальше будет так: контора либо начинает восстанавливать учет, но это для них не реально, либо платят за восстановление, не факт что возможно. Им это нужно рассказать, а не делать ИБД, как ты. С 16 гигами ОП и при этом спрашивать - мудрые советы. Не зависимо не от чего, тут мудрых советов не будет.

Скока очередь к винтам в мониторе ресурсов?

(36) дык видимо по его советам нашли денег на скуль и серверную винду

ну а после... деньги кончились

(0) Посмотри на досуге, может натолкнет на какие-то мысли
https://youtu.be/oljKKUJwAUw

(38) возникают сомнения,что купили, потому что тот ms sql что там описан плюс серверные лицензии 1с выйдут в астрономическую сумму и контора, которая смогла бы себе это позволить, 10 тыщ на ssd точно бы нашла. Поди проблема, что глючат там все кряки ломалки у топикстартера. Но это так, предположение.

(40) А ты видел чтобы кряки-ломалки "глючили" и в чем это проявлялось?

(15)>Но при выключенной службе 1с
"после" - не значит "в следствие".
При остановленном rphost'е базы не используются и по этому их состояние и не меняется в консоли скуля. Они в рекавери падают не потому, что их 1С использует, а потому, что их вообще просто кто-то использует.

(41) я в них не разбираюсь, но поедполагаю всякие отваливания ключей и что-то такое.

(41) безблагодатная тема

(0) За пару тыщ рубликов куплю твой хлам, мне как раз нужен сервак под эксперименты. Могу тебе взамен отдать пару-тройку компов на 415-465 чипах, на них люди работают и не жалуются. Первым делом снесу ОС и все разделы ЖД напрочь, а потом буду учить его работать как надо.

(41) Я видел. На последней платформе 8.3.10. Проявлялись что файловые базы через минуту работы вываливалась с ошибкой в структуре (серверная работала без проблема)
Лечилась заменой кряка или установкой ключа. При этом физически с базой ничего не происходило

(34) > отдал под 1с 7гб, а под sql 6гб оперативы, загрузка процессора взлетела до 100%
Загрузка чем? Просто загрузка это сферический конь в вакууме.

Попробуй указать серверу количество ИБ на процесс 1, а соединений побольше. На более тухлом по процессору сервере это помогло, правда все на ssd, хотя и сата2.

(0) люто на такой машине 40баз на 180Г гонять...
А юзеров то сколько?
Зеркало для производительности никаким местом.
> отдал под 1с 7гб, а под sql 6гб оперативы, загрузка процессора взлетела до 100%

6Г для 180Г баз? Да вы издеваетесь!!!
Разумеется будет диск постоянно дёргать и проц уходит в топ.

Из говна не сделать конфетки как ни крути. На вашем-бы месте я:
1.Переустановил ос и весь софт на сервере.
2.Файлопойку в другое место.
3.Добавил рамы хотябы ещё 16Г.
4.Схема электропитания = высокопроизводительная.
5.Раз денег мало один винт(побольше) под ос и базы, второй(поменьше) под журналы, третий (самый дешманский ссд) под темпы.
6.Антивирусы, брэндмауэры и прочее лесом.
7.настроить shared memory.

8.начал бы искать работу.

В общем и целом, я решил проблему.
Первым шагом - грохнул кеш сервера 1с. Базы стали открываться без задержки, но все равно с сообщением о том что база не обнаружена.
Вторым шагом - отключил все базы в sql, грохнул логи, подключил обратно. Все по одной. Сообщение о не существовании базы исчезли.
Но так-то это не решение, а чистой воды везение. Первым делом нужно разжиться ссд, а дальше уже по обстоятельствам.

(50) оперативой еще разживитесь. Максимально возможным объемом