Так не морги, а крематории, потому что раньше ими никто не пользовался, они не рассчитаны, что все будут там кремироваться.
Пара месяцев это 60 дней, за этот срок при обычной жизни в Италии умирает около 90 тысяч. Люди умирают, это нормально. Вирус, возможно, несколько ускоряет этот процесс, но вряд ли столь значительно, чтобы делать такие серьезные выводы, способные обрушить экономику.
В Италии пишут, что не морги переполнены, а крематории, которые просто не успевают за таким количеством из-за того, что запретили хоронить обычным способом. То есть раньше просто мало кто кремировал, а теперь в одночасье стали всех кремировать.
Про переполнение в Нью-Йорке противоречивые данные.
Если при типичной смертности в 1500 человек в день в Италии увеличить это значение в 2 раза, а значит увеличить вероятность пенсионера умереть в этот день, а не через год, то также будут морги перегружены. Это не будет говорить о чрезмерной смертоносности вируса и опасности для всего человечества.
Я не знаю что именно они сделали и не силен в понимании внутренностей. Но УПП практически полностью тормозит из-за блокировок. А ERP отлично масштабируется проводя на том же железе значительно больше операций. Многочисленные собственные тесты показали это при одних и тех же версиях платформы.
Автор, я вот прочитал статью, некоторые абзацы неоднократно. Но так и не понял что у вас происходило. Что-то висло, что-то вводили. Почему список баз не в сетевой шаре? Зачем разделять по портам (привет, Гилеву из прошлых)? Что за одна база — одна служба? Какой смысл в дублировании менеджера кластера? Или это имеется ввиду рабочий процесс? Так он и так на каждую базу создается, а в последних релизах штатно вообще нельзя их изменять.
Если нужно убивать только какую-то одну базу, что мешает определить под каким рабочим процессом работаем база и грохнуть его?
Единственное соглашусь делать отдельного пользователя для службы, но то рекомендует документация для разгуливания блокировок на sql с соответствующими правами.
В статье решаются проблемы, применимые только к режиму совместимости и толстыми клиентами. Они не поддерживают кластеризацию в полной мере, например.
К примеру, после перехода на ERP проблемы работы сервера почти полностью ушли (добавились новые, но это другая история). Теперь 1с хорошо разруливает блокировки, хорошо кластеризуется добавляя отказоустойчивости и производительности, теперь хорошо распределяется на многопоточность, совет про частоту процессора больше не актуален, связано это скорее-всего с более эффективной работой с блокировками, но факт остается. В виртуальной среде также все отлично работает, заметного падения производительности нет. Причем ни в УПП в режиме совместимости ни в ERP без оного.
Ну, в общем, примерно так телеграм и поступает, на сколько я понял) Поэтому деградации сервиса практически нет, а скорость развертывания, судя по всему, очень высокая. Главное клиентом как-то сообщить об обновлении серверов. Пока управу на DC_UPDATE не нашли, но думаю, у телеграма есть в запасе еще какие-то технологии.
Администратор торгового центра «Амазон», тоже ничего не нарушал и его клиенты не нарушали перед законами страны, в которой работают. Амазон же не виноват, что его клиенты заблокированы в Северной Корее? Так и тут.
Если бы телеграм своими действиями отключал каким-то образом IP адреса, то да. А в данном случае это как считать косвенно виноватыми прохожих, в которых товарищ полицейский попал из пистолета, пытаясь убить негодяя. Видите ли сами не успели остановить преступника и допустили своим бездействием использование оружия.
Блокировать у нас не запрещено. Но вроде бы нигде не указывалось снятие ответственности за недополученную прибыль. То есть подразумевается внесудебная блокировка адресов организаций, ведущих заведомо незаконную деятельность. В данном случае организации не нарушали закон и вроде как имеют право взыскать потери с того, кто в этом виноват.
К сожалению нет СХД с такой производительностью. Но есть контроллеры и свитчи 16Gb. Если расскажите как можно без СХД это по тестировать, то я бы попробовал.
Я бы понял расхождение в проценты, но не на порядок…
Привет из 2025. Необходимость в IPv4 так и не появилась)
Мы используем эти контроллеры. Нормальные контроллеры, ничего сверхъестественного.
Пара месяцев это 60 дней, за этот срок при обычной жизни в Италии умирает около 90 тысяч. Люди умирают, это нормально. Вирус, возможно, несколько ускоряет этот процесс, но вряд ли столь значительно, чтобы делать такие серьезные выводы, способные обрушить экономику.
Про переполнение в Нью-Йорке противоречивые данные.
Если нужно убивать только какую-то одну базу, что мешает определить под каким рабочим процессом работаем база и грохнуть его?
Единственное соглашусь делать отдельного пользователя для службы, но то рекомендует документация для разгуливания блокировок на sql с соответствующими правами.
К примеру, после перехода на ERP проблемы работы сервера почти полностью ушли (добавились новые, но это другая история). Теперь 1с хорошо разруливает блокировки, хорошо кластеризуется добавляя отказоустойчивости и производительности, теперь хорошо распределяется на многопоточность, совет про частоту процессора больше не актуален, связано это скорее-всего с более эффективной работой с блокировками, но факт остается. В виртуальной среде также все отлично работает, заметного падения производительности нет. Причем ни в УПП в режиме совместимости ни в ERP без оного.
Я бы понял расхождение в проценты, но не на порядок…