Всегда иметь возможность зайти по ssh

Озвучь данные сервера. У меня коробок совсем слабый, но всегда SSH работал отлично, даже когда был насилуем ownCloud.

не поможет, если система фризится из-да дискового ио, то тут либо что-то с дисками делать (аппаратный рэйд например) либо прибивать сервис из-за которого проблемы

ну еще может планировщик сменить поможет, но не факт

от сервера это не зависит, но если подключен сторэйдж с ссд по оптике, то воспроизвести это, конечно, сложнее.

УПД: именно из-за IO приложения не помню, чтобы оно случалось, но бывает так, что какой-то резко появившийся процесс провоцирует своп или сброс кэшей на диск, и тогда очередь на io лавинообразно нарастает на нагруженной системе, и может находиться в таком состоянии довольно долгое время.

Чтобы прибить сервис, надо сначала залогиниться, а это не получается, см. п.1. Отсюда и вопрос, собственно. И потом, не всегда можно просто взять и прибить что-то, иногда нужно чтобы оно пусть со скрипом, но работало.

тогда остается либо демона написать, который будет прибивать сервис (аккуратно) или с дисковой системой что-то делать

только kvm

кстати, а если кэш уменьшить или вообще отключить?

D 90% случев на сервере своп НЕ НУЖЕН. Поэто можно просто убрать свом с сервера, лутчше получить быстрый oom и смерть демона чем уход сервера в глубокий своп из которого его потом пол часа вытаскивать.

неплохая идея, спасибо, только надо наверное не уменьшать кэш, а ускорять его сброс на диск чем-то вроде vm.dirty_background_ratio.

Возможно, да. Я тоже не вижу причин, для чего на новых серверах с кучей памяти может понадобиться своп. Но вендоры почему-то упорно рекомендуют не выключать...

Даже если мало памяти своп тоже особо не нужен. Активный своп приводит к резкому замедлению производительности сервера, как следствие растет ко-во конкурентных запросов и очередей, это в свою очередь повышает расход ресурсов сервера (RAM + CPU) что сильнее увеличивает нагрузку на своп, и получается эффект снежного кома.

Своп на сервере бывает полезен в двух случаях: спецефичное ПО / конфигурация где можно выгружать очень редко используемые модуля / сервисы в своп (которые постоянно активны, потребляют много RAM но при этом редко используются), кривой софт с мемори ликами - в таком случае мемори лики со временем уйдут в своп и их там никто не будет трогать (хотя например для JAVA это не прокатит так как GC будет все равно осуществлять обход зависших объектови переодически выдергивать их со свопа).

А почему не сделать swappiness=1, чтобы система не лезла в swap до последнего? Ведь лучше по факту разгрести тормоза потекшего приложения, чем разгребать последствия OOM killer?

По уму нужен kvm, чтобы точно иметь доступ в случае глобальных зависонов, но это дорого удовольствие.

swappiness=1 я пробовал у себя на десктопе несколько лет назад, и сейчас почти на всех серверах его тоже ставлю. Но на самом деле он помогает слабо, там какие-то мутные алгоритмы, и все равно своп периодически идет, особенно когда под нагрузкой. Т.е. по моим наблюдениям swappiness работает хорошо, когда и так все хорошо, но не когда все плохо.

kvm тоже не панацея, тем более что он у меня есть в виде консоли вмвари/ipmi. Все равно при локальном логине надо читать файлы, что-то делать, а потом еще и команды выполнять. При намертво ставшей на вводе-выводе машине оно все равно почти не работоспособно. Хотя лучше чем ssh, да.

Нельзя отключать своп, никогда. Если у тебя сервер встает колом из-за нехватки ресурсов, то это ошибка проектирования и админа надо гнать ссаным веником.

почему?

Гнать админа это, конечно, здорово, это ведь он пишет тот софт, который ставит все раком.

почему?

Потому, что будут падения сервисов, что для серверов неприемлемо.

Гнать админа это, конечно, здорово, это ведь он пишет тот софт, который ставит все раком.

Тот кто пишет софт, выдвигает системные требования.

Плюсую. «Подушку безопасности» в виде swap на сервере надо иметь.

Кагбэ тред о том, что такая подушка безопасности на самом деле намного опаснее, чем ее отсутствие. Если сервис упал по ООМ, то он будет перезапущен через пару секунд. Если система встала раком из-за свопа, работать точно также ничего не будет, но восстанавливаться оно может часами. И чтобы ускорить это дело, мне хочется иметь возможность зайти по ssh даже в таких условиях.

По большому счету сервер не должен уходить в своп. Следить за этим дело админа. ООМ «бездушен» простаивающий но «откушавший» процесс может и не кильнуть, при этом активный ssh как раз килять. Т.е. кого убьет ООМ а кого нет, та еще рулетка. И вот как раз своп с бОльшей вероятностью при случае закончившейся памяти вам даст зайти по ssh и начать разбираться с проблемой.

Кого убъёт OOM - не рулетка, там вполне конкретный алгоритм. Влиять на него тоже можно, при помощи oom_adjscore. У sshd oom_adjscore уменьшен из коробки.

Кого убъёт OOM - не рулетка, там вполне конкретный алгоритм. Влиять на него тоже можно, при помощи oom_adjscore. У sshd oom_adjscore уменьшен из коробки.

Однако даже здесь (но не только) были темы как раз про убийство sshd.

По секрету скажу, что в 'six nines' системах свопа почти никогда нет. Там даже OOM-killer отключают, кончается память — сразу паника ядра и перезагрузка узла. Надёжность не в свопе, а в тестировании, redundancy и архитектуре, которая эту redundancy эффективно использует.

Вопрос просто для повышения эрудированности. Разве в Linux нельзя создать «процесс с мигалкой»? В смысле, чтобы его запросы на дисковый ввод-вывод пихались в начало очереди ввода-вывода, даже перед запросами на подгрузку страниц из подкачки, и как следствие тут же выполнялись при любой загрузке системы? А ещё запретить этот процесс своппить. Если такого механизма нет, то почему?

Мне кажется такая фича вполне логичной применительно к тому же демону SSH (а также порождённым им шеллом). Понятное дело, что такой процесс может поставить систему раком (если, например, в бесконечном цикле без задержек постоянно читать-писать), но для выстрела себе в ногу есть и более простые способы - например, записать рандом в /dev/mem.

можно только увеличить/уменьшить приоритет для процесса и ограничить память на процесс, остальным рулит ядро.

Ты хорошо себя чувствуешь?

Основано на опыте разработки того, чем ты пользуешься каждый день, не замечая этого.

для sshd ввод/вывод — это прием/отсылка пакетов, а в этот момент пакеты еще/уже не связаны ни с каким процессом, т.е. равнозначны

не только, если ты говоришь про сетевые процессы. sshd читает кучу файлов при старте и при запуске сесии: конфиги, настройки, профили, либы, модули PAM и еще кучу всего. Если что-либо из этого находится на диске, то запросы встают в очередь. Если очередь забита ядерным вводом-выводом (своп, сброс кэша и т.п.), то очередь до sshd дойдет очень не скоро, если вообще дойдет.

'six nines' системах свопа почти никогда нет

А на тачки для драг-рейса ставят реактивные двигатели. Но владельцу фордфокуса вряд ли подойдет такое решение.

свопа почти никогда нет.
Там даже OOM-killer отключают
кончается память — сразу паника ядра и перезагрузка узла.

Что за системы, где используются, кто разрабатывал архитектуру? Пополню чёрный список.

Надёжность не в свопе

Модель работы с памятью в linux рассчитана на наличие свопа. Это не вопрос надёжности, это вопрос архитектуры.

Что за системы, где используются, кто разрабатывал архитектуру? Пополню чёрный список.

Выкинь все свои мобильники и 3G/LTE модемы, они соприкасались с еретическими сетями.

Модель работы с памятью в linux рассчитана на наличие свопа.

[[citation needed]]

не только, если ты говоришь про сетевые процессы. sshd читает кучу файлов при старте и при запуске сесии: конфиги, настройки, профили, либы, модули PAM и еще кучу всего. Если что-либо из этого находится на диске, то запросы встают в очередь. Если очередь забита ядерным вводом-выводом (своп, сброс кэша и т.п.), то очередь до sshd дойдет очень не скоро, если вообще дойдет.

Ага. А вот еще 15 лет назад telnet спасал. Работал даже при полностью мертвом харде.

Выкинь все свои мобильники и 3G/LTE модемы, они соприкасались с еретическими сетями.

Ты скажи конкретно, что за продукт, какой оператор и где применяет? Я некоторых знаю, позвоню, спрошу чего и как. Очень слабо верю в то что ты написал, ибо

кончается память — сразу паника ядра и перезагрузка узла.

лютый идиотизм.

Ты скажи конкретно

google://NDA

лютый идиотизм.

Тебе виднее.

google://NDA

))))

Насколько я знаю, у многих операторов этой страны используется лютый зоопарк осей и технологий. Так что вполне может быть, что где-то настроен сервис рукожопей чем обычно.

Ну чего ещё ждать от человека, считающего, что

Модель работы с памятью в linux рассчитана на наличие свопа.

Hint: во многих embedded системах под linux и накопителей-то в принципе нет, уже это делает использование свопа затруднительным.

Короче, админ пыхохостинга экстраполирует свои знания.

Как вариант - kvm переключатель https://ru.m.wikipedia.org/wiki/KVM-переключатель Который может по сети.

Тогда и ssh не нужен и доступ надежнее

во многих embedded системах под linux и накопителей-то в принципе нет, уже это делает использование свопа затруднительным.

То есть ты всё это время вещал про embeded, в то время как все остальные обсуждали железные ящики. И операторы твои крутят серверный софт на embeded? Надо как то креативней выкручиваться, раз начал.

Hint: Купи поддержку red hat, сделай на сервере swapoff, урони сервис, обратись в саппорт, напиши куда тебя послали.

И операторы твои крутят серверный софт на embeded?

google://контрпример

Купи поддержку red hat, сделай на сервере swapoff, урони сервис, обратись в саппорт, напиши куда тебя послали.

Поддержка одного крупного вендора, специализирующегося на RTOS, и который также делает дистр linux имени себя, куплена, свопа нет, никуда не послали.

Если тебе нужен своп, возможны следующие альтернативы:

1) Ты допускаешь непредсказуемую деградацию производительности

2) Твой софт течёт

3) Ты не знаешь, как твоя задача масштабируется

4) У тебя нет overload protection

google://контрпример

Это не контрпример был, а глупость не в тему.

куплена, свопа нет, никуда не послали.

Постеснялись обращаться в саппорт, это правильно.

Если тебе нужен своп

Он не только мне нужен, он тебе нужен, чтоб ты не писал вот такие глупости:

кончается память — сразу паника ядра и перезагрузка узла.

Я ж тебя спрашивал, где, у кого такая беда? А ты ломаешься, ссылаешься на несуществующие nda. Дай адресок конторы, я им помогу, не дорого.

Количество возражений по существу на мои тезисы равно нулю.

Огородно-поливальный камуфляж засчитан.

Количество возражений по существу на мои тезисы равно нулю.

Какие тезисы? Что у тебя кернелпаник на ровном месте - норма? Ты, вместо просмотра аниме, почитай доки того же red hat, например, узнаешь много нового, в том числе о необходимости swap, в частности, и linux memory managment, в общем.

Что у тебя кернелпаник на ровном месте

Кернел паник на «ровном месте» случается только если это место — кора мозга. Ну или космическая частица в память неудачно попадёт, хотя от последних, в принципе, защита бывает в железе.

кернелпаник - норма?

Это ЧП. В продакшне на моей памяти паника именно из-за отстутствия памяти случалось всего пару раз — на всех машинах, расставленных по миру. Правда это к существенному сервис-импакту, к счастью, не приводило — благодаря тому, что архитектура сети и софта подобное предусматривает.

того же red hat

Всем уже ясно, что ты к этому дистру неравнодушен. Он, конечно, неплохой — мы в нём билды запускаем, ну ещё файлы можно редактировать.

узнаешь много нового, в том числе о необходимости swap, в частности, и linux memory managment, в общем.

Расскажи мне про memory managemenet что-нибудь новое. Удиви.

мы в нём билды запускаем, ну ещё файлы можно редактировать.

На переменах или на уроках информатики?

На переменах, конечно. На информатике мы пока только paint проходим. Дяденька, ну расскажи про memory management, ну пожалуйста.

На переменах, конечно.

Ну зачем же ты так? Будешь красноглазить на переменах, жизнь пройдёт мимо. Ты это бросай.