Привет. Нужно собрать максимально производительный сервер для 1с. Сейчас база sql весит 400гб, raid10 4x2Tb HDD 7200rpm (новые), 64Gb DDR3 2xXeon X5650. Производительности не хватает. Развернуть копию базы занимает 4-6 часов. Бекап базы с архивацией занимает 1,5-2 часа. Посмотрел пару тем типа этой, из этого понял, что 1с любит высокую частоту и максимальную пропускную способность памяти (ПСП)
Для начала собрал из того, что было
Xeon 2678v3 12 ядер с разблокированным турбобустом 3.3GHz. 64Gb DDR3 разогнанная до 1866MHz с тюнингом таймингов (ПСП чтение-запись в AIDA64 55000Mb/s)
Под систему поставил 250Gb nvme Samsung 970 EVO
Под базу поставил 500Gb nvme Samsung 970 EVO Plus
Из того, что я увидел копия базы развернулась за 20 минут. Бекап делается за 6 минут. Но одновременно используется всего несколько ядер. Скорость nvme на запись выше 1000Mb/s я не видел. Вот я и думаю, будет ли толк, если поставить к примеру какой-нибудь core i7 с частотой 5GHz
В этом году нужно сделать свертку базы и я понятия не имею, сколько это займет времени. Поэтому нужно максимально ускорить этот процесс. Возможно, придется поставить raid0 из двух nvme, если это удвоит скорость записи
Для начала собрал из того, что было
Xeon 2678v3 12 ядер с разблокированным турбобустом 3.3GHz. 64Gb DDR3 разогнанная до 1866MHz с тюнингом таймингов (ПСП чтение-запись в AIDA64 55000Mb/s)
Под систему поставил 250Gb nvme Samsung 970 EVO
Под базу поставил 500Gb nvme Samsung 970 EVO Plus
Из того, что я увидел копия базы развернулась за 20 минут. Бекап делается за 6 минут. Но одновременно используется всего несколько ядер. Скорость nvme на запись выше 1000Mb/s я не видел. Вот я и думаю, будет ли толк, если поставить к примеру какой-нибудь core i7 с частотой 5GHz
В этом году нужно сделать свертку базы и я понятия не имею, сколько это займет времени. Поэтому нужно максимально ускорить этот процесс. Возможно, придется поставить raid0 из двух nvme, если это удвоит скорость записи
По теме из базы знаний
- Command/com - конфигурация для управления сервером 1С из браузера
- Создание (сканирование) штрих кода товара в документе Поступления для конфигурации 1С:Розница
- Веб-портал "Service Desk Online" для конфигураций 1С:ITIL, 1С:ITILIUM, Управление IT-отделом 8
- Особенности отраслевых конфигураций 1С. На что обратить внимание
- Анализ конфигурации 1С на наличие платформеннозависимого кода
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(8)я прекрасно понимаю, для чего создают RAID10, но диски 7200 rpm - это "для обычных пользователей".
Серверные диски 15к rpm имеют более высокие скоростные показатели.
SSD NVME позволят ускорить все операции, но вот городить из них RAID0 - такое себе.
Серверные диски 15к rpm имеют более высокие скоростные показатели.
SSD NVME позволят ускорить все операции, но вот городить из них RAID0 - такое себе.
А какая цель свертки? Если уменьшить размер базы, то она может даже увеличиться в размерах. Может стоит перенести справочники и регистры сведений в чистую базу и сделать ввод начальных остатков по регистрам накопления
MSSQL vs Postgres
Сейчас база sql весит 400гб, raid10 4x2Tb HDD
вы лучше опишите , на каких дисках ОС
какая СУБД и на каких дисках базы и журналы
не на разделах , а на физических дисках
сколько пользователей
и сколько лет работает база ( желательно конфигурация )
а потом еще вопрос , это на реальном железе или виртуалки ?
Сейчас база sql весит 400гб, raid10 4x2Tb HDD
вы лучше опишите , на каких дисках ОС
какая СУБД и на каких дисках базы и журналы
не на разделах , а на физических дисках
сколько пользователей
и сколько лет работает база ( желательно конфигурация )
а потом еще вопрос , это на реальном железе или виртуалки ?
Из всех наших манипуляций над серверами больше всего производительности добавил интеловский ssd. Точную модель уже не помню, но он сцуко дорогой был. Однако производительность увеличил в разы, примерно раза в 4 на одинаковых операциях. До этого был 10 raid. Игры с памятью и процессорами не давали практически ничего. Памяти было в районе 160 гиг, база весила в скуле 200 гиг, выгрузка в dt весила 40 гиг. Годовой перерасчет себестоимости делался 12 часов, что никак не устраивало, ссдшкой удалось добиться расчета за 3 часа и уже спокойно можно было по ночам делать.
(16) я не отвечал за железо, поэтому точно не могу сказать. Говорил админу у нас все впирается в диск, а он вечно памяти докупал. Ту ссдшку ему поставщик дал на тест драйв и после тест драйва мы её купили.
По софту и юзерам могу сказать. УПП была, до сотни юзеров в онлайне доходило. База была одна единственная и неповторимая.
По софту и юзерам могу сказать. УПП была, до сотни юзеров в онлайне доходило. База была одна единственная и неповторимая.
(20)
когда-нибудь настанет момент узкого места или толстого кошелька
а вот
"всегда и все гружу в одну базу и на один физический сервер"
это не может использоваться к 1с и более 50 пользователей ( + - )
"ибо парить себе мозг с эксплуатацией всей этой бороды я не имею не малейшего желания."
так вы кто - админ, что ли....
когда-нибудь настанет момент узкого места или толстого кошелька
а вот
"всегда и все гружу в одну базу и на один физический сервер"
это не может использоваться к 1с и более 50 пользователей ( + - )
"ибо парить себе мозг с эксплуатацией всей этой бороды я не имею не малейшего желания."
так вы кто - админ, что ли....
(21)
Хотите верьте, хотите нет, но реально сотня пользователей активно работала и даже без конфликтов блокировок. Да, память они отжирали неподетски, почему её и было аж 160 гиг. 60 гиг был фиксированный лимит скулю и сотня пользователям на растерзание. В день порядка 1000 первичных документов плодилось по десятку организаций, все в одной базе - ибо агрохолдинг и нужна консолидация.
А на одном сервере - ну не верю я, что со всем хозяйством будет только админ париться, все равно и мне прилетит подарочков. Базу эту воедино собирал лично из нескольких кривых распределенок, это было то еще адищще разбираться почему слетел десяток документов после обмена (так почти каждый день было). И еще есть соображение, что все таки сервера между собой через ОЗУ обмениваются данными несколько быстрее, чем через сетку. Хотя детальных замеров и не производил, но почему-то так кажется.
Хотите верьте, хотите нет, но реально сотня пользователей активно работала и даже без конфликтов блокировок. Да, память они отжирали неподетски, почему её и было аж 160 гиг. 60 гиг был фиксированный лимит скулю и сотня пользователям на растерзание. В день порядка 1000 первичных документов плодилось по десятку организаций, все в одной базе - ибо агрохолдинг и нужна консолидация.
А на одном сервере - ну не верю я, что со всем хозяйством будет только админ париться, все равно и мне прилетит подарочков. Базу эту воедино собирал лично из нескольких кривых распределенок, это было то еще адищще разбираться почему слетел десяток документов после обмена (так почти каждый день было). И еще есть соображение, что все таки сервера между собой через ОЗУ обмениваются данными несколько быстрее, чем через сетку. Хотя детальных замеров и не производил, но почему-то так кажется.
(25) есть даже для локалхоста два варианта обмена - через сетевой сокет и через общую память (shared memory). Второе на 15-20% быстрее - об этом почти везде написано.
Проблема виртуалки не в том, что она забирает производительность - она не много забирает, даже мало. Там проблема в том, что виртуальные процессоры не умеют так хорошо управлять энергопотреблением своим, как реальные. Фактически теряется возможность всех этих турбобустов мгновенных, также задачи скачут между ядрами, что снижает эффективность использования кеша инструкций и данных первого уровня, а он самый быстрый. В итоге вместь 1-2% съедания в реальности общая производительность под высокой нагрузкой может снизиться и в 2-3 раза, хотя по документам этого быть вроде как не должно, ноосновной драйвер высокой производительности - кеш первого уровня - расходуется на динамическую трансляцию кода виртуальной среды. Поэтому смысл вынести на виртуалку все эти dns, dhcp и прочие сервисы несомненно есть, а вот вытаскивать туда высокопроизводительный кластер - смысла нет.
Проблема виртуалки не в том, что она забирает производительность - она не много забирает, даже мало. Там проблема в том, что виртуальные процессоры не умеют так хорошо управлять энергопотреблением своим, как реальные. Фактически теряется возможность всех этих турбобустов мгновенных, также задачи скачут между ядрами, что снижает эффективность использования кеша инструкций и данных первого уровня, а он самый быстрый. В итоге вместь 1-2% съедания в реальности общая производительность под высокой нагрузкой может снизиться и в 2-3 раза, хотя по документам этого быть вроде как не должно, ноосновной драйвер высокой производительности - кеш первого уровня - расходуется на динамическую трансляцию кода виртуальной среды. Поэтому смысл вынести на виртуалку все эти dns, dhcp и прочие сервисы несомненно есть, а вот вытаскивать туда высокопроизводительный кластер - смысла нет.
у нас УПП, база на raid10 (4xST2000DM008), ssd удаленка ,бекапы и журнал на отдельных десктопных hdd. Пользователей до 30, база растет с 2012 года. Гипервизор Vmware ESX тоже забирает часть производительности ((
сервер 1с - и сервер СУБД на одном сервере
сервер 1с - и сервер СУБД на одном сервере
Начали делать свертку базы, буквально через 5 минут получаем ошибку "Недостаточно памяти". Почитал за ошибку - они типична для файлового варианта базы. У меня настроен клиент-серверный вариант, в свойствах sql по умолчанию установлено "Максимальный размер в МБ" - 2147483647. На локальных дисках свободное пространство больше размера базы. Возможно, проблема в ОС, у меня быстро была настроена работа в Windows 10
Сервер x64 разрядный. Резко заканчивается оперативная память, rphost съедает 63гб , а затем сеанс обрывается. По рекомендациям, нужно выставить значение поля "Максимальный объем памяти рабочих процессов", но его нет в настройках сервера 8.3.17 ((
Возможно, как то выставить его через конфигурационные файлы 1с? В версии 1с сервера 8.3.10 этот параметр хранится в файле 1CV8Clst.lst
Выставил вручную, но этот параметр на ограничение не повлиял. Выставил 12582912000 байт, на скриншоте видно
P.S Кстати, а как начисляется SM за сообщения? Последнее начисление было за сообщение 09.07, хотя после этого уже я написал еще 2 раза
Возможно, как то выставить его через конфигурационные файлы 1с? В версии 1с сервера 8.3.10 этот параметр хранится в файле 1CV8Clst.lst
Выставил вручную, но этот параметр на ограничение не повлиял. Выставил 12582912000 байт, на скриншоте видно
P.S Кстати, а как начисляется SM за сообщения? Последнее начисление было за сообщение 09.07, хотя после этого уже я написал еще 2 раза
Прикрепленные файлы:
(34) Архитектуру вашего чипсета в студию! Смотрите как подключен SSD. Может быть он подключен через южный мост. Может на шине PCIexp весит несколько ресурсоемких устройство или у вас несколько SSD стоит котрые делять пропускную способность шины. Или прерывания.. да дофига чего. из-за того что процессор овердофига гигабит, не значит что на всем пути следования до SSD ширина одинаковая. Может у вас "контроллер SSD тухлый".
(37)
И у вас небось система стоит на SAS или SATA диске на южном мосту. И SWAP-файл чтобы с памятью обменятся гоняет трафик от процессора к SATA (SAS) через загруженную шину от процессора до южного моста! И какая бы шустрая у вас не была память прогнать более 2000 Мб/с не может. А там еще сетевая карта, и другие SATA-диски висят и тоже отжирают пропускную способность. "Пробки " на это трассе с утра и до вечера )
И у вас небось система стоит на SAS или SATA диске на южном мосту. И SWAP-файл чтобы с памятью обменятся гоняет трафик от процессора к SATA (SAS) через загруженную шину от процессора до южного моста! И какая бы шустрая у вас не была память прогнать более 2000 Мб/с не может. А там еще сетевая карта, и другие SATA-диски висят и тоже отжирают пропускную способность. "Пробки " на это трассе с утра и до вечера )
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот