помню в 90-х некоторые очень жаловались на виддовс и хвалили «правильную» os/2. где теперь та os/2?
примерно то же самое с freebsd, сколько на ней сетапов в top500, например?
конечно же все эти люди из top500 на linux те еще мухи, кушающие то, что на земле лежит :))
ну вот, это 3150+ за 16GB, а DDR3 REG ECC 1600 (которая отлично работает на 1800) 64GB покупается на Али за 5700, например.
в 4 каналах вполне хороший вариант.
думаю, что 200k «деревянных» — это категорически мало для «волшебника», который должен понимать и SAP и Oracle и проч. а еще мучаться поездками на Бауманскую (ну или отдавать полтинник за аренду жилья недалеко).
ps. объявления для смеха, не иначе.
интересно как вырастет цена на батарейки, если каждая семья начнет покупать их…
еще очень интересно сколько будет стоить электричество из сети, если его перестанут покупать в нынешних объемах — ведь капитальные вложения все равно нужно отбивать, вложения в сети тоже нужно отбивать.
что значит «осень бывает разной»? вот конкретная осень (а так же зима и весна) когда солнца очень мало. и что делать?
какие нужно будет занять площади под панели?
ну и вопрос о потреблении промышленностью аккуратно проигнорирован, как обычно.
зато минусы — пожауйста, никому не жалко :))
почему-то пишут про зеленую энергетику в какой-нибудь европе, но замалчивают, что самый большой потребитель электроэнергии (промышленность) из европы перебирается в Азию, где (сюрприз) увеличивают кол-во угольных станций (в Китае, например).
p.s. сколько прямого солнечного света досталось средней полосе РФ этой осенью нужно напоминать?
cpubenchmark дает 1920x 20085 попугаев. e5-2697v2 — 17170. то есть два e5 за 23 тысячи рублей просто порвут 1920x. фирменная материнка на 2xe5 + 16xddr3 покупается в нераспакованной коробке за 8 тысяч рублей. DDR3 сейчас покупается по 100-110руб/ГБ.
ps. обожаю старые зионы!
во-вторых, я не знаю что ты подразумеваешь под zero-downtime.
как я писал выше — приложения не видят failover на другой сервер, это все происходит прозрачно. но сама процедура failover'а по-определению не может не занимать времени — на сервере лежат общие данные для всех клиентов (часто десятки тысяч узлов). даже процедура обнаружения смены сервера занимает время. далее разные дополнительные задержки в виде холодного кэша на сервере и проч.
в силу масштабов систем, такие задержки рассматриваются как существенные и их стараются планировать заранее. за подробностями можно гуглить os jitter hpc.
заказчик обычно сам репортит проблему в jira, дальше просим ту или иную информацию (логи/дампы), пытаемся воспроизвести локально, обычно появляется regression test, фикс заворачиваем в минорный релиз(ы).
заказчики не готовы обновляться, потому что для обновления нужно останавливать систему (это не микросервисы, а большая система хранения данных). в некоторых ситуациях возможен постепенный upgrade через failover-сервера, но не всегда — даже такой failover, будучи прозрачным для приложений, занимает какое-то время и часть приложений простаивает.
очень часто обновления планируются за недели и даже месяцы, за исключением каких-то критических проблем. бывает так, что приходится выключать те или иные оптимизации на лету до обновления.
так это все прекрасно существует без devops… ну или я чего-то не понимаю.
скажем, у нас релизы редко, ну так повелось и заказчики не готовы обновляться постоянно (за исключением случая критической баги).
при этом есть:
1) gerrit
2) автоматизированный анализ кода
3) несколько тысяч скриптованых тестов, накопленных за 18 лет
4) система, запускающая тесты на патчи в gerrit и отправляющая все результаты в БД
примерно то же самое с freebsd, сколько на ней сетапов в top500, например?
конечно же все эти люди из top500 на linux те еще мухи, кушающие то, что на земле лежит :))
чуднейше!
в 4 каналах вполне хороший вариант.
ps. объявления для смеха, не иначе.
еще очень интересно сколько будет стоить электричество из сети, если его перестанут покупать в нынешних объемах — ведь капитальные вложения все равно нужно отбивать, вложения в сети тоже нужно отбивать.
что значит «осень бывает разной»? вот конкретная осень (а так же зима и весна) когда солнца очень мало. и что делать?
какие нужно будет занять площади под панели?
ну и вопрос о потреблении промышленностью аккуратно проигнорирован, как обычно.
зато минусы — пожауйста, никому не жалко :))
p.s. сколько прямого солнечного света досталось средней полосе РФ этой осенью нужно напоминать?
ps. обожаю старые зионы!
во-вторых, я не знаю что ты подразумеваешь под zero-downtime.
как я писал выше — приложения не видят failover на другой сервер, это все происходит прозрачно. но сама процедура failover'а по-определению не может не занимать времени — на сервере лежат общие данные для всех клиентов (часто десятки тысяч узлов). даже процедура обнаружения смены сервера занимает время. далее разные дополнительные задержки в виде холодного кэша на сервере и проч.
в силу масштабов систем, такие задержки рассматриваются как существенные и их стараются планировать заранее. за подробностями можно гуглить os jitter hpc.
заказчики не готовы обновляться, потому что для обновления нужно останавливать систему (это не микросервисы, а большая система хранения данных). в некоторых ситуациях возможен постепенный upgrade через failover-сервера, но не всегда — даже такой failover, будучи прозрачным для приложений, занимает какое-то время и часть приложений простаивает.
очень часто обновления планируются за недели и даже месяцы, за исключением каких-то критических проблем. бывает так, что приходится выключать те или иные оптимизации на лету до обновления.
скажем, у нас релизы редко, ну так повелось и заказчики не готовы обновляться постоянно (за исключением случая критической баги).
при этом есть:
1) gerrit
2) автоматизированный анализ кода
3) несколько тысяч скриптованых тестов, накопленных за 18 лет
4) система, запускающая тесты на патчи в gerrit и отправляющая все результаты в БД