Comments 150
Всколыхнуло воспоминания о нашем «старичке» — файл-сервере под FreeBSD, который молотил без перезагрузки больше четырех лет. Мы на него буквально дышать боялись. Когда пришло время его списывать, решили ради спортивного интереса все-таки ребутнуть. И ведь поднялся, зараза! Но ровно до того момента, как мы попытались скопировать с него данные. Сетевая карта отвалилась намертво — ядро после перезагрузки просто не нашло драйвер, который не обновлялся со времен динозавров. Вот тогда и начались классические «танцы с бубном».
ядро после перезагрузки просто не нашло драйвер, который не обновлялся со времен динозавров
Может я глупость спрошу...
А куда делася старый драйвер?
Почему ядро решило искать новый?
Предположу что кто-то в прошлом удалил его командой rm. Возможно, он собирался положить на его место новую версию драйвера, но не нашёл её. Или кто-то отвлёк.
Т.е. вопрос к качеству обслуживания/сопровождения.
А я предположу, что в потрошка FreeBSD полез молодой, бывший виндовый админ, ужаснулся, что сервер не перезагружали больше недели и "не обновляли систему", немедленно всё обновил и отправил в ребут.
И тут-то что-то пошло не так...
Во-первых, ваше предположение противоречит описанию ситуации:
Когда пришло время его списывать, решили ради спортивного интереса все-таки ребутнуть.
Во-вторых, не должен исчезать драйвер сетевой карты при штатном обновлении системы.
Допустим, вы обновили ядро ОС.
Во Фре это сделать было чуть-чуть сложнее, его еще пересобрать надо, а в Линуксе сейчас вот вообще просто в порядке апдейта, особенно если настроить автообновление.
Но в новой версии ядра что-то поломали - такое было раньше, и бывает сейчас. И теперь при загрузке сетевая карта не определилась, или определилась не так, и драйвер не заработал.
Вот и "не должен".
Во Фре драйвера вкомпилены в ядро (раньше так было во всяком случае), при обновлении дерева исходников ядра старый драйвер мог некорректно заработать с новым ядром (такое встречалось, правда, там был драйвер несовсем стандартной железки, но теоретически мог быть и драйвер сетевой).
Из относительно свежих примеров - отказы в работе c WiFi-чипами в Убунте, пропадание поддержки звука через HDMI, пропадание сетевой карты в Армбиане.
И вот это всё вы увидите только после перезагрузки на новом ядре. после штатного в общем-то процесса обновления.
В моей практике были windows-2000 сервера которые не перезагружались годами. От системы не зависит и у каждой системы есть свои проблемы.
сервер не перезагружали больше недели и "не обновляли систему", немедленно всё обновил и отправил в ребут
Любой нормальный сервер должен переживать подобные манипуляции без сбоев.
Если сервер от них сломался, то это значит, что с машиной явно что-то совсем не так. И не важно, виндовый админ с ним поработал или нет...
и "не обновляли систему"
Ну так на линуксе тоже важно "обновлять систему", это, как минимум, вопрос безопасности, разве нет?
Инфраструктура в целом должна быть готова к выходу из строя любого отдельного сервера, независимо от того, работает он сутки или год - запросы передаются на дублирующие/резервные, в это время заменяется железо.
Когда он попытался запустить
apt-get update, выяснилось, что репозитории для этой версии ОС уже давно не существуют.
По хорошему надо иметь локальные репозитории, куда после проверок подтягиваются обновления из апстрима, но при этом при необходимости добавляются свои пакеты с бекпортом фиксов из новых версий.
Инфраструктура в целом должна быть готова к выходу из строя любого отдельного сервера
Уточним. Инфраструктура, которая в течение десяти лет не обновлялась из-за нехватки денег, должна быть готова к выходу из строя любого из двух серверов (базы данных или бухгалтерского), дублировать который нечем из-за нехватки денег.
Для фирмы с штатом из директора и уборщицы логичнее арендовать инфраструктуру в облаке и не лезть в вопросы надёжности железа.
Сильно от экономики нищебродства зависит. В одном небольшом стартапе оказалось что держать сервер рабочую станцию в кладовке с двумя GPU на порядок дешевле чем брать в аренду самый простой GPU'ушный сервер. Бонусом - анлим на ML-эксперименты
Вопрос в необходимости аптайма 24/7 и стоимости простоя.
А расходы на электричество считали?
Они могут включаться в стоимость аренды
БП:750 Вт
Расчетная пиковая: 140 Вт (GPU1) 200 Вт (GPU2), 120 Вт CPU, остальное по мелочи(HDD 1шт, 3 SSD, вентиляторы), пусть будет еще 100 Вт. Итого: ~660 Вт. В простое, очевидно, ватт 100 будет.
30 дней *24 часа * 660 Вт = 475 кВт Это если все 30 дней под нагрузкой. Сколько там киловатт нынче стоит в однотарифном режиме? 5 р./7р.? пусть 7р. итого 3500 р. В простое 75кВт/мес. или 500 р. Вот вам вилка. Двухтарифность добавьте сами.
За 3500 ЦОД предложит выделенный сервер с 1-2 CPU(8p) 16/32 Гб и 1-2 Тб. Ни о каких ГПУ внутри и речи не будет.
Каллок за 3500 тоже никто не предоставит - 1U в среднем от 5000 начинается, плюс каждые 100 Вт (сверх 200) это +500-700 р. Итого размещение нашего сервера обошлось бы в 10к
---
Так что наш сервер в кладовке окупился за 1-1.5 года. С учетом того что мы еще смогли урвать на авито A4000х16Gb за 45к (посмотрите сколько они сейчас стоят), так вообще щииикарно.
Да, т.к. он в кладовке, доступность не 99.99, а 95%(условно) и то без чего нельзя прожить пару часов на нем ессно не стоит.
И вроде все счастливы - бизнес не платит конские расходы, инженеры могут экспериментировать сколько им хочется
Инфраструктура, которая в течение десяти лет не обновлялась из-за нехватки денег
На покупку инфраструктуры деньги были, а на обновление внезапно кончились ? Или просто сова-менеджер взвесила риски, и поняла, что на лошади можно нужно ехать пока не издохнет? Издохнет - деньги найдутся, а данные тушканчики руками восстановят, за зарплату.
Да, на покупку инфраструктуры была субсидия от департамента.
Иначе говоря, эффективная сова сидит этажом выше, в департаменте. Знакомая картина ;)
Это не эффективная сова, это разные статьи расходов - закупка и обновление. А от слов "нецелевое расходование бюджетных средств" любая сова в бюджетной сфере, что эффективная, что не очень падает в обморок. Причем в чувство ее приводит прокурорская проверка.
Вы правы. Просто слово "бюджет" сразу тянет за собой такой совятник, что ой.
(хотя мне и не нравится это сравнение. Совы, которые Strigiformes, его не заслужили)
Обсудим этот совятник.
Предположим, что вы не хотите, чтобы ваши деньги украли. Вы знаете цену на товар. У вас немножко не хватает до этой цены, однако, в принципе, можно напрячься или занять деньги.
Теперь вы пришли в магазин и видите, что продавцы хотят украсть ваши деньги. В другом магазине тоже. И везде так. Всюду все продавцы ставят две-три цены за этот товар. Однако у вас нет и никогда не будет столько денег.
Как правильно выстроить покупку, чтобы заплатить за 1 товар только 1 цену или даже сэкономить при покупке?
Спасибо.
Всюду все продавцы ставят две-три цены за этот товар
Поправьте меня, если я ошибаюсь, но вроде эту штуку называют рынком.
Как правильно выстроить покупку, чтобы заплатить за 1 товар только 1 цену или даже сэкономить при покупке?
Очевидно же. Используя административный ресурс. В последнее время популярный метод, между прочим.
Возможно, стоит отказаться от схемы оплаты "товар сейчас, деньги когда бюджет согласуют", уменьшить требования по количеству сопровождающей товар макулатуры, и заодно забыть про откат.
Тогда и новые, адекватные, продавцы появятся, и старые зашевелятся.
Всюду все продавцы ставят две-три цены за этот товар
Может с вашими деньгами что то не так? Раз именно для вас такая специальная цена?
В этой ветке диалога под словом «мы» понимают все бюджетные учреждения.
Тогда для вас есть определенные правила, их нужно соблюдать. И про дёшево там нет.деньги выделены - потратьте и отчитайтесь.
Теперь вы пришли в магазин и видите, что продавцы хотят украсть ваши деньги.
Не ваши. Когда родители отправили вас с бидончиком за сметаной - они не предполагали, что вы будете бегать по магазинам и искать как выкроить себе на мороженку.
В рамках нашей темы пример с родителями выглядит иначе.
Родители дали вам бидон и послали за сметаной. Они объяснили, что купить надо в самом дешёвом месте, потому что если цена будет выше минимальной, родители не смогут заплатить. У них едва-едва хватает денег. А чтобы купить мороженку, вы должны, кроме школы, кружковых занятий и помощи по домашнему хозяйству, ещё и работать по вечерам. Например, говорят родители, вы можете за деньги продавать копии своих диктантов.
Они объяснили, что купить надо в самом дешёвом месте
Ну, допустим, тендер. Не аукцион же. Кто предлагает цену больше - выиграть не может.
Кто предлагает цену больше - выиграть не может
Есть вполне встречающаяся на просторах нашей Родины схема, когда крупные игроки сговариваются, а мелкие не в состоянии удовлетворить формальным условиям тендера (всякие там наличия подтвержденных компетенций и все такое). Убрать такие условия тоже нельзя, потому что тогда хрен отобьешься от мошенников или просто некомпетентных поставщиков. Распространяется, кстати, не только на тендеры от госов.
Первый вопрос: если во всех магазинах цена х2 ~ х3 от той цены, которую знаю я - откуда я знаю эту цену?
PCI DSS с недоумением смотрит на хосты с аптаймом больше 3-4 месяцев.
Ну и в целом, кажется, "работает - не трогай" в 21 веке - удел замшелых ретроградов, которые не до конца понимают, "как оно там унутре работает".
А какому конкретно пункту стандарта противоречит аптайм более 3-4 месяцев?
p.s. как PCI админ смотрю с недоумением на такие заявления. Меня бы порвали на части, если бы мои Linux хосты имели такой аптайм.
6.3.3 All system components are protected from
known vulnerabilities by installing applicable
security patches/updates as follows:
• Critical or high-security patches/updates
(identified according to the risk ranking process
at Requirement 6.3.1) are installed within one
month of release.
• All other applicable security patches/updates are
installed within an appropriate time frame as
determined by the entity (for example, within
three months of release).
Продолжайте смотреть с недоумением :) Что вообще плохого в низком аптайме хостов? В наше время все более-менее пригодные к продукционному использованию системы умеют бесшовно мигрировать при плановых техработах.
PCI-DSS регламентирует требования к накатыванию обновлений, но не к перезагрузке. Установка обновлений необязательно должна сопровождаться перезагрузкой.
Мы изначально говорим про хосты с Linux. Для применения новой версии ядра в общем случае нужна перезагрузка.
Обновления могут и не затрагивать ядро. Обновления бывают и для обычных пакетов. Поэтому, не очень корректно говорить, что если хост не обновлялся 3-4 месяца, то это сразу противоречит требованиям PCI-DSS.
Поэтому, не очень корректно говорить, что если хост не обновлялся 3-4 месяца, то это сразу противоречит требованиям PCI-DSS.
если хост не перезагружался 3-4 месяца то вероятность того что требования установки апдейтов не соблюдаются при этом почти 100%
А ставить апдейты без перезагрузки кстати чревато, вот запущена у вас софтина, вы часть пакетов обновили...и чё надо софтину рестартить, вручную это делать? вести список обновленных пакетов и сервисов которые надо обязательно перезапустить, чтобы они не использовали старую версию при уже накаченной новой? кмк тут появляется состояние нестабильности которое отслеживать сильно сложнее чем сервак ребутнуть
Во многих случаях это может делать автоматика пакетного менеджера. (Скрипт написать который это делает - тривиально, если dlopen не используется).
а что она сделает, автоматика то? обновить полностью систему она не сможет, и оставлять ситуацию когда апдейты поставили но работающий софт работает не старых версиях и непонятно когда это изменится - нельзя
Получить список зависимостей софта не использующего dlopen для подгрузки модулей - просто.
(ldd по модулям, берём список библиотек, прогоняем по ним apt-file, получаем список пакетов. Если ваша кастомная софтина не в репозиториях - вешаем dpkg hook который перезапустит сервис.
Собственно ubuntu, например, умеет спрашивать - какие сервисы рестартовать при апдейте, почему не вписаться в эту систему.
Более того - в /proc у вас есть все замапленные файлы процесса ;-)
Собственно ubuntu, например, умеет спрашивать - какие сервисы рестартовать при апдейте, почему не вписаться в эту систему.
для любых линкусов на самом деле доступно - https://github.com/liske/needrestart ну или почти для любых, маргинальщину не использующую rpm/deb вычеркиваем
маргинальщину не использующую rpm/deb вычеркиваем
ага, ту самую которая на проде работает которую программеры программят и энтерпрайз покупает
мы опять про сервисы уровня nginx/apache/smtpd говорим?
и какой же не rpm-deb лынукс покупает енторпрайз? озвучите?
Линукс-то как раз rpm-deb, а вот те программы, которые на этом линуксе запускаются - нет.
ну тут отдельный вопрос кто неосилил пакетный менеджер (видимо предки тех, кто сейчас в докеры пакуют). на моей памяти это nvidia (и то дистры научились), рейдовые тулы и прочий оракл. если у вас самсэм-савсэм кровавый, никто же не мешает запекеждривать самому и получить все бонусы.
У IBM куча софта идёт со своими инсталлерами вместо пакетов.
никто же не мешает запекеждривать самому и получить все бонусы.
"За это не платят" (с)
нет, на самом деле можно так сделать, но это потом будет сложно поддерживать (вы уволитесь, ваш зам тоже, а те кто придет потом угорят в таком инструментарии разбираться)
а всё ради чего? чтобы сервак не ребутать? а в чем профиль админа то? нивчем, а бизнес и так готов штатно делать окна сервисных работ для некоторых сервисов
"За это не платят" (с)
на самом деле все проще. если у вас в ансиблах и иже с ними забиты строки apt-get upgrade && systemctl restart whatever и вас не парит отсутвие авторестарта и неподдержка тулы needrestart.
либо парит и тогда вы расписываете риски, которые может принести неперезапущенный softwarename при обновленном glibc где обнаружился CVSS10. и тогда резко находятся ресурсы.
нет, на самом деле можно так сделать, но это потом будет сложно поддерживать (вы уволитесь, ваш зам тоже, а те кто придет потом угорят в таком инструментарии разбираться)
я не знаю как там в непрофильных конторах - у нас все пэкджирование завернуто в конвеер и прекрасно документировано. хоть вся команда уволится, разобратся будет элементарно.
а всё ради чего? чтобы сервак не ребутать? а в чем профиль админа то? нивчем, а бизнес и так готов штатно делать окна сервисных работ для некоторых сервисов
его так или иначе ребутать из-за кернела и микрокода CPU. я про то, чтоб не ребутать когда не надо.
Спасибо, я забыл как пакет звался.
Я говорю по своему опыту - за три года работы в финтехе с ежеквартальными обновлениями пакетов на хостах не было ещё ни разу, чтобы линукс не попросил перезагрузиться.
долгий аптайм означает одно: BCP нормально не тестировался, что еще хуже для современных аудиторов, т.к. это базовый процесс.
6.3.1 в явном виде говорит, что риск надо оценивать "с учетом потенциального влияния". Уязвимость может иметь сколь угодно высокий рейтинг, но если конкретно ваша инфраструктура такова, что она не может быть легко проэксплуатирована (например, вообще не попадает в поверхность атаки) или ее эксплуатация не может повлечь тяжелых последствий, то она просто не будет классифицирована как критичная, и, как следствие, установка патча в течение месяца не будет обязательной. А срок установки некритичных - "for example", у вас может быть один example, у кого-то другой, и никакие стандарты это не нарушает.
которые не до конца понимают, "как оно там унутре работает".
"Софт нормально сделать не могут и своё рукожопство прячут за периодическими ресетами", мы всё правильно понимаем?
Статья — бальзам на душу! Особенно про вентилятор, державшийся на магнитной левитации. У нас был похожий случай с сервером, который 5 лет не выключали. После перезагрузки он просто молчал... как будто ему надоело
Про DNS-кэш — чистая правда! Сколько раз сталкивался: 'у меня не работает', а оказывается, nscd закэшировал старый IP. Теперь всегда первым делом его чищу
Про кэш DNS - правда только для тех, кто не знает, как работает DNS.
а если еще почитать умные книги про DNS то можно открыть сакральное знание - как корректно мигрировать записи, чтобы вот такого не возникало :)
А не подскажете такие книжки? Да и в целом, что читать по сетям? Я неиронично, если что.
кажется орелевская классика была. но про сеть это чуть другое. и да, одно дело это теория в книгге, другое дело разбирать сетевку на практике, жизнь, зараза куда богаче.
я еще завтра поищу, где-то на хабре годнота про DNS проскакивала, но там прям деньги жег народ организовывая все. я прям оргазм испытал, читая, как все грамотно делают.
в целом тут рецепт для митигации кэша простой - уменьшаем TTL на половину до 0 ступенчато. на 0 переключаем записи и обратно.
нашел хабровскую https://habr.com/ru/company/ozontech/blog/722042
цикл статей был «сети для самых маленьких», или типа того. вроде бы даже на хабре
Я начал работать официально как сисадмин в 1998 году. До этого баловался.
Статья меня просто поразила. Или я действительно уже старый и ничего уже не понимаю в колбасных обрезках (мои нынешние работодатели так, правда, не считают), или компетенции молодых специалистов уже не те.
Простое выключение-включение. «Феникс» больше не взлетел. RAID-контроллер решил, что с него хватит, а заодно прихватил с собой пару дисков из массива
Я никак не могу уловить связь uptime сервера с надёжностью оборудования. Что бы изменилось, если бы сервер по расписанию перезагружался каждую ночь? Лиски бы проработали дольше? Или контроллер? Может вместо перезагрузки следует настроить корректный мониторинг дисков и контроллера? Сейчас для этого полно вариантов.
Плановые, регулярные перезагрузки — это не признак нестабильности системы (как во времена Windows 9x), а важнейшая проверка ее здоровья. Это единственный надежный способ протестировать скрипты автозапуска, выявить скрытые проблемы с железом и применить обновления ядра.
Вообще, по моему, дичь.
Есть системы, от которых требуется uptime, измеряемый годами.
Способ протестировать скрипты автозапуска, далеко не единственный. Есть staging environment. Более того, я админил до нескольких сотен физических серверов и тысячи виртуальных - даже не представляю что нужно сделать, чтобы при штатном обновлении стабильной ветки OS, сломать загрузку.
Ядро давным давно уже обновляется без перезгрузки.
О каких скрытых проблемах железа идет речь, я не понимаю. Если инженер обладатель профильного образования, то он знаком с теорией надежности и методикой оценки отказов. Если не обладает - всегда можно ознакомится.
Секретов тут никаких нет: мониторинг для предсказаний отказов и резервирование. За последние 50 лет ничего нового не придумали. И регулярные перезагрузки тут вообще никаким боком не вписываются.
В телекоме есть железки (сам знаю, я из телекома вырос), которые работают больше 10 лет в uptime. У меня есть серверы с uptime более 5 лет. Это нормально. Ненормально, если такие серверы необслуживаемые и с кучей уязвимостей, которые могут быть эксплутируемы.
В общем, я действительно в растерянности. Такая статья - и такой бред. Хорошо, что мои преподаватели уже не прочтут..
В следующий раз, когда вы увидите сервер с аптаймом в 1000 дней, не гордитесь им. Пожалейте его. И запланируйте ему достойные проводы, заменив его молодым и свежим клоном. В этом и есть дзен современного администрировани
Кошмар просто.. наверное такими же рекомендациями руководствовались админы и разработчики последнего Фобоса и лунного модуля. "Перезагрузите ваш компьютер " - это в принципе не везде работает!
А еще есть системы жизнеобеспечения и энергетика!
Ядро давным давно уже обновляется без перезгрузки.
А это тогда почему выводится периодически при подключении по ssh?
*** System restart required ***
Наверное забыли включить лайвпатчинг.
который требует про в убунтах и мерзости snapd
А оно ещё и не по умолчанию включено?..
Оно несовместимо с kprobe, наверное поэтому выключено. Но даже у RHEL ядро обновляется раз в неделю и на критичных системах без этой штуки жизни нет.
В убунтах оно требует ключ. Который нужно сначала получить у каноникла (и бесплатно этот ключ будет работать лишь на 5 машинах).
Ядро давным давно уже обновляется без перезагрузки
Ну расскажите мне как перелезть с 6.1 на 6.18 без перезагрузки.
А апгрейд имеет смысл, например, для свежих систем на Intel/AMD очень много всего допилено. Или, например, свежая версия софта может хотеть свежее ядро (например, io_uring пилят постоянно)
жесткие диски тоже с подшипниками, шпиндель может и не раскрутиться после остановки.
А еще есть системы ... и энергетика!
в энергетике все попроще, там есть ППРы (планово-предупредительный ремонт) - раз в год-полтора-два, в любой системе начинают дергать\обновлять\заменять\отключать\устранять замечания. В том числе и ЗИПы проверяют.
в энергетике все попроще, там есть ППР
... пока ещё есть ...
Но скоро умрут люди, которые умели думать физикой и реальностью, и начнут работать люди живущие в айтишной парадигме "ну и пофиг что сломалось, щас починим"
Раскройте мысль, там где я работаю(или работал) и в IT, и в пр-ве были свои ППРы. В АйТи это было:
Проверка бэкапов раз в n-месяцев. Причем не просто почмотреть что они есть, а именно развернуть на стенд и пройтись тестами
Автоматизированная проверка обновлений (--bugfix и --security)
Проверка оборудования перед вводом в эксплутацию. Нас тут недавно заставили 300+ портов проверять - втыкаться в кросс и смотреть что данные ходят (а не просто линк поднялся). Скоро чую будут заставлять скорость тестировать.
На пр-ве +- таж фигня, т.к. редко когда к сдаче все смежные системы работают и практически всегда есть договор на поддержку (читайте допил) системы
Раскройте мысль
С давних времён в еулах писалось "вы пользуетесь этим так как оно есть, на свой страх и риск". Однако, первоначально этим занимались люди, которые выросли в условиях 100% физического мира, в котором поломки имели последствия. Ну и интернета не было в таком количестве, поэтому, у потребителей не всегда была возможность обновить глючный продукт.
Сейчас же у нас есть люди, которые изначально выросли в условиях, когда сбой софта не считается чем-то проблемным, а повсеместное наличие интернета позволяет в любой момент выкатить обновление.
У людей появилась возможность следить за оставшимися "процентами здоровья" и ориентироваться на них. Технологии это позволяют.
Когда люди, целиком выросшие в этой парадигме, станут людьми принимающими решения, они начнут применять то везде то, к чему привыкли с детства.
То что сейчас в энергетике есть ППР, это призрак из прошлого. Люди, которые осуществят переход с ППР на работу по текущему состоянию.
Ведутся ли работы по внедрению предиктивной аналитики для прогнозирования аварий, там где Вы работаете?
Я никак не могу уловить связь uptime сервера с надёжностью оборудования. Что бы изменилось, если бы сервер по расписанию перезагружался каждую ночь? Лиски бы проработали дольше? Или контроллер?
Связь простая - сдохло бы раньше - "по расписанию", а не когда перезагрузка случилась нештатно (видимо подразумевается в статье).
А так, полностью с вами согласен. [Joke] Для меня тоже выглядит как "заказная статья от разработчиков windows server" [\Joke]
даже не представляю что нужно сделать, чтобы при штатном обновлении стабильной ветки OS, сломать загрузку.
не так давно в стейбле дебиана ломался 32-битный grub-efi. настолько, что даже вручную загрузить ядро нельзя было- нужен был внешний загрузчик. наткнулась как-то на атомном планшете, у которого uefi строго 32-битный и у него таки села батарейка.
ну а говноплатники на армбиане, которым в апдейтах прилетает ядро без драйвера то на сеть, то на контроллер sdmmc (на котором висит корневой диск)- ваще классика.
Не хватает аналогии с живыми организмами. Именно поэтому мы рождаемся и умираем, чтобы экспериментировать и не накапливать ошибки. Каждый акт рождения - это процесс сброса, обнуления.
Позвольте немного подушнить. Мы умираем не затем, чтобы не накапливать ошибки, а как раз из-за того, что ошибок стало слишком много. Мы, своего рода, Arch дистры. А рождение - бэкап до состояние, когда количество багов - приемлимое.
Есть механизмы старения не связанные с накоплением ошибок, тогда мы наверное умираем через определённый период, чтобы оставить ресурсы молодому поколению.
Напрашивается философский вопрос. Механизм старения - баг, который пока не пофиксился или фича? Сервер-то 1000 дней работает и ничего. Смысл его трогать? Стоит менять, когда новые requirements подвезут.
У большинства живых существ - механизм старения фича. А у серверов баг. Эволюция жизни направлена на выживание вида - а это эффективно можно делать только устраивая ротацию и отыскивая слабые особи, эволюция серверов направлена на максимизацию надёжности - а на 100% надёжный сервер - работает до тех пор, пока его не выключат.
Вопрос "зачем" предполагает наличие воли. А мы скорее рождаемся и умираем "почему" (потому что всё предыдущие поколения наших предков оставили потомство следуя этой последовательности, а все, кто потомства не оставил - не наши предки).
Ну либо наличие бога предполагается)
По поводу скрытых повреждений софта и физической деградации железа - а какая разница, когда сервер упадет, во время плановой еженедельной перезагрузки, или во время плановой/внеплановой перезагрузки раз в пару лет? Ну, кроме того факта, что во втором случае у вас была пара лет спокойной жизни без ночных авралов.
В первом случае ты готов, к тому, что что-то пойдет не так. И бизнес тоже в курсе.
Во втором случае ты якобы спокоен, но весь operations - это решение всяких неожиданных проблем, 24/7. Так что от пейджера уже скоро вздрагивать начинаешь.
Бизнес в курсе? Его волнует не работоспособность сервера, а работоспособность сервиса
Сервер ожидаемо, по расписанию, ребутался в 12 ночи и не поднялся - у вас вся ночь впереди на решение инцидента.
Сервер ребутнулся днем в разгар рабочего дня и не взлетает - инцидентище)
Думаю концептуально разница в этом)
'Сервер ребутнулся днем в разгар рабочего дня и не взлетает
Тут два варианта. Или нагрузка перенесена на другие серверы, и пользователи не замечают проблем, или бизнес устраивает простой (на самом деле вполне обычная ситуация, зачастую простой сервера условно на один день в год стоит куда меньше, чем потребуется на резервирование).
Сервер ожидаемо, по расписанию, ребутался в 12 ночи и не поднялся - у вас вся ночь впереди на решение инцидента.
Сколько там в стране часовых поясов? А если у вас глобальный сервис?
Сервер ребутнулся днем в разгар рабочего дня и не взлетает - инцидентище)
Инцидентище в разгар рабочего дня, как по мне, это куда попроще, чем инцидент в разгар ночи :) Тем более что сейчас еще надо очень-очень постараться найти такой сервер, чтобы он одновременно был и критичен для бизнеса, так, чтобы его простой в течении нескольких часов приводил бы к каким-то финансовым потерям, и при этом не был бы хорошо продублирован.
тут основной акцент не на времени все-таки) А в ожидаемости.
Пусть даже ребут в 11 утра ежедневно.
Как только сервер придет в состояние Х, при котором он уже будет не в состоянии стартануть - точка отказа случится предсказуемо на следующий день.
А вот иной кейс - когда сервер не ребутался очень долго, вы проводите штатные работы "ща на 5 минуток памяти доткнуть потушим" и тут у вас случается факап. Причем диагностика несколько затягивается из-за того, что первым делом начинаешь "откатывать изменения" думая, что из-за них и произошел сбой (а на самом деле нет)
Как по мне, если ты ребутишь сервер, который ты не ребутил чуть более чем никогда на своей памяти, это само по себе событие, которое у тебя должно вызывать некую настороженность by default.
вот об этом и речь же)
Что если условно у тебя что-то ребутится регулярно, то и точка отказа становится... я даже не знаю как правильно это сказать...
пусть будет "более детерминированной", чтоли
вы исходите из того, что простой сервера — проблема-проблема-проблема.
но современные тенденции — резервирование ключевых сервисов, отключение единичного сервера тут штатная ситуация, при которой деградации сервиса для пользователей не происходит.
вы исходите из того, что простой сервера — проблема-проблема-проблема
нет, я исхожу из-за непредвиденности ошибки. Вместо сервера впишите любое устройство - например домашний роутер.
Если вы будете каждый день его ребутать - вы сразу же узнаете, когда он выйдет из строя, а если он будет годами включен, то можно долгое время жить и не знать, что он УЖЕ неспособен сам загрузиться.
Это отложенная ошибка, такое бывает и в софте и в механике - я каждые несколько месяцев проверяю, что мои шаровые краны работают и выполняют свою функцию. В то время как у отца они перестали полностью перекрывать воду, а узнал он об этом как раз в тот момент, когда ему нужно было ее перекрыть из-за протечки в ванной, а он не смог этого сделать, т.к. кран закоксовался и не перекрывал полностью поток.
так себе аналогия. переодическое перекрывание шаровых кранов увеличивает срок службы, а перезагрука роутера — сокращает.
и что вам толку от того, что вы прямо сейчас узнали что домашний роутер больше не грузится, не лучше ли бы это случилось через полгода когда электричество отключат?
Если вы будете каждый день его ребутать - вы сразу же узнаете, когда он выйдет из строя
При нештатном отключении я об этом тоже "сразу же узнаю". Причем если вы сейчас скажете, что время работы до фатального отказа этого роутера при ежедневных перезагрузках будет выше - я вас попрошу привести статистически достоверные результаты. А если нет - так к чему эти танцы с бубнами?
если вы сейчас скажете
не скажу, при любом "нештатном" почти всегда есть отягчающие обстоятельства.
Лично меня жестко бесит, когда по какой-то причине дома ковыряешься с девайсом - ребутаешься а он тютю.
Занялся какой-то мелкой проблемой - а тебе комом навалило новых, причем они были давно, просто являлись скрытыми "отложенными" эффектами, и никак не проявлялись, о которых ты узнал в день Х.
С кранами достаточно точный пример - у вас потек шланг от стиралки - вы пытаетесь запереть шаровой кран - а он уже давно свои функции не выполняет - а для вас это сюрприз - вот веселуха то? Достаточно тривиальный таск "перекрыть воду - на след день пойти купить новый шланг и все исправить"
Превращается в "ТАЗИКИ, ЗВОНКИ В АВАРИЙКУ" - огромная разница, проблемы имеют накопительный эффект. Так зачем вместе с одной, иметь себе потенциальную вторую?)
А что, нештатная ситуация не может случиться после того, как вы роутер сами перегрузили? Вот вечером перегрузили, а он на следующий день взял и издох. Не бывает? Еще как бывает. И опять возвращаемся к вопросу статистики частоты сбоев и среднему времени простоя. А что кого бесит, обсуждать не вижу смысла. Может кого-то постоянные перезагрузки бесят, и что? :)
нештатная ситуация не может случиться после того, как вы роутер сами перегрузили?
причем тут это? Вы вообще статью и тред читали?
У вас есть целое множество причин отказа, мы рассматриваем один ИЗ. Который очень часто проявляется таким образом, что у вас устройство УЖЕ неработоспособно, но вы об этом пока что не знаете. А узнать можете в тот момент - когда вам меньше всего этот самый отказ нужен будет
статистики частоты сбоев и среднему времени простоя
к чему эта статистика тут?
Вы либо реально читаете между строк, либо прикидываетесь)
Который очень часто проявляется таким образом, что у вас устройство УЖЕ неработоспособно, но вы об этом пока что не знаете.
Это вы что-то совсем странное пишете. Задача роутера - пакеты маршрутизировать. Если он эту задачу выполняет - он работоспособен, и точка.
Перезагрузки же - просто костыль, проистекающий из технического несовершенства оборудования и окружения. И чем выше средний аптайм как отдельной единицы оборудования, так и всего комплекса - тем меньше, в среднем, проблем у тех, кто это обслуживает. Если вам нравится постоянно перезагружаться - да бога ради. Остальные-то тут причем?
А узнать можете в тот момент - когда вам меньше всего этот самый отказ нужен будет
Повторяю вопрос - а если ежедневно перезагружаетесь, такого не может случиться? Вот в 1.00 у вас плановая перезагрузка, а в 8.56 объект дохнет. И чем вам та плановая перезагрузка помогла подготовиться? :/ Вы либо готовы к внезапному отказу и у вас есть план действий на этот случай, либо не готовы и его нет, третьего не дано. Штатные, плановые перезагрузки конкретно тут не влияют вообще ни на что. А нужны ли штатные перезагрузки как средство предотвращения отказов и с какой частотой их нужно делать (нужно, а не вам хочется) - это предмет отдельного рассмотрения в конкретных условиях.
Повторяю вопрос - а если ежедневно перезагружаетесь, такого не может случиться?
может случиться, с чего вы взяли, что не может? Вы об этом узнаете на следующий день, а не через год - вот и вся разница.
Вы ловите инцидент, который проявил себя спустя сутки после того, как он был спровоцирован, какими-либо внешними факторами, не живете со скрытым дефектом месяцы/годы.
Это вы что-то совсем странное пишете. Задача роутера - пакеты маршрутизировать. Если он эту задачу выполняет - он работоспособен, и точка.
да плюньте вы уже на этот роутер\сервер\нужное подчеркнуть. Я уже привел пример - краны на трубопроводе!
на их месте может быть что угодно, мы сферический в вакууме отказ рассматриваем, а не вьетнамские флешбеки или доктрины о том как надо в суровом кровавом энтерпрайзе
Кстати об энтерпрайзе, когда я читал разборы полетов о крупных отказах жирных датацентров - добрую часть снежного кома проблем наваливают как раз скрытые дефекты подобного толка.
Перезагрузки же - просто костыль, проистекающий из технического несовершенства оборудования и окружения
это абсолютно так. В том числе некоторые перезагрузки могут быть прямой причиной отказа (даже штатные, "мягкие" - привет майкрософт)
Вы об этом узнаете на следующий день, а не через год - вот и вся разница.
А зачем это мне и, что даже более важно - зачем это бизнесу? Если не перезагрузиться, то оборудование прослужит на год дольше? Так это же прекрасно со всех точек зрения. :) Профит-то перезагрузки в чём в итоге?
Я уже привел пример - краны на трубопроводе!
Это типичная ложная аналогия. У шарового крана функция - крутиться. Если он не крутится - он не может выполнить свою задачу, поэтому логично, что его основную функцию надо проверять. А у роутера функция - маршрутизировать пакеты. Он ее выполняет без кручения перезагрузок? Да, выполняет. Поэтому необходимость перезагрузки нуждается в каком-то дополнительном обосновании, кроме "а вдруг потом не заработает".
добрую часть снежного кома проблем наваливают как раз скрытые дефекты подобного толка
Ну приведите какой-нибудь конкретный кейс, и давайте посмотрим.
А зачем это мне и, что даже более важно - зачем это бизнесу?
не знаю, а я не утверждаю, что это нужно бизнесу. Я приводил конкретно свои примеры и зачем это может быть нужным именно мне.
А вообще мне чисто теоретически интересно само явление. Потому что это явно отказ, скрытый дефект и инцидент. Просто он никак не диагностируем адекватными методами. Равно как и холодный резерв, например,нет способа его проверить, не включая с некой периодичностью - но никто не дает гарантии, что он не выйдет из строя на следующий день после проверки раз в пол года)
Профит-то перезагрузки в чём в итоге?
могут быть кейсы, когда скрытые дефекты недопустимы. Не все устройства в мире покрыты горячим резервированием, бесшовной миграцией и прочими приколами.
А у роутера функция - маршрутизировать пакеты. Он ее выполняет без
крученияперезагрузок? Да, выполняет.
Т.е. если вы каким-то чудом (Б-г шепнет на ушко) узнаете, что вот конкретно этот роутер в данный момент небутабелен - вы ничего с этим не сделаете?
Лично я считаю, что загрузка и возможность переходить из выключенного состояние в работоспособное - это так же функция роутера и он в таком кейсе - потенциально ее уже не в состоянии выполнить.
Ну приведите какой-нибудь конкретный кейс, и давайте посмотрим.
ну из кейсов я по памяти могу смутно вспомнить китайский роутер на openWRT, у которого при перезапуске, может развалиться файло на eMMC, причем сама по себе перезагрузка не является триггером, она скорее как лакмусовая бумажка в данном случае)
А рабочий кейс у меня был с инстансом Jira, который очень подолгу может работать без ребутов, даже установка плагинов не требует ресета - но вот беда, инстанс очень легко можно привести в состояние, когда он не сможет ребутаться, а отдиагностировать почему JVM падает при запуске не самый простой, лично для меня, кейс.
Таким образом инстанс ребутался еженочно, во-первых для чистки кешей, во-вторых для проверки бутабельности. Потому что очень часто плагины подсирают друг другу именно при запуске.
Говорят "работает - не трогай" - и это правильно.
Но еще говорят "Семь бед - один ресет" - и это тоже правильно) Я больше 10 лет работал в Helpdesk, очень много проблем решал банальной перезагрузкой. А самое интересное, почти не встречал таких проблем на железках и софте, которые периодически перезагружаются)
В разделе про DNS не хватает выходного кеша хостера. Сбросить его невозможно, только ждать пока соблагоизволит обновиться…
А грамотно ставить TTL DNS-записей - уже харам?
Во-первых, "грамотно" - это как? 5 секунд ставить глупо, а всё что больше - ведёт к проблемам.
Во-вторых, от авторитативного сервера как-то ожидаешь, что он среагирует на изменение настроек сразу же, а не спустя TTL.
Во-вторых, от авторитативного сервера как-то ожидаешь, что он среагирует на изменение настроек сразу же, а не спустя TTL.
Только это нарушает спецификацию DNS, если я правильно помню. Опять же - даже если у вас есть авторитативный сервер - напрямую он не даёт ответов клиентам, они всё равно получат это из кэшей по дороге.
Во-первых, "грамотно" - это как? 5 секунд ставить глупо, а всё что больше - ведёт к проблемам.
В смысле? У вас есть допустимый по SLA период недоступности сервиса. Если у вас по SLA, допустим 99.9% доступности - это 9 часов недоступности в год. Ставите TTL в 1/2 часа и проблем нет. У вас есть возможность упасть ~18 раз в год и не нарушить SLA.
Если у вас более высокие требования надёжности - то тут уже вы будете делать более сложные решения.
А некоторые сервисы настраивают кеш так, что он игнорирует TTL записей. Натыкался уже несколько раз на такие ситуации. TTL - минута, все остальные клиенты уже используют новый адрес. Но за определённым провайдером - спустя час всё ещё получали старый адрес от провайдерского кеша.
Честно говоря, по-моему обоснование противоречит тезису. Если у вас сделано «по уму» и от работоспособности отдельного сервера не зависит работоспособность сервиса, то какая разница какой аптайм, и, соответственно, зачем его искусственно ограничивать? Есть повод перезагрузиться (например, технологии обновления ядра без перезагрузки пока в зачаточном состоянии) — перезагружаемся, нет — так и зачем?
В Ubuntu Pro есть Livepatch, позволяющий устанавливать обновления безопасности в работающее ядро без перезагрузки.
Всегда старался при плановых работах заодно сбросить аптайм, если можно. Почему? Да потому что я видел зависание crond при больших аптаймах на 4 (четырёх) разных ОС:
- Solaris 5.8
- HP-UX 11.23
- AIX не помню какой версии
- И наш любимый Linux тоже
Solaris 5.8 это очень давно,
на 5.9 впрошлый год видели аптайм 10 лет,
но единственный диск посыпался, прилось перегружать, и собирать зеркало на SVM
а актуальная 5.11.4.84, lf
Интересная статья, спасибо.
Почитать бы еще подобное в контексте разработки и деплоя программ. Потому что тут тоже может весело:
Спустя пол года решили доработать сервис. Случайно добавили баг. Решили откатить на старую версию, а ее уже нет. Из-за политики хранения образов, старая версия уже давно была удалена.
Начали деплоить новую версию приложения, которое до этого работало 3 месяца без доработок. Оказалось, что за это время поменялись правила деплоя, и приложение сходу не завелось. Тут оказалось проще - поменялось требование к количеству реплик.
Добавлю историю про перезагрузку.
Повадилась одна виртаулка после перезагрузки не стартовать контейнеры докера. И после очередного подарка от Яндекса в виде массовой перезагрузки виртуалок решил я наконец-то разобраться что там творится. Попросил доступ и пошёл изучать ситуацию.
Контейнеры докера не стартовали потому что сам докер не мог стартовать. При этом вручную докер без проблем запустился. С мыслью "что за ерунда?" я полез изучать логи. А в логах докер не мог создать какой-то нужный ему файл потому что файловая система была только для чтения.
Первой мыслью был искорёженный порядок зависимостей в юнитах, из-за которой докер запускался слишком рано. Однако, аномалий в unit-файлах не обнаружилось, конфигурация была похожа на стандартную. Симтомы проблемы не гуглились. Я уже совсем закопался в тонкости архитектуры systemd, но потом догадался перезагрузить виртуалку ещё раз. Догадка была верна - корневая ФС так и осталась рид-онли, никакой systemd её и не собирался делать нормальной. Почему же тогда до этого такой проблемы не было? Ну, после угрозы применения пыток коллега, который давал мне доступ, сознался - он сделал remount корневой ФС, потому что иначе не получалось создать мне учётку на сервере.
И так, проблема сервера была не в порядке юнитов, а исключительно в корневой ФС. Но где? Первым делом посмотрел в fstab, нет ли там ключа ro. Ключа не нашёл, как и вообще записей. "Ого!" - подумал я, "неужели и fstab уже в окончательно systemd переехал?" Полез изучать systemd дальше, но с ходу почему-то не нашёл где вообще точки монтирования были настроены. Пришлось идти другим путём и выяснять кто вообще в systemd отвечает за монтирование корневой ФС и что с ним случилось. Нашёл нужный юнит, а дальше снова облом - в логах ни единой ошибки. И даже прямой запуск команды systemd-remount-fs ничего не делает (и снова ничего не делает без единой ошибки).
Спустя неокторое время до меня наконец-то дошло, что эти два тупика, в которые я упёрся, на самом деле прекрасно складваются в общую картину: systemd-remount-fs ничего не делает именно потому, что fstab пуст. Добавление туда корректной записи для системного диска решило проблему, и проклятая глючная виртуалка стала самой обычной.
Осталось понять как вообще этот файл оказался пуст? Ну, точно уже не узнать, но на сервере ранее отключали подкачку. Видимо, в процессе работ случайно удалили лишнюю строчку.
Ну, после угрозы применения пыток коллега, который давал мне доступ, сознался - он сделал remount корневой ФС, потому что иначе не получалось создать мне учётку на сервере.
И так, проблема сервера была не в порядке юнитов, а исключительно в корневой ФС.
Неет, проблема была в кривых руках. Которые, в том числе, снесли fstab, и свалили всё на "устаревание"...
По-моему где-то здесь недавно я рассказывал как в бытность админом сдох один из серверов биллинга в местной телеком конторе. Суть в том, что в серверной стояли обычные сплит офисные сплит-системы, которые были и так на износе и постоянно выходило из строя. Приходилось открывать окна в серверной и туда вечно наметало пыли. Руководство отмахивалось, мол и так работает же (контора полу-государственная и руководство менялось регулярно с выборами. Новая власть - новые люди. Старались оставить проблемы на преемников). Пока не выключился старичок от IBM, уже не помню из-за чего, и не проснулся. Сдох один из кулеров от кучи пыли и биос вываливался с ошибкой. "Новый" кулер заказали в китае на барахолке, но ехать он должен был чуть ли не месяц и нет гарантий, что он рабочий. Старый чистили - не помогло. Тогда я раскрутил проблемный кулер мощной воздуходувкой и включил сервер. Биллинг через некоторое время поменяли на новый, руководство наконец-то докумекало и в серверной поставили нормальные промышленные системы охлаждения.
Знакомая ситуация. В лаборатории где я работаю использовался сервер для расчетов стоящий в датацентре. Uptime был 7(!) лет. В определенный момент его стало просто страшно перезапускать -- кто знает поднимется ли он после? Так работает -- и хорошо. Однако, заявку на рекорд грубо обломали электрики, затеявшие ремонтные работы в датацентре. Мы пальцы скрещивали, чтобы он поднялся)
Кстати, там где реально требуется отказоустойчивость (коммерческая авиация), есть как минимум два управляющих компьютера, и они переключаются после каждого полета, с правого на левый и обратно. Это сделано специально, чтобы любые проблемы вылезали как можно раньше, а не в ситуации, когда в полете сдох основной, а резервный сдох еще полгода назад, но про это никто не знал. А теперь вспомните вашу фирму. Допустим, в ней есть основной и резервный сервер. А вы уверены, что при отказе основного резервный способен полностью принять все его задачи?
Как обычно, на самом деле всё не совсем так, хотя и похоже )
Есть проблема физического износа: те же вентиляторы, диски и тому подобное. Да, они постепенно выходят из строя, и при этом как правило именно включение-выключение их и добивает.
Хотите добить быстро - выключайте почаще, это не даст им незаметно состариться, умрут молодыми.
Но есть другое решение: регламент плановой замены - раз в N месяцев старые диски выкинули, новые диски поставили, несмотря ни на SMART, ни на чуйку, ни на что. По регламенту.
Есть проблема неактуальности версий: уже вышла Proga 12.6.3 , а у нас до сих пор 8.0.0!
Срочное обновление!!
Нет, срочно по рукам лопатой. Потому что при этом есть очень хорошая вероятность сломать совместимость с чем-то, что казалось бы ну вот вообще никак не связано.
Готовим новое железо (или виртуалку на старом), устанавливаем новую версию, ТЕСТИРУЕМ - а потом миграция системы на новую версию.
Да, и даже ядро ОС. Тем более ядро ОС.
А как же безопасность?! Ведь в старой версии, если в полнолуние криворукий дятел три раза щелкнет клювом - в систему может пролезть сетевой червь?!
Ну если криворукий дятел знает, что в систему может пролезть червь - ну поставь ты сначала вокруг защиту, не будь криворуким дятлом! И даже если не знаешь - представь, что может - и поставь.
Потом - см.выше - новая инсталляция, тестирование, миграция.
Да, и про плановую замену не забываем, чтобы у кулеров не вырастала борода из пыли и диски не летали.
И остается вопрос с кривыми программами, которые жрут память, гадят под себя на диск какашками временных файлов, и оставляют зомби по углам.
Штош, видимо на тех серверах, у которых аптайм годами, такие просто не водятся.
Либо отцы-программисты их пролечили, либо админ-владелец решил выбрать другое решение задачи.
Как-то так.
А не вот это вот "в любой непонятной ситуации - перезагружайся!"
админ унаследовал несколько Debian-серверов с аптаймом 1300+ дней. Когда он попытался запустить apt-get update, выяснилось, что репозитории для этой версии ОС уже давно не существуют.
А, ммм. Про миграцию релизов с deb.debian.org на archive.debian.org мы не слышали.
Не без плясок, но с вероятностью 85% можно взять debian buzz и обновиться до trixie. squeeze - trixie - 99%.
https://archive.debian.org/debian/dists/
Один коллега рассказал, как планово перезагружал vSphere-хост с аптаймом 300+ дней. После ребута система не нашла загрузочный USB-диск — он оказался поврежден. Гипервизор для клиента просто перестал существовать.
Другой админ с ужасом смотрел на SAN-хранилище с аптаймом в 1400 дней. Никто не решался его трогать, потому что все понимали: при перезагрузке есть неиллюзорный шанс столкнуться с массовым отказом старых дисков.
Классика жанра: сервер выключают для замены одного сбойного диска в RAID-массиве (не hotswap). После включения умирает еще один диск.
Что такое "наработка на отказ", дата TEC, регулярные тесты SMART, а также мониторинг raw_read_error_rate.
Но вообще, если почитать свитки древних, там всё написано. И как часто харды менять, и как часто серваки обновлять, и как часто новые покупать.
Но аптайм 300 дней конечно зло, да.
В следующий раз, когда вы увидите сервер с аптаймом в 1000 дней
Аптайм 1к дней на новом серваке - дык там по аптайму запас ещё на 1-2к дней, не считая хардов. Но харды как будто можно заменить не роняя аптайм.
Другой вопрос что ядро надо иногда обновлять, но как будто придумали livepatch.
Это медленный и коварный процесс, когда приложение захватывает память, но «забывает» ее освободить после использования. Со временем это приводит к деградации производительности, чрезмерному использованию swap и, в конечном итоге, к падению приложения или всей системы. Это классический пример роста энтропии внутри запущенного процесса.
Lol, ну так-то уже лет 5 как swap > 2-4G моветон. Нормально вообще его отключать.
И в линуксе как будто бы есть oom-killer. Сожрал много памяти - тебя убьют. systemd заново тебя поднимет, живём дальше. В винде он тоже есть, кстати.
Если бы ещё oom-killer вовремя срабатывал, обычно сожранная память вытесняет в своп страницы кода, после чего система наглухо зависает. И отключение свопа не помогает, потому что именно для страниц кода каждый бинарник - сам себе своп.
Решение проблемы в свежих ядрах уже есть, но по умолчанию отключено.
Lol, ну так-то уже лет 5 как swap > 2-4G моветон
кто это вам сказал? у меня достаточно серверов, в которых своп не меньше ram. я не говорю уже про десктопы (вот сейчас пишу с машины, в которой 32ГБ памяти и 150ГБ свопа, из которых занято 26, но бывает и 100+) и нотбуки (если своп меньше RAM, то куда hibernate-то делать?)
и откуда вообще пошла эта идиотская мода делать своп размером в 4ГБ при памяти 256ГБ? какой смысл в свопе на порядки меньшего размера, чем ОЗУ?
Минусующим:
package main
import (
"bufio"
"fmt"
"os"
"os/exec"
"strings"
"sync"
"time"
)
func main() {
var wg sync.WaitGroup
// жрёт память
wg.Add(1)
go func() {
defer wg.Done()
var memoryHog [][]byte
chunkSize := 100 * 1024 * 1024 // 100 МБ
fmt.Println("[MEM-HOG] Начинаю потреблять память...")
for i := 0; ; i++ {
chunk := make([]byte, chunkSize)
for j := range chunk {
chunk[j] = 1 // или любое значение — главное, чтобы была запись
}
memoryHog = append(memoryHog, chunk)
fmt.Printf("[MEM-HOG] Заполнено %d МБ\n", (i+1)*100)
time.Sleep(200 * time.Millisecond)
}
}()
// Основной поток: читаем dmesg в поисках OOM
fmt.Println("[LOGGER] Запускаю мониторинг dmesg на предмет OOM...")
// Запускаем `dmesg -w` (требует sudo!)
cmd := exec.Command("dmesg", "-w")
stdout, err := cmd.StdoutPipe()
if err != nil {
fmt.Fprintf(os.Stderr, "[LOGGER] Ошибка при создании pipe: %v\n", err)
os.Exit(1)
}
if err := cmd.Start(); err != nil {
fmt.Fprintf(os.Stderr, "[LOGGER] Не удалось запустить dmesg: %v\n", err)
fmt.Println("[LOGGER] Попробуйте запустить программу с sudo.")
os.Exit(1)
}
scanner := bufio.NewScanner(stdout)
for scanner.Scan() {
line := scanner.Text()
if strings.Contains(strings.ToLower(line), "killed process") &&
strings.Contains(line, "oom") {
fmt.Printf("[LOGGER] ⚠️ Обнаружено сообщение OOM-killer:\n%s\n", line)
// Можно завершить программу, но на самом деле процесс уже мёртв
// Это сообщение может прийти уже после того, как нас убили,
// но в рамках теста — выводим и выходим.
break
}
}
if err := scanner.Err(); err != nil {
fmt.Fprintf(os.Stderr, "[LOGGER] Ошибка при чтении dmesg: %v\n", err)
}
// Ждём завершения (на практике до этого не дойдёт — нас убьют раньше)
wg.Wait()
}root@debian-12:/srv# dmesg | grep oom
[ 568.321823] oom-hog invoked oom-killer: gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), order=0, oom_score_adj=0
[ 568.321834] CPU: 2 PID: 40019 Comm: oom-hog Not tainted 6.1.0-21-amd64 #1 Debian 6.1.90-1
[ 568.321886] oom_kill_process.cold+0xb/0x10
[ 568.322034] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
[ 568.322084] [ 40016] 0 40016 1361892 938391 9580544 245468 0 oom-hog
[ 568.322088] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-4.scope,task=oom-hog,pid=40016,uid=0
[ 568.322124] Out of memory: Killed process 40016 (oom-hog) total-vm:5447568kB, anon-rss:3753564kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:9356kB oom_score_adj:0root@debian-12:/srv# swapon --show
NAME TYPE SIZE USED PRIO
/dev/sda5 partition 975M 10.3M -2/dev/sda5 partition 975M 10.3M -2
ещё раз, зачем нужен своп такого смешного размера?
если вам не нужен своп, вполне можно обойтись без свопа вообще.
или наоборот, например:
edo@edo-home:/tmp$ free -h
total used free shared buff/cache available
Mem: 31Gi 21Gi 6,7Gi 492Mi 3,8Gi 9,5Gi
Swap: 149Gi 35Gi 113Gi
[MEM-HOG] Заполнено 134100 МБ
[MEM-HOG] Заполнено 134200 МБ
[MEM-HOG] Заполнено 134300 МБ
signal: killed
разумеется, тормозило. но ютуб в браузере работал, в звуковом ряде было несколько микро-фризов, и под конец большой на 1-1.5с.
Были еще известные истории как на дорогущих стоечных свичах Cisco отваливалась оперативная память после перезагрузки.
Вот на дебиан тянуть не надо — archive.debian.org отлично работает и позволяет доустановить пакеты или обновить систему на следующую версию. Оно, конечно, неправильно, держать такую древность, но случаи разные бывают.
Половину осилил... Народ Вы вроде взрослые а в байки верите... Большинство серверов рассчитанный на работу 24/7 в течении 4-5 лет, потому и цены у них такие космические.
Статья в целом интересная и что особенно важно, соответствует реальности. Резервирование в том или ином виде наше всё. Пусть плохонькое и на костылях, но ехать позволит. Зы - у меня разок было, что на системе хранения одна голова отвалилась. И вторая все полки на себе тащила. Пользователи конечно бухтели, но работать можно было.
Цифровая энтропия: почему ваш сервер с аптаймом в 1000 дней — это ходячий мертвец, и как с этим жить