Здравствуйте, хотелось бы узнать мнение профессионального сообщества по такому вопросу.

Есть организация, у нее есть 1с ERP 2.4. Также у нее есть 2 тестовых базы. Крутятся они на сервере бд на MSSQL с ЦП Процессор Intel® Xeon® E5-2630 v2, 15 МБ кэш-памяти, тактовая частота 2,60 ГГц и с 16 Гб оперативки на борту.

нагрузка в обоих базах - 2-4 сессии(челвоека) чето там тестируют, фоновые и регл отключены

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

И, главное, так убедительно говорят, гады, что я уже начал сам сомневаться - может реально чето подкрутить надо где-то. Вот мне интересно, чисто теоретически, может такой сервак сносно крутить 2 erp тестовых с минимальным присутствием человеков, тыкающих на кнопки, проводящих документы и тп?

Приведенные исходные данные позволяют построить спектр возможных практических ситуаций от нуля до бесконечности.
Так что "чисто теоретически" - конечно может.

А "сносно" - это сколько примерно от "хоть святых выноси"? Половина? Одна десятая?

Админы, разумеется, не предоставили никаких значений счётчиков... Ну, просто чтбы слова свои доказать?
А ещё в виртуалку сервер, небось, запихнули...
Да и памяти на две ерп мало

16 Гб оперативки...
вот тут пример под боком: 320 Гб оперативки и размер базы 100 Гб (данные + лог), постоянно занято около 100 Гб оперативы, при некоторых операциях память жралась до 250..
так что пишите сюда размер базы, а у себя смотрите очередь диска как минимум

(4) Первый здравый совет (посмотреть на очередь к диску)

>>сервак отличный для этих задач
а в чём собственно проблема у вас? Может вы 1 печатную форму рисуете в неделю, так какая разница бизнесу какая будет скорость вашей работы?

Спасибо за отклики, щас добавлю все, что знаю))
2 базы размером 170 Гб + 20 Гб логов
Из счетчиком знаю только значение теста Чистова - 1,5 единицы)))

Насчет других счетчиков - не шарю я, чтобы спросить у них, очередь диска сейчас попробую нагуглить что это и посмотреть, спасибо)

(6) проблема у нас в том, что мы внедряем производство своими силами и специалисты, которые моделируют тестовые ситуации на базах и сверяют проводки жалуются, что документы проводят по 20 минут

(8) Озвучьте это руководству, озвучьте ставку программиста, количество программистов и купите новый сервер.

(8) системный монитор на сервере глядеть, это если админы доступ к нему разрешат, а если нет, то проблема производительности- их проблема :)

(7) 1.5 единицы - значит с записью у вас беда. Скорее всего в диски упирается. Т.е. нужно смотреть нагрузку на диск в купе с настройками сиквела.

(8) у меня сервак для тестирования с 100гб на борту

170ГБ базы на 16ГБ памяти???
Мммм Как вам сказать, не матерясь... А никак. Поэтому промолчу ))

Я не профессионал в этом деле, но все равно вставлю свои 5 копеек. Xeon v2 это же Ivy Bridge? Если так, то лучше его заменить его на что-то поновее для ERP 2.4 и с частотой ядра побольше. Смотрите в сторону Casade Lake или Coffe Lake или новее. Количетво ядер выберите сами исходя из количества пользователей. Второй момент, попросите администраторов предоставить вам счетчики производительности за последнюю неделю, полюбому можно будет обнаружить узкие места, типа диска. Две базы по 170ГБ? Пускай даже активно работают только 3 человека, это катастрофически мало, начните хотя бы с 64ГБ, а лучше 128

(13) А чего тут не так? Вы из секты "база должна полностью помещаться в ОЗУ"?

"Две базы по 170ГБ? Пускай даже активно работают только 3 человека, это катастрофически мало, начните хотя бы с 64ГБ, а лучше 128" Это я про 16ГБ, не дописал

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

В общем, запустил я монитор системный на серваке, понадобавлял параметров, у меня получилось:
% загруженности процессора - колеблется от 0 до 20,
Скорость записи на диск - от 0 до 90,
Среднее время обращения к диску - от 30 до 100,
Средняя длина очереди к диску - почти всегда 100,
Средняя длина очереди записи на диск - почти всегда 100 изредка падает до 30.


https://ibb.co/4RYqnvR


Надеюсь, что я правильно вас понял))
я не очень разбираюсь в системных этих делах, но почитав интернеты, понимаю, что это не очень хорошие показатели, особенно по дискам.

(15) Я из этой секты. В (17) все верно сказано, нужно найти узкое место. Но опыт, есть опыт: Не верю, что 160г база будет работать на 16ОЗУ даже в тестовом режиме. Разуемеется это касается 1С. Какая-нибудь мегаоптимизированая и узкоспециализированная база может.

(17) Я написал про счетчики производительности

блин, на скрине цвета не очень отличаются((
Но мне главное понять, что это нужный инструмент, а там я с гуглом разберусь о нужных показателях

(19) Это только для жесткого ОЛАПа разве что имеет смысл. В реальной рабочей базе доступ производится к нескольким гигабайтам актуальных данных, соответственно кэшировать больше можно, но выигрыша это не даст..

(18) Ну вот, узкое место нашли (Средняя длина очереди к диску - почти всегда 100)
Теперь смотри, какие именно файлы в топе на запись.

(22) Вот и я про тоже. 1С-это нечто среднее с присущими и тому и тому недостатками.

Ищут клиента в базе: жуткий тормоз, кэш не прогрет и все читается с диска. А к нему очередь ого-го. Потом делают проводку: регистр бухглатерии читается, сервер 1С крутится, ОЗУ нехватает, справочник контрагентов из кэша выгружается... Следующий выбор контрагента опять жесткие тормоза... Замкнутый круг.

(18) Хотя, на рабочие базы лучше даже и не смотреть. Тест Гилева в 1.5 попугая - это какая-то очевидная беда с инфраструктурой. Лучше всего на тесте Гилева с нагрузкой и разбираться тогда.

(24) Так читается не весь регистр, а только таблицы итогов с использованием индексов по нужным разрезам. Это немного, на самом деле. Можете проверить, считая реальные чтения с диска во время выполнения запросов. Редко когда появляются извращенские запросы типы выборки с LIKE по комментарию из основной таблицы регистра.

(26) Индексы могут занимать дохрена, на самом деле. Особенно если их много наклепали по большим таблицам.

(27)  Лежат на диске, не пищат

(26) Мимо. Самая мякотка в нагруженных системах - это поиск в динамических списках с RLS

(26) В 1С индексы могут занимать от четверти объема данных и выше.

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

(31) запусти тест гилева на любом скоростном компе в конторе и покажи руководству результат. )

(31) Нагрузочный тест Гилева тупо фигачит проведение "пустышек". При таких сверхнизких показателях почти стопроцентно упор в диски. Что подтверждается твоими показателями производительности.

(32) а что это даст? разве результаты этого теста отличаются от клиента, с которого запускается?

(31) в узкие места ты сам лезешь и настройки правишь, тест покажет хуже или лучше стало.

(33) ну вот тогда подготовлю эти показатели и попробую пробить ссдшные диски что ли. Если на*ер не пошлют)
Спасибо за помощь

(35) а, понял, значит придется еще и разобраться в настройках sql и серверов...

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

(38) а, понял. ну, я на рабочем серваке запускал тест - тест показал 9,5)) В принципе разница существенная, а настройки там одинаковые. Ну те, до которых мне дали дотянуться.

(18) у вас коэффициент 100 стоит на очереди. он будет 100 отображать когда очередь =1.
уберите все лишние параметры и поставьте коэффициент другой чтобы видеть не упирающийся в потолок, а реальный график. например 1.

(40) спасибо,поставил коэффициент = 1, получил колебания в пределах от 10 до 20.

(41) это ОЧЕНЬ много.
дисковая система у вас не справляется. при 6-8 ощущаются как серьезные тормоза в работе.
при 20 ... мои бы нервы не выдержали.
идите к руководству.

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

(43) Сколько админы у вас получают?

буду пугать сложными словами и цифрами руководителей) а то на ERP денег хватило, а железо слепили "из того, что было".

(44) все мы тут получаем мало) Для нашего города 30 тысяч - неплохая зарплата. У нас ее получают далеко не все)

(39) Вы очень несчастные люди.
У нас Гилев дает 50 на рабочем сервере

(47) нам обещали новый сервер на боевую базу) так что и у нас скоро будет счастье.
Но потом...

https://sun9-49.userapi.com/c629316/v629316960/2e15f/uKKzsQpeyAw.jpg

(46) прочитал бегло. Конфигурацию СХД выше не озвучивали?

У нас на новом с W-2265 на клиент-серверном тесте больше 48 так и не смог получить, иногда прыгнет до 51, но это предел

(41) так в (23) какие файлы? Может и не в дисках дело, а в свопе.
И обслуживание базы делали тестовых в части "Реорганизация и перестроение индексов"?

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

(51) вот разбираюсь щас, как можно посмотреть эту очередь.
Насчет реорганизации - нет, не делали 2 года последних точно. Почитаю об этом, спасибо

(52) Система хранения данных

(52) "Данные хранятся на обычных HDD"
ну это никуда не годится

(53) в мониторе ресурсов закладка диск там отсортировать по чтению/записи/всего.

(54) да термин то я расшифровал, но четко не могу ничего сказать, так как не сталкивался с такими штуками. знаю, что у нас сервера комплектуются HDD

(55) парочку SAS дисков в зеркало с кеширующим рейд-контроллером, хотя бы что-нибудь, даже древнее.
Лучше ssd конечно.

(56) на первом месте с большим отрывом сервер с 1 из тестовых баз, чтото делают там, видимо сейчас

https://ibb.co/4NKqXX4

(0) Тест CrystalDiskMark сервера можешь показть?

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

"Так вот, эти базы тормозят так, что хоть святых выноси"


Уже предлагали выяснить скорость чтения и записи дисков?

(59) касперский тоже что то жрет, хотя бы настроили его ?

(60) вот намерял
https://ibb.co/4dNRnnP

(62) вот выяснил
https://ibb.co/4dNRnnP

(64) мдя, там цифры больше на порядок должны быть по идее. А на NVME дисках на 2 порядка.
Плюс 16 гигов оперативки, сервер 1с вешается.

(64) У вас данных в базе мало. Видишь, в тесте, куски 1Мб читаются быстрее, а 4Кб медленнее. Значит наполните базу что бы куски данных были минимум по 1Мб у вас все залетает.

(67) ты всё перепутал) тс это лучше не читать

(67) Что за бред?

(69) Это стёб

(65) цифры грустненькие. Сравни хотя бы с дешевым SSD на моём домашнем компе:
https://ibb.co/6PwCGD8

Память от 64 к.
Дисковая система, три нулевых рейда: винда, скуль, базы данных.
Никаких лишних сервисов, типа терминала, файлового хранилища.
"Горячий" процессор, по Гилёву: http://www.gilev.ru/systemperfomance/

При (значительной) нехватке памяти система обычно лезет в своп(page.sys для Windows) и если туда начинает выгружаться память сервера приложений, при интенсивном тестировании...
Посмотрел результаты(теста Гилева) для E-2276G, W-2145, Gold 6244. Какие-то жалкие, убогие значения - от 40-а до 50-ти.
Хотя бы, 70-75, в к-с варианте, конечно.

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

(19) иэх. а боевая база такого объема на клюшках вполне работала...

(75) ну и спутниками управляли в 90х,

(76) ага.
"а теперь со всей этой ***ней мы попробуем взлететь"©

Количество баз - вообще не несет никакой информативности. Важен размер баз, количество пользователей и задачи, которые эти пользователи в базах решают. Может просто сидят и создают раз в час документик на пару позиций, а может формируют отчеты за 10 лет с мощной детализацией или проводят по 30 документов на 1000 позиций каждый, а раз в неделю - проведение с начала года.

Ну и все такое, вы идею поняли.

Откуда у них база на 170 гб?

Ну что, разобрался куда админы серверные диски замышили, воткнув ХДД с бабкиного компа?

(80) https://ark.intel.com/content/www/ru/ru/ark/products/75790/intel-xeon-processor-e5-2630-v2-15m-cache-2-60-ghz.html
q3'2013 =)

(81) это дата выхода. Купили его наверняка сильно позже, году так в 15-16-м. В те времена ХДД уже не такими тормозами были

(82) если на "сервере" написано DEPO всё может быть

такой скорости диска радовались где то в 2005 +/- году примерно...

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

Что такое "Получше" - будут определять админы)))

Спасибо большое за помощь, я узнал много нового, благодаря вам)

"специалисты, которые моделируют тестовые ситуации на базах и сверяют проводки жалуются, что документы проводят по 20 минут"
вместо нескольких секунд.
учитесь переводить эти показатели в деньги, которые контора теряет - из за некачественного тестирования, потому что полноценно просто физически провести его не успевают. и просто на зарплате тестирующих функционал специалистов - которые просто сидят тупят по 20 минут в ожидании.

А мне интересно... Если там режим "тестирование", то почему не попробовали на самом сервере в файловом режиме запустить и посмотреть, как будет работать именно тестовая база или демо база, а не какая-то,  которая получилась на 170 гб. Но никто не знает чем же она там заполнилась.

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

Но для работающей ЕРП на нескольких активных сеансах да еще на двух базах одновременно - 16 гб оперативы для сервера СУБД маловато будет.

Ну и не указано в топике на какой версии платформы и не указано с какими доработками установлена конфигурация.

Но! Почему-то мне показалось, что никто не обратил внимание, что у ТС на серваке отключили регламентные и фоновые задания вообще все.
На ЕРП 2.4 с ее БСп, что в нее встроена, категорически нельзя устанавливать режим блокировки регламентных и фоновых заданий.

(88) у него очередь к диску 100, никакого смысла что то советовать
(85) а студент за 10к с работой поменял бы чтобы всё зашевелилось

(85) Странный ты типок,

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

(51) >> обслуживание базы делали тестовых в части "Реорганизация и перестроение индексов"?
(53) >> Насчет реорганизации - нет, не делали 2 года последних точно.

Понятно, что летать базы на данном сервере не будут.
Но может начать с малого?
- Выполнить все регламенты СУБД для этих баз.
- Проверить и настроить регламенты 1С для этих баз. Например, если включен полнотекстовый поиск, то проверить, что его индекс актуален и регулярно обновляется. Может его не обновили и он в данный момент перестраивается и, если сервер приложения находится на том же сервере, то перестроение индекса ППД строит такие безумные очереди.
- Проверить что в базе настроены и рассчитаны итоги по всем регистрам (косяк в установке периода рассчитанных итогов на боевой базе может не вызывать критичных тормозов на нормальном железе, в отличии от тестового).
- Если сервер приложения на том же серваке, то отключите ведение журнала регистрации 1С в базах, и ведение технологического журнала сервера 1С.

Вообще кто-то уже ведь советовал посмотреть - чтение и запись каких файлов находится в топе при росте очереди к диску. Может так оказаться, что очереди устраивает вовсе и не СУБД, а сервер приложения или вообще какой-нибудь другой процесс.

(0) Поставьте вопрос по другому, не новый сервер, а покупка памяти и SSD диски + проведите регламентные работы с базой. Пользуйтесь замера производительности, хватит оперировать понятиями тормозит и летает.

И все-таки снять блокировку с выполнения фоновых и регламентных никто ему так и не подскажет :-)

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

База нормальная -это тупо копия боевой, то есть там документы, справочники, регистры за последние 4-5 лет от полутора тысяч пользователей. Данных там полно.

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

(89) про студента не понял)))

(90) а что значит "требования к проведению документов"? типа сказать руководству, что документ должен проводится 2 секунды, а проводится 20 минут?

Пока так говорят мне))

(91) понял, надо как следует заниматься обслуживанием, буду расти вширь как специалист))

(88) платформа 8.3.15, конфа 2,4,7, вот сижу обнволяю на2,4,12. Вернее подготавливаю.
Конфа нетиповая слегка - пару модулей своих, много подписок, несколько расширений, ничего глобального, но хватает работы для нашего коллектива

(98) понятно, что надо сделать для нормальной нужной вам рабочей базы.

Только речь о том, что заведите базу для тестирования. Загрузить в эту базу что-то мелкое - демо-базу типовую. Включите ее полностью, как положено, с регламентными, с фоновыми и т.д. Как ее запустите, то сможете хотя бы понять, глючит именно ваша боевая база в том состоянии, как ее кто-то изнасиловал. Или все-таки просто сервак не настроен или не подходит под любую базу ERP на той платформе, что у вас там.

И понятно, что тестировать в файловом режиме нужно было не ту самую нахлобученную данными по самые не балуйся, а демку. Просто для проверки пригодности железа для запуска Клиентского приложения с базой уровня ERP-демка.

(96) ты там кто?

(96) говорят тебе - отвечай "хорошо, цена вопроса - вот такая."
главное никогда не отказываться от задач.
но вместе с задачами забирать на себя бюджеты.

(101) стараюсь так и делать) особенно если задачи интересные
(100) по документам - программист, а так - программист, администратор и тех поддержка)

Как сказал мне как-то 1 пользователь по телефону - "как это не к вам, вы же эти... как вас... айпишники")

(102) ну а нафига вы как администратор запускаете такие базы на таком овне, идите и найдите норм железо

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

(104) а что, на рынке мало народу представляющий услуги аренды серверов?

(106) полно, но с точки зрения руководства нашего это не целесообразно)
уже пытались продавить несколько предложений.

(105) полно, но с точки зрения руководства нашего это не целесообразно)
уже пытались продавить несколько предложений.

(105) не прокатит.

(104) Попросите SSD на 2Tb 2.5 и переустановите полностью систему.
https://market.yandex.ru/product--tverdotelnyi-nakopitel-samsung-2000-gb-mz-76q2t0bw/418376466

(109) да, ссд для баз данных было бы самое то)
Предложу несколько вариантов апдейта

(109) а лучше https://market.yandex.ru/product--tverdotelnyi-nakopitel-samsung-860-evo-2000-gb-mz-76e2t0bw/1969039134
Думаю, данное решение устроит и собственника бизнеса, вас и админов.

(111) спасибо)

(111) самсунги не любят fsync

(113) Здесь https://habr.com/ru/company/selectel/blog/521168/ высказывают мнение, что дело больше в технологических различиях между серверным и десктопным сегментами, нежели в конкретной модели определенного производителя.

(114) угу, в вере в конденсаторы