Имелось ввиду, что поток Hyper-Threading не даст ускорения, в случае отсутствия свободных исполнительных блоков. Кроме того, сам по себе "прирост" от увеличения количества потоков не является двукратным. Один дополнительный поток в идеальных условиях может предоставить 20-30% мощности от ядра.
У меня бизнес работает с Марией 10.3 вот уже 2 года. Вы явно делаете что-то не так.
А уведомления об абузе приходили? Повторится, конечно.
Если я правильно понял - уберите для начала
А вообще, вам нужно контролируемое кэширование настраивать.
baas, Я почему-то не уверен, что там всё хорошо, но вот вам ман по установке мунина на виндовую машину (сомневаюсь, что вы его не нашли, правда) http://munin-monitoring.org/wiki/HowToMonitorWindows
В остальном мунин малопопулярен, поэтому сомневаюсь, что вам попадётся кто-то, кто виндовые машины им мониторит...
Так, как я рассказал. Из минусов - много места на бэкапы жрётся и на самих нодах, и на хранилищах.---------- Добавлено 14.01.2020 в 09:11 ----------
Для того, чтобы восстановить все данные клиента в консистентное состояние. Т.е. избежать ситуации, что бэкап сделан после аварийного выключения сервера по питанию с побитием БД к примеру. Восстанавливается такая виртуалка в исходное состояние, прямо на момент бэкапа, как будто она не перезагружалась. Только часы переводятся.
Содержимое снепшота меняться не может. Он для этого и сделан. Снепшот - "фотография" состояния диска на виртуалке на момент снятия дампа памяти. Поэтому после того как мы сделали дамп ОЗУ и снепшот на этот момент виртуалки - мы её запускаем и пусть там хоть что дальше делают, мы потихоньку копируем снимок в хранилку.---------- Добавлено 14.01.2020 в 09:12 ----------
Чур меня. Я в продакшн это не повезу на линуксах, ни под каким соусом.---------- Добавлено 14.01.2020 в 09:14 ----------
Сам по себе такой - ещё не проблема. У меня тут 500 Гбайт ВПСки так бэкапятся - вот тут приятного мало - просаживает и сеть и иопсы.
Так вам стандартный мониторинг надо, да поднять если упало? Потому, как 140 штук. Скажем так, если всё стандартно - да это вообще не проблема, на самом деле. Только вот к этим 140 штукам добавляются хитрые связки (ну у вас же там поди ISPManager Business стоит, на 140-то штуках? И они все увязаны между собой, узлы?), перекрёстные бэкапы по хитрым алгоритмам (потому, что родное в ISPManager не устраивает), специфический тюнинг веб-сервера, сервера БД на каком-то узле, объединение их в локальные сети между собой для передачи данных, разные роли у разных серверов и прочая прочая. Т.е. дьявол кроется в деталях. Я не удивлюсь, если поступит задача накрутить ceph и размазать какие-то сайты по ряду серверов, устроить отказоустойчивый кластер и прикрутить к каким-то проектам лоад-балансинг. Не?
Наши клиенты и на парке с пятью ВПС на ISPManager 5 иногда ТАКОГО просят (я начинаю понимать, что дёшево продались за "всё включено"), что я пару раз даже поперхнулся чаем, выдавая задачу админу.
В связи с чем и говорю - здесь без детального ознакомления со списком задач будет тяжеловато на вскидку сказать, сколько денег вы должны, т.к. у вас может быть свой хостинг и к нему надо обеспечить саппорт, объяснить клиенту, где он не прав (извиниться и сделать как ему надо), да разобраться почему скрипт X не хочет работать на сервере Y (найти причину при внешнем их отсутствии). А может, нужно только своевременно поднять если что-то упало (и принять меры), да патчи вовремя прикрутить, чтобы злые хакеры не добрались и бэкапы проверить. Или вы веб-студия, и вам нужно поддерживать инфраструктуру развёртки ваших проектов на серверах, сделать для вас к этому ещё и CI/CL, etc. В обычном случае (из нашего опыта) задачи редко сводятся к банальным yum/apt update/upgrade и втыканию в мониторинг, чтобы в случае чего что-то перезагрузить.
Да ну уж нафиг. Отличаются. И ещё как отличаются. Правда, аутсорс тоже разный бывает... Но в любом случае те, кто готов работать с Индией и т.п. - он знает, зачем ему нужен аутсорс и такого вопроса бы не поднимал. В случае с СНГ я бы не сказал, что аутсорс дешёвый, но немцы по определению будут дороже, ага.
Да как бы компании из ДС на удалёнку нанимают сисадминов из глубинки и тоже не хило экономят.
Я, если честно, не понял, что у него за задачи.
Если бы у бабушки были яйца, то она была бы дедушкой. Естественно, что плох тот руководитель, который зависит от своих сотрудников. Но вообще круглосуточно инженер работать НЕ должен. Да и посыл был в другом: аутсорс дешевле до определённой границы. У каждого бизнеса она своя. У нас один клиент ушёл после того, как количество обслуживаемых нами серверов выросло до 60 штук - он решил, что ему пора нанять своих специалистов. И нанял. В деньгах пока не выиграл, но и не проиграл, по некоторым задачам мы до сих пор с ним работаем.
Наверное, у вас нет инженеров нужной квалификации. Т.е. они либо overqualified, либо недостаточно компетентны для этих задач, в результате получается, что их использование не эффективно, а держать своего инженера для этих задач экономически не целесообразно. Но это не везде так, и зависит прежде всего от структуры бизнеса.
Ага, щас. Аутсорс выгоднее, когда задач раз-два и обчелся. А когда начинаете загружать аутсорсеров как положено - оказывается, что своих держать выгоднее. Не, ну если это индусы какие-то, да и то.
Смысл заключается в том, что когда у вас в организации задач для DevOps инженера крайне мало - аутсорсер будет делать эти задачи дешевле (условные 20к в месяц против зарплаты инженера в 150к). А когда вы будете загружать аутсорсеров на полную ставку их инженера - вы оплатите и зарплату этого самого инженера, и сопутствующие расходы на содержание бухгалтерии аутсорсера, его директора, юристов. Другое дело, что аутсорсер может быть не из дефолт-сити, тогда инжерегр ему обойдется дешевле и возможны нюансы.
