Купили админы себе лялю: cisco ucs hx220c бла-бла-бла, за сколько не спрашивайте - мля, имхо неадекватно дорого, причем лезвий ещё можно докупить... предлагают нерезать виртуалок и переехать с железных серверов на виртуальные.... Как-то смущает, что больше 16 ядер на каждый кусок нарезки предоставить не хотят как-то забавно это обосновывая (нифига не канает на обоснование, имхо... хотя возможно это ограничение ихней игрушки, но не хотят признаваться).
1с 8.3.8.2197 и понижаться не будет.
Есть смысл перенести туда что-то (1с(win), ms-sql(win) или может postgre(разумеется под пигвинчиком))?

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

(0) При прямых руках админов виртуалка прекрасно живет. УПП, база почти террабайт, 800 пользователей. И сервер 1С, и скуль - виртуалки. Нормально работает

проголосую ....


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

Я за этот вариант

(0) сформируйте тестовую зону, сэмулируйте нагрузку (у Fragster'а, вроде, какой-то попугаёметр, например, есть), посмотрите, что будет.
Пока это гадание на кофейной гуще в условиях, когда даже кофе ни кто не заварил

(43) А можно в двух словах про прямые руки админов?
Ну или хотя бы где не должно быть кривизны?
Я сам не админ, но эта тема очень интересует.

Нересурсотребовательные переместить на виртуалку, 1С-у нужно много iops диска - его по возможности поставить на железо.
Сам в одно лицо жил на виртуалке на 2-х "серверах". Поставил SSD и начал экспериментировать. Железный оказался быстрее. Перенёс все виртуалки на старенький комп, самый быстрый сделал "железным".
Возможно у меня как у админа уже не прямые руки, но время деньги.

(43) Поднимите на этом же железном хосте виртуалки с терминалом под ваши 800 пользователей и у вас ляжет любое дисковое хранилище. :) :) :)
SQL и Сервер 1С создают вполне прогнозируемую и управляемую нагрузку на хранилище. А вот терминал...

(49) Да? Пробовал? Из 800 пользователей 500 - терминальные, на том же дисковом массиве, но в других виртуалках

(0) Немного юмора в тему: https://www.anekdot.ru/id/-32016009/
>>Купили админы себе лялю: cisco ucs hx220c бла-бла-бла
Прямо навеяло :)...

Во! Вспомнил! Тестами от Гилёва пробовали 1Ц в виртуалке и на железе. Разница получилась более чем в 2 раза

(0) >> нерезать виртуалок и переехать с железных серверов на виртуальные

Зачем?
Этот вопрос вообще никого не интересует?
Все так активно бросились обсуждать достоинства и недостатки виртуальных машин, что забыли о такой мелочи, как банальное обоснование необходимости переезда на виртуалки.
С точки зрения 1С обосновать такую необходимость весьма сложно. Кроме каких-то невнятных пространных рассуждений админов о чисто гипотетических возможностях быстро поднять копию сервера. И еще - о балансировке нагрузки, которая 1С-у в реальной жизни нафиг не нужна, не говоря о возможных проблемах со слетанием программных лицензий при баловстве с размером выделенной серверу памяти.

Получить стопку проблем ради того, чтобы потешить эго админов, - какое-то сомнительное удовольствие.

PS Когда-то проводили эксперимент, понаслушавшись админских сказок. Кроме проседания по производительности и танцев с прокидыванием портов для ключей защиты, ничего не получили. Сейчас всё на физических серверах.

(53) Да причина похоже проста. Купили дорогую железку, но всю под 1С ее отдать не хотят - слишком жирно, да и не съест 1С всех ее ресурсов. Пытаются оптимизировать.

(52) А тесты давно были,по моему тогда 8.3 только начиналась

(54) наоборот. Железка дорогая и надо оправдать ее наличие. Потому хотят всунуть все в нее всю 1С, а то.,что было до сих пор отобрать на другие нужные фирме цели.

(54) (56) Как-то странно, сначала купили железяку, потом оправдываем ее покупку...

(57) Вполне обычная ситуация.

(57) Обычная практика. Особенно в конторах с большим бюджетом на ИТ.
Собственно говоря выгода для админов несомненно есть. Им гораздо проще обслуживать одну стойку с кучей виртуалок, чем кучу физических серверов. Плюс всяческие плюшки по балансировке ресурсов (там где это реально надо) и возможности по быстрому развёртыванию виртуальных машин.
Только применительно к 1С всё это, как собаке пятая нога.

(55) В ноябре и декабре того года. А что?

(59) >> Особенно в конторах с большим бюджетом на ИТ.
Не соглашусь. В некоторых конторах большой бюджет тратят на мелкие сервера. Их обслуживать гораздо удобней и рисков меньше по поводу всяких остановок. Один большой сервант если остановится, то встанет всё. и нафиг такое счастье?

(60) Такую железку еще надо суметь остановить.

(61) Хочешь сказать, что чем дороже сервак, тем он более надёжен? Ха 3 раза. Сервак за 1,5 млн наш админ в сумке возил в Мск из Красноярска, т.к. сервисный центр есть только там. И это через 2 месяца после покупки. При этом в сервисном центре дождался ответа от производителя, что покупайте другой, т.к. этот старый слишком. А вот с НР-шками за 150-250 тыс никаких проблем не было вообще.

(57) Обычное дело. Руководство в этом вопросе не разбирается. А админам лишь бы в железе повозиться.

у меня сейчас вполне приличная железка, поднимать на ней виртуалку - не дал... крутится сервер 1с+SQL по моим прикидкам железка сейчас используется примерно на 25%

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

старый сервак вообще под чистую разработку и тестирование забрал.

Сейчас все довольны, даже удаленные проекты затягиваем к нам на сервер :) и НИКТО не заикается про "деньги на ветер"

хотя пол года назад был кошмар... все тупило, денег жалели и т.д.


как говорится - все познается в сравнении!

(64) А какой sql, если не секрет?

(0) Во многих конторах много лет на виртуалках - никаких проблем. Если админы все правильно сконфигурировали, то нормально работает.

Относительно 16 ядер - бред какой-то. На кой ляд Вам больше 16 ядер для 1С?

(62) Да, более надежен. И похрен что Вам админ куда возил. Их комплектуют с учетом совместимости железа, тестируют. Это промышленный продукт, а не собранный из .овна и палок на коленке криворукими админами. Если Вы считаете, что брендовые серверы совсем не ломаются - это не так. Ломается все. Но проблем с ними на порядок меньше, чем с "самопалом".

(60) Тестил года 2-3 назад и "в разы" не заметил.гилевскими

Основная проблема всего - это то, что народ не понимает, что если мы хотим оптимальной одновременной работы 50 пользователей - нам нужно 50 ядер процессора (при условии годной дисковой системы). Ровно столько и немного больше.
Но одновременно 50 пользователей не работает и 50 ядер никогда загружены не будут. Будет момент, когда и 16 ядер загружены не будут. И 2.
Как только появляется виртуалка - у админа появляется соблазн оптимизировать неиспользуемые (с его точки зрения) процессоры. И поставить отдельную виртуалку, например под сервер терминалов. Чебынет?!

(66) Хренасе. А че бы нет? Одно обращение пользователя занимает 1 ядро проца. Сначало идет десериализация на сервере 1С, потом запрос SQL, обработка запроса на сервере 1С, сериализация ответа. Все эти действия занимают ровно 1 ядро (при Max_Dop=1).

так виртуалки можно делать без динамического распределения ресурсов

(69) "если мы хотим оптимальной одновременной работы 50 пользователей - нам нужно 50 ядер процессора" - А если у тебя 300 пользователей, то надо 300 ядер? :)

(71) Тебя часто пускают к физическим серверам?

(72) Было бы неплохо.

(74) Понятно, что было бы неплохо. Но кто же позволит столько серверов закупить?

Вывод: если убл..чные админы, то лучше физ сервера

(69) > если мы хотим оптимальной одновременной работы 50 пользователей - нам нужно 50 ядер процессора

Что за ересь?

(77) Нормальная такая ересь, когда у тебя есть RAID из SSD на PCI-E а не унылые SAS и ожидания на блокировках минимальны.

Единственное, со словами "оптимальной" я погорячился. Максимально комфортной, скажем так.

(78) Какое отношение ядро на рыло имеет к RAID?

(79) Проц же станет узким местом

Имею отрицательный опыт с виртуалкой... 1С Бух 2.0, 16 пользователей, периодически повисала на пару минут то у одного, то у другого, пользователи жаловались. Сильно вникать не стал, сисадмину приказали грохнуть виртуалку. На тот же сервер поставили просто в файловом режиме сначала - все забегало

(80) Голое теоретизирование или в основе этой ереси какие-то исследования есть?

(82) Личный опыт

> Откуда, блеать, тяга эта к виртуалкам и терминалкам, в том месте, где ее быть не должно.

обслуживание упрощается на порядок, внушительная экономия ресурсов -- более чем увесистые аргументы.
Другое дело что далеко не каждый админ умеет правильно настраивать и управлять виртуалками под скуль+1С. Товарищи из (0) либо не сталкивались, либо решили накатить а там если чо на эсника свалим.

(83) Т.е. субъективные ощущения?

(69) Как-то анализировали загрузку сервера терминалов и пришли к следующему выводу: количество пользователей в терминале нужно рассчитывать исходя из характера работы пользователей. Мы выделили два таких характера: первый назовем его "оператор" - занимается только вводом информации. Требуемые ресурсы минимальны. Таких пользователей можно сажать до 4х на одно ядро (а можно и больше, тут уже нужно смотреть на конкретной программе). Второй, назовем его "аналитик" занят исключительно отчетами. Такому пользователю в идеале нужно целое ядро. Но так как пользователь не постоянно формирует отчеты, а есть какое-то время, когда он просматривает, анализирует и принимает какие-то решения (короче, не грузит комп), то таких сотрудников можно садить два на одно ядро.  Т.е. допустим, у нас есть 4х ядерный сервак. На него можно воткнуть 16 операторов, либо 8 аналитиков.

(84) ну так 95% "админов" и не умеют их ставить и настравивать отсюда и мнение

(87) здесь самое время запостить гайд :)

Могу поделиться своим печальным опытом.
Компания, где я работаю, входит в один крупный междынародный холдинг. Соостветственно всей сетевой и серверной архитектурой рулят товарищи из капиталистического зарубежья. Под их управлением сервера и сети в десятках компаний по всему миру, SAP на тысячи пользователей и тыды, так что подозревать в криворукости вроде их вроде как не стоит. И наконец дошли у них руки и до нас.
Купили мега сервера (по словам наших админов ооочень крутые), поставили туда виртуалку (не для оптимизации серверных ресурсов, а потому что им управлять ими удобнее), переселили сервер 1С и SQL туда. Вроде как на сервере стояла только 1 виртуалка. Производительность провисла драматически. Неделю пытались что-то сделать, не выходит каменный цветок. На физическом, пусть и значтельно более слабом сервере, 1С значительно быстрее.
Вернули нам 1с на физический сервер.
Часть народу работает в терминальном режиме. И этот терминальный сервер тоже забабахали виртуальном. Имеем ситуацию, что пока там 1-2 человека вроде пашет. 3 и более начинает тормозить. Бьемся, чтобы и терминальнык вернули взад и развиртуализировали). А главное, что даже в момент конкретнейших тормозов на виртуальных машинах, все мониторы серверные (как на виртуалке, так и на физическом) показывают простой оборудования

(89) криворукие. Терминальный вообще сложно виртуализировать так чтобы сильно медленнее физики было.

(90) Для всего остального корпоративного софта пряморукие, а только для 1С криворукие?) Может это 1С как-то странно написана?

(91) а какое другое корпоративное? И к примеру вижу, что тормоза в 1С при запуске клиента и тормоза в MS Office тоже при старте - одинаковы

(91) Ага. Таким особым, неведомым кодом.

Когда я сталкиваюсь с тормозами на сверхсовременном сервере - я первым делом запускаю CPUZ и все становится на свои места. Как правило - это режим экономии энергии, который дикий по своей природе к редконагружаемому ПО (1С - это оно и есть).

Вторым делом я запускаю CrystalDiskMark, но это редко.

(92) SAP, MS SQL, офис, инженерный софт, да масса всего. Корпорация производящая и торгующая промышленным оборудованием по всему миру имеет большой набор софта.
(93) Я честно говоря не знаю, я очень далек от серверных вещей, могу озвучивать только результаты.
(94) Экономия энергия стояла по началу. Но это первое что прибили, в попытках заставить работать 1с на виртуалке.

Дикость экономии энергии неочевидна, но коварна и зловеща.
На всяких программах рендеринга, там где проц работает от и до она не проявится. Она проявится непостоянно нагруженных ПО. Ядро проца выходит из спячки (когда у него производительность в 3 раза меньше максимума) постепенно и выйдет из нее он уже тогда, когда это будет не нужно. И снова в спячку. А нам запрос пользователя надо выполнить здесь и сейчас.

(91) здесь не надо декомпилировать 1С, здесь достаточно владеть инструментами мониторинга нагрузки, и сразу все узкие места нашлись бы, дальше бы сообразили. Даже без этих ваших мистару.

(95) Вы ее не прибили. Было такое, макс производительность стояла на вирт. машине, на физ. машине и в настройках виртуалки. CPUZ показывал спячку. Потом админы заказчика посмотрели на мои скриншоты CPUZ, что-то пошаманили и проц в спячку уходить перестал и все взлетело.

(95) Скачай CPUZ, запусти бенчмарк и посмотри, поднимается ли производительность ядра с 500-600 до 1500 попугаев или стабильна.

(100)

(0) Виртуальные машины имеют и свои плюсы и свои минусы.

Многое зависит от организационной структуры компании.
Например "крупный международный холдинг" когда одинэсники сидят в Москве а айтишники в Бангалоре, причём до начальства которое может и одинэсникам и айтишникам приказывать и от Москвы и от Бангалора около десяти тысяч километров и на родном языке начальства нормально не говорят ни айтишники ни одинэсники для внедрения 1С на виртуалках подходит плохо.

Проблемы производительности 1С на виртуальной машине можно решить. Но есть ситуации их проще не решать.

У 1С специфические требования к железу, которые желательно учитывать до покупки железа а не после.

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

(98) а ты не знаешь где что нужно подкручивать, чтоб отключить?

(103) Для начала в биосе, потом в хостовой, а потом уже в гостевой

(67) >> Их комплектуют с учетом совместимости железа, тестируют
А хьюлеты за цену в 150-250 тыс думаешь не так комплектуют????? Ты не ошибаешься????

"У 1С специфические требования к железу,"

интересно узнать, в чем их специфика

(101) Каша какая-то.
Какие Бангалор, какая Москва, каким боком это вообще к теме ветки?
Ты походу на какой-то своей волне...

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

А вот если отбросить пустословие, типа "криворукий", то поставив всё в виртуалке, а потом на голом железе получим, что виртуалка медленнее. Мне кажется виртуалка будет быстрее железа только если надо поднять 14 сайтов, DNS и прочую фигню на одном сервере, которые все разом пытаются что-то монополизировать.
Ещё камень в концепцию с виртуалкой в том, что один большой сервер если ломается, то останавливается всё. Тогда как много мелких железных серверов гораздо более надёжны из-за кол-ва

"много мелких железных серверов"

Еще и более быстры, но как ты этого добьешься в 1С?

(110) В кластеры их все и нормально. 1Сина раскидывает пользователей по серверам. Вот MS SQL-ю больше понравился один большой сервер, но тоже без виртуалки.

Идеально клиентские сеансы можно загонять в виртуалку. Серверверные на физику.

Тут нужно оговорится, если база небольшая но это редко бывает, кто балуется виртуалками при малой базе. Если база большая можно позволить виртуалку, но только при многих условиях, основное бутылочное горлышко даже не память, а чтение запись винта. Т.е. нужно запретить ограничение скорости винта на виртуалках, даже при простое. На самом sql установить минимальные квоты памяти, чтобы не освобождалась эта память в принципе. Ну а в целом, как работают даже самые умные админы, вы можете посмотреть на всех облаках на 1с, они режут винт на всех клиентов, такого не должно быть, клиентов не должно быть большое количество на одной машине, т.е. одна физика делается для балансировщика, АД, и SQL и Сервера 1с предприятия, больше туда никого не сажаем.

(112) А ну еще в добавок памяти у скл в идеале должно быть примерно как размер базы, конечно 200гб  не вытащишь, памяти но если база 60гб еще можно, что то придумать, Есть еще балансировщик sql где можно на пару серверов распределить нагрузку. Средствами sql, для 7.7 такое делал для 8 не пробовал ни разу, но должно работать. Естественно если мы делаем распределение нагрузок sql сервера между серверами кладем оптику гигабитную. Физическими, и на физические сервера где сервер скл и сервер 1с никого не пускаем. Из тех кто может создать нагрузку

(111) Синхронизация сеансовых данных постучит к тебе пушным зверьком.

(113) А что, ms sql можно распределять на несколько машин?

(114) не стучало. Много лет не стучало. Пользователи работали как ужаленные, 1Сники пытались раком ставить сервера, проблем с данными не было.

базы можно реплицировать на несколько машин, там сервис выбирает куда оптравлять запрос на а или на б, с 7.7 эта штука проходила. Могу погуглить щас уже не помню, как это точно называется, А данные между базами сам sql синхронизирует при каждой транзакции

Недавние страдания Сравнение производительности VMware ESX и физического сервера для 1С
(113) >>  конечно 200гб  не вытащишь
Обычные серверные материнские платы(современные) позволяют использовать от одного до двух TB оперативной памяти. Надо просто воспользоваться этой возможностью.

Немного юмора из Красноярска:
Есть проблема, что основная база на Парусе 7 тормозит жутко. После выяснений обалдели - сервер на базе коре дуо какой-то там, 2 гектара памяти. На нём стоит вынь2007 на которой водрузили вамвару. В ВМВаре стоит сервер 2012 на котором поднята AD и прочее сопутствующее. В другой виртуалке стоит рабочий парус. Ещё пара виртуалок для экспериментов админу. И никто не может почему всё тормозит.
У меня другой вопрос - КАК рукопопый админ умудрился это всё запустить на 2-х гигабайтах памяти? Как он умудрился сделать так, что Парус ещё и работал!?!?!?!

(107) Прямое отношение к ветке.
Проблема производительности 1С в виртуальной среде может быть решена относительно легко, но возможна ситуация когда нет человека который бы имел одновременно необходимые для решения мотивацию, знания и полномочия. То есть одни не знают что нужно сделать, другие не имеют полномочий сделать а третьим это просто не нужно.

(0) Виртуальные машины - ЗЛО. И всегда были злом. Под словом "всегда" я подразумеваю все времена, начиная с операционной системы СВМ ЕС (да, я застал ее), и заканчивая  этими вашими нынешними вмварями, и прочей хренью. Потому что - ТОРМОЗА. Всегда тормоза, у любого админа. И ничего, кроме раздражения от этих тормозов.

Ну и, раз уж говорить про "тогдашние времена":

"Виртуализация в СВМ была последовательной и полной, в частности, на виртуальной машине можно было запустить другую копию системы СВМ, и так далее".

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

(119) Настоящий админ, сейчас таких почти не осталось.

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

(119) (123) вот это просто шедевр )

(119) Возможно изначально памяти было больше. Но...
"chuma: знаете, любой системный администратор слегка краснеет, если про валяющуюся у него дома обжимку спросить - "где купил?"

(125) Я честно свою обжимку купил =)

всё упрётся в дисковую подсистему

(0)Виртуалка всегда снижение производительности.

(0) накой тебе 16 ядер ? С каких это пор снеговик умеет распараллеливаться ?

ах да, все на металле: сервак 1С на i7, скуль на Xeon

(121) Ты не прав. ЕС1033 и 1045 очень достойные железяки для своего времени. Там очень грамотно и круто была реализована многозадачность, линукс нынешний выдыхает.
Божественная надпись look-outside ;), УПД на ГМД, бАрмалей ... ;)

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

(0)
Для себя уяснил одно.
1. 1С на отдельном серваке.
2. Если админ спорит насчет виртуалки, размещения там чего либо - убеждать бесполезно. Лучше всего помогает удар поддых с разбегу.
3. Если что будет тормозить - админ всегда не при делах. Почта работает ? Какие к нему претензии

PS Сейчас работаю с умными вменяемыми админами

(25)Не пойму чёт, зачем на физике одном, одна виртуалка? :) Нельзя что-ли сразу на физике работать или что?

(129) Проснись и пой. Частенько так бывает, что на сервере работает больше одного пользователя.

(129) вы не поверите - каждый рабочий процесс (имени моего единственного числа) - отдельный процесс.

(136) отдельный процесс = отдельная задача которая видна в диспетчере как автономная задача... ну почти автономная от других одноименных процессов

Сервер 1С можно и на виртуалке, но сервер MS SQL лучше держать на отдельном физическом сервере, где нет никаких других сервисов...

(115) можно, стратегий много, начиная от деления файлов и заканчивая кластером

(121) вы не правы, Виртуалки хорошая вещь, но нужно понимать, для чего она хороша а для чего плоха. У Виртуалок есть довольно много способов применения где все будет супер, но так-же есть и узкие места где их лучше не использовать. Это примерно как 1с загнать на билинг Билайна - все встанет... а для другого она супер....

(129) снеговик замечательно работает с ядрами, сколько рхостов - столько и ядер... если у меня ограничение 1 рхост на 1 базу и баз 50, то мне надо 50 ядер как минимум

all
имею как отрицательный так и положительный опыт 1с и скуля на виртуалках... Ну а сервера лицензий - однозначно на виртуалки выносим...

(139) а сколько сеансов максимум на рабочий процесс?

Деревянные ....  очень хорошие сервера для 1С 8.ХХХ