1с сервер и sql сервер на разных компьютерах как лучше
Обновлено: 07.07.2024
Здравствуйте, хотелось бы узнать мнение профессионального сообщества по такому вопросу.
Есть организация, у нее есть 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 единицы - значит с записью у вас беда. Скорее всего в диски упирается. Т.е. нужно смотреть нагрузку на диск в купе с настройками сиквела. 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.
Надеюсь, что я правильно вас понял))
я не очень разбираюсь в системных этих делах, но почитав интернеты, понимаю, что это не очень хорошие показатели, особенно по дискам.
Но мне главное понять, что это нужный инструмент, а там я с гуглом разберусь о нужных показателях (19) Это только для жесткого ОЛАПа разве что имеет смысл. В реальной рабочей базе доступ производится к нескольким гигабайтам актуальных данных, соответственно кэшировать больше можно, но выигрыша это не даст.. (18) Ну вот, узкое место нашли (Средняя длина очереди к диску - почти всегда 100)
Теперь смотри, какие именно файлы в топе на запись.
(22) Вот и я про тоже. 1С-это нечто среднее с присущими и тому и тому недостатками.
Ищут клиента в базе: жуткий тормоз, кэш не прогрет и все читается с диска. А к нему очередь ого-го. Потом делают проводку: регистр бухглатерии читается, сервер 1С крутится, ОЗУ нехватает, справочник контрагентов из кэша выгружается. Следующий выбор контрагента опять жесткие тормоза. Замкнутый круг.
(18) Хотя, на рабочие базы лучше даже и не смотреть. Тест Гилева в 1.5 попугая - это какая-то очевидная беда с инфраструктурой. Лучше всего на тесте Гилева с нагрузкой и разбираться тогда. (24) Так читается не весь регистр, а только таблицы итогов с использованием индексов по нужным разрезам. Это немного, на самом деле. Можете проверить, считая реальные чтения с диска во время выполнения запросов. Редко когда появляются извращенские запросы типы выборки с LIKE по комментарию из основной таблицы регистра. (26) Индексы могут занимать дохрена, на самом деле. Особенно если их много наклепали по большим таблицам. (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) Вот попробую скомпоновать отчет/служебку с этими всеми показателями и пойду, потому что тестировщики ко мне все идут, говорят "сделай ченить", а админы говорят - "отличный сервак, че ты".
Поэтому надо обоснование, вот щас чтото вырисовывается буду пугать сложными словами и цифрами руководителей) а то на ERP денег хватило, а железо слепили "из того, что было". (44) все мы тут получаем мало) Для нашего города 30 тысяч - неплохая зарплата. У нас ее получают далеко не все) (39) Вы очень несчастные люди.
У нас Гилев дает 50 на рабочем сервере
(47) нам обещали новый сервер на боевую базу) так что и у нас скоро будет счастье.
Но потом.
И обслуживание базы делали тестовых в части "Реорганизация и перестроение индексов"? (49) не знаю такого термина, к сожалению) Данные хранятся на обычных HDD. Бэкапы на отдельных серверах. (51) вот разбираюсь щас, как можно посмотреть эту очередь.
Насчет реорганизации - нет, не делали 2 года последних точно. Почитаю об этом, спасибо (52) "Данные хранятся на обычных HDD"
ну это никуда не годится (53) в мониторе ресурсов закладка диск там отсортировать по чтению/записи/всего. (54) да термин то я расшифровал, но четко не могу ничего сказать, так как не сталкивался с такими штуками. знаю, что у нас сервера комплектуются HDD (55) парочку SAS дисков в зеркало с кеширующим рейд-контроллером, хотя бы что-нибудь, даже древнее.
Лучше ssd конечно.
(56) на первом месте с большим отрывом сервер с 1 из тестовых баз, чтото делают там, видимо сейчас
(59) для полного счастья можешь еще фрагментацию этого файла посмотреть.там тысяч 20 фрагментов будет я предположу.
но админы да.. хлеб едят зря.
"Так вот, эти базы тормозят так, что хоть святых выноси"
Уже предлагали выяснить скорость чтения и записи дисков?
(64) мдя, там цифры больше на порядок должны быть по идее. А на NVME дисках на 2 порядка.Плюс 16 гигов оперативки, сервер 1с вешается. (64) У вас данных в базе мало. Видишь, в тесте, куски 1Мб читаются быстрее, а 4Кб медленнее. Значит наполните базу что бы куски данных были минимум по 1Мб у вас все залетает. При (значительной) нехватке памяти система обычно лезет в своп(page.sys для Windows) и если туда начинает выгружаться память сервера приложений, при интенсивном тестировании.
Посмотрел результаты(теста Гилева) для E-2276G, W-2145, Gold 6244. Какие-то жалкие, убогие значения - от 40-а до 50-ти.
Хотя бы, 70-75, в к-с варианте, конечно. короче это не сервер у вас, машина на уровне домашнего компа разработчика 6+ летней давности, ну или сервера 10+ летнего.
если все настолько плохо, возьмите современный системник рублей за 70 и работайте на десктопном железе забыв про этот "сервер" как страшный сон.
пока денег на нормальный сервер не дадут. (19) иэх. а боевая база такого объема на клюшках вполне работала. (76) ага.
"а теперь со всей этой ***ней мы попробуем взлететь"©
Количество баз - вообще не несет никакой информативности. Важен размер баз, количество пользователей и задачи, которые эти пользователи в базах решают. Может просто сидят и создают раз в час документик на пару позиций, а может формируют отчеты за 10 лет с мощной детализацией или проводят по 30 документов на 1000 позиций каждый, а раз в неделю - проведение с начала года.
Ну и все такое, вы идею поняли.
Ну что, разобрался куда админы серверные диски замышили, воткнув ХДД с бабкиного компа? (81) это дата выхода. Купили его наверняка сильно позже, году так в 15-16-м. В те времена ХДД уже не такими тормозами были такой скорости диска радовались где то в 2005 +/- году примерно.Ну так, показал циферки всем, до кого мог дотянутся, сказали - ну а че, в принципе работает же. Пользователей там нету, вы потерпите, а мы может попробуем в след году пробить новый сервер. Ну или какой нибудь старый отдадим получше.
Что такое "Получше" - будут определять админы)))
Спасибо большое за помощь, я узнал много нового, благодаря вам)
"специалисты, которые моделируют тестовые ситуации на базах и сверяют проводки жалуются, что документы проводят по 20 минут"вместо нескольких секунд.
учитесь переводить эти показатели в деньги, которые контора теряет - из за некачественного тестирования, потому что полноценно просто физически провести его не успевают. и просто на зарплате тестирующих функционал специалистов - которые просто сидят тупят по 20 минут в ожидании. А мне интересно. Если там режим "тестирование", то почему не попробовали на самом сервере в файловом режиме запустить и посмотреть, как будет работать именно тестовая база или демо база, а не какая-то, которая получилась на 170 гб. Но никто не знает чем же она там заполнилась.
Ну и второй момент - база на субд сервере. Всем хочется чтоб тактовая частота на процесс на СУБД сервере была повыше, но на таком достаточно большом размере баз надо бы пускать 1С сервер на своем железе и пусть там будет высокая частота при количестве памяти в 16 Гб - тестируют - а вот сервер СУБД на другом железе.
Но для работающей ЕРП на нескольких активных сеансах да еще на двух базах одновременно - 16 гб оперативы для сервера СУБД маловато будет.
Ну и не указано в топике на какой версии платформы и не указано с какими доработками установлена конфигурация.
Но! Почему-то мне показалось, что никто не обратил внимание, что у ТС на серваке отключили регламентные и фоновые задания вообще все.
На ЕРП 2.4 с ее БСп, что в нее встроена, категорически нельзя устанавливать режим блокировки регламентных и фоновых заданий.
(85) а студент за 10к с работой поменял бы чтобы всё зашевелилось
(85) Странный ты типок,
установи требования к проведению документов, и пусть они занимаются их доведением, до приемлимых значений
(51) >> обслуживание базы делали тестовых в части "Реорганизация и перестроение индексов"?
(53) >> Насчет реорганизации - нет, не делали 2 года последних точно.
Понятно, что летать базы на данном сервере не будут.
Но может начать с малого?
- Выполнить все регламенты СУБД для этих баз.
- Проверить и настроить регламенты 1С для этих баз. Например, если включен полнотекстовый поиск, то проверить, что его индекс актуален и регулярно обновляется. Может его не обновили и он в данный момент перестраивается и, если сервер приложения находится на том же сервере, то перестроение индекса ППД строит такие безумные очереди.
- Проверить что в базе настроены и рассчитаны итоги по всем регистрам (косяк в установке периода рассчитанных итогов на боевой базе может не вызывать критичных тормозов на нормальном железе, в отличии от тестового).
- Если сервер приложения на том же серваке, то отключите ведение журнала регистрации 1С в базах, и ведение технологического журнала сервера 1С.
Вообще кто-то уже ведь советовал посмотреть - чтение и запись каких файлов находится в топе при росте очереди к диску. Может так оказаться, что очереди устраивает вовсе и не СУБД, а сервер приложения или вообще какой-нибудь другой процесс.
(0) Поставьте вопрос по другому, не новый сервер, а покупка памяти и SSD диски + проведите регламентные работы с базой. Пользуйтесь замера производительности, хватит оперировать понятиями тормозит и летает. И все-таки снять блокировку с выполнения фоновых и регламентных никто ему так и не подскажет :-)(88) пробовали в файловом варианте запускать, когда еще не было сервера лицензий выделенного, - без ссд дисков база тупо вылетает с ошибкой. Сейчас лицензии перевели на отдельный сервер, поэтому нету лицензий, чтобы проверить как работает файловая база. Конечно, можно заморочится и все же реализовать это, но есть у меня стойкое подозрение, что результат будет тот же - зависание и вылет.
База нормальная -это тупо копия боевой, то есть там документы, справочники, регистры за последние 4-5 лет от полутора тысяч пользователей. Данных там полно.
Насчет отключения регламентных - я этого вопроса не касался, предыдущий специалист когда передавал дела, сказал, что отключил их, чтобы всякие загрузки не пересекались с боевой базой. Надо изучить этот вопрос подробнее, спасибо
(90) а что значит "требования к проведению документов"? типа сказать руководству, что документ должен проводится 2 секунды, а проводится 20 минут?
Пока так говорят мне))
(91) понял, надо как следует заниматься обслуживанием, буду расти вширь как специалист)) (88) платформа 8.3.15, конфа 2,4,7, вот сижу обнволяю на2,4,12. Вернее подготавливаю.Конфа нетиповая слегка - пару модулей своих, много подписок, несколько расширений, ничего глобального, но хватает работы для нашего коллектива
(98) понятно, что надо сделать для нормальной нужной вам рабочей базы.
Только речь о том, что заведите базу для тестирования. Загрузить в эту базу что-то мелкое - демо-базу типовую. Включите ее полностью, как положено, с регламентными, с фоновыми и т.д. Как ее запустите, то сможете хотя бы понять, глючит именно ваша боевая база в том состоянии, как ее кто-то изнасиловал. Или все-таки просто сервак не настроен или не подходит под любую базу ERP на той платформе, что у вас там.
И понятно, что тестировать в файловом режиме нужно было не ту самую нахлобученную данными по самые не балуйся, а демку. Просто для проверки пригодности железа для запуска Клиентского приложения с базой уровня ERP-демка.
Постоянно сталкивался с высказываниями ИТ специалистов «сеть нагружена на 20%… процессоры на 50%… очередей к дискам мало… Значит сеть и сервера справляются… смотрите код в 1С проблемы исключительно там».
На самом деле происходило следующее ( сервер 1С и SQL разнесены на разные компьютеры): сеть практически использовалась по максимуму(эти "20% загрузки сетевого интерфейса" = «20% полезные данные» + «80% потеря на служебной обработке»). И соответственно из-за малой ширины канала обмена «полезными» данными — SQL сервер с «Сервером 1С» постоянно ожидали друг друга, что вело к малой утилизации ресурсов CPU и дисковой системы.
Ведение: Сначала хочу заострить внимание на том что же такое 1С платформа?.
Программист в среде 1С — пишет объектную логику, а за сборку/разборку и запись объектов в «плоский вид» по таблицам базы данных отвечает сама платформа.
Основные "+" и "-" с точки зрения ORM:
"+" Программист в среде ORM получает преимущество в скорости разработки приложения из-за уменьшения количества кода и его простоты по сравнению с исключительно реляционным программным кодом (пример SQL запросы). А также освобождается от написания кода работающего непосредтсвенно с записями в таблицах Реляционной СУБД.* 1
"-" Сложности для создателей «платформ» ORM и проблемы производительности:
Использование реляционной базы данных для хранения объектно-ориентированных данных приводит к «семантическому разрыву», заставляя программистов писать программное обеспечение, которое должно уметь как обрабатывать данные в объектно-ориентированном виде, так и уметь сохранить эти данные в реляционной форме. Эта постоянная необходимость в преобразовании между двумя разными формами данных не только сильно снижает производительность, но и создает трудности для программистов, так как обе формы данных накладывают ограничения друг на друга.
*1«Уточнение». Несмотря на то, что 1С 8.х позволяет работать с реляционно-подобным кодом (только чтение) в объекте 1С «Запрос» — это все-таки не напрямую один-в-один транслируемый в реляционную СУБД запрос к таблицам хранения данных, а прежде всего «Объектный запрос» — также не минующий стадию сборки разборки объектов. Поэтому зачастую вместо много-тысяче строчных «Объектных запросов» — наиболее оптимально по быстродействию кода и скорости разработки — написать объектный не ряляционно-подобный код.
Глава 1: Расмотрим модель клиент-серверной 1С 8.х
Отмечу основные «узкие» места влияющие на производительность:
1) Первое узкое место — это коммуникационная среда передачи данных.
На рисунке стрелками показаны потоки обмена данными, где «красные» — это Реляционная СУБД<->Объектная СУБ, «оранжевые» — синхронизация между Объектными СУБД.
Т.к. при использовании отдельных серверов для СУБД и кластеров 1С – коммуникационная среда это сетевые соединения – то существуют существенные задержки в передаче данных многочисленными мелкими порциями – как из-за латентности самой физической реализации интерфейсов, так и из-за латентности узлов в этой сети.
Рассмотрим на примере сетевого стандарта Ethernet Gigabit (график зависимости скорости передачи данных… ниже)
на примере работы Сервера 1С с MS SQL (по умолчанию размер коммуникационных пакетов 4 кб):
На графике видно, что при использовании пакетов ДАННЫХ =4 кб пропускная способность рассмотренной сети всего 250 Мегабит/с. (как правильно заметили в комментария к публикаци: это не пакеты протоколов например уровня TCP, а пакеты ДАННЫХ которые генерируют приложения участвующие в обмене)
…
Из практики: такое разнесение на Два отдельных сервера
MS SQL (сервер №1)< — Ethernet Gigabit ---> «Сервер 1С»(сервер №1)
проигрывало по скорости работы платформы
на 50% варианту MS SQL (сервер №1) < — Shared Memory (без сети через участок памяти) ---> «Сервер 1С»(сервер №1)… и это уже «на одном высоконагруженном пользовательском сеансе»
2) Узкое место — это количество отдельных компьютеров «кластеров 1С», чем их больше тем больше затраты на синхронизацию и как следствие уменьшение производительности системы.
3) Узкое место — количество отдельных процессов сервера 1с, чем их больше тем больше затрат на их синхронизацию… Но тут скорей всего необходимо найти «золотую середину» — для обеспечения стабильности. 2*
2* «Уточнение» — для MS Windows существует такое правило:
Процессы дороже чем потоки, что означает применительно к данному случаю на практике следующее: скорость обмена между двумя потоками внутри одного процесса значительно превышает, скорость обмена между потоками находящихся в разных процессах.
Поэтому например «Файловая 1С 8.х» всегда превышает по скорости однопользовательской работы платформы в клиент-серверном варианте. Все просто т.к. в случае «Файловой 1С 8.х» поток «Реляционной СУБД» общается с потоком «Объектной СУБД» внутри одного единого процесса.
4)Узкое место – одно-поточность пользовательского сеанса, т.к. каждый отдельно взятый — пользовательский сеанс не распараллеливается платформой на несколько, то его работа ограничивается использованием ресурсов одного ядра CPU => следовательно желательна максимальная скорость каждого ядра, в этом случае быстродействие платформы 1C например на 10-ядерном CPU по 1 ггц — будет значительно уступать быстродействию платформы на 4-ех ядерном CPU по 3 Ггц – естественно до определенного количества потоков.
Глава 2(Итог): Рассмотрим не масштабируемый и масштабируемый варианты — наиболее эффективных схем для платформы 1с 8.х. для OS Windows (пологаю для Linux ситуация аналогична)
1-Вариант(не масштабируемый). В расчете на 100 «высоконагруженных пользовательских сеанса»
1) эффективен обычный 2-ух сокетный сервер с 4-ех ядерными CPU по 3 Ггц.
2) быстрая дисковая система на SSD
3) MS SQL < — Shared memory --> «Сервер 1С»
2-Вариант(масштабируемый). начиная со 100 «высоконагруженных пользовательских сеанса» и далее….
Тут логичней всего пойти по пути немецкой 1с-ки «Sap HANA»))
Собирать модульный «Супер-компьютер» от фирмы SGI – состоящий из «лезвий» на 2-х сокетных материнских платах, каждое лезвие соединяется друг с другом сложной топологией сверх-быстрого интерконнекта на основе NUMA-чипов, и все находится под управлением единой OS. Т.е. программы внутри такого сервера по определению имеют доступ к ресурсам любого «лезвия».
1) добавляем «лезвия» по необходимой нагрузке… из расчета примерно одно «лезвие» на 100 пользователей.
Есть задача:
Организовать на нем работу серверной 1с. пользователей сейчас до 30, но планируют увеличивать до 100.
Что по вашему мнению выгоднее:
1) на хостовую машину Hyperv-server. на виртуальные 1с и sql ?
2) на хостовую машину MS Server 2012R2 и на нее уже сервер 1с и sql ?
Я бы разнес на вирутуальные _)) Но сейчас многие говорят что можно ставить на 1 машину и 1с и sql и все будет хорошо и быстрее на 30 и выше процентов_))
Современные виртуальные машины класса Hyper-V, ESX и тп. - жрут жалкие проценты производительности. Только виртуальные машины. На каждую машину - одна роль. И второй такой же сервер для фэйловера. Потерь производительности не будет.
Можно конечно как неандертальцы все на одну ставить, но потом не пишите сюда вопросы что делать, если после очередного обновления какой-либо системы у вас рухнуло ВСЕ. И вам за ночь нужно будет поднять и настроить их все. нет к сожалению второго такого сервера _))
если б он был, можно было бы все на железе отдельном развернуть, хотя отказоустойчивость тогда 0 _)) В любом случае поставить голый гиперв на любой комп и развернуть на нем бэкапы виртуалок в разы проще восстановления системы на другом железе. nfire, вы, видимо с энтерпрайзом не сталкивались. Развернуть виртуалку с MSSQL, которой требуется 64Гб оперативы и 100-200Гб SSD, на любой комп не всегда возможно. Дмитрий, зато я сталкивался с переносом системы на другой сас-контроллер. Больше не хочется.
Разница с железом в производительности процентов 5%, то есть вы этого даже не заметите.
Но в случае сбоя поднять виртуалку из бэкапа (если он у вас есть) - минутное дело, всяко-разно никак не сопоставимо с многочасовой настройкой ПО на железе.
1) на хостовую машину Hyperv-server. на виртуальные 1с и sql ?
Выгодно в плане удобства администрирования.
Крайне невыгодно в плане производительности. Если для вас удобство важнее производительности, то вполне нормальный вариант.
2) на хостовую машину MS Server 2012R2 и на нее уже сервер 1с и sql ?
Ну если полтора процента для вас "Крайне снижает производительность".
Или получать данные напрямую из памяти, или гонять данные через два сетевых интерфейса, с очередями и задержками присущими сетям.
Какие полтора процента? В два-три раза как минимум.
Или получать данные напрямую из памяти, или гонять данные через два сетевых интерфейса, с очередями и задержками присущими сетям.
1) Вас кто-то обманул.
2) Запомни, студент, в любой задаче, где интенсивно используется СУБД при грамотной организации решения этой задачи - основная нагрузка по перевариванию данных как раз ложиться на СУБД. А уже переваренный в СУБД небольшой по объему результат уезжает по сети в приложение.
3) Локально ты будешь обращаться к СУБД через сетевые интерфейсы тоже. И да, они будет конечно виртуальными, не связанными с реальным железом. Но ненамного более простыми, чем виртуальные интерфейсы виртуальных машин.
отвечу за "студента"
1) никто его не обманул, человек явно работал с 1С ;)
2) вы знаете как 1С работает с СУБД? там используются только самые базовые ф-ции самой базы без переваривания силами СУБД и сокращение издержек в этом месте положительно влияет на производительность
3) локально к СУБД можно (и в данном контексте нужно!) обращаться через SharedMemory (это кстати ответ на то почему нежелательно разносить сервера)
вы знаете как 1С работает с СУБД? там используются только самые базовые ф-ции самой базы без переваривания силами СУБД и сокращение издержек в этом месте положительно влияет на производительность
Вы описываете семерку. Она почила в бозе уже 10 лет как. Хотя кое где используется.
;)
там ситуация не сильно лучше
Да, это очевидно, что он работал с 1С, но:
3) локально к СУБД можно (и в данном контексте нужно!) обращаться через SharedMemory (это кстати ответ на то почему нежелательно разносить сервера)
А еще можно вообще от операционной системы отказаться. Она же часть ресурсов забирает.
Oracle в свое время сделал возможность своей СУБД работать с дисками напрямую, минуя файловую систему. И что? Думаете сразу фантастический рост производительности? Отнюдь. Серебряной пули не существует.
Что до конкретно 1С - ФИЗИЧЕСКИ разносить сервера не стоит.
Но на различные виртуальные машины в пределах одной физической машине - не наблюдается никакого страшного падения производительности.
Сеть 1С использует не столь сильно.
вы крайне переоцениваете восьмерку ;)
там ситуация не сильно лучше
Исходя из того, что восьмерка должна отображать пользователям кучу инфы, когда пользователи листают экран журнала документов например - конечно она вытягивает много данных.
Впрочем, чего гадать-то на кофейной гущи. Возьмите хоть встроенный профилировщик Windows и замерьте нагрузку на сеть.
Будете очень удивлены.
Вроде бы да, 1С использует сеть интенсивно. Но при этом сетевая карта не так чтоб даже и нагружена.
Ну а виртуалка вполне годна.
Она не притормаживает работу на вот эти смешные
как написал Артем.
Какие два раза, Артем?
Даже при самом худшем сценарии - и 10 процентов не достигает.
InoMono, "Эффект Даннинга — Крюгера"
Я не буду особо вам доказывать, но сталкиваясь на разных крупных предприятиях с интеграцией 1С, ВСЕ интеграторы однозначно рекомендуют ставить по возможности сервера вместе. или они не профессионалы? не понимают бедные что сеть не тормозит? что sharedmemory глупости?
фантастического роста конечно не будет, но борьба с производительностью в крупных базах у 1С это одна из самых больных проблем тянущихся с семерки до сих пор, и до сих пор нет однозначного способа победы, по этому в бой идут все возможные способы
Ой какую дискуссию развели.
InoMono, При чем тут виртуальные машины вообще? Была дана конкретная ситуация.
Разносить на разные машины сервер 1с и скуля крайне не рекомендуется ввиду просадки производительности.
Это факт. Подтвержденный практикой эксплуатации типовых решений 1с.
Да в восьмерке если взяться и оптимизировать код, то можно свести к минимуму обмен информацией между сервером 1с и скулем.
Но кто блин это делать будет? Нанимать программеров и оптимизировать кучу типового кода, который постоянно меняется. На сопровождении разоритесь, программеры 1с очень жадные люди, и денежки любят.
Цифра не с потолка взята. Типовые базы 1с работают в режиме SharedMemory в два, три раза быстрее нежели по сети.
Поэтому разносят 1с и скуль по разным серверам в двух ситуациях -
1)Железо банально не справляется чтобы тянуть и то и другое.
2)Когда производительность не сильно важна, ресурсов гарантированно больше чем надо, и на первое место выходит удобство.
Подскажите, на сколько критично, если разместить SQL и сервер 1С на одной машине, особых ограничений в ресурсах нет. Т.е. это будет виртуальная машина?
Скажется ли это на производительности 1С, при размере базы 8 Гб и 10 пользователей. Конфигурацию Бухгалтерия 2.0?
Основной затык сейчас это проведение реализаций за квартал для себестоимости, идет сутки.
у меня на одном серваке крутиться база размером 15 гб (MDF), сревер 1с и скуль, в программе работают одновременно 15 пользователей, правда оперативы там 16гб, серваку уже три года, брали примерно за 160-180 рублей еще тогда. Народ трудиться нормально, документооборот составляет около 400-500 документов в день, бухгалтерия типовая, не самолет конечно, но люди трудятся нормально, машина по железу еще 32 разрядная, если будете брать 64-х думаю проблем особых не будет, базу не допиливал на предмет прямых скуль-запросов. проведение всех доков за месяц проходит примерно за 5-6 часов, главбух на ночь запускает и уходят утром косяки все правят, потом финальное проведение и закрытие.Виртуальная машина, берет ресурсы с железки, поэтому удивляет "особых ограничений в ресурсах нет".
Рекомендации по выбору оборудования для работы с 1С:Предприятием 8
Для работы с 1С:Предприятием 8 рекомендуемая конфигурация компьютера, приведенная в “Руководстве по установке и запуску”, имеет следующие характеристики:
компьютер конечного пользователя:
операционную систему: Microsoft Windows 98/Me, Microsoft Windows 2000/XP/Server 2003/Vista (рекомендуется Microsoft Windows XP)
процессор Intel Pentium II 400 МГц и выше (рекомендуется Intel Pentium III 866 МГц);
оперативную память 128 Мбайт и выше (рекомендуется 256 Мбайт);
жесткий диск (при установке используется около 220 Мбайт);
устройство чтения компакт дисков;
USB-порт;
SVGA дисплей;
компьютер, используемый для разработки конфигураций:
операционную систему: Microsoft Windows 2000/XP/Server 2003/Vista (рекомендуется Microsoft Windows XP);
процессор Intel Pentium III 866 МГц и выше (рекомендуется Intel Pentium IV/Celeron 1800 МГц);
оперативную память 512 Мбайт и выше (рекомендуется 1024 Мбайт);
жесткий диск (при установке используется около 220 Мбайт);
устройство чтения компакт дисков;
USB-порт;
SVGA дисплей;
32 разрядный рабочий сервер кластера серверов:
операционные системы Microsoft Windows 2000/XP/Server 2003/Vista или один из дистрибутивов Linux (текущий состав поддерживаемых дистрибутивов Linux публикуется здесь)
процессор не ниже Pentium III 866 МГц (рекомендуется Intel Pentium IV/Xeon 2,4 ГГц). Допустимо и даже желательно использование многопроцессорных машин, так как наличие нескольких процессоров благотворно сказывается на пропускной способности кластера серверов 1С:Предприятия 8.1, особенно в случае интенсивной работы нескольких пользователей;
оперативная память не менее 512 Мбайт (рекомендуется 1024 Мбайт и выше). Хотя рабочие процессы кластера серверов 1С:Предприятия 8.1 могут исполняться в достаточно небольших объемах памяти, при пиковых нагрузках их потребности могут быть весьма значительными;
требуется наличие USB-порта для подключения ключа аппаратной защиты кластера серверов 1С:Предприятия 8.1;
устройство чтения компакт-дисков.
64 разрядный рабочий сервер кластера серверов:
операционные системы Microsoft Windows XP/Server 2003/Vista для x64 или один из дистрибутивов Linux для x86-64 (список дистрибутивов публикуется здесь)
процессор с архитектурой x86-64 (Intel с поддержкой EM64T, AMD с поддержкой AMD64). Допустимо и даже желательно использование многопроцессорных машин, так как наличие нескольких процессоров благотворно сказывается на пропускной способности кластера серверов 1С:Предприятия 8.1, особенно в случае интенсивной работы нескольких пользователей;
оперативная память 1024 Мбайт и выше. И хотя рабочие процессы кластера серверов 1С:Предприятия 8.1 могут исполняться в достаточно небольших объемах памяти, в пиковых ситуациях их потребности могут быть весьма значительными;
требуется наличие USB-порта для подключения ключа аппаратной защиты кластера серверов 1С:Предприятия 8.1;
устройство чтения компакт-дисков.
сервер баз данных:
Microsoft SQL Server 2000 + Service Pack 2 (рекомендуется Service Pack 4);
Microsoft SQL Server 2005;
PostgreSQL 8.1;
PostgreSQL 8.2;
IBM DB2 Express-C 9.1
компьютер сервера баз данных:
в качестве сервера баз данных может использоваться любой компьютер, на котором может работать Microsoft SQL Server, PostgreSQL или IBM DB2. Технические характеристики компьютера и операционная система должны соответствовать требованиям используемой версии сервера баз данных Microsoft SQL Server, PostgreSQL или IBM DB2.
Эти значения можно использовать в качестве базовых при выборе состава оборудования для решения задач автоматизации предприятий.
Разумеется, при выборе аппаратного обеспечения для конкретного внедрения, необходимо учитывать различные факторы: функциональность и сложность используемого прикладного решения (конфигурации); состав и многообразие типовых действий, выполняемых той или иной группой пользователей; количество пользователей и интенсивность их работы и т.д.
В данном документе приводится информация о том, как характеристики оборудования влияют на эффективность использования системы в различных режимах и даются рекомендации по подбору оборудования в зависимости от решаемых задач.
У меня стоит сервер 1С с SQL внутри, проблем не замечаю, всё работает стабильно и быстро. Пользователей около 25, в день до 100 документов. Перепроведение квартала до часа.
В общем случае SQL и 1С разносят на отдельное железо для большей отказоустойчивости, безопасности и возможности масштабирования при многократном увеличении числа пользователей, и вообще это более правильно со всех точек зрения, но и более затратно.
Знакомый спец не советовал устанавливать 1С на виртуальную машину, как и SQL базу данных. Виртуализация признана увеличить отказоустойчивость и надёжность систем, упростить работу админам и прочему обслуживающему персоналу, а так же уменьшить возможный простой дорогостоящего железа. Виртуализация не помогает в скорости, более того немного (а по некоторым тестам много) замедляет общую производительность системы.
Читайте также: