По теме из базы знаний
- Как настроить сервер 1С по умолчанию для ПРОФ лицензии после 10.09.2019
- Подбираем сервер для 1C:ERP
- 10 «заповедей» эксплуатации крупной информационной системы 1С
- Сервер лицензирования 1С на 12 тыс. пользователей: настройка, мониторинг, резервирование
- Sales force automation: мобильное приложение мерчандайзера на платформе 1С с распознаванием товара на 15 языках в одном из крупнейших агентств на нашем континенте (и не только)
Найденные решения
Таблицы серверов, конечно же, есть. Но они довольно условные. И рекомендаций на эту тему море. И противоречий в них тоже много. Ведь, у каждого был свой опыт. Напишу и своё видение. :)
В общем, если достаточно денег, то надо главным образом смотреть частоты процессоров и скорость дисков. Если производительность не упирается в качество кода, то упирается именно в процессоры и диски.
1. По процессорам. За одни и те же деньги лучше больше тактовой частоты, но меньше ядер. Если, например, поставить восьмиядерный процессор на 2 ГГЦ против четырёхъядерного на 4 ГГц, то со вторым система будет работать быстрее.
Опять же, если денег хватает, то лучше вовсе взять два или четыре весьмиядерных процессора по 4 ГГц. Будет хватать и потоков и тактовой частоты.
2. По дискам. Здесь нужно выбирать между надёжностью, производительностью и ценой. Любые два.
Делать массив из бытовых твердотельников производительно, не слишком надёжно и относительно недорого.
Массив из шпиндельных дисков - надёжно, непроизводительно и относительно недорого.
Есть компромисс когда tempdb и журнал транзакций на твердотельниках, а сами данные на шпиндельных дисках. Тоже недорого.
И есть самый лучший на мой взгляд. RAID 50 из энтерпрайзных твердотельников. Дорого, производительно.
Базы и журнал хранить на них.
Надёжность обеспечивается, собственно, избыточностью дисков. Одновременно может выйти из строя два любых диска и данные не потеряются. Да и твердотельники сейчас такие, что надо ещё постараться выработать весь цикл четния-записи.
А ещё у любого хорошего RAID-контроллера есть софтина, которая при соответствующей настройке будет отправлять на почту сообщения если что-то идёт не так.
Резервные копии, естественно, хранить на шпиндельных дисках в другом массиве.
3. Про память. Кашу маслом не испортить, поэтому её можно покупать столько, сколько планок поместится на материнке. Опять же при условии, что по деньгам карт-бланш.
4. Сервер 1С и сервер СУБД лучше не разносить про разным серверам, если это возможно. Северный мост работает быстрее, чем сеть, как ни крути. Да и к тому же, сервер 1С и MSSQL поддерживают Shared Memory.
В общем, если достаточно денег, то надо главным образом смотреть частоты процессоров и скорость дисков. Если производительность не упирается в качество кода, то упирается именно в процессоры и диски.
1. По процессорам. За одни и те же деньги лучше больше тактовой частоты, но меньше ядер. Если, например, поставить восьмиядерный процессор на 2 ГГЦ против четырёхъядерного на 4 ГГц, то со вторым система будет работать быстрее.
Опять же, если денег хватает, то лучше вовсе взять два или четыре весьмиядерных процессора по 4 ГГц. Будет хватать и потоков и тактовой частоты.
2. По дискам. Здесь нужно выбирать между надёжностью, производительностью и ценой. Любые два.
Делать массив из бытовых твердотельников производительно, не слишком надёжно и относительно недорого.
Массив из шпиндельных дисков - надёжно, непроизводительно и относительно недорого.
Есть компромисс когда tempdb и журнал транзакций на твердотельниках, а сами данные на шпиндельных дисках. Тоже недорого.
И есть самый лучший на мой взгляд. RAID 50 из энтерпрайзных твердотельников. Дорого, производительно.
Базы и журнал хранить на них.
Надёжность обеспечивается, собственно, избыточностью дисков. Одновременно может выйти из строя два любых диска и данные не потеряются. Да и твердотельники сейчас такие, что надо ещё постараться выработать весь цикл четния-записи.
А ещё у любого хорошего RAID-контроллера есть софтина, которая при соответствующей настройке будет отправлять на почту сообщения если что-то идёт не так.
Резервные копии, естественно, хранить на шпиндельных дисках в другом массиве.
3. Про память. Кашу маслом не испортить, поэтому её можно покупать столько, сколько планок поместится на материнке. Опять же при условии, что по деньгам карт-бланш.
4. Сервер 1С и сервер СУБД лучше не разносить про разным серверам, если это возможно. Северный мост работает быстрее, чем сеть, как ни крути. Да и к тому же, сервер 1С и MSSQL поддерживают Shared Memory.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(7) Я бы не рекомендовал слепо следовать той таблице. Лучше учесть и то, что я написал выше.
Если процессор брать только по ядрам, то согласно той таблице
два процессора E5-2650L v4 (14 ядер 1,7 ГГц)
будут примерно равны по производительности четырём E5-2643 v4 (6 ядер, 3.4 ГГц).
А у рабочего места разработчика подходящие процессора вообще описываются целым семейством. От core i3 и выше.
Это же огромный перечень процессоров, у которых разброс по мощности находится в очень широких пределах.
Вот, например i7-4765T. Ай семь! Круто же!
Но конфигуратор с УТшкой 11.3 будет открываться на нём несколько минут.
Если процессор брать только по ядрам, то согласно той таблице
два процессора E5-2650L v4 (14 ядер 1,7 ГГц)
будут примерно равны по производительности четырём E5-2643 v4 (6 ядер, 3.4 ГГц).
А у рабочего места разработчика подходящие процессора вообще описываются целым семейством. От core i3 и выше.
Это же огромный перечень процессоров, у которых разброс по мощности находится в очень широких пределах.
Вот, например i7-4765T. Ай семь! Круто же!
Но конфигуратор с УТшкой 11.3 будет открываться на нём несколько минут.
(5) Эта таблица была похоже составлена еще в 2010-2011 годах, когда процессоры i3 были 1 поколения. Сейчас они уже 7 поколения и при тех же характеристиках, количество ядер, частота, современные в 2-3 раза быстрее. Тоже самое касается Xeon - ов. В этой таблице надо писать ГФлопсы или индексы производительности, а не ядра. А по количеству ОЗУ в принципе актуально.
(1) по хорошему нужно писать нагрузочный тест, всё остальное - это пальцем в небо, либо оборудование будет простаивать (что означает выкинутые деньги), либо оборудования не хватит (что тоже может означать выкинутые деньги). 500 операций в день на 350 чел? Кажется 1.5 операций в день это не много. Но и операции бывают разные - я знаю у некоторых расчет зарплаты по всему заводу несколько часов идет.
Еще как вариант - арендовать железо в ЦОДе например на месяц и поработать.
Еще как вариант - арендовать железо в ЦОДе например на месяц и поработать.
Таблицы серверов, конечно же, есть. Но они довольно условные. И рекомендаций на эту тему море. И противоречий в них тоже много. Ведь, у каждого был свой опыт. Напишу и своё видение. :)
В общем, если достаточно денег, то надо главным образом смотреть частоты процессоров и скорость дисков. Если производительность не упирается в качество кода, то упирается именно в процессоры и диски.
1. По процессорам. За одни и те же деньги лучше больше тактовой частоты, но меньше ядер. Если, например, поставить восьмиядерный процессор на 2 ГГЦ против четырёхъядерного на 4 ГГц, то со вторым система будет работать быстрее.
Опять же, если денег хватает, то лучше вовсе взять два или четыре весьмиядерных процессора по 4 ГГц. Будет хватать и потоков и тактовой частоты.
2. По дискам. Здесь нужно выбирать между надёжностью, производительностью и ценой. Любые два.
Делать массив из бытовых твердотельников производительно, не слишком надёжно и относительно недорого.
Массив из шпиндельных дисков - надёжно, непроизводительно и относительно недорого.
Есть компромисс когда tempdb и журнал транзакций на твердотельниках, а сами данные на шпиндельных дисках. Тоже недорого.
И есть самый лучший на мой взгляд. RAID 50 из энтерпрайзных твердотельников. Дорого, производительно.
Базы и журнал хранить на них.
Надёжность обеспечивается, собственно, избыточностью дисков. Одновременно может выйти из строя два любых диска и данные не потеряются. Да и твердотельники сейчас такие, что надо ещё постараться выработать весь цикл четния-записи.
А ещё у любого хорошего RAID-контроллера есть софтина, которая при соответствующей настройке будет отправлять на почту сообщения если что-то идёт не так.
Резервные копии, естественно, хранить на шпиндельных дисках в другом массиве.
3. Про память. Кашу маслом не испортить, поэтому её можно покупать столько, сколько планок поместится на материнке. Опять же при условии, что по деньгам карт-бланш.
4. Сервер 1С и сервер СУБД лучше не разносить про разным серверам, если это возможно. Северный мост работает быстрее, чем сеть, как ни крути. Да и к тому же, сервер 1С и MSSQL поддерживают Shared Memory.
В общем, если достаточно денег, то надо главным образом смотреть частоты процессоров и скорость дисков. Если производительность не упирается в качество кода, то упирается именно в процессоры и диски.
1. По процессорам. За одни и те же деньги лучше больше тактовой частоты, но меньше ядер. Если, например, поставить восьмиядерный процессор на 2 ГГЦ против четырёхъядерного на 4 ГГц, то со вторым система будет работать быстрее.
Опять же, если денег хватает, то лучше вовсе взять два или четыре весьмиядерных процессора по 4 ГГц. Будет хватать и потоков и тактовой частоты.
2. По дискам. Здесь нужно выбирать между надёжностью, производительностью и ценой. Любые два.
Делать массив из бытовых твердотельников производительно, не слишком надёжно и относительно недорого.
Массив из шпиндельных дисков - надёжно, непроизводительно и относительно недорого.
Есть компромисс когда tempdb и журнал транзакций на твердотельниках, а сами данные на шпиндельных дисках. Тоже недорого.
И есть самый лучший на мой взгляд. RAID 50 из энтерпрайзных твердотельников. Дорого, производительно.
Базы и журнал хранить на них.
Надёжность обеспечивается, собственно, избыточностью дисков. Одновременно может выйти из строя два любых диска и данные не потеряются. Да и твердотельники сейчас такие, что надо ещё постараться выработать весь цикл четния-записи.
А ещё у любого хорошего RAID-контроллера есть софтина, которая при соответствующей настройке будет отправлять на почту сообщения если что-то идёт не так.
Резервные копии, естественно, хранить на шпиндельных дисках в другом массиве.
3. Про память. Кашу маслом не испортить, поэтому её можно покупать столько, сколько планок поместится на материнке. Опять же при условии, что по деньгам карт-бланш.
4. Сервер 1С и сервер СУБД лучше не разносить про разным серверам, если это возможно. Северный мост работает быстрее, чем сеть, как ни крути. Да и к тому же, сервер 1С и MSSQL поддерживают Shared Memory.
(11)Если текущий размер базы 20-30 ГБ и будет расти 5-10 ГБ в год, например, то 256 ГБ оперативной памяти хватит надолго, в том смысле, что СУБД будет работать с комфортом, не елозя по дискам в поисках очередной порции данных и не конкурируя за память с сервером приложений 1С.
Если же база довольно быстро вырастет до 200-350 ГБ(должны же 350 человек что-то делать), то этого размера памяти перестанет хватать так же быстро.
Впрочем, современные серверные материнские платы(двухпроцессорные) поддерживают от одного до двух ТБ оперативной памяти, так что развернуться есть где.
Линейка последних моделей серверных процессоров весьма разнообразна
А "хороший RAID контроллер" для такой задачи - это контроллер с 1-2 ГБ кеша(лучше 2) и батарейкой.
И не надо там 62 ядра, 24-32 хватит более чем, не будут же ваши 350 пользователей, все как один, массово перепроводить документы или формировать отчеты за несколько лет...
Рекомендации в (2) и мои мысли вслух направлены на то, чтобы вы не появились здесь месяца через два-три с темой "Купили новый крутой сервер, а все тормозит, Что делать?"
Если же база довольно быстро вырастет до 200-350 ГБ(должны же 350 человек что-то делать), то этого размера памяти перестанет хватать так же быстро.
Впрочем, современные серверные материнские платы(двухпроцессорные) поддерживают от одного до двух ТБ оперативной памяти, так что развернуться есть где.
Линейка последних моделей серверных процессоров весьма разнообразна
А "хороший RAID контроллер" для такой задачи - это контроллер с 1-2 ГБ кеша(лучше 2) и батарейкой.
И не надо там 62 ядра, 24-32 хватит более чем, не будут же ваши 350 пользователей, все как один, массово перепроводить документы или формировать отчеты за несколько лет...
Рекомендации в (2) и мои мысли вслух направлены на то, чтобы вы не появились здесь месяца через два-три с темой "Купили новый крутой сервер, а все тормозит, Что делать?"
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот