Подробный разбор устройства Linux: от BIOS и загрузчика до ядра и системных вызовов, объяснение ключевых понятий и процессов.
Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.
Generated from the transcript and can be wrong — check the timestamp.
Key Takeaways
- Linux — это ядро, а не просто дистрибутив или ОС.
- Загрузка системы — сложный процесс с несколькими этапами и компонентами.
- Ядро обеспечивает безопасность и изоляцию процессов через виртуальную память.
- Системные вызовы — единственный легальный способ программ взаимодействовать с оборудованием.
- Монолитная архитектура ядра обеспечивает высокую производительность, но повышает риски сбоев.
What the video covers
- Linux — это ядро, управляющее железом, а не просто операционная система.
- Процесс загрузки начинается с BIOS/UEFI, который запускает POST и ищет загрузчик GRUB.
- GRUB загружает ядро Linux (vmlinuz) и initramfs — временный диск с драйверами для монтирования настоящего диска.
- Ядро работает в Ring 0 — режиме с полными правами, объединяя драйверы и подсистемы в монолитном пространстве.
- Основные задачи ядра: управление памятью с помощью виртуальной памяти, планирование процессов и абстракция оборудования.
- Виртуальная память обеспечивает изоляцию процессов и возможность свопинга, а oomkiller убивает самые ресурсоёмкие процессы при нехватке памяти.
- Планировщик процессора реализует вытесняющую многозадачность, переключая процессы по квантам времени.
- Ядро предоставляет универсальный интерфейс для работы с оборудованием, скрывая аппаратные детали от пользовательских программ.
- Между user space и kernel space существует строгая граница, доступ к оборудованию возможен только через системные вызовы.
- Пример системного вызова показан на примере Python, где вызов write проходит через libc и ядро для записи данных.
Chapters
- 00:00Введение и определение Linux
- 01:41Загрузка ядра и роль GRUB
- 02:56initramfs и pivot root
- 04:35Управление памятью и oomkiller
- 06:23Планировщик процессов и многозадачность
- 07:23Абстракция оборудования ядром
- 07:58Системные вызовы и взаимодействие user space с ядром
- 09:42Запуск первого процесса и дальнейшая работа системы
Full Transcript — Download SRT & Markdown
Speaker A
Всем привет. Вы на канале Просто DevOps. Мы часто говорим слово Linux, подразумевая операционную систему Ubuntu, CentOS, Debian, но с инженерной точки зрения это неверно. Linux — это ядро. По сути, кусок кода, который управляет железом. А всё, что мы видим
Speaker A
на экране, всё, с чем мы взаимодействуем — это просто набор программ, которые крутятся поверх этого ядра. И в этом видео мы разберёмся, как этот самый Linux устроен. Начнём с самого низа, а именно с железа. Нажимаем кнопку питания на сервере. Пошёл ток. Процессор
Speaker A
просыпается, но в этот момент он пока что тупой кусок кремния. Он не знает, что такое Linux. Он не знает, что такое файлы. Он даже не знает, сколько у него оперативной памяти. Он просто ищет первую инструкцию по жёстко заданному
Speaker A
адресу. Первый стартует прошивка материнской платы BIOS или же UEFI. Её задача — привести железо в чувство. Она запускает POST power on self-test, проверяет, есть ли память, работает ли видеокарта, инициализировался ли процессор, нашёл ли он оперативку и так далее. Затем она начинает опрашивать
Speaker A
устройства и ищет, с кого можно загрузиться. Допустим, она нашла жёсткий диск, но BIOS сам не умеет читать файловые системы. Он не знает, что такое EXT4 или XFS. Он не может просто взять и открыть файл, поэтому он считывает самые первые
Speaker A
512 байт диска. Это MBR или же смотрит в специальный EFI раздел. А там живёт загрузчик. В мире Linux — это почти всегда GRUB 2. GRUB — это маленькая, но умная программа. Её единственная способность — она умеет читать файловую систему. Заглядывает в раздел boot. Там
Speaker A
лежат два критически важных файла, без которых никакой магии не случится. Первый файл — это vmlinuz Linux. По сути, и есть тот самый Linux. Это само ядро, сжатое в бинарный файл. Буква z в конце означает zip, то есть сжатый. GRUB берёт
Speaker A
этот файл, распаковывает его прямо в оперативную память и передаёт ему управление. Всё. С этого момента BIOS уходит курить в сторонку, загрузчик умирает. Теперь в системе только один босс — это ядро. И [музыка] вот тут ядро сталкивается с главной инженерной
Speaker A
проблемой, проблемой курицы и яйца. Ядро загрузилось в память. Его задача — смонтировать наш основной диск, чтобы запустить систему. Но чтобы смонтировать диск, нужны драйверы файловой системы и контроллера диска. А где лежат драйверы?
Speaker A
Правильно, на том самом диске, который мы ещё не можем прочитать, потому что у нас нет драйверов. Замкнутый круг.
Speaker A
Именно для этого GRUB загрузил второй файл initramfs. Это маленький временный архив, который разворачивается в оперативной памяти как виртуальный диск.
Speaker A
Внутри него лежит мини-версия Linux с минимальным набором драйверов. Соответственно, что происходит? Ядро монтирует initramfs как временный корень. Оттуда оно подгружает драйверы для нашего реального железа:
Speaker A
RAID-контроллеры, NVMe, LVM и так далее. Далее оно находит настоящий большой диск и делает трюк под названием pivot root, то есть смена корня. Ядро выкидывает временный диск из памяти и заменяет его настоящим. Если сервер виснет на этапе загрузки с ошибкой, которую вы видите на
Speaker A
экране, это значит, что ядро застряло именно в этом моменте. Оно либо не нашло initramfs, либо внутри него не оказалось нужного драйвера для диска. Итак, загрузчик отработал, драйверы подгрузились, мы попадаем в kernel space. С точки зрения архитектуры процессора мы находимся в кольце защиты
Speaker A
Ring 0. Здесь разрешено всё: любая инструкция процессора или любой адрес памяти. Linux — это монолитное ядро, а не набор разрозненных сервисов. Драйвер видеокарты, сетевой стек TCP/IP, драйвер файловой системы EXT4. Всё это варится в одном гигантском котле в едином адресном
Speaker A
пространстве. И это даёт дикую производительность, потому что нет накладных расходов на общение между компонентами. Но это повышает риски.
Speaker A
Если драйвер кривой видеокарты упадёт, он утащит за собой весь сервер в kernel panic. [музыка] А у самого ядра есть три основных задачи. Сейчас посмотрим на каждую из них. Первое — это управление памятью. И на самом деле здесь главная
Speaker A
задача ядра — врать. Оно врёт нашим программам. Когда условный engines или Python просит память, он думает, что единственный в системе. Для него [музыка] всё выглядит как красивая непрерывная лента адресов. Хотя на самом деле физическая память фрагментирована, и куски данных разбросаны хаотично. Ядро
Speaker A
использует механизм виртуальной памяти. Оно ведёт гигантскую таблицу, где записано: "Виртуальный адрес X для процесса Ins на самом деле лежит в физической ячейке Y". И это даёт две вещи. Первое — изоляция. Один процесс физически не может залезть в память
Speaker A
другого. А второе — это свопинг. То есть ядро может незаметно выгрузить часть данных на диск, если оперативка закончилась. Но если память кончилась совсем и своп тоже забит, то приходит oomkiller. И он неспроста так назван. Это буквально киллер, который нанят ядром. Он
Speaker A
просыпается, сканирует таблицу процессов и находит того, кто ест больше всех и имеет при этом низкий приоритет, и пускает ему пулю в лоб. Например, в том же Kubernetes это происходит постоянно. Если мы неправильно настроим лимиты в кластере, то oomkiller будет приходить и молча
Speaker A
убивать наше приложение. Вторая задача ядра — делить время между процессами. И для этого существует так называемый планировщик процессора. Допустим, у нас на сервере четыре ядра, а запущено 500 процессов. Как они работают одновременно? [музыка] Никак. Это иллюзия. Ядро использует вытесняющую многозадачность. Оно даёт процессу
Speaker A
проработать несколько миллисекунд, так называемый квант времени, а потом жёстко его останавливает, и происходит свитч контекста. То есть ядро сохраняет состояние регистров процессора [музыка] для текущей задачи, загружает состояние для следующей задачи и нажимает Play. И это происходит тысячи раз в секунду.
Speaker A
Если мы видим в мониторинге высокий load average, но процессор не загружен на 100%, возможно, система тратит всё время не на работу, а на бесконечное переключение контекста между тысячами процессов. А про load average у нас, кстати, было видео. Вот оно. Ну и третья
Speaker A
задача ядра — это абстракция оборудования. Если говорить по-простому, то ядро выступает в качестве переводчика. Программы, которые запущены в user space, то есть наши программы пользовательские, не знают железа. Вот условно у нас есть программа на Python, которая записывает одно слово в файл, но
Speaker A
только Python не знает, куда он записывает. На самсунговскую SSD, на какой-то старый жёсткий диск или вообще на сетевую шару. У каждого диска свой протокол, свои вольтажи, свои команды контроллера, а ядро предоставляет универсальный интерфейс.
Speaker A
Программа буквально говорит: "Пиши в этот файл". А драйвер ядра переводит это в электрические сигналы. И благодаря этому наш код работает одинаково на любом железе. Двигаемся выше. У нас есть ядро, которое всем управляет. И есть наши программы, которые хотят что-то
Speaker A
сделать: прочитать файл, отправить пакет или вывести текст на экран. Но есть проблема. Между режимом пользователя, где живут наши программы, и режимом ядра стоит бетонная [музыка] стена.
Speaker A
Процессор физически запрещает коду из user space обращаться к оборудованию. И если наша программа пытается напрямую обратиться к диску, процессор немедленно её убьёт с ошибкой Segmentation Fault. И как же нам быть? На самом деле, в этой стене есть одна единственная бронированная дверь. Она называется
Speaker A
системный вызов. Это строго регламентированный API. Ядро говорит, что оно не пустит нас к диску, но если мы вежливо попросим через специальную функцию, то оно сделает это за нас. И давайте рассмотрим это на примере того же Python. Вот мы пишем print Hello
Speaker A
World, но происходит целая цепочка событий. Интерпретатор Python вызывает стандартную библиотеку C libc. Библиотека формирует системный вызов write. Она кладёт аргументы в регистры процессора и генерирует специальное программное прерывание. Процессор останавливает программу, переключает режим в ring 0, тот самый режим бога, о котором мы
Speaker A
говорили в самом начале, и передаёт управление ядру. Ядро проверяет, а есть ли у этого юзера права писать в этот файл. И если всё окей, то ядро рисует пиксел...
Speaker A
программе. И на самом деле системных вызовов великое множество, их в районе 300-400. Но основные сисколы, которые нужно знать, на которых держится вся база, сейчас у вас на экране. Это Fork Exeg, это Open и Close, это Rit и Right,
Speaker A
это Socket и Connect. Но зачем это знать именно Divпсу? А потому что программы часто врут. Логи могут быть пустыми, а ошибки неинформативными. Но программа не может врать [музыка] ядру. Она обязана давать все ссколы, чтобы хоть что-то сделать. И здесь на сцену выходит самый
Speaker A
главный инструмент отладки Sraйс. Это прослушка для сисколов. Мы запускаем Sraйс на какой-то процесс и видим всю подноготную, что он пытался сделать, [музыка] что он получил или на чём он завис. Sraйс - это рентген. Он показывает нам, что программа пытается
Speaker A
сказать ядру на самом деле. И если вы умеете читать выводст, то для вас не существует непонятных багов. Продолжаем двигаться вверх по стеку. Ядро загрузилось, инициализировало память и драйверы, но сервер всё ещё пустой. В нём нет ни СШ, ни консоли, ни сети.
Speaker A
Чтобы система ожила, ядро должно запустить самый первый процесс в пространстве пользователя. И для этого оно ищет на диске исполняемый файл по адресу sbin/it и запускает его. Этот процесс получает ПиIT 1, его уникальный айдишник. Все остальные процессы в системе Пит 2, 3, 4.000, 10.000
Speaker A
будут потомками этого процесса. Если первый процесс умрёт или завершится, яро решит, что система сломалась и вывалится в KNAL Pic и сервер встанет. А в современном Линуксе роль первого процесса выполняет System D. А почему именно System D? Раньше, во времена
Speaker A
CSway и процессы запускались тупо по очереди. Сначала сеть, потом диск, потом база. Это было долго. System D работает как менеджер зависимостей. Он строит направленный граф, кстати, как в тероформе. Условно говоря, он видит так: зависит от сети, пагress зависит от
Speaker A
диска, а SSH ни от чего не зависит и запускает всё это параллельно, максимально утилизируя процессор при загрузке. А что физически делает Systemd при старте? Во-первых, он монтирует реальные диски в дерево каталогов.
Speaker A
Во-вторых, он определяет цель загрузки и, в-третьих, [музыка] начинает поднимать юниты. запускает SSHD, чтобы мы могли подключиться, запускает демон докера, чтобы поднялись контейнеры, и так далее. При этом мы, как админ, не можем просто сказать процессу: "Запустись". Мы общаемся с пиtit
Speaker A
System CTL. Когда мы пишем System CTL start Engines, по сути, мы отправляем команду System D через определённый сокет. System D, есть ли у нас права, смотрит в зависимости инжинкса и выполняет системный вызов Fork, то есть создаёт копию себя, и exeg, то есть
Speaker A
заменяет копию на бинарник Инжнкса. Так рождается процесс веб-сервера. Он ребёнок систем D. Итак, процессы запущены, но процессы в вакууме бесполезны. Им нужно читать конфиги, писать логи, сохранять картинки. Мы поднимаемся ещё на следующий уровень абстракции файловой системы. И здесь царит главная философия
Speaker A
Unix. Всё есть файл. Но давайте разберём это не как лозунг, а как инженерное решение. В винде все привыкли к буквам дисков C, D, E, F и так далее. Это физическое разделение устройств. В Линуксе подход другой. [музыка] Здесь существует единое дерево каталогов. Оно
Speaker A
всегда начинается с корня, то есть символа слыша. Процессу плевать, сколько у нас дисков. Он видит только дерево. Ну и, соответственно, как это работает физически. Внутри ядра есть прослойка VFS. Виртуальная файловая система. Это точно также универсальный интерфейс. Мы берём условный SSD-диск и говорим ядру.
Speaker A
Примонтирую его в папку boot. Потом берём сетевой диск и говорим примонтировать его в другой каталог.
Speaker A
Берём оперативную память и монтируем её в RН. Для программы всё это выглядит одинаково. [музыка] Она просто пишет файлы по путям, а ВФэска сама на лету решает, куда отправить эти байты. По кабелю SAD или по сетевому кабелю на другой сервер. Это и есть прозрачность
Speaker A
абстракции. Теперь спускаемся ниже. Что такое файл физически? Для нас [музыка] это просто какое-то название, условно photo. JPG, но для ядра имя - это пустой звук. Просто набор байт для удобства кожаного мешка. Для ядра файл - это iнода, индекс нода. Каждый файл в
Speaker A
системе - это просто номер. В айноде хранится вся метаинформация, кроме имени: кто владелец, какие права доступа, размер файла, тайм-стампы и самое главное, указатели на сектора диска, где физически лежат нулее единицы. А что тогда такое имя файла?
Speaker A
Имя живёт в каталоге. И технически каталог, то есть папка - это тоже файл, но внутри него лежит простая таблица из двух колонок: имя файла и номерноды. И когда мы, например, выполняем команду C и передаём ей имя файла, то ядро в этот
Speaker A
момент читает каталог, находит имя, берёт соответствующий номер иноды, потом идёт в таблицу ит, смотрит права и сектора диска и после этого начинает читать данные. Ну, а теперь давайте раскроем концепцию всё есть файл на полную. Помните, мы говорили, что VFS -
Speaker A
это абстракция? Так, разработчики Линукса подумали: "А зачем нам ограничиваться дисками? Давайте представим само ядро в виде файлов".
Speaker A
Итак, появились папки проs и SIS. В них нет файлов на диске. Размер этих файлов 0 байт. Это иллюзия, но это прямой интерфейс доступа к структурам данных ядра в оперативной памяти. И, например, когда мы читаем файл процpu ядро не идёт на диск, оно опрашивает
Speaker A
процессор и генерирует текст ответа на литу. И самое крутое - это работает в обе стороны. Мы можем писать в эти файлы. Хотим включить маршрутизацию пакетов, то есть стать роутером. Нам не надо искать никакую галочку ни в какой панели управления. Мы просто пишем цифру
Speaker A
один вот в этот файл, который показан на экране. Ядро перехватывает эту запись и меняет переменную в своём коде. Вот что значит всё есть файл. Это универсальный апи для управления системой. Мы разобрались с хранением, то есть с нашими файловыми системами. Теперь
Speaker A
переходим к исполнению. Что такое запущенная программа? Это процесс. Процесс - это изолированный контейнер в памяти, у которого есть свой PID, свои переменные и свои ресурсы. Но процесс в вакууме бесполезен. Ему нужно получать данные и отдавать результат. И здесь
Speaker A
снова работает правило, всё есть файл. Когда ядро запускает любой процесс, оно автоматически открывает для него три файла, то есть три канала связи. В таблице файловых дескрипторов они всегда занимают первые три строчки. Первый из них, хотя, вернее сказать, нулевой - это
Speaker A
DDIN, то есть стандартный ввод. По умолчанию этот файл привязан к нашей клавиатуре. Процесс читает оттуда то, что мы печатаем. Второй - это D out, то есть стандартный вывод. По умолчанию этот файл привязан к нашему экрану, ну или же терминалу. Сюда летит результат.
Speaker A
Иdr, стандартный вывод ошибок тоже привязан к экрану, но это отдельный поток. А зачем разделили stdout и stdr?
Speaker A
На самом деле, чтобы мы могли отличить мух от котлет. Если программа работает и сыпет ошибками, мы можем сказать оболочки. Полезные данные, то есть первый индекс, записать в файл data.txt, а ошибки, то есть второй индекс, просто выкинуть в defnal чёрную дыру. В девопсе
Speaker A
это база логирования. А теперь переходим к главной магии Linux, символу вертикальной черты Pйpe. Это механизм межпроцессного взаимодействия. Возьмём вот эту команду. Как она работает? Ядро запускает процесс C и процесс греп одновременно, но для CAT оно подменяет stdout, то есть выход, и вместо экрана
Speaker A
оно направляет его в специальный буфер памяти пайп. А для ГЕБ ядро подменяет его, то есть вход. И вместо клавиатуры он подключает его к тому же самому буферу. И в чём гениальность? Процессы КТ и ГП не знают о существовании друг
Speaker A
друга. Кэт думает, что пишет на экран, а Греб думает, что читает с клавиатуру. Ядро просто переткнуло провода, и это позволяет строить конвейеры любой длины.
Speaker A
Вот посмотрите на экран. Пять глупых маленьких программ, соединённых пайпами, превращаются в мощный инструмент аналитики. Это и есть подход Юникса.
Speaker A
писать программы, которые делают одну вещь, но хорошо, и научить их работать вместе через текстовые потоки. Мы разобрались, как процессы работают и как данные летают по пайпам. Но кто решает, кому можно читать файл, а кому нельзя?
Speaker A
Мы поднимаемся [музыка] на уровень безопасности. В Линуксе безопасность - это не магия антивируса, это простая проверка битов в Вайноде.
Speaker A
Когда мы логинимся в систему, мы думаем, что пользуемся админкой. Но ядро не знает слов. Ядро знает только цифры.
Speaker A
Наше имя транслируется в UID, user ID. Наша группа транслируется в Git, Group ID. Это база данных соответствии лежит в простых текстовых файлах PVD и etcoup. И помните, мы говорили пройноды. В каждой аноде записано: "Этим файлом владеет UID такой-то, группа [музыка] такая-то. И
Speaker A
там же записаны три набора прав: usеer, то есть, что может делать владелец, group, то есть, что может делать группа, иers, что может делать любой другой рандомный процесс. А сами действия примитивны: read, [музыка] то есть читать, write, то есть изменять, и
Speaker A
execute, то есть сказать ядру, загрузить [музыка] этот файл в память и исполнить как процесс. И каждое действие имеет своё число. read 4, write 2, execute 1.
Speaker A
Почему именно это? Это не случайные цифры. Это битовая маска в двоичной системы. Чтение - это 100, запись - это 0,10, исполнение - это 01. И когда мы пишем условно чмот 755, мы просто складываем биты. 7 - это 4 + 2 + 1.
Speaker A
Владелец [музыка] может всё. 5 - это 4 + 0 + 1. То есть группа может читать и исполнять, но [музыка] не писать. Ну и ещё раз пятёрка для всех остальных. И здесь есть важный нюанс. Право [музыка] X, то есть execute для каталога означает
Speaker A
не запуск, а возможность в него попасть. Если у нас есть права на чтение папки, но нет права на вход, то мы можем увидеть список файлов, но не можем прочитать их метаданные. Но у всех правил есть исключение. [музыка] В
Speaker A
Линуксе есть один пользователь, для которого ядро отключает проверку прав. Это [музыка] root. У него всегда UID0.
Speaker A
Когда процесс UID0 делает CS call open, ядро не смотрит в айноду, оно просто открывает файл. Root может читать etcad, где лежат хэши паролей, может убить процессы и ниты, положить сервер, может отформатировать диск на живой системе, поэтому сидеть под рутом - это дурной
Speaker A
тон и риск. Для администрирования используется [музыка] механизм суда. Это утилита с особым битом SUID, которая временно повышает наш UID до нуля, выполняет одну команду и, что критически важно, записывает это в лок аудита. Так мы получаем безопасность без потери
Speaker A
контроля. И вот мы поднялись на самый верхний уровень userspace. У нас есть [музыка] ядро, есть файловая система, есть права, но система всё ещё голая.
Speaker A
Нужен софт, веб-серверы, база данных, утилиты. Как программы попадают в Linux? В Виндоусе все привыкли делать, как идём на сайт, качаем экзэшник, кликаем Next, и каждая программа тащит с собой свои собственные библиотеки. В Линуксе принят инженерный подход. Централизованные репозитории. Это проверенные склады
Speaker A
бинарных пакетов, которые поддерживаются разработчиками вашего дистрибутива. Здесь работает пакетный менеджер АТ, Яма, ПК. Когда мы пишем APT installings, происходит не просто скачивание.
Speaker A
Пакетный менеджер - это умный архиватор с базой данных. Он скачивает топ или то rpm пакет, распаковывает файлы строго по стандарту FHS, то есть бинарник [музыка] кладёт в userbin, configги в etc, сервисный файл в lipstem [музыка] D system. Ну а самое важное, он проверяет,
Speaker A
есть ли у нас нужны библиотеки. Почему это важно? Потому что Linux экономит ресурсы. Программы в Линуксе почти всегда динамически слинкованы. Это значит, что бинарник Джинкса весит копейки. В нём нет кода шифрования, в нём нет кода сжатия. Вместо этого он
Speaker A
просто [музыка] при запуске говорит ядру: "Мне нужна такая-то библиотека". И ещё вот такая. А сами эти библиотеки шареные. Они лежат в системе в одном экземпляре, обычно в Userер и когда мы запускаем условный Engin SSH клиент и Python Script, все они используют один и
Speaker A
тот же файл библиотеки. Ядро загружает её в оперативную память один раз, и все процессы просто получают ссылку на этот участок памяти. И это колоссально экономит оперативку, но при этом создаёт сложность. Версии библиотек должны совпадать. Именно поэтому нам нужен
Speaker A
пакетный менеджер, а не ручное скачивание файлов. Он следит, чтобы версия библиотеки в системе подходила всем установленным программам. А если этот карточный домик рушится, это называется Dependency Hell, то есть ад зависимостей. [музыка] Но в современных дистрибутивах это случается крайне редко. Ну и теперь
Speaker A
давайте соберём этот пазл воедино. Мы прошли путь от холодного кремния до нашей клавиатуры. Теперь у вас в голове должна быть не каша из команд, а чёткая вертикальная структура. Смотрите на Linux как инженер. Внизу лежит тупое железо, которое разбудил BIOS. Над ним
Speaker A
стоит диктатор. Ядро. Оно врёт программам про память, нарезает время процессора и управляет драйверами. Между ядром и миром бетонная стена с одним окошком. Никто не проходит мимо. Ядро запускает первого рабочего, который строит всё окружение юзерспейса. И всё это пространство организовано в единое
Speaker A
дерево, где каждый файл - это просто номер с правами доступа. И на самой вершине сидим мы. Если держать в голове эту схему, магия исчезает. Остаётся чистая, сухая логика. Больше не придётся гуглить ошибки вслепую. Увидим проблему Permission Dight и поймём, что это не
Speaker A
просто Linux абстракт на ругается, а это ядро при выполнении Cisc Open, сверило наш UID с битами в айноде и вернула код ошибки. А когда сервер тормозит, то есть высокий loadт average, мы понимаем, что это не процессор устал, а это очередь
Speaker A
процессоров в планировщике стала слишком длинной, и система тратит ресурсы на переключение контекста. А когда нас спрашивают про докер, мы улыбаемся, потому что знаем, что нет никакого докера. Есть просто грамотное использование [музыка] неймспейсов и сигрупсов, которые ядро предоставляет любому процессу. Это и есть инженерное
Speaker A
мышление. Иникейщик учит команды наизусть, а инженер понимает, как текут байты. Команду можно нагуглить за 5 секунд, а понимание архитектуры нагуглить нельзя, его можно только наработать. И у нас в Телеге мы подготовили для вас полную карту архитектуры Linux одним пдфом. Там
Speaker A
расписаны основные сисколы, структура файловой системы и этапы загрузки. Это ваша шпаргалка, чтобы картинка всегда была перед глазами. Забираете её в нашем Телеграме, ссылка в описании.
Speaker A
Перестаньте быть просто пользователями, становитесь инженерами, смотрите в корень. И пока-пока. По
Topics:Linuxядро Linuxзагрузка LinuxBIOSGRUBinitramfsвиртуальная памятьпланировщик процессовсистемные вызовымонолитное ядро











