![]() |
1 2 ► |
Информационные технологии
:: Администрирование
|
|
| ||
Mamont_SXI 10.10.16 - 13:35 | Добрый день форумчане!
Собираемся покупать новый сервер под 1С. На нём будет стоять Winwows Server, крутиться SQL и сервер 1С. Объём базы порядка 30 Гб. терминала не будет. Интересует какой брать процессор Е3 или Е5 и в каком количестве (сильно ли измениться производительность) или лучше сделать упор на память? С какими параметрами сервера 1С работает быстрее(Режим распределения нагрузки - приоритет по производительности или о памяти) | ||
Волшебник Модератор 1 - 10.10.16 - 13:37 | упор на диски | ||
Mamont_SXI 3 - 10.10.16 - 13:39 | (1) предлагаешь использовать ssd? | ||
Cyberhawk 4 - 10.10.16 - 13:44 | "терминала не будет. " // Т.е. работать в конфигураторе с этой базой будут с клиентских машин? | ||
Boleev 5 - 10.10.16 - 13:45 | |||
zak555 6 - 10.10.16 - 13:48 | что за конфа ? | ||
Mamont_SXI 7 - 10.10.16 - 13:54 | (4) да, только с клиентских | ||
Mamont_SXI 8 - 10.10.16 - 13:55 | (6) ут 11.2 | ||
Волшебник Модератор 9 - 10.10.16 - 13:57 | (3) SSD надо использовать правильно. Главное, оставляй резерв свободного места 70%. Минимум нужно 50% свободного места, но у вас база вырастет же, значит диск должен быть 128 Гб. И надо следить за износом ячеек. Так что лучше сразу взять 240 Гб, чтобы раньше времени не крякнулся. | ||
MrStomak 10 - 10.10.16 - 13:59 | |||
H A D G E H O G s 11 - 10.10.16 - 14:00 | raid ssd под данные
дешевый отдельный ssd под лог+tempdb+tmp 1C HDD под бэкапы, систему и образ системы 32 гига оперативки Intel на вкус и оставшиеся средства. | ||
H A D G E H O G s 12 - 10.10.16 - 14:02 | (10) "Чем обосновывается упор на диски?"
Правильными алгоритмами, которые не заставят SQL елозить по данным в памяти, дикими nestedloop-ами. | ||
MrStomak 13 - 10.10.16 - 14:03 | (12) Это не обоснование "упора на диски" | ||
arsik 14 - 10.10.16 - 14:03 | (0) Я обычно вот тут обсуждаю серрвера для 1С.http://3nity.ru/viewforum.php?f=40&sid=712a01d6793df41243eb8b3349f9088f
Не реклама. Нормально ребята помогают. | ||
oleg_km 15 - 10.10.16 - 14:04 | |||
Fragster 16 - 10.10.16 - 14:06 | проще под темпы и сеансовые данные сделать рэмбрайв на 8-16 ГБ (это для 1с), а базу на нормальный sas. Это будет не сильно медленнее SSD, но зато места намного больше. не будет проблем развернуть рядом еще пару-тройку копий баз | ||
MrStomak 17 - 10.10.16 - 14:07 | (11)
Ага, прекрасно. Например, Intel® Xeon® Processor E3-1258L v4 с базовой тактовой частотой 1.8Ghz прекрасно подойдёт, да? | ||
MrStomak 18 - 10.10.16 - 14:07 | (16) +100500 | ||
Midaw 19 - 10.10.16 - 14:07 | (16) если уже ВР про SSD на сервере говорит, то это уже грех не использовать их ))) | ||
Волшебник Модератор 20 - 10.10.16 - 14:09 | (10) Ни процессор, ни память обычно не являются узкими местами для работы с 1С. | ||
Cyberhawk 21 - 10.10.16 - 14:14 | (12) А к чему тут сказано про упоминание о памяти? Чтобы не елозить в памяти, нужно не елозить в данных, которые в эту память попадают с диска. | ||
H A D G E H O G s 22 - 10.10.16 - 14:19 | (16) Копию развернете на HDD. | ||
H A D G E H O G s 23 - 10.10.16 - 14:20 | |||
H A D G E H O G s 24 - 10.10.16 - 14:20 | (17) Откуда столько негатива? | ||
Дарлок 25 - 10.10.16 - 14:28 | (24) продажники "инсталляторв" будут впаривать другое, еще потом до кучи и 5E raid настроят.
Это если конечно техника брендовая | ||
Cyberhawk 26 - 10.10.16 - 14:28 | |||
Cyberhawk 27 - 10.10.16 - 14:30 | |||
Дарлок 28 - 10.10.16 - 14:35 | (27) сколько сейчас предел по объему ОЗУ? | ||
PR 29 - 10.10.16 - 14:37 | (20) Процессор еще как является | ||
MrStomak 30 - 10.10.16 - 14:37 | (24)
На мой взгляд, есть тенденция к переоценке преимуществ ssd в задачах работы с базами данных. Понятно, что Windows на ssd грузится в 10 раз быстрее, скорость чтения случайных данных у него прекрасная. Однако, для задач СУБД всё же активно используется кэш MS SQL(для чтения) и кэш raid-контроллера(для записи). Это во многом снижает преимущества ssd по скорости работы с базой данных. Одновременно с этим есть тенденция к недооценке значимости производительности процессора и памяти в современных конфах вроде УТ11 и ERP. Лично мне так видится, что делать упор на ssd не стоит, вместо этого лучше собрать raid10 на быстрых sas (который обеспечит заведомо более низкую стоимость гигабайта), а на сэкономленные средства взять более быстрый проц, дабы перелопачивать кучу данных в памяти (в том числе, лопатить кэш SQL), сериализовать огромные таблицы, которые постоянно передаются в УТ11/ERP, производить быструю инициализацию фоновых заданий и кучу всего, что кладет медленные процы в раз. Рекламное место пустует | ||
Дарлок 31 - 10.10.16 - 14:39 | (30) как соберешь, скрины счетчиков производительности выкладывай... заценим | ||
Чихуахуа 32 - 10.10.16 - 14:41 | (30) Чувак, ты забыл самое главное - нужно два рэйда, один для ОСи, другой для базы. Скуль очень не любит когда винда веник дергает. | ||
MrStomak 33 - 10.10.16 - 14:42 | (31) Разрешите бегом??! | ||
Fragster 34 - 10.10.16 - 14:42 | (20) вот эта штука как правило упирается в проц + латентность сети между скулем и 1с сервером:
http://fragster.ru/perfomanceTest/ | ||
Cyberhawk 35 - 10.10.16 - 14:43 | (28) Штатно в 8.2 вроде 80% от установленного объема на ОС хоста | ||
Cyberhawk 36 - 10.10.16 - 14:43 | *в 8.3 | ||
Дарлок 37 - 10.10.16 - 14:45 | |||
Evgueni 38 - 10.10.16 - 14:46 | (30) У меня форточки на SSD, а скуль на рейде. В данный момент экспериментирую tempdb. Перенёс темпы с рейда на SSD, похоже что только хуже стало. | ||
Дарлок 39 - 10.10.16 - 14:46 | (34) оно не напрямую отдельными сетевухами подключено? | ||
Cyberhawk 40 - 10.10.16 - 14:49 | (37) А, ясно. Сколько физически хз, вроде за последние лет 5 ни разу не видел серверов 32б | ||
Jump 41 - 10.10.16 - 14:53 | (30) Если SQL так оно и есть.
Справятся обычные HDD, главное не грузить их ничем кроме БД. Если пользователи непосредственно на нем работать не будут - то можно обойтись и без SSD. | ||
Дарлок 42 - 10.10.16 - 14:55 | (40) если базы уйдут в RAM, то будет пофиг на дисковую, что логично. | ||
Cyberhawk 43 - 10.10.16 - 14:56 | |||
H A D G E H O G s 44 - 10.10.16 - 14:56 | |||
Jump 45 - 10.10.16 - 14:57 | (38) tempdb это активная запись.
Необходимо чтобы работал TRIM и было много свободного места. Если проблемы с TRIM, например диски в рэйде или еще чего - то обязательно оставлять резерв неразмеченный опять же в достаточных масштабах. Иначе закономердая деградация скорости записи до очень плачевных цифр. | ||
Дарлок 46 - 10.10.16 - 14:58 | (43) если базы большие в месяца по 10гб роста, то RAM рано или поздно закончится, и скорее это будет рано | ||
MrStomak 47 - 10.10.16 - 14:59 | (44) То есть можно смело брать 1.8Ghz, да? | ||
Дарлок 48 - 10.10.16 - 15:00 | |||
Jump 49 - 10.10.16 - 15:01 | Если говорить о SQL то там особых требований к дискам нет кроме скорости.
Т.е диск тупо должен уметь быстро читать/писать. Режим чтения/записи близок к линейному. SQL основную работу ведет в памяти и практически не делает случайных выборок с диска. | ||
MrStomak 50 - 10.10.16 - 15:01 | (49)
+1 | ||
Cyberhawk 51 - 10.10.16 - 15:02 | (47) Я б не рекомендовал. На сходных ПК с Вин7 / Вин 8.1 с одинаковыми дисками и объемом ОЗУ у меня типовые демобазы УТ / БП шустро работают на i7, а на втором железе с i5 уже медленнее. | ||
MaxS 52 - 10.10.16 - 15:02 | Бывают же гибридные контроллеры - SSD для кэша и HDD для остального.
Может быть существуют контроллеры с RAM + SSD + HDD | ||
Cyberhawk 53 - 10.10.16 - 15:02 | |||
Cyberhawk 54 - 10.10.16 - 15:03 | (46) Ну закончится. И что? Как это объясняет, что для скуля надо "делать упор на диски"? | ||
Jump 55 - 10.10.16 - 15:04 | |||
Дарлок 56 - 10.10.16 - 15:04 | (54) очередь к диску начинает расти | ||
H A D G E H O G s 57 - 10.10.16 - 15:05 | (47) Надо убрать снобизм и почитать статью. | ||
Fragster 58 - 10.10.16 - 15:06 | (39) даже напрямую отдельными сетевухами задержки зависят от множества факторов | ||
MrStomak 59 - 10.10.16 - 15:06 | (51)
Вот и у меня такие наблюдения. Наблюдал вот именно УТ11 на xeon с 1.8Ghz. Никакие ссд не помогали - оно вообще не шевелилось. | ||
Дарлок 60 - 10.10.16 - 15:07 | (58) масштабируемость недостижима? Рекламное место пустует | ||
H A D G E H O G s 61 - 10.10.16 - 15:09 | (53) Это был сарказм. | ||
H A D G E H O G s 62 - 10.10.16 - 15:11 | Мне вот интересно, столько тысяч страниц индексов и данных обновляется при проведении средненького РТУ в УТ11.2 и в каких местах диска они расположены? | ||
Jump 63 - 10.10.16 - 15:14 | (56) Очередь не будет расти - там ближе к линейке запись и чтение.
А очередь активно растет когда куча конкурентных запросов, либо работа с мелкими блоками. | ||
Jump 64 - 10.10.16 - 15:16 | Под скуль и сервер 1с надо процессор как можно шустрей.
Памяти - чем больше тем лучше. А диски - они должны быть, особых требований нет. Ну если не рассматривать ситуации когда у вас на одном диске или массиве и база и ОС. Тогда да, будут проблемы с дисками. | ||
MrStomak 65 - 10.10.16 - 15:16 | |||
XMMS 66 - 10.10.16 - 15:22 | Изучал тему, довольно много ссылок в том числе и от Гилева, которые подтверждают большую роль частоты процессора.
Пруф: http://www.gilev.ru/bestproc1c/ В Тринити, к слову, с этим не согласились и предлагали процессоры многоядерные и слабые. Но Гилеву + (34) я верю больше. | ||
MrStomak 67 - 10.10.16 - 15:26 | (66) Спасибо за линк, познавательный.
Автору топика, на мой взгляд, следует учесть важный вывод статьи, с которым я полностью согласен: "Могу утверждать, что в среднем при покупке сервере стоимость процессора составляет где то 10% от всего сервера, а вот вклад в общую производительность может достигать 50%. Поэтому если придерживаться принципа парето, экономить на процессоре — это самая большая ошибка имхо." | ||
Дарлок 68 - 10.10.16 - 15:28 | (63) дык... типичная нагрузка при 100+ пользователей, не? | ||
Garykom 69 - 10.10.16 - 15:31 | Выкинуть из конфиги покупку MS Windows и MS SQL взамен linux+postgres и взамен улучшить железо. | ||
H A D G E H O G s 70 - 10.10.16 - 15:37 | (69) самый фееричный совет, который может быть. | ||
Jump 71 - 10.10.16 - 15:38 | (68) Если скуль то нет.
Смысл скуля как раз и есть в том чтобы оптимизировать работу. Линейное чтение большого куска данных - активная работа с ним в памяти, и запись большого куска данных. | ||
H A D G E H O G s 72 - 10.10.16 - 15:38 | (65) Нет, не значит, что нужно бежать и покупать 1.8 ГГЦ. Это значит, что не стоит гнаться за последним поколением, и, возможно за I7 | ||
MrStomak 73 - 10.10.16 - 15:39 | (68) 100+ пользователей работают, как правило, с несколькими фиксированными областями данных, которые помещаются в кэш SQL
То, что было полтора года назад, никто уже не использует. Эти данные вообще иногда выделяют и выкидывают на отдельный диск, дабы не мешали. | ||
Дарлок 74 - 10.10.16 - 15:46 | (73)
>>Эти данные вообще иногда выделяют и выкидывают на отдельный диск, дабы не мешали. мы сейчас про 1С говорим? там появилось архивирование данных? >>100+ пользователей работают, как правило, с несколькими фиксированными областями данных, которые помещаются в кэш SQL 1C-ки часто умудряются запускать фулскан по таблице (71) для баз от 500gb статистика такая же? | ||
MrStomak 75 - 10.10.16 - 15:46 | (72)
Согласен. Просто обрати внимание, это не вполне соответствует сказанному тобой "Intel на вкус и оставшиеся средства". Вот поэтому указанную рекомендацию считаю вредной. | ||
H A D G E H O G s 76 - 10.10.16 - 15:48 | (71) ACID говорит, что ты не прав. | ||
Дарлок 77 - 10.10.16 - 15:50 | (76) мне кажется это должно зависеть от соотношения RAM и размера базы. У тебя базы по сколько весят? | ||
MrStomak 78 - 10.10.16 - 15:53 | (74)
>>там появилось архивирование данных? секционирование таблиц MS SQL https://msdn.microsoft.com/ru-ru/library/ms190787.aspx >>1C-ки часто умудряются запускать фулскан по таблице 1с-ки могут и на сервере две таблицы по 100к строк в памяти соединять. Если стоит задача сделать что-то узким местом - это кодится очень быстро. | ||
H A D G E H O G s 79 - 10.10.16 - 15:54 | (77) Я вам не корпорация. У меня нет баз. | ||
H A D G E H O G s 80 - 10.10.16 - 15:56 | (77) Буковка D в слове ACID говорит, что после Commit транзакции, даже если сервер падет, после его перезапуска, эта транзакция никуда не денется. | ||
MrStomak 81 - 10.10.16 - 15:56 | (76) ACID обеспечивается батарейкой в raid-контроллере.
А если у тебя тру-хайлоад система и условных 64Мбайт кэша не хватает, то используется массив SSD для буферизации записи в рэйд из SAS дисков. | ||
Jump 82 - 10.10.16 - 15:57 | (74) Дело не только в размере.
Дело в том влазят ли в память все данные с которыми активно работают или нет. Если не влазят - начинается активная работа с диском, и тормоза. Тут даже SSD не спасет. | ||
H A D G E H O G s 83 - 10.10.16 - 15:58 | (81) ACID был контраргументом к фразе "Линейное чтение большого куска данных - активная работа с ним в памяти, и запись большого куска данных." | ||
H A D G E H O G s 84 - 10.10.16 - 16:00 | (83) Грубо говоря - sql пофиг, че у вас там за оборудование, он сбросит данные на диск при commit-е транзакции. | ||
Jump 85 - 10.10.16 - 16:00 | (83) И в чем конкретно проблема касательно ACID? | ||
Дарлок 86 - 10.10.16 - 16:00 | |||
Fragster 87 - 10.10.16 - 16:01 | (60) ну, сотни юзеров на типовых - достижимы. тысячи юзеров на самописках - также достижимы. десятки тысяч - с более менее развернутым функционалом - с трудом. | ||
Jump 88 - 10.10.16 - 16:03 | (86) Загони в базу мильен картинок - у тебя будет офигенно большая база.
А реально данных с которыми работают - копейки. | ||
Дарлок 89 - 10.10.16 - 16:04 | |||
Jump 90 - 10.10.16 - 16:04 | (87) Ну так нефиг линейно масштабировать.
Разделяй и властвуй. | ||
Jump 91 - 10.10.16 - 16:05 | (89) Ты не поверишь, чего только там не хранят. | ||
Дарлок 92 - 10.10.16 - 16:07 | (90) ога....
- для чего внедряли ERP? - для того, что бы данные были в одной базе... так сказать единое информационное пространство... - а зачем разделили на разные серверы? - тормозило-сЪ | ||
ptiz 93 - 10.10.16 - 16:18 | К вопросу о бесполезности SSD.
Когда сидели на RAID-10 из 8 дисков, база (400гб) помирала в то время когда батарейка "обучалась", юзеры курили. Перешли на SSD - очередь в диску исчезла вообще. | ||
Fragster 94 - 10.10.16 - 16:20 | (89) сотни на 7.7 без приблуд? только в терминале и то, она загибалась на блокировках еще на 20-30 юзерах. прямые запросы и всяческие ухищрения позволяли поднять этот предел, но у людей висел либо вылет по блокировкам при таймауте 0, либо приблуда для вставки таймаута в сервера.
на технологии гибких блокировок можно было сотню пустить, но это уже совершенно другие (относительно снеговика) вложения в разработку и обслуживание. Да и функционал типовых намного беднее. | ||
MrStomak 95 - 10.10.16 - 16:21 | (84) Вообще говоря, нет.
SQL поддерживает протокол опережающей записи. Т.е. все модификации базы пишутся линейно в транзакционный журнал, после этого данные меняются в кэше, и только потом - сбрасываются на диск. До сброса данных на диск уже снимается блокировка и происходит Commit, т.е. commit не обязательно завязан на физическую запись именно в таблицы базы данных. Если вдруг происходит сбой, то СУБД определяет транзакции, которые не успели сбросится на диск, и делает Redo. https://technet.microsoft.com/en-us/library/cc966500.aspx | ||
Jump 96 - 10.10.16 - 16:22 | (93) Файловая? | ||
Дарлок 97 - 10.10.16 - 16:23 | (94) там база была забавная. Основа торговля 7.0. Регистры не закрытые, да и вообще они по минимуму использовались. Но база жила без доп. приблуд. Сам вспоминаю и удивляюсь. Активных от 80 до 100 юзверей было. | ||
Fragster 98 - 10.10.16 - 16:23 | (93) не обучалась, а умирала. и выключался кэш записи. у нормальных админов такого не происходит. | ||
Alexor 99 - 10.10.16 - 16:31 | (94) 180 пользователей Комплексная в DBF без приблуд. Размер базы за 16 гигов.
Транзакции бывают, но жить можно. | ||
Fragster 100 - 10.10.16 - 16:33 | (99) а сколько номенклатуры и сколько документов в день эти 180 пользователей вводят? сколько отчетов делают? |
1 2 ► |
Список тем форума
|