Поговорим про то, как Linux управляет памятью. Без PhD и без занудства.
Представь, что у тебя есть квартира. Ты в ней живёшь, всё нормально. Но вот к тебе приходят гости — запускаются новые процессы. Им тоже нужно место. И вот тут Linux не идиот: он не даёт каждому гостю реальную комнату сразу. Он показывает каждому виртуальную карту квартиры — мол, вот твоя территория, распоряжайся. Но по факту физической RAM под это ещё нет. Это называется виртуальная память.
Зачем? Потому что большинство программ запрашивают памяти гораздо больше, чем реально используют. Браузер открылся и думает, что у него есть гигабайт. А по факту он пока потрогал мегабайт пятьдесят. Остальное ядро выделит тогда, когда программа реально полезет в этот адрес. Этот механизм называется demand paging — отдай только то, до чего дотянулись руки.
Дальше интереснее. Память поделена на страницы, обычно по 4 килобайта. Ядро ведёт таблицы страниц для каждого процесса — это такой словарь, где написано: виртуальный адрес такой-то соответствует физическому адресу такому-то. Процессор смотрит в эту таблицу через специальный блок MMU и переводит адреса на лету. Процесс даже не знает, где реально лежат его данные.
Если физической памяти не хватает, ядро берёт страницы, до которых давно не дотрагивались, и выкидывает их в swap — на диск. Это как убрать вещи на антресоль, когда в квартире тесно. Когда они снова понадобятся, ядро притащит их обратно. Медленно, но лучше, чем упасть с out of memory.
Кстати, OOM Killer — это отдельный зверь. Когда swap кончился, физическая память кончилась и вообще всё плохо, ядро запускает этого убийцу. Он смотрит на все процессы, считает кто жрёт больше всего и кого убить дешевле всего, и просто посылает ему SIGKILL. Никакого суда, никакой апелляции. Бывает, что он убивает не тот процесс, и тогда ты сидишь и думаешь: почему умер nginx, а не эта жирная java-параша на восемь гигабайт. Потому что алгоритм у OOM Killer простой и иногда тупой.
Ещё есть copy-on-write. Когда процесс делает fork и рождает дочерний процесс, они оба смотрят на одни и те же физические страницы памяти. Копирования нет. Как только один из них попытается что-то записать, вот тогда ядро делает реальную копию страницы. До этого момента — экономия.
Итого: виртуальная память, страницы, таблицы страниц, demand paging, swap, OOM Killer, copy-on-write. Вот и вся подсистема памяти Linux в одном абзаце. Элегантно, если не знаешь, что под капотом это несколько тысяч строк кода, которые могут повести себя как полный псих при определённых условиях.
Но работает. И это главное.
Подпишись на создателей: https://t.me/linuxexex
Представь, что у тебя есть квартира. Ты в ней живёшь, всё нормально. Но вот к тебе приходят гости — запускаются новые процессы. Им тоже нужно место. И вот тут Linux не идиот: он не даёт каждому гостю реальную комнату сразу. Он показывает каждому виртуальную карту квартиры — мол, вот твоя территория, распоряжайся. Но по факту физической RAM под это ещё нет. Это называется виртуальная память.
Зачем? Потому что большинство программ запрашивают памяти гораздо больше, чем реально используют. Браузер открылся и думает, что у него есть гигабайт. А по факту он пока потрогал мегабайт пятьдесят. Остальное ядро выделит тогда, когда программа реально полезет в этот адрес. Этот механизм называется demand paging — отдай только то, до чего дотянулись руки.
Дальше интереснее. Память поделена на страницы, обычно по 4 килобайта. Ядро ведёт таблицы страниц для каждого процесса — это такой словарь, где написано: виртуальный адрес такой-то соответствует физическому адресу такому-то. Процессор смотрит в эту таблицу через специальный блок MMU и переводит адреса на лету. Процесс даже не знает, где реально лежат его данные.
Если физической памяти не хватает, ядро берёт страницы, до которых давно не дотрагивались, и выкидывает их в swap — на диск. Это как убрать вещи на антресоль, когда в квартире тесно. Когда они снова понадобятся, ядро притащит их обратно. Медленно, но лучше, чем упасть с out of memory.
Кстати, OOM Killer — это отдельный зверь. Когда swap кончился, физическая память кончилась и вообще всё плохо, ядро запускает этого убийцу. Он смотрит на все процессы, считает кто жрёт больше всего и кого убить дешевле всего, и просто посылает ему SIGKILL. Никакого суда, никакой апелляции. Бывает, что он убивает не тот процесс, и тогда ты сидишь и думаешь: почему умер nginx, а не эта жирная java-параша на восемь гигабайт. Потому что алгоритм у OOM Killer простой и иногда тупой.
Ещё есть copy-on-write. Когда процесс делает fork и рождает дочерний процесс, они оба смотрят на одни и те же физические страницы памяти. Копирования нет. Как только один из них попытается что-то записать, вот тогда ядро делает реальную копию страницы. До этого момента — экономия.
Итого: виртуальная память, страницы, таблицы страниц, demand paging, swap, OOM Killer, copy-on-write. Вот и вся подсистема памяти Linux в одном абзаце. Элегантно, если не знаешь, что под капотом это несколько тысяч строк кода, которые могут повести себя как полный псих при определённых условиях.
Но работает. И это главное.
Подпишись на создателей: https://t.me/linuxexex
Почему у него такой маленький еблет?
Источник (2ch /b/): https://2ch.org/b/res/336957727.html
Подпишись на создателей: https://t.me/linuxexex
Источник (2ch /b/): https://2ch.org/b/res/336957727.html
Подпишись на создателей: https://t.me/linuxexex
Двач
/Бред/ - Почему у него такой маленький еблет?
Окей, слушай сюда. Есть один трюк в терминале, который я использую каждый день, и каждый раз ловлю себя на мысли: почему мне никто не сказал об этом раньше.
Ctrl+R
Вот и весь секрет. Нажимаешь это в bash или zsh, и терминал переходит в режим обратного поиска по истории команд. Начинаешь набирать кусок команды, которую вводил когда-то, и он находит её мгновенно. Не надо листать стрелкой вверх пятьдесят раз, не надо помнить флаги наизусть, не надо лезть в историю через grep вручную.
Допустим, ты полчаса назад запускал какой-то длинный ffmpeg с кучей параметров. Жмёшь Ctrl+R, вводишь "ffmpeg" и вот она, родимая. Нашёл, нажал Enter, команда выполнилась. Или Ctrl+R ещё раз, чтобы получить следующее совпадение в истории.
Это работает из коробки на любом нормальном дистрибутиве. Ничего не надо ставить, ничего не надо настраивать.
Если хочешь прокачать это до уровня бога, поставь fzf и повесь его на Ctrl+R. Тогда поиск по истории превращается в интерактивный фильтр с нечётким поиском, и ты реально перестаёшь тратить время на тупую работу.
Но даже голый Ctrl+R уже меняет жизнь. Сколько людей об этом не знают и каждый день страдают со стрелкой вверх, это отдельная трагедия.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Ctrl+R
Вот и весь секрет. Нажимаешь это в bash или zsh, и терминал переходит в режим обратного поиска по истории команд. Начинаешь набирать кусок команды, которую вводил когда-то, и он находит её мгновенно. Не надо листать стрелкой вверх пятьдесят раз, не надо помнить флаги наизусть, не надо лезть в историю через grep вручную.
Допустим, ты полчаса назад запускал какой-то длинный ffmpeg с кучей параметров. Жмёшь Ctrl+R, вводишь "ffmpeg" и вот она, родимая. Нашёл, нажал Enter, команда выполнилась. Или Ctrl+R ещё раз, чтобы получить следующее совпадение в истории.
Это работает из коробки на любом нормальном дистрибутиве. Ничего не надо ставить, ничего не надо настраивать.
Если хочешь прокачать это до уровня бога, поставь fzf и повесь его на Ctrl+R. Тогда поиск по истории превращается в интерактивный фильтр с нечётким поиском, и ты реально перестаёшь тратить время на тупую работу.
Но даже голый Ctrl+R уже меняет жизнь. Сколько людей об этом не знают и каждый день страдают со стрелкой вверх, это отдельная трагедия.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
CTRL+R — это знают все. А вот про это скорее всего не знаешь.
В bash и zsh есть встроенная штука под названием CDPATH. Работает как PATH, только для команды cd.
Допустим, ты постоянно лазишь в ~/projects, ~/work, ~/configs. Без CDPATH каждый раз пишешь полный путь или городишь алиасы. С CDPATH делаешь один раз:
export CDPATH=.:~/projects:~/work:~/configs
И теперь просто пишешь cd myrepo, cd nginx, cd scripts — шелл сам ищет по всем директориям из списка и прыгает куда надо. Без полного пути, без алиасов, без боли.
Точка в начале — это текущая директория, она должна быть первой, иначе шелл начнёт искать сначала в ~/projects и будет вести себя как идиот.
Добавляешь в.bashrc или.zshrc, переоткрываешь терминал, кайфуешь.
Бонус для параноиков: когда cd срабатывает через CDPATH, шелл вежливо печатает куда именно он тебя унёс. Это не баг, это фича, чтобы ты не офигел внезапно оказавшись не там.
Почему об этом мало кто знает? Потому что это в мане. А кто читает маны, тот читает маны.
Подпишись на создателей: https://t.me/linuxexex
В bash и zsh есть встроенная штука под названием CDPATH. Работает как PATH, только для команды cd.
Допустим, ты постоянно лазишь в ~/projects, ~/work, ~/configs. Без CDPATH каждый раз пишешь полный путь или городишь алиасы. С CDPATH делаешь один раз:
export CDPATH=.:~/projects:~/work:~/configs
И теперь просто пишешь cd myrepo, cd nginx, cd scripts — шелл сам ищет по всем директориям из списка и прыгает куда надо. Без полного пути, без алиасов, без боли.
Точка в начале — это текущая директория, она должна быть первой, иначе шелл начнёт искать сначала в ~/projects и будет вести себя как идиот.
Добавляешь в.bashrc или.zshrc, переоткрываешь терминал, кайфуешь.
Бонус для параноиков: когда cd срабатывает через CDPATH, шелл вежливо печатает куда именно он тебя унёс. Это не баг, это фича, чтобы ты не офигел внезапно оказавшись не там.
Почему об этом мало кто знает? Потому что это в мане. А кто читает маны, тот читает маны.
Подпишись на создателей: https://t.me/linuxexex
лайфхак, который я использую каждый день, а вы, скорее всего, нет
если ты работаешь в терминале и до сих пор вручную переписываешь длинные команды из истории — ты тратишь своё время в мусорное ведро по одной минуте.
вот штука, которую знают немногие: Ctrl+R
это reverse search по истории bash/zsh. нажимаешь Ctrl+R, начинаешь вводить кусок команды — и терминал сам находит последнюю похожую из истории. не надо листать стрелками вверх двадцать раз, не надо помнить точный синтаксис.
набрал "docker run" — оно вытащило ту длинную команду с флагами, которую ты писал три дня назад. нажал Enter — готово.
хочешь следующее совпадение — жми Ctrl+R ещё раз. хочешь редактировать найденное — стрелка вправо или End, и команда встаёт в строку ввода.
работает в bash, zsh, и даже вfish если правильно настроен.
бонус для параноиков и перфекционистов: если хочешь, чтобы история была длиннее и не терялась между сессиями, добавь в.bashrc вот это
HISTSIZE=100000
HISTFILESIZE=200000
HISTCONTROL=ignoredups:erasedups
shopt -s histappend
теперь твоя история не затирается при открытии нового терминала, дубли не засоряют выдачу, и Ctrl+R находит команды даже из прошлой недели.
простая хрень, которая реально сокращает время на рутину. пользуйтесь.
Подпишись на создателей: https://t.me/linuxexex
если ты работаешь в терминале и до сих пор вручную переписываешь длинные команды из истории — ты тратишь своё время в мусорное ведро по одной минуте.
вот штука, которую знают немногие: Ctrl+R
это reverse search по истории bash/zsh. нажимаешь Ctrl+R, начинаешь вводить кусок команды — и терминал сам находит последнюю похожую из истории. не надо листать стрелками вверх двадцать раз, не надо помнить точный синтаксис.
набрал "docker run" — оно вытащило ту длинную команду с флагами, которую ты писал три дня назад. нажал Enter — готово.
хочешь следующее совпадение — жми Ctrl+R ещё раз. хочешь редактировать найденное — стрелка вправо или End, и команда встаёт в строку ввода.
работает в bash, zsh, и даже вfish если правильно настроен.
бонус для параноиков и перфекционистов: если хочешь, чтобы история была длиннее и не терялась между сессиями, добавь в.bashrc вот это
HISTSIZE=100000
HISTFILESIZE=200000
HISTCONTROL=ignoredups:erasedups
shopt -s histappend
теперь твоя история не затирается при открытии нового терминала, дубли не засоряют выдачу, и Ctrl+R находит команды даже из прошлой недели.
простая хрень, которая реально сокращает время на рутину. пользуйтесь.
Подпишись на создателей: https://t.me/linuxexex
CTRL+R все знают. Это база. А вот что реально мало кто использует — это ** в глобинге в bash и zsh.
По умолчанию в bash нужно включить его руками:
shopt -s globstar
И после этого конструкция ** начинает означать «любое количество вложенных директорий». То есть:
ls **/*.log
выдаст тебе все.log файлы рекурсивно по всему дереву. Без find, без xargs, без этого бесконечного танца с флагами.
В zsh это работает из коробки, без шопта.
Казалось бы, мелочь. Но когда ты в третий раз пишешь:
find. -name "*.conf" -exec grep -l "timeout" {} \;
и в четвёртый раз путаешься в этих скобках и слешах — вспоминаешь, что можно было просто:
grep -l "timeout" **/*.conf
Чище, быстрее, читается как человеческая речь, а не как заклинание из документации к sendmail.
Ещё один момент, который реально удивляет людей: ** работает не только в ls и grep, но и в for-циклах. Хочешь пройтись по всем Python-файлам в проекте и что-то с ними сделать — пожалуйста:
for f in **/*.py; do
echo "$f"
done
Никакого find -exec, никакого subshell, никакого головняка с пробелами в именах файлов.
Пробелы, кстати, отдельная история. Глобинг обрабатывает их корректно, если переменная в кавычках. А вот find -exec и обратные кавычки — это уже лотерея.
В общем, shopt -s globstar в.bashrc, и жизнь становится чуть менее похожей на ад.
Подпишись на создателей: https://t.me/linuxexex
По умолчанию в bash нужно включить его руками:
shopt -s globstar
И после этого конструкция ** начинает означать «любое количество вложенных директорий». То есть:
ls **/*.log
выдаст тебе все.log файлы рекурсивно по всему дереву. Без find, без xargs, без этого бесконечного танца с флагами.
В zsh это работает из коробки, без шопта.
Казалось бы, мелочь. Но когда ты в третий раз пишешь:
find. -name "*.conf" -exec grep -l "timeout" {} \;
и в четвёртый раз путаешься в этих скобках и слешах — вспоминаешь, что можно было просто:
grep -l "timeout" **/*.conf
Чище, быстрее, читается как человеческая речь, а не как заклинание из документации к sendmail.
Ещё один момент, который реально удивляет людей: ** работает не только в ls и grep, но и в for-циклах. Хочешь пройтись по всем Python-файлам в проекте и что-то с ними сделать — пожалуйста:
for f in **/*.py; do
echo "$f"
done
Никакого find -exec, никакого subshell, никакого головняка с пробелами в именах файлов.
Пробелы, кстати, отдельная история. Глобинг обрабатывает их корректно, если переменная в кавычках. А вот find -exec и обратные кавычки — это уже лотерея.
В общем, shopt -s globstar в.bashrc, и жизнь становится чуть менее похожей на ад.
Подпишись на создателей: https://t.me/linuxexex
Знаете, что вообще могло угробить Linux в зародыше?
В 1992 году Эндрю Таненбаум, профессор и автор учебной операционки MINIX, публично назвал Linux технологически отсталым и устаревшим ещё до того, как оно толком взлетело. Мол, монолитное ядро — это прошлый век, будущее за микроядрами, и вообще Линус Торвальдс написал фигню для одной архитектуры x86, которая протухнет через пять лет.
Этот срач вошёл в историю как дискуссия Tanenbaum-Torvalds и до сих пор цитируется в учебниках.
Линус не стал вежливо раскланиваться. Он ответил прямо в Usenet: да, ядро монолитное, и что с того. Потом добавил, что MINIX с её лицензией на тот момент была бесполезна для реального применения, а теории Таненбаума хороши для лекций, но не для работающего софта.
Таненбаум был прав насчёт архитектуры с академической точки зрения. Микроядра действительно чище по дизайну. Но Linux оказался прав с практической: монолитное ядро с правильно написанными модулями работало быстро, его легко было портировать, оно жрало меньше ресурсов на IPC и вокруг него сложилось сообщество, которое просто допилило всё руками.
Сегодня Linux крутится на большинстве серверов планеты, на вашем телефоне, на МКС, на суперкомпьютерах и в холодильниках умных домов. MINIX тихонько живёт в учебных аудиториях и, по иронии, внутри процессоров Intel как управляющая прошивка, о которой большинство пользователей вообще не знает.
А спор о микроядрах против монолитных до сих пор не закрыт. Просто пока что у монолитного ядра серверная стойка, а у микроядра — конспект с лекции.
Подпишись на создателей: https://t.me/linuxexex
В 1992 году Эндрю Таненбаум, профессор и автор учебной операционки MINIX, публично назвал Linux технологически отсталым и устаревшим ещё до того, как оно толком взлетело. Мол, монолитное ядро — это прошлый век, будущее за микроядрами, и вообще Линус Торвальдс написал фигню для одной архитектуры x86, которая протухнет через пять лет.
Этот срач вошёл в историю как дискуссия Tanenbaum-Torvalds и до сих пор цитируется в учебниках.
Линус не стал вежливо раскланиваться. Он ответил прямо в Usenet: да, ядро монолитное, и что с того. Потом добавил, что MINIX с её лицензией на тот момент была бесполезна для реального применения, а теории Таненбаума хороши для лекций, но не для работающего софта.
Таненбаум был прав насчёт архитектуры с академической точки зрения. Микроядра действительно чище по дизайну. Но Linux оказался прав с практической: монолитное ядро с правильно написанными модулями работало быстро, его легко было портировать, оно жрало меньше ресурсов на IPC и вокруг него сложилось сообщество, которое просто допилило всё руками.
Сегодня Linux крутится на большинстве серверов планеты, на вашем телефоне, на МКС, на суперкомпьютерах и в холодильниках умных домов. MINIX тихонько живёт в учебных аудиториях и, по иронии, внутри процессоров Intel как управляющая прошивка, о которой большинство пользователей вообще не знает.
А спор о микроядрах против монолитных до сих пор не закрыт. Просто пока что у монолитного ядра серверная стойка, а у микроядра — конспект с лекции.
Подпишись на создателей: https://t.me/linuxexex