Что лучше для 1C: железные сервера или виртуальные? #793506

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

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

Если есть причины не перехода на виртуалки - хотелось-бы поподробнее.

Нет ни одной причины в 2017 годы н.э. не использовать гипервизор. Но при этом принцип "работает, не тронь" никто не отменял конечно же.

тонкости есть или из коробки?

Я поставил жесткое условие на внедряемую на 100 юзверей переписанную УТ11 - сервер 1С + SQL крутится на физической машине, на которой больше ничего нет. Знаем эти ваши виртуалки, плавали.

Минус виртуалки в том, что она виртуалка и ты не будешь скорее всего иметь доступа к физической машине, что легко и непреужденно позволит шалить админам, например, включить экономию энергии. Это вообще жесть - процессор показывает 500 попугаев CPUZ непонятно откуда, при норме в 1700 на ядро, все тормозит и стонет. При этом - если ядро загружать - оно постепенно выходит на 1700, а потом падает до 500. Но нам нужно здесь и сейчас :-)

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

Да

Тонкости бывают при организации отказоустойчивого кластера. А так никаких. У совсем клинический случай.

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

Виртуализация всё же предназначена для шаринга ресурсов между 100500 потребителей. И плохо реагирует на пиковые нагрузки. А 1С именно пиковые постоянно и создаёт. Притом не такие, как описаны в рекламных проспектах виртуализации ("если вам надо, вы сможете выделить..."), а краткосрочные. Вот именно сейчас 1С требуется 100Мб/сек дискового траффика и 100% процессора. А через секунду снова тишь да гладь, благодать. С большой вероятностью админы на ту же физическую машину повесят виртуалку с ActiveDirectory (она же не загружена), виртуалку для экспериментов (на неё же заходят пару раз в неделю для проверки), виртуалку с почтовиком (наши 100 писем в час нагрузки не создают)... В результате 1С будет постоянно тормозить и тупить. Как минимум из-за дисковой подсистемы, потому что даже висящая в простое виртуалка заметно просаживает IOPS.

Хотя... если удастся обеспечить, что бы на хосте крутилась одна и только одна виртуалка, которая с 1С... Тогда почему нет? Гораздо легче будут решаться вопросы с выводом серверов на обслуживание и прочие технические нужды.

И, извините за необразованность, cisco ucs hx220c это там, где хранилище отделено от серверов? Отдельно бездисковые сервера, отдельно хранилище? Однозначно нафиг. У меня что-то подобное. Только без Cisco. Отдельно хранилище по iSCSI организовано. Тормоза зверские. Пока 1С8 всё что надо не закеширует, любое действие в 1С означает секунду-другую тормозов. Терпим эту порнографию только из-за того, что основной оперативный учет на 7.7 ведётся.

точно не скажу, но типа того... вроде как есть свой внутренний сверхъестественно быстрый диск но небольшой и внешнее айскази

Виртуалки - это хорошая идея. Но не нужно забывать, что это не панацея от всех проблем. Здесь тоже есть свои минусы. Мое мнение: на больших объемах (сотни пользователей) лучше ставить физ.сервер. А виртуалить можно небольшие (десять пользователей в терминале, например) объемы. Либо какие-то специфичные задачи.

Стояла ГиперВИ, очень тормозила. Уговорили админов дали еще одну виртуалку, разнесли сервер 1с и сервер SQL. Тупники продолжались. В итоге дали виртуалку еще одну на 2012 с настоящими ЖД=) В итоге теперь все в норме. Виртуалка это хорошо,когда имеешь доступ к физическому серверу и можешь смотреть из за чего идут траблы. В противном случае это может быть поиском черной кошки в черной комноте

Один раз у админо вначалась запланированая дефрагментация на виртуальных серверах, долго мы ломали голову почему 1с тупит...

т.е. с нашей пиковой нагрузкой в 3 базах 200-300 юзеров активистов ловить нечего? кста у нас вмваря

+ 200-300 в каждой из трех баз

Глупо. Нормально все работает. Нужны прямые админы с руками просто.

Я бы не стал. Есть риски, что админы не смогут гарантировать производительность на должном уровне. Скорей всего, события будут развиваться так: вы переезжаете на виртуалку, админы трахаются с настройками неделю/две (до тех пор, пока не возникнет вопрос "Доколе это будет продолжаться?"). Потом вы переезжаете с песнями и плясками обратно. И каков результат? Результата ноль. Пусть админы покажут результаты сравнения производительности на физике и виртуалке.

Я за параллельное масштабирование, поэтому за много маленьких серверов. И гибко и удобно и очень производительно. Виртуалки удобны для хостингов, а под 1Ц они тормозят странно и жутко.

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

как они покажут реальную производительность 1С с нагрузкой живых пользователей?

Возможно. Но вот какая тонкость. Работает всё нормально. За исключением 1С8. 1С8 в терминале на любой чих (пока не закешируется как-то) порождает пиковую нагрузку на дисковую подсистему. А так как этих виртуалок немеряно на одном хранилище хочет (ну на сколько я ситуацию понимаю), IOPS сильно просаживаются. И скорость обмена с диском резко падает. Отсюда делаю вывод, что 1С8 в терминале плохо подходит для виртуализации.

Я бы скорее выбрал вариант с несколькими серверами под 1С, на каждом из которых одна виртуальная машина. Можно еще несколько серверов на которых в нескольких виртуальных машинах домен, почта и так далее. Не будет проблемы с просаживанием дисковой подсистемы. И будет удобство с оборудованием. Вышел один сервер из строя. Переносим виртуальную машину на другой и продолжаем работать, хоть и медленно.

Именно так и есть. КАк правило в конторке дают, например, 2,5 млн рублей и айтишники совещаются на тему один большой сервак или 10 маленьких. В одной конторе купили один большой и потом весь год вокруг него бегали и пыль сдували, т.к. его и выключить нельзя и работать должен всегда как слон. А в другой конторке взяли кучу маленьких серверов и это просто красота - притащили блэйдик, подцепили в кластер, надо у СКУЛЬного сервера пыль сдуть, один вытащили из кластера и с насвистыванием админы обслужили. Сказало начальство срочно мобилизовать 1Ску, навтыкали в 1С-кластер самых разных компов и тоже нормально. А вот с виртуалками такая попа была: 2012 сервак с гиперви. При этом под 1С виртуалку все ресурсы. ТиИ шло почти 24 часа. Потом нафиг всё снесли, поставили 2008 сервак без виртуалок и хопа, тестирование от 4 до 6 часов. В тонкостях не разбирался, но выводы для себя сделал большие

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

нагрузочной тестирование?

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

согласен, пусть тренируются на копии сначала

Ты немного путаешь. При использовании iSCSI как раз нет разницы виртуалка или реальная железка. Т.к. и виртуалка и железка работают напрямую с iSCSI устройством. Нет потерь на виртуализации дисковых устройств. Возможно у вас просто настроены виртуалки неправильно и работают они допустим не с iSCISI, а с виртуальным HDD который находится на ISCSI,

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

Я привёл iSCSI ка пример общего дискового хранилище и влияния его на быстродействие 1С. iSCSI обычно работает как общее хранилище для, например, кластера серверов. Если у нас сервер под виртуализацией и на нём несколько виртуальных машин, его дисковая подсистема, какая бы она не была, работает как общее хранилище для всех виртуальных машин. И позиционирования головок, сброса дисковых буферов, промахов мимо кэша и прочих очень вредно влияющих на быстродействие хранилища, становится гораздо больше. Что может кардинально снизить IOPS. По своему опыту. Имею хранилище iSCSI, на котором живёт слишком много что. Постоянно чувствуется влияние других процессов на быстродействие 1С. То кто-то из пользователей большой объём перебрасывает в личной папке. То админу общие папки массово обработать надо. То какую-то базу из бэкапа поднять, что бы бухгалтерия в "архив глянула". Быстродействие 1С заметно просаживается. Больше даже не быстродействие, пожалуй, а комфортность работы, отзывчивость интерфейса. Начинают возникать на ровном месте "тупняки" на секунду-две.

Ну так нужно с хранилищем разбираться, а не с виртуалками. Не разу не пользовался виндовой виртуализацией и ты ее не пользуй :)

Ну знаешь, по 2 месяца на одну настройку, это шикарные эксперименты. Кто за них платить то будет? Да и в любом случае я не могу предположить как в виртуалке будет работать быстрее, если всё равно куча прослоек присутствует. На рабстанциях виртуалка, это вообще тоска. Хрюше даёшь 4 гига памяти и она еле шевелится. В общем я останусь в клане антивиртуалистов

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

А зачем виртуальный если есть железный?

Тут 2 решения 1) Ограничить иопсы на некритичных виртуалках. 2) Выделить отдельный массив для вируалки с 1С.

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

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

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

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

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

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

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

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

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

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

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

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

Немного юмора в тему: >>Купили админы себе лялю: cisco ucs hx220c бла-бла-бла Прямо навеяло :)...

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

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

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

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

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

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

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

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

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

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

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

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

у меня сейчас вполне приличная железка, поднимать на ней виртуалку - не дал... крутится сервер 1с+SQL по моим прикидкам железка сейчас используется примерно на 25% да, можно сказать - что часть денег выкинули в пропасть, а можно сказать - это на будущий рост компании.... старый сервак вообще под чистую разработку и тестирование забрал. Сейчас все довольны, даже удаленные проекты затягиваем к нам на сервер :) и НИКТО не заикается про "деньги на ветер" хотя пол года назад был кошмар... все тупило, денег жалели и т.д. как говорится - все познается в сравнении!

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

Во многих конторах много лет на виртуалках - никаких проблем. Если админы все правильно сконфигурировали, то нормально работает. Относительно 16 ядер - бред какой-то. На кой ляд Вам больше 16 ядер для 1С?

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

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

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

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

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

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

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

Было бы неплохо.

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

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

Нормальная такая ересь, когда у тебя есть RAID из SSD на PCI-E а не унылые SAS и ожидания на блокировках минимальны. Единственное, со словами "оптимальной" я погорячился. Максимально комфортной, скажем так.

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

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

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

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

Личный опыт

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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