Какие операции замедляют работу компьютера в многозадачных системах linux
Linux дает много преимуществ своим пользователям. Например, его можно считать свободным от вирусов, поскольку их существует очень небольшое количество. Для многих очень важно, что никто, кроме вас, не будет контролировать то что вы делаете в системе. Свободное программное обеспечение звучит очень привлекательно, в свете последних событий, когда в прошлом году мы узнали что большие компании вроде Microsoft и Apple следят за своими пользователями.
Свободное программное обеспечение становится очень актуальным если вы не хотите платить за использование самой новой версии операционной системы.
Многие помнят, что кликнув двойным щелчком по ярлыку в Windows нужно достаточно долго подождать, пока запустится программа. Здесь у Linux тоже преимущество - он намного быстрее. И это касается всех, кто использует компьютер с новеньким восьмиядреным процессором, и тех у кого старый ноутбук прошлого века. Если вы хотите еще больше скорости в Linux, следуйте инструкциям из этой статьи. Дальше мы рассмотрим как ускорить Linux. Мы будем ориентироваться в первую очередь на Ubuntu, но все эти советы могут быть применены также к другим дистрибутивам.
Используйте VirtualBox
Некоторые из приведенных здесь советов включают модификацию системных файлов от имени root пользователя. При таком способе редактирования всегда есть шанс случайно что-нибудь сломать и сделать ваш компьютер неработоспособным. Поэтому лучше сделайте резервную копию всех файлов, с которыми вы будете работать, чтобы потом при необходимости восстановить старые настройки.
Еще лучше поэкспериментировать сначала с виртуальной машиной. Таким образом, вы можете делать все что захотите, а потом просто откатиться к последнему рабочему снимку.
Как ускорить Linux
1. Ускорение загрузчика Grub
Если у вас установлено две операционные системы, то вы, наверное, знакомы с этим меню загрузки. Но то что вы, скорее всего, не заметили, это обратный отсчет в самом низу, под областью ввода. Это время, на протяжении которого система будет ждать, перед тем как начать загружать дистрибутив по умолчанию.
Например, в Ubuntu - это 10 секунд. Обычно вы можете нажать Enter, но если вы находитесь далеко от машины, более благоразумным будет поставить интервал покороче, например, 3 секунды. Этого будет вполне достаточно чтобы выбрать ОС.
Чтобы ускорить загрузку Linux откройте файл /etc/default/grub от имени root. Измените значение GRUB_TIMEOUT = 10, на 3.
sudo vi /etc/default/grub
А затем обновите конфигурацию Grub. Вот:
sudo grub2-mkconfig -o /boot/grub/grub.cfg
2. Отключите сервисы
Во время загрузки системы, есть огромная разница между загрузкой ядра и готовностью к работе рабочего стола. Дело в том, что система загружает очень больше количество сервисов, и не все из них вам нужны. В большинстве современных дистрибутивов используется система инициализации systemd. У этой системы инициализации есть специальная утилита, позволяющая проанализировать какие сервисы сколько времени заняли во время загрузки. Это systemd-analyze:
Кроме того, вы можете посмотреть все сервисы списком, добавленные в автозагрузку:
systemctl list-unit-files --state=enabled
Определить какие сервисы, нужны, а какие нет, вы можете просто выполнив поиск в интернете. Во многих дистрибутивах есть графические приложения для управления сервисами, но, в Ubuntu для этого придется воспользоваться консольной утилитой systemctl, это поможет сильно ускорить работу linux. Чтобы отключить сервис выполните:
sudo systemctl disable имя_сервиса
3. Отключите приложения
Приложения, запускаемые по умолчанию после старта оболочки тоже могут сильно замедлять запуск системы. В Gnome есть утилита Приложения запускаемые по умолчанию, которую можно открыть из главного меню:
Удалите оттуда все приложения, которые вы не используете. Для отключения автозагрузки можно просто снять галочку напротив программы.
4. Ускорение файлового менеджера
Файловый менеджер в Gnome по умолчанию при открытии каждой папки выполняет быстрое сканирование всех файлов, чтобы показать миниатюры и дополнительную информацию. В принципе это быстрое сканирование, но в папке с большим количеством файлов, этот процесс будет совсем небыстрым.
Чтобы перестать тратить процессорное время на эту задачу кликните по иконке бутерброда, затем выберите пункт Параметры:
В открывшемся меню перейдите на вкладку Поиск и предпросмотр файлов, в разделе Миниатюры измените параметр из Всегда или Только локальные файлы на Никогда.
Вы увидите, что теперь Nautilus работает намного быстрее.
5. Используйте легкое окружение
Для слабого оборудования принято выбирать более легкие дистрибутивы. В них меньше ненужных программ, а самое главное - используется более легкое окружение рабочего стола. Вы можете установить легкое окружение или даже легковесный оконный менеджер в свою систему. Если вы используете тяжелые окружения вроде KDE или Gnome, попробуйте что-либо более простое. Это даст значительный прирост производительности.
Самая важная задача рабочего окружения - управлять запущенными графическими программами, и давать вам достаточно контроля над ними. Но такие окружения могут выполнять намного больше функций чем вам нужно. Вы можете попробовать XFCE, LXDE или какой либо оконный менеджер. Они ещё более лековесны и быстры. К самым популярным можно отнести Openbox, Fluxbox, i3wm, awesome и другие.
Кроме того, вы можете использовать легкий оконный менеджер вместо стандартного оконного менеджера окружения. Для этого, например, после установки для запуска оконного менеджера openbox наберите:
Через несколько секунд вы увидите, что стиль окон изменился. Это и есть Openbox. с помощью контекстного меню вы можете перемещать окна, закреплять или устанавливать поверх других. Но больше ничего другого. Ваши окна теперь двигаются быстрее.
6. Ускорьте KDE
Если вы используете окружение рабочего стола KDE, то у вас есть отличный шанс получить ускорение работы linux. Хотя Plasma работает довольно быстро если у вас современная машина, но это сложный стек программного обеспечения. Каждый компонент KDE может быть настроен для более эффективной его работы. Мы уже рассматривали как ускорить KDE, читайте об этом подробно в отдельной статье.
7. Заблокируйте рекламу
При просмотре веб-страниц вы заметите что сайт загружается не сразу, он ждет пока будут загружены все компоненты страницы, в том числе и рекламные объявления. Flash анимация очень раздражает при большом количестве блоков на странице, поэтому вы можете ее заблокировать (не нужно этого делать на нашем сайте, мы белые и пушистые).
Для большинства популярных браузеров - Chromium, Firefox, Opera есть расширение AdGuard или AdBlock, которое отлично справляется с этой функцией. Программа использует базу данных чтобы заблокировать наиболее популярные источники объявлений.
8. Используйте сочетания клавиш
Кому-то это может показаться очевидным. Работа только с клавиатурой намного быстрее, чем движение от мышки к клавиатуре и обратно. Много функций можно сделать с помощью клавиатуры. Например, стандартные команды копирования и вставки из меню правка.
Стоит создать сочетания клавиш для всех часто используемых действий. Например, переключение между приложениями и рабочими столами. Вы можете пойти еще дальше и использовать в качестве текстовых редакторов vim и emacs.
Интерфейс запуска приложений открываемый по Alt+F2 может сделать намного больше. Например, вы можете набрать Выключить для выключения или Заблокировать для блокировки экрана. Вы можете выполнять простые расчеты начав выражение со знака =. Там есть еще много подобных функций в зависимости от плагинов. Наберите знак ? и нажмите стрелку вправо чтобы узнать подробнее. В качестве текстового редактора можно использовать Vim, также для многих сред разработки есть расширения, обеспечивающие поддержку сочетаний клавиш из Vim.
9. Пропатчите ядро
Если вам нужна максимальная производительность программного обеспечения, то множество исправлений можно внести в ядро. Оптимизация ядра Linux может дать отличный эффект. Вы можете оптимизировать ядро самостоятельно, но есть и более легкий путь. Вы можете использовать ядро, скомпилированное Con Koliva, оно включает огромное количество патчей производительности. Патчсет ядра называется -ck и он был собран с упором на производительность.
Чтобы его установить, вам нужно скачать исходные тексты ядра, той версии на которую рассчитаны эти патчи. Затем скачайте сам патч и выполните команду в папке с исходниками ядра:
patch -p1 < patch-5.*-ck1
Теперь соберите ядро в соответствии с инструкциями из вашего дистрибутива. Это проще сказать чем сделать, но в интернете есть очень много инструкций, в том числе на нашем сайте - собираем ядро Linux.
10. Разгон видеокарты
Не нужно использовать BIOS, для видеокарт Nvidia была создана утилита с помощью которой можно выполнить разгон видеокарты. Но чтобы включить поддержку разгона вам надо добавить одну строчку в файл /etc/X11/xorg.conf. В современных дистрибутивах такого файла обычно нет, но его можно создать выполнив:
После того как файл /etc/X11/xorg.conf будет создан откройте его в текстовом редакторе с правами root, найдите секцию Device который описывается ваша графическая карта и добавьте в конец секции для регулирования оборотов кулера:
Option "Coolbits" "5"
Или для разгона:
Option "Coolbits" "8"
Затем перезапустите Х сервер. Утилиту можно установить с помощью из FlatHub. В самой программе вы можете создать профиль разгона для видеокарты увеличив частоту памяти и графического ядра, а также регулировать обороты кулера.
Каждый раз когда вы меняете параметры, изменяется тепловыделение. Убедитесь что температура остается в разумных пределах. Как только настроите все параметры, добавьте утилиту в автозагрузку, чтобы она загружала параметры при старте системы.
Есть ещё один способ увеличить производительность видеокарты. Утилита Nvidia XSettings на вкладке PowerOptimizer позволяет не только менять частоту графического ядра, но и выбирать профиль производительности. Вы можете включить профиль Prefer maximum performance:
11. Разгон оборудования
Разгон и различные трюки с увеличением параметров выше рекомендуемых скоростей и температур может повредить ваши данные и привести к поломке вашего оборудования и это очень хорошее ускорение linux. Но многие компоненты сейчас разработаны с учетом больших нагрузок, чем их стандартная конфигурация. Этот запас оставляет много места для экспериментов.
Многие материнские платы включают в себя пункты по умолчанию, для повышения скорости системы, без необходимости больших знаний в области компьютера.
Вы можете настроить все это в своем BIOS. Для доступа к нему используйте клавиши F2 или Del. Возможно, вы найдете там опции для ускорения процессора, увеличения частоты оперативной памяти и т д. Но после разгона не забывайте протестировать стабильность процессора и следить за температурой с помощью консольной утилиты sensors или графической xsensors:
12. Отключите IPv6
Linux уже очень давно поддерживает протокол IPv6, но если вы его не используете, то его отключение может повысить быстродействие сети, таким образом, выполнив ускорение Linux при работе с сетью. Самый простой способ сделать это через NetworkManager.
Откройте настройки вашего подключения к сети, перейдите на вкладку IPv6 и выберите пункт Выключить:
Браузер Firefox тоже позволяет отключить ipv6. Просто наберите в адресной строке about:config и активируйте пункт network.dns.disableIPv6.
Кроме того, можно отключить IPv6 на уровне всего дистрибутива. На этом сайте уже есть статья об этом: Как отключить IPv6 в Ubuntu.
13. Статическая линковка
Многие программы подгружают для своей работы библиотеки динамически, во время работы программы. На это уходит не очень много времени, но если приложения большие и подгружают много библиотек, то статическая линковка может дать отличное ускорение Linux. Для этого используются утилиты preload и prelink.
Prelink преобразует исполняемые файлы таким образом, чтобы они загружали как можно меньше библиотек. Preload же следит за системой и держит в памяти часто используемые программы. После небольшой калибровки хорошо чувствуется оптимизация Linux. Сначала установите Prelink:
sudo apt install prelink
Затем запустим утилиту для обработки всех исполняемых файлов:
sudo prelink --all
Для периодичного запуска prelink, чтобы выполнялась оптимизация Linux для новых файлов, откройте файл /etc/default/prelink и замените строчку PRELINKING=unknown на yes:
sudo vi /etc/default/prelink
Далее установите Preload:
sudo apt install preload
Эту программу достаточно только установить, она не требует настройки после установки.
14. Используйте ZRAM
Если у вас недостаточно оперативной памяти, вы можете очень просто увеличить ее количество на 25, а то и 50% с помощью сжатия оперативной памяти zram. Это модуль ядра, который позволяет сжимать содержимое оперативной памяти на лету, таким образом вместимость ОЗУ остается увеличивается, а скорость остается прежней. Это даст хорошее ускорение работы Linux для старых компьютеров.
15. Уменьшите активность жесткого диска
Система очень активно пишет и читает файлы из каталога /tmp. Это каталог для временных файлов, и с ним могут одновременно работать большое количество программ. Будет лучше, если содержимое этого каталога будет находиться в оперативной памяти. Чтобы ускорить работу linux, таким образом, добавьте строчку в файл /etc/fstab:
sudo vi /etc/fstab
tmpfs /tmp tmpfs defaults,noexec,nosuid 0 0
Но сначала убедитесь не примонтирована ли уже папка tmp в оперативную память, выполнив команду mount. Во многих дистрибутивах эта оптимизация linux включена по умолчанию.
16. Настройте работу подкачки
Не все системы рационально используют пространство подкачки на жестком диске. По умолчанию значение vm.swappiness установлено 60:
Поэтому, если (100-60) 40% оперативной памяти занято, система начнет сбрасывать данные на жесткий диск. Это справедливо для систем с небольшим количеством ОЗУ, 1-2 Гб, но если у вас 16 Гб, то нагружать жесткий диск когда у вас занято только 4 Гб несерьезно. Чтобы это изменить выполните команду:
sudo sysctl -w vm.swappiness=10
Это значит начинать сбрасывать данные в Swap когда занято 90% памяти (100-10). Можно использовать и другие значения. При частом переполнении памяти это отличная оптимизация Linux.
Выводы
В этой статье мы разобрали достаточно много методов как ускорить Linux, но все же я думаю это далеко не все решения. Если вы знаете другие интересные варианты ускорения работы Linux, поделитесь с нами в комментариях.
О многозадачности Линукса и его готовности стать основой корпоративной системы обработки информации
По просьбам граждан излагаю свою позицию по поводу особенностей работы Linux вообще и мейнфреймовского в частности. Чтобы не дергать переключатель языка на клавиатуре в дальшейшем буду называть Linux Линуксом, а мейнфреймовский Linux for System Z или zLinux - МФЛинукс. Поскольку все, написанное ниже, будет написано быстро, и я не собираюсь делать из своих соображений полноценную статью, то и располагаю написанное здесь, в разделе Колонок. Ранее это было опубликовано на этом же сайте, на Блог-площадке, но коллеги указали, что заметка не соответствует формату блогов. Все, написанное ниже, является моей субъективной точкой зрения, я вполне готов услышать аргументы в пользу противоположной точки зрения и вполне допускаю, что где-то ошибся.
Во-первых , хочу сразу и недвусмысленно заявить: я не являюсь ни Линукс-ненавистником, ни даже Линукс-скептиком. Более того, именно с Юникс-системы Демос начался мой путь на мейнфреймы, так что с Юниксом на мейнфреймах я работаю уже больше времени, чем некоторые живут на свете. Я свободные Юниксы люблю (Линукс в их числе), с удовольствием ими пользуюсь в повседневной жизни, отдаю должное их вкладу в формирование нашего ИТ-ланшафта и убежден в их огромном потенциале для будущего развития.
Во-вторых, говоря о Линуксе, я в большей степени буду говорить о ядре, потому что многозадачность обеспечивается именно подпрограммами ядра. Кроме того, именно для ядра осуществляется четких контроль вносимых изменений и отслеживается соблюдение авторских прав. В этом смысле вне зависимости от дистрибутива Линукс, речь будет идти о некоей общей сущности, а значит, и об особенностях вообще всех Линуксов, включая и МФЛинукс. Ядро - это не только базовая часть Линукса, но и одинаковая часть дистрибутивов (при условии одинаковости версий).
Прямым побуждением написать то, что вы тут читаете, были мои реплики на небольшой (я бы даже сказал - камерной) встрече мейнфреймщиков в 17 декабря в зале ресторана Обломов. Там неоднократно прозвучала формулировка «в связи с однозадачностью Линукса. ». Более того, некоторое время назад уже звучал тезис, что «для нормальной работы установок на базе Линукс требуется применение гипервизоров». Я бы хотел порассуждать на эту тему. При этом я не буду затрагивать вопросы «вплетания» Линукса в WLM-конфигурации и глобальное управление приоритетами, потому что это совершенно отдельная тема, и если тащить ее в эту заметку, то она распухнет до неприличия.
Факт номер один: Линукс ни в коем случае не однозадачная система. Она вполне себе многозадачная, поддерживает параллельное выполнение нескольких адресных пространств и нескольких задач в адресном пространстве. И поддерживал это с самого начала, также как прародители Линукса, типа Миникса. В составе Линукса есть хорошо разработанные средства переключения адресных пространств, а значит, и сохранения/восстановления контекста. Все разговоры про однозадачность Линукса (равно как и Windows) - результат либо недопонимания, либо неверного истолкования чьих бы то ни было вызказываний.
Факт номер два: Линукс, как и его предшественник Миникс (разработанный Танненбаумом), разрабатывался для процессоров вполне определенной архитектуры, а именно, Линукс - для Intel 80386, Миникс - для Intel 80286. Он, вообще говоря, не задумывался как многоплатформенная система. Затем, когда стало понятно, что есть огромный общественный интерес к такой системе, было сделано многое, чтобы повысить перносимость ядра. Оно было определенным образом структурировано, была осуществлена стандартизация средств обмена информацией с драйверами и предприняты огромные усилия, чтобы локализовать машинно-зависимую часть. Именно благодаря этой работе ядро (а также компиляторы и утилиты) перенесены на массу других архитектур. Хочу, чтобы все меня поняли хорошо именно в этом месте. Основа Линукса - это очень хорошо структурированное ядро, которое фактически работает на абстрактной Intel-подобной архитектуре, взаимодействуя с реальным оборудованием посредством хорошо документированного набора сервисов. Поэтому портирование Линукса на мейнфрейм было осуществлено (как гордо заявил в свое время IBM) с помощью переработки не более 5% исходных текстов. Фактически с помощью программной прослойки архитектура System Z была превращена в ту самую Intel-подобную абстрактную машину, что имеет массу прямых последствий. Но к этому мы вернемся позже.
Факт номер три: Архитектура Intel не имеет жестко закрепленных приоритетов у прерываний. Что это значит на практике? То, что в реальной жизни в случае ошибок, стечения обстоятельств или преднамеренных действий программа, обладающая достаточными полномочиями, может легко понизить приоритет прерываний от таймера (обработка которых, вообще говоря, критически важна для диспетчера системы и обработчиков прерываний других типов) и от других аппаратных ресурсов. А это, с свою очередь, делает систему непредсказуемой в случае превышения нагрузки выше некоторой граничной величины.
Конечно, любая система захлебывается, когда ее «заваливают» запросами и когда у нее не хватает ресурсов на обработку этих запросов. Но на оборудовании с жестко закрепленными приоритетами прерываний есть техническая возможность написать программное обеспечение таким образом, чтобы система при перегрузках не потеряла управляемости или хотя бы сообщила о недостатке ресурсов! Вы скажете: «Какие проблемы? Давайте писать на Intele программы так, чтобы не менять приоритеты прерываний, и все дела!». Это было бы неплохо, но увы, ни в Windows, ни в Линукс явно запретить это действие вам не удасться уже потому, что над целым рядом программ, работающих с полномочиями ядра, вы не властны. Это, в частности, драйвера оборудования. Да, Microsoft борется за качество драйверов, подписывая их. Да, Линуксовые сборщики дистрибутивов тоже пытаются идти в этом направлении. Но реальность такова: гарантировать неприкосновенность приоритетов прерываний вы не можете, уже потому, что возможность их поменять есть, а в систему лезут «третьи силы».
А есть ли системы, куда прямым директивным способом не допускаются чужие низкоуровневые программы? Конечно. Это - гипервизоры первого уровня. Для них фиксируется оборудование, на которых они будут работать, сами гипервизоры поставляются как проприетарные программные комплексы, где нет неверифицированного производителем системного программного обеспечения. Вот там вероятность того, что диспетчер задач получит квант процессора вовремя, во много крат выше, чем у обычного Линукса (и Windows тоже), что кардинально повышает устойчивость работы системы в целом и в случае высоких нагрузок - в частности. Мы поговорим об этом дальше, запомните эту мысль.
Предлагаю вам всем повторить пару экспериментов, которые я провел пару месяцев назад, выбирая конфигурацию программ и оборудования для одного своего маленького проекта. Я взял системный блок, и поставил туда Линукс, Ubuntu LTS без графической части. Инсталлировал Apache, MySQL и создал 4 виртуальных сайта, куда был установлен WordPress и выложен некий контент, небольшой, только чтобы обеспечить выполнение тестов. WordPress был использован потому, что сайты предполагалось делать на нем, и потому, что он достаточно прожорлив - для эксперимента было интересно обеспечить приличную нагрузку. После этого с помощью бесплатных сервисов было проведено нагрузочное тестирование. Сначала, пока запросов было мало, на графике зависимости времени ответа от количества запросов было совершенно плоское плато (рост количества запросов не вызывал роста времени ответа сайта), ресурсов системы вполне хватало для их обработки. Далее, по достижении определенного количества запросов к сайтам (N1), рост времени ответа системы стал линейным, зависящим от количества запросов (система боролась, но справлялась). Затем при некоем пороге (N2) время начало расти экспоненциально (система подходила к порогу насыщения). В конце концов при достижении порога N3 сервер перестал отвечать, потому что время обработки запросов стало больше сетевого таймаута. Сервер умер. На нем работал один Линукс и четыре виртуальных сайта. Кому интересно, посмотрите при этом, сколько адресных пространств Апача висит в такой конфигурации (я помню, вроде 7), пара адресных пространств MySQL, и около двух десятков адресных пространств всякой сервисной шняги. Всего было задействовано около 800 Мбайт памяти, я специально посмотрел, это важная информация.
Далее я заколотил (о, это была отдельная мучительная история!) на этот же системный блок (обычный I7 и 8 ГБайт памяти) KVM. Да, я знаю, что этот гипервизор, может быть, не самый лучший, но у меня были конкретно заточенный под мое оборудование продукт и инструкция по его установке именно на системный блок Lenovo для работы с Ubuntu. После этого я, как вы понимаете, инсталлировал четыре Линукса, в каждом из которых был Apache, MySQL с WordPress - по одному сайту на каждый Линукс. При этом количество адресных пространств в сумме было в разах больше, чем в первом случае, ибо Линуксов стало 4 (с четырьмя ядрами и всей системной шнягой), плюс сам гипервизор, который тоже вроде как специально заточенный Линукс. То есть совокупное количество запущенных процессов на железке выросло очень существенно. Каждому гостевому Линуксу я дал по гигабайту памяти, предыдущий эксперимент показал, что этого должно хватить, и, как показали дальнейшие наблюдения, хватило. Нагрузочное тестирование было повторено. В результате было следующее. Начальное время ответа сайтов было несколько (процентов на 30%) больше, чем в первом случае. А вот далее была пологая-пологая линейная кривая, но все-таки не плато. Разницу между значением N1 и N2 я поймать не смог, так как кривая была очень пологая с постепенным увеличением угла наклона. Но самое забавное в том, что в пределах моих бесплатных возможностей на сервисе нагрузочного тестирования я не смог загнать сервер в экспоненциальный рост времени ответа (граница N3), не говоря об умирании сервера! То есть время реакции росло, оно и в начале второго эксперимента было выше, чем в начале первой фазы первого эксперимента, процессор молотил, диск мигал - но на сетевой тайм-аут я не вышел, все четыре сайта (хотя и со скрипом!!) отдавали потребителям свои страницы. Что это значит? Что диспетчер KVM упорно получал свой квант процессора и распределял ресурсы по гостевым Линуксам, где этот квантик отдавался соответствующим адресным пространствам Apache и MySQL.
(Обновление в процессе обсуждения - графиков нет, потому что я и не думал на этапе экспериментирования что-то подобное публиковать. Предлагаю желающим потратить недельку и повторить мои изыскания, готов выложить сюда графики).
Теперь вопрос: почему в первом случае Линукс захлебнулся, а во втором - нет? Ведь в первом случае совокупная нагрузка на систему была меньше, чем во втором. Было арифметически меньше адресных пространств (процессов) и подзадач (нитей, или тредов, как их называют в Линуксе), запросы ввода-вывода, инициированные прикладными процессами Apache и MySQL отрабатывались ядром и оборудованием по более короткому пути, нежели в при использовании KVM, где ввод-вывод отбрасывается на специально выделенный системный процесс. Более того, KVM должен был не только разбираться с запросами на процессор и ввод-вывод, но и обслуживать запросы на память от виртуальных Линуксов, чего в первом случае не было. Количество переключений контекстов тоже вроде бы было существенно больше, чем в первом случае (а это, как говорилось в факте 4, очень расходная операция) То есть, по общим соображениям, система во втором варианте должна была бы захлебнуться раньше, чем в первом варианте, а не только время ответа должно быть больше. В реальной жизни, как вы можете проверить сами, время ответа будет действительно больше, а вот граница умирания и профиль кривой зависимости времени ответа от количества запросов будет совсем иными. Вот правда, почему? Ведь в KVM ядро практически такое же, как в обычном Линуксе!
Ответ, по моему мнению, вот какой. Действительно, с учетом факта 4 (огромное количество ресурсов, требуемых для переключения контекста), во втором случае мой системный блок должен был захлебнуться раньше в связи с тем, что адресных пространств стало больше. Но на самом деле вышло вот что. В первом эксперименте (с одним ядром и 4 виртуальными сайтами) при росте количества запросов накладные расходы, связанные с переключением адресных пространств, в конце концов завалили диспетчер. Он уже не столько раздавал кванты процессора пользовательским адресным пространствам, сколько готовил под них контекст, затем давал маленький квант и тут же готовил новый контекст. Мгого запросов - много переключений. Фактически с ростом количества запросов именно диспетчер со своей расходной (хотя и мобильной) дисциплиной переключения адресных пространств в Линуксе становится ахиллесовой пятой системы, даже если какой-нибудь кривоватый драйвер не изменит приоритета прерываний (а уж если изменит, то оборудование и при минимальной нагрузке может уйти в зацикливание, потому что диспетчер не получает вовремя свой квант). Вот попадание в это состояние, когда при определенном количестве запросов становится невозможно гарантировать получение пользовательским адресным пространством кванта процессора в разумный промежуток времени, и дал основание считать Линукс однозадачной системой. Ведь для того, чтобы сдвинуть границу захлебывания приходилось уменьшать количество задач в Линуксе, вплоть до одного-единственного, но важного пользовательского адресного пространства! На уровне одного пользовательского процесса можно было потреблять сколько угодно ресурсов, ядро от этого не страдало, свой квант оно всегда отъедало, а вот роста количества адресных пространств, особенно потребляющий чуть-чуть процессора и тут же уходящих в ожидание, диспетчер боится как огня! А ведь именно так и работают большинство СУБД и вообще информационных систем - короткие процессорные запросы на доставание из устройств хранения данных и ожидание завершения ввода-вывода.
А что происходит во втором эксперименте? Во втором эксперименте заваливание диспетчера не происходит потому, что запросы и адресные пространства четко эшелонированы по уровням иерархии. На уровне первичного Линукса (то есть KVM) адресных пространств было немного - фактически четыре виртуальные машины с гостевыми Линуксами, адресное пространство ввода-вывода, диспетчер и небольшое количество служебных процессов. Диспетчер честно крутился между пятью основными потребителями ресурсов, и на чистом железе уверенно разбрасывал эти ресурсы. Далее, внутри виртуальных машин, ядро гостевых Линуксов тоже неплохо справлялось с распределением выделенных, пусть небольших, ресурсов между малым количеством основных потребителей - на один виртуальный сайт нужно относительно небольшое количество активно потребляющих ресурсы адресных пространств. Диспетчер KVM обрабатывал небольшое количество запросов от оборудования и переключал малое количество адресных пространств, поскольку львиную долю запросов от оборудования пространство ввода-вывода отображало на гостевые Линуксы. А внутри гостевых Линуксов было и самих запросов меньше, и адресных пространств меньше. Поэтому был линейных рост времени ответа от количества запросов, но не произошло насыщения системы и ее умирания.
Значит ли это, что систему с гипервизором вообще нельзя завалить? Конечно можно! У меня просто кончилась бесплатная квота на серверах нагрузочного тестирования. Любые системы можно завалить, если не центральную часть, то коммуникационную, на этом и стоят DDOS-атаки. Просто вид графика зависимости времени реакции от количества запросов будет, как я полагаю, несколько иной - будет линейная кривая, которая переходит в более плавную экспоненту, которая тоже уйдет в бесконечность при полном исчерпании аппаратных ресурсов.
В этом смысле абсолютно предсказуемым был третий эксперимент, когда конфигурация первого эксперимента была перенесена в среду виртуальной машины. Под KVM в одном гостевом Линуксе были созданы 4 виртуальных сайта, и нагрузочное тестирование было повторено. Картина в точности повторила график первого эксперимента с тем лишь отличием, что вместо плато была пологая, но линейная кривая, а все временные характеристики были хуже процентов на 25-30. Веб-сайты на вопросы не отвечали, а вот консоль KVM была вполне себе жива, и системный блок был вполне управляем. Правда, на уровне гостевого Линукса толку от этого было мало.
То, что проблема переключения адресных пространств в Линуксе носит архитектурно-независимый характер, доказывает и поведение МФЛинукса. Я не доводил ситуацию до полноразмерного эксперимента, описанного выше, но могу сказать совершенно точно - временные характеристики работы трех нагруженных баз данных DB2, помещенных в один МФЛинукс, были хуже, чем работа трех МФЛинуксов под VM, в каждом из которых была только одна база. При этом, как вы все понимаете, эффективность VM как гипервизора, в сотни раз выше KVM-а! Понятно, почему МФЛинукс также плох в переключении контекста, как и обычный Линукс: ведь основные подпрограммы ядра не перерабатывались, они охраняются патентным правом, перерабатывались только минимально необходимые компоненты, которые работают с оборудованием и без которых некуда деться (те самые 5% кода). Все попытки использовать преимущества архитектуры на уровне ядра приведут к потере права называть систему Линуксом, а значит, придется постоянно доказывать совместимость новорожденной системы с Линуксом. На это, как мне кажется, никто сейчас не пойдет.
Формулирую короткие выводы. В чем основное преимущество Линукса? В его переносимости и единообразии на всех платформах. В этом же и его основная беда. Для мейнфреймовского Линукса эта беда, в основном, выражается в отказе от использования крайне эффективных механизмов обеспечения многозадачности и примитивная работа с аппаратными ресурсами. Именно использование максимально переносимых механизмов многозадачности приводит к необходимости дополнять Линукс проприетарными гипервизорами. Для мейнфрейма, чтобы обеспечить более высокие эксплуатационные характеристики Линукса приходится использовать не только проприетарные гипервизоры (VM, PR/SM), но и прямой доступ к FBA-дискам (фактически - сдвигать работу с дисками на уровень дискового контроллера), аккуратно управлять сетевыми адаптерами (как и с дисками, сдвигать работу с оборудованием на плечи проприетарного гипервизора) и применять виртуальные устройства (то есть опять же, пользоваться возможностями VM). Все это, по моему мнению, не позволяет считать Линукс вообще и МФЛинукс в частности самодостаточными ОС, готовыми для того, чтобы стать основой современных информационных систем корпоративного масштаба, особенно в случаях применения высоконагруженных критически важных приложений. Отказ от переносимости в сторону использования возможностей оборудования для повышения надежности и эффективности работы МФЛинукса я считаю маловероятным.
Приветствую вас на канале Old Programmer о программировании и программистах. Тематическое оглавление канала здесь . А тут собраны все ссылки по C/C++. Здесь перечень ссылок на ресурсы, посвященные многозадачности в Linux.
Пример конкурентной работы дочернего и родительского процесса (OS Linux)
Сегодня мы рассмотрим похожую задачу но с двумя процессами. О создании потоков можно посмотреть в статьях:
И в этом смысле в программе sinh4000.c нет ничего нового. С помощью функции fork() создается дочерний процесс, а затем в родительском процессе и дочернем процессе на консоль опять выводятся буквы. При чем каждая букв дважды. Дочерний процесс выводит прописные буквы, а родительский заглавные. Между выводом такой пара делается временная задержка. Если запустить такую программу, то вывод будет перемешиваться, при чем при каждом запуске перемешивание будет разным. Перемешивание происходит и в промежутке между выводом одинаковых букв. Например так
AaaAbBBCbcCDcddDeEefEFfgFGghGHHIhiIiJjJKjkkKlLlLmMMNmnnoNOopOPpqPQqrQRrsRSstSTtuTUuvUVvwVWwxWXxyXYyzYZzZ
А как заставить программу, чтобы прерывание не происходило по-крайней мере между выводами двух одинаковых букв?
Проблема синхронизации процессов (OS Linux)
На самом деле с подобной синхронизацией, но не в многозадачном программировании встречается каждый программист. И он знает, что для этого можно использовать глобальную переменную. В данном случае такой подход тоже возможен. Вы можете возразить, что для потоков это возможно, а для процессов проблематично. Но на самом деле нет, так можно использовать переменную в разделяемой памяти .
Как может работать такая переменная - флаг? Начальное состояние переменной, назовем ее A положим равной 0 . Пусть к ней обращаются два процесса (или потока). Пусть первый процесс проверяет значение переменной, если значение равно 0 , то он увеличивает ее на 1 и приступает к выполнению важной для себя (критической) секции кода. Если второй процесс теперь проверит значение переменной и обнаружит, что переменная равна 1 , то он переходит в состояние ожидания, проверяя время от времени значение переменной. Как только при очередной проверке значение переменной становится равной 0, то он увеличивает ее на 1 и начинает выполнять свое критическое действие. Почему же переменная стала равной 0? Да потому что первый процесс закончив выполнение своей критической секции, уменьшает значение переменной на 1 . Вот в принципе такой незамысловатый механизм использование такой переменной.
Дело в том, однако, что этот механизм несовершенен. Суть вот в чем. Первый процесс может проверить значение переменной A , но не успеет увеличить ее значение, а в этот момент значение проверит второй процесс. И таким образом оба процесс окажутся в критической секции, что может быть недопустимо, по условию задачи. Да, вероятность такая не велика, но не равно нулю. И вот чтобы избежать такой коллизии, используется очень интересный механизм светофоров , который в Linux реализован на уровне ядра. Но об этом в следующей статье.
Замечание. Функция fflush() , которая используется в программе sinh4000.c , сбрасывает в файл (в примере в выходной поток) содержимое буфера. Можете по экспериментировать, проверив, что будет, если убрать эту функцию.
Любите и изучайте многозадачность и не забывайте подписываться на мой канал о программировании и программистах Old Programmer .
По умолчанию ядро Linux оптимизировано для общих случаев использования. Поэтому большинство серверов Linux работают достаточно хорошо без какой-либо дальнейшей оптимизации. Однако если вы действительно хотите добиться максимальной производительности вашего сервера, вам необходимо применить некоторые навыки оптимизации системы. В этой статье вы узнаете, как это сделать.
Понимание основ оптимизации системы
Ядро Linux предлагает сложную структуру, позволяющую вашему серверу вести себя наилучшим образом. По умолчанию он настроен на среднюю рабочую нагрузку. На многих серверах средняя рабочая нагрузка просто недостаточно хороша, поэтому доступны некоторые расширенные возможности настройки Linux.
Внося изменения в настройки Linux, вы можете значительно повысить производительность вашего сервера. Однако существует и риск. Также относительно легко настроить сервер таким образом, что производительность будет ухудшаться, а не улучшаться. Именно поэтому настройка производительности Linux должна выполняться экспертами, которые знают, что они делают.
Чтобы научиться настраивать производительность Linux, нужно знать намного больше, чем в этой статье. Тем не менее эта статья даст вам фундамент для дальнейшего изучения и применения оптимизации системы.
Для начала, настройка производительности требует много исследований. Например на основе этой статьи: top, iostat, vmstat и pidstat. Мониторим Linux. После проведения исследования вы можете спокойно приступить к оптимизации производительности.
- Никогда не пробуйте настройки на рабочем сервере. Используйте тестовую систему для испытаний и к рабочим серверам применяйте только те параметры, которые вы проверили.
- Меняйте одну настройку за раз и тщательно её проверяйте. Хорошее тестирование обычно означает повторение одного и того же теста три раза. Если после выполнения трех тестов вы убедились, что производительность улучшилась, значит можно применить на рабочем сервере.
- Составьте план перед началом. Слишком большая оптимизация производительности происходит без хорошего плана, в результате чего администратор на самом деле не работает над повышением производительности, а меняет случайные настройки, надеясь, что из этого получится что-то хорошее.
Понимание файловой системы /proc
Ключ к настройке производительности Linux находится в файловой системе /proc. Эта файловая система предлагает интерфейс к ядру Linux и может использоваться для анализа текущего состояния ядра и внесения изменений в различные настройки. Далее вы узнаете, как получить информацию об оптимизации производительности из файловой системы /proc и как оптимизировать ее производительность. Многие, если не все системные утилиты (включая lscpu, uname, top, ps, lsmod и многие другие) получают информацию, которую они показывают, из файловой системы /proc. Так что, если вам не очень нравится чтение из файловой системы /proc, просто убедитесь, что вы нашли подходящий инструмент.Использование / proc для анализа производительности
Файловая система /proc содержит много файлов, которые предоставляют информацию о текущем состоянии производительности сервера Linux. Большинство утилит для анализа производительности получают информацию из файловой системы /proc. В таблице 1 представлен обзор важных, связанных с производительностью файлы.
В этих каталогах вы найдете, например, файл состояния, содержащий подробную информацию об использовании памяти, или файл окружения, который дает обзор всех переменных среды, которые используются процессом.
В листинге 1 показано, как может выглядеть содержимое файла состояния. Обратите внимание, что он содержит информацию, которую нельзя легко показать каким-либо другим способом, включая количество переключений контекста, которые были сделаны в отношении этого конкретного процесса.
Использование /proc/sys для настройки производительности Linux
Ключом к оптимизации производительности Linux является каталог /proc/sys. В этом каталоге вы найдете настраиваемые элементы, разделенные на разные категории. В Таблице 2 содержится обзор этих элементов.
| Элемент | Объяснение |
| abi | Это двоичный интерфейс приложения. Он используется для предоставления интерфейса приложениям, в частности приложениям с открытым исходным кодом. Вы, вероятно, никогда не будете использовать это для оптимизации. |
| crypto | Криптографический интерфейс, который обеспечивает криптографию для определенных служб, таких как IPsec и dm-crypt. Используется редко для оптимизации производительности Linux. |
| debug | Когда в ядре Linux включены функции отладки, этот каталог содержит настраиваемые параметры. Не часто используется для обычных задач системного администратора. |
| dev | Содержит несколько настраиваемых параметров, связанных с устройствами. |
| fs | Интерфейс к виртуальной файловой системе. Содержит несколько полезных настроек, таких как file-max, в которых указывается максимальное количество файлов, которые могут быть открыты одновременно. |
| kernel | Интерфейс ядра. Содержит много полезных настроек. |
| net | Сетевой интерфейс. Содержит много полезных настроек. |
| sunrpc | Интерфейс sunrpc. Содержит несколько полезных настроек, связанных с общим доступом к файлам NFS. |
| vm | Интерфейс виртуальной памяти. Содержит много полезных настроек. |
Чтобы оптимизировать систему Linux, каталог /proc/sys содержит много параметров.
- Используйте echo для записи нового параметра в настраиваемый файл ядра.
- Используйте sysctl -w, чтобы записать параметр в настраиваемое ядро.
После того, как вы вы убедились, что всё работает, вы можете сделать его постоянным, как описано в следующем разделе. В упражнении 1 вы узнаете, как временно изменить значение имени хоста, поддерживаемое ядром. Обратите внимание, что это всего лишь пример того, как изменить системное имя хоста, которое в настоящее время известно ядру Linux. Для внесения постоянных изменений в имя хоста используйте команду hostnamectl.
Использование sysctl для автоматизации параметров оптимизации системы
Чтобы постоянно изменять настройки ядра, вам нужно записать их в sysctl. Sysctl - это служба, которая считывает несколько файлов конфигурации, которые применяются во время загрузки системы. В этом разделе вы узнаете, как работать с sysctl.
- Файл /etc/sysctl.conf - это файл конфигурации по умолчанию. На RHEL или CentOS этот файл больше не должен использоваться.
- Каталог /usr/lib/sysctl.d используется для параметров оптимизации по умолчанию. Содержимое этого каталога предназначено для управления через RPM, а не вручную, поэтому не вносите в него никаких изменений.
- Каталог /etc/sysctl.d используется для пользовательских параметров. Если у вас есть какие-либо изменения, это нужно сделать здесь.
Итак, файл /proc/sys/vm/swappiness упоминается как vm.swappiness в sysctl.
Чтобы получить представление обо всех доступных настройках, вы можете использовать команду sysctl -a. Эта команда выводит список всех доступных настроек. Она предлагает простой способ найти конкретные параметры, особенно когда совместно используется с grep или совместно с less. После того, как вы нашли переменную, которую хотите установить, вам нужно поместить ее в файл конфигурации sysctl.
В листинге 3 показан частичный вывод команды sysctl -a.
Расположение по умолчанию для всех настраиваемых параметров - это каталог /etc/sysctl.d. В этом каталоге вы должны создать файл с именем, оканчивающимся на .conf. В этом файле вы поместите переменную со значением, которое вы хотите установить для настройки. В строках, в которые вы их помещаете, вы сначала вводите имя настраиваемого элемента, затем пробел, затем знак =, затем еще один пробел и предполагаемое значение.
Вы не должны помещать содержимое в файл /etc/sysctl.conf или в каталог /usr/lib/sysctl.d; оба места считаются управляемыми системой.
Команда sysctl также предлагает несколько полезных опций. В таблице 3 представлен их обзор, а в упражнении 2 вы узнаете, как применять некоторые параметры.
Читайте также: