До того как начать что-то использовать в меру, необходимо усвоить ещё более важные принципы — не охотиться с мортирой на воробьев, не забивать микроскопом гвозди, не использовать что бы то ни было только потому, что “ну, раз оно есть, то надо заюзать” или “а чтоб было!”, и т.д. Убеждён, если бы все так поступали, микросервисных поделок было бы на порядки меньше. K8s для какой-нибудь тудушки на пару сотен юзеров — это даже не смешно, это микросервис головного мозга в терминальной стадии.
Кстати, из опыта того же StackOverflow -- там, где нагрузка может привести к падению процесса (справедливости ради — это везде :), в первую очередь надлежит не об отдельном сервисе задумываться, а убедиться в обеспеченности этого процесса ресурсами. Их главная инженерка прямо отметила, что поставить на машину с PostgreSQL терабайт RAM оказалось решением куда более простым и эффективным, чем вся так микросервисная фигня, которая частенько взбредает в головах “молодых да буйных”.
Попасть в ядрену боеголовку -- весьма нетривиальная задача по причине скорости полета этой самой боеголовки. На входе в атмосферу там 20-25Mach. Решили, что проще шарахнуть несколько мегатонн, чтобы снести всё в радиусе нескольких километров.
На земле “ничего не будет”, Симоньян же рассказывала :)
Немножко корректировок/уточнений из того, что сам знаю, поскольку сам непосредственно работал как раз на том самом объекте, что на картинке про “Полигон Сары-Шаган” (это объект 51, 38-я площадка). Прежде всего, “компьютеризированная система ПРО” там не просто испытывалась, а буквально создавалась — инженерный персонал причастных “почтовых ящиков” из России, Украины, Беларуси, Казахстана нередко проводил куда больше времени в продолжительных командировках (с переездом всей семьи) на этом самом полигоне, чем в стенах своих НИИ, куда ездили раз в полгода на перекомандировку (КЗоТ запрещал командировки продолжительнее 180 дней).
А-350Ж по сути так и не “случилась”. В отличие от В-1000, которой, собственно, и был осуществлён впервые успешный перехват боеголовки МБР. В 1968.
А-35 вокруг Москвы была практически бутафорской. Всегда.
ЭВМ в составе комплекса называлась 5Э92б, а не 5Э926. А по сути это была БЭСМ в военном исполнении. Кстати, прямо с центрального пульта 5Э92б “Иртыша” (это РЛС/ФАР, самый большой “шарик” на фотографии, слева) на “Аргуни” в 1985-м говорили по “громкой” с Джанибековым, стыкуя его с мертвеньким Салютом-7.
Кстати, у 5Э92б была и более продвинутая “младшая сестра” 5Э51. Продвинутость выражалась прежде всего в наличии плавающей запятой.
Во второй половине 80-х стало ясно, что и эти ЭВМ слишком “динозавры” для актуального состояния дел. В НИИДАР “по заданию партии” разработали “спец-вычислитель” Д-89ОА. Тоже монстр многостоечный, гарвардской архитектуры, с канальным В/В (использовалась периферия ЕС). На 133 ТТЛ элементной базе. Работающей на верхних порогах допустимых частот. Как закономерное следствие — на двух рядом стоящих машинах одна и та же программа могла показать разные результаты. Понижение частоты выравнивало картину :) Всего было выпущено 14 машин, 12 отправились на “объект”, две уехали в Гомель, в Конструкторское Бюро Системного Программирования.
В первой половине 90-х мы (говорю “мы”, поскольку это было при моём непосредственном участии) таки нашли способ управления конвейерами отправляемых с ФАР “Аргуни” и получаемых отражёнными от “целей” зондов, а потом и способ отличать ядерные боеголовки от ложных на раннем этапе — в верхних слоях атмосферы.
Ну, а потом “Перестройка” с окончательным развалом “совка” закончили всё это дело.
Заявить “Agile умер” мог только человек, который Agile никогда не видел живьём, и имел в виду то, что видел, называя это почему-то Agile.
Просто у меня Agile “случился” ещё в конце 80-х, хотя такого названия ещё не имел. Зато я с тех пор хорошо представляю, как оно выглядит, и никакими скрамами с дейликами меня не обманешь — они к Agile не имеют никакого отношения. Могут быть, а могут и не быть, но их отсутствие не делает Agile-команду какой-то “неправильной”. А вот наличие оных, да ещё и под иерархическим руководством множественных менеджеров, мастеров и экспертов всех мастей — очень даже может.
Интересные у вас сравнения, однако. Как в On Premise, так мастер-серверам подайте аж “не менее 512GB RAM”, а как “приходите в наше облако, сэкономите!”, так ему уже и 64GB хватает.
Эксплуатация предполагаемой инфраструктуры в полтора десятка обычных серийных серверов — это работа для трёх лежачих администраторов, жалование которых по масштабам никогда не приблизится к “операционным расходам” на ваше чудесатое “облако”.
Ключевое заблуждение с первого же слова статьи. И повторяется далее неоднократно.
Agile невозможно внедрить. Оно может только возникнуть. Относитесь к нему примерно так же, как к счастью — оно может свалиться с неба, вырваться из-под земли, материализоваться из воздуха, но насадить его невозможно никакими методами.
В одной очень близкой мне типографии за долгие годы работы перепробовали кучу всего. С выхлопом от “Вы вообще о работе типографии чего-нибудь знаете, если написали такое убожество?” до “Да идите вы лесом, если необходимая для нашего полиграфического производства функция требует три месяца вашей работы и полмиллиона наших денег!”
Итог — в полтора лица с нуля написанная своя система (1С, всё ещё 7-ка). Любая блажь пользователей — от гендира/коммерса/сэйла до операторов ламинатора и резки — решается за несколько часов. Дней, если блажь масштабная.
Это ваше “впервые слышу” лишь выдаёт ваш довольно скромный опыт. Думайте логично и хотя бы неможко рыночно — в своё время владелец СКС потратил на неё от нескольких сотен тысяч до миллионов рублей, с чего бы он вдруг занимался благотворительностью и дарил её новым “жильцам”? По-моему, его желание получить некоторую, с учётом амортизации, компенсацию своих затрат вполне объяснимо и нормально.
С учётом того, что из двух тредов zstd, создаваемых “по умолчанию”, один занимается I/O, а другой [де]компрессией, то исполнение обоих на одном ядре — нормальное явление для системы, у которой average load не стремится к нулю.
ДВК — это целая линейка довольно разных компьютеров, а LSI-11 — конкретный 4-чиповый микропроцессор. Маловато простора для аналогий, система команд — далеко не единственный критерий.
уместить весь код в крошечные 4 килобайта оперативной памяти Altair 8800 — невероятно сложная задача по тем временам.
Вот это вот “по тем временам” умиляет :) Можно подумать, что сегодня эта задача стала сильно проще. Боюсь, для большинства нынешних т.н. разрабов эта задача не “невероятно сложная”, а невозможная.
Так и я сверху сослался на мануал :) Вот этот же пункт из zstd 1.5.2:
ZSTD_NBTHREADS can be used to set the number of threads zstd will attempt to use during compression. If the value of ZSTD_NBTHREADS is not a valid unsigned integer, it will be ignored with a warning message. ZSTD_NBTHREADS has a default value of (1), and is capped at ZSTDMT_NBWORKERS_MAX==200. zstd must be compiled with multithread support for this to have any effect.
А ещё ZSTD_NBTHREADS не обязана существовать.
А ещё вот это:
На четырёхядерной системе zstd активно работает в один поток
если zstd запускался без --single-thread, противоречит тому, что сказано в доступных мне мануалах:
--single-thread: Does not spawn a thread for compression, use a single thread for both I/O and compression. In this mode, compression is serialized with I/O, which is slightly slower.
Из описания как бы вполне очевидно следует, что без этого ключа (и без -T#) zstd взлетает двумя тредами.
В версии 1.5.5 всё точно так же. Никакого подобия приведённой тобой формуле. Что у тебя за zstd, на какой платформе?
По умолчанию, кстати, zstd работает не в 2 потока, а в зависимости от количества процессорных ядер от 1 до 4.
Это откуда и где? Согласно мануалу по умолчанию используется 2 потока — один для собственно [де]компрессии, другой для I/O. Если указать --single-thread, то всё будет в одном потоке. А если указано -T0, то задействуются все физические ядра.
Требования ZFS к памяти — это свойство ZFS, а не ОС.
Кстати, мне вполне комфортно работается с ней на убогом ноутбуке с 4GB (против настоятельно рекомендуемого везде и всюду минимума в 8GB) — достаточно просто разумно ограничить vfs.zfs.arc.max, чтобы не жрал всю память под ARC.
Планирую эксперимент на совсем убогом EEE PC от Asus, в который больше 2GB не поставишь :)
Тебе, похоже, не надо в ИТ — ты чертовски невнимателен. Практически прямая ссылка есть в подписи ко второй картинке (Этап №1).
До того как начать что-то использовать в меру, необходимо усвоить ещё более важные принципы — не охотиться с мортирой на воробьев, не забивать микроскопом гвозди, не использовать что бы то ни было только потому, что “ну, раз оно есть, то надо заюзать” или “а чтоб было!”, и т.д. Убеждён, если бы все так поступали, микросервисных поделок было бы на порядки меньше. K8s для какой-нибудь тудушки на пару сотен юзеров — это даже не смешно, это микросервис головного мозга в терминальной стадии.
Кстати, из опыта того же StackOverflow -- там, где нагрузка может привести к падению процесса (справедливости ради — это везде :), в первую очередь надлежит не об отдельном сервисе задумываться, а убедиться в обеспеченности этого процесса ресурсами. Их главная инженерка прямо отметила, что поставить на машину с PostgreSQL терабайт RAM оказалось решением куда более простым и эффективным, чем вся так микросервисная фигня, которая частенько взбредает в головах “молодых да буйных”.
Попасть в ядрену боеголовку -- весьма нетривиальная задача по причине скорости полета этой самой боеголовки. На входе в атмосферу там 20-25Mach. Решили, что проще шарахнуть несколько мегатонн, чтобы снести всё в радиусе нескольких километров.
На земле “ничего не будет”, Симоньян же рассказывала :)
Если бы создатели StackOverflow считали микросервисы “правильным путем”, у нас бы не было StackOverflow. Как один из примеров, что у всех на виду.
Немножко корректировок/уточнений из того, что сам знаю, поскольку сам непосредственно работал как раз на том самом объекте, что на картинке про “Полигон Сары-Шаган” (это объект 51, 38-я площадка). Прежде всего, “компьютеризированная система ПРО” там не просто испытывалась, а буквально создавалась — инженерный персонал причастных “почтовых ящиков” из России, Украины, Беларуси, Казахстана нередко проводил куда больше времени в продолжительных командировках (с переездом всей семьи) на этом самом полигоне, чем в стенах своих НИИ, куда ездили раз в полгода на перекомандировку (КЗоТ запрещал командировки продолжительнее 180 дней).
А-350Ж по сути так и не “случилась”. В отличие от В-1000, которой, собственно, и был осуществлён впервые успешный перехват боеголовки МБР. В 1968.
А-35 вокруг Москвы была практически бутафорской. Всегда.
ЭВМ в составе комплекса называлась 5Э92б, а не 5Э926. А по сути это была БЭСМ в военном исполнении. Кстати, прямо с центрального пульта 5Э92б “Иртыша” (это РЛС/ФАР, самый большой “шарик” на фотографии, слева) на “Аргуни” в 1985-м говорили по “громкой” с Джанибековым, стыкуя его с мертвеньким Салютом-7.
Кстати, у 5Э92б была и более продвинутая “младшая сестра” 5Э51. Продвинутость выражалась прежде всего в наличии плавающей запятой.
Во второй половине 80-х стало ясно, что и эти ЭВМ слишком “динозавры” для актуального состояния дел. В НИИДАР “по заданию партии” разработали “спец-вычислитель” Д-89ОА. Тоже монстр многостоечный, гарвардской архитектуры, с канальным В/В (использовалась периферия ЕС). На 133 ТТЛ элементной базе. Работающей на верхних порогах допустимых частот. Как закономерное следствие — на двух рядом стоящих машинах одна и та же программа могла показать разные результаты. Понижение частоты выравнивало картину :) Всего было выпущено 14 машин, 12 отправились на “объект”, две уехали в Гомель, в Конструкторское Бюро Системного Программирования.
В первой половине 90-х мы (говорю “мы”, поскольку это было при моём непосредственном участии) таки нашли способ управления конвейерами отправляемых с ФАР “Аргуни” и получаемых отражёнными от “целей” зондов, а потом и способ отличать ядерные боеголовки от ложных на раннем этапе — в верхних слоях атмосферы.
Ну, а потом “Перестройка” с окончательным развалом “совка” закончили всё это дело.
Уже 7 лет картинке, но что-то список всё в том же состоянии...
Может, я чего-то не понимаю в актуальной реальности, но:
каким образом процессорный сокет оказался чипсетом?
Заявить “Agile умер” мог только человек, который Agile никогда не видел живьём, и имел в виду то, что видел, называя это почему-то Agile.
Просто у меня Agile “случился” ещё в конце 80-х, хотя такого названия ещё не имел. Зато я с тех пор хорошо представляю, как оно выглядит, и никакими скрамами с дейликами меня не обманешь — они к Agile не имеют никакого отношения. Могут быть, а могут и не быть, но их отсутствие не делает Agile-команду какой-то “неправильной”. А вот наличие оных, да ещё и под иерархическим руководством множественных менеджеров, мастеров и экспертов всех мастей — очень даже может.
Интересные у вас сравнения, однако. Как в On Premise, так мастер-серверам подайте аж “не менее 512GB RAM”, а как “приходите в наше облако, сэкономите!”, так ему уже и 64GB хватает.
Эксплуатация предполагаемой инфраструктуры в полтора десятка обычных серийных серверов — это работа для трёх лежачих администраторов, жалование которых по масштабам никогда не приблизится к “операционным расходам” на ваше чудесатое “облако”.
Ключевое заблуждение с первого же слова статьи. И повторяется далее неоднократно.
Agile невозможно внедрить. Оно может только возникнуть. Относитесь к нему примерно так же, как к счастью — оно может свалиться с неба, вырваться из-под земли, материализоваться из воздуха, но насадить его невозможно никакими методами.
В одной очень близкой мне типографии за долгие годы работы перепробовали кучу всего. С выхлопом от “Вы вообще о работе типографии чего-нибудь знаете, если написали такое убожество?” до “Да идите вы лесом, если необходимая для нашего полиграфического производства функция требует три месяца вашей работы и полмиллиона наших денег!”
Итог — в полтора лица с нуля написанная своя система (1С, всё ещё 7-ка). Любая блажь пользователей — от гендира/коммерса/сэйла до операторов ламинатора и резки — решается за несколько часов. Дней, если блажь масштабная.
Это ваше “впервые слышу” лишь выдаёт ваш довольно скромный опыт. Думайте логично и хотя бы неможко рыночно — в своё время владелец СКС потратил на неё от нескольких сотен тысяч до миллионов рублей, с чего бы он вдруг занимался благотворительностью и дарил её новым “жильцам”? По-моему, его желание получить некоторую, с учётом амортизации, компенсацию своих затрат вполне объяснимо и нормально.
Не в туда ответил, прошу прощения :)
Текст перенесён.
С учётом того, что из двух тредов zstd, создаваемых “по умолчанию”, один занимается I/O, а другой [де]компрессией, то исполнение обоих на одном ядре — нормальное явление для системы, у которой average load не стремится к нулю.
ДВК — это целая линейка довольно разных компьютеров, а LSI-11 — конкретный 4-чиповый микропроцессор. Маловато простора для аналогий, система команд — далеко не единственный критерий.
Вот это вот “по тем временам” умиляет :) Можно подумать, что сегодня эта задача стала сильно проще. Боюсь, для большинства нынешних т.н. разрабов эта задача не “невероятно сложная”, а невозможная.
Так и я сверху сослался на мануал :) Вот этот же пункт из zstd 1.5.2:
А ещё ZSTD_NBTHREADS не обязана существовать.
А ещё вот это:
если zstd запускался без
--single-thread, противоречит тому, что сказано в доступных мне мануалах:Из описания как бы вполне очевидно следует, что без этого ключа (и без -T#) zstd взлетает двумя тредами.
В версии 1.5.5 всё точно так же. Никакого подобия приведённой тобой формуле. Что у тебя за zstd, на какой платформе?
Это откуда? Про одно ядро.
zstd не занимается планированием cores, там нет ни строчки кода, хоть как-то влияющего на CPU affinity mask.
Это откуда и где? Согласно мануалу по умолчанию используется 2 потока — один для собственно [де]компрессии, другой для I/O. Если указать --single-thread, то всё будет в одном потоке. А если указано
-T0, то задействуются все физические ядра.Требования ZFS к памяти — это свойство ZFS, а не ОС.
Кстати, мне вполне комфортно работается с ней на убогом ноутбуке с 4GB (против настоятельно рекомендуемого везде и всюду минимума в 8GB) — достаточно просто разумно ограничить vfs.zfs.arc.max, чтобы не жрал всю память под ARC.
Планирую эксперимент на совсем убогом EEE PC от Asus, в который больше 2GB не поставишь :)