From d75feac76775183244278fb57671e7a3353b1ef7 Mon Sep 17 00:00:00 2001 From: dpol Date: Thu, 2 Jan 2025 16:04:19 +0700 Subject: [PATCH] Corrections text --- docs/source/kernel-parameters.rst | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/source/kernel-parameters.rst b/docs/source/kernel-parameters.rst index d90ceb6..0dbee12 100644 --- a/docs/source/kernel-parameters.rst +++ b/docs/source/kernel-parameters.rst @@ -157,7 +157,7 @@ sysctl kernel.sysrq = 1 -Собственно именно добавлением таким строк мы и будем применять +Собственно именно добавлением таких строк мы и будем применять соответствующие настройки. .. warning:: Настройки прописываемые в файле ``/etc/sysctl.conf`` не @@ -213,7 +213,7 @@ udev Udev [#]_ - менеджер для управления вашими устройствами, который отслеживает их подключение/выключение, и предоставляет возможность создавать так называемые "правила", которые вызываются каждый раз, -когда происходит определенной действие с тем или иным устройством. +когда происходит определенное действие с тем или иным устройством. Внутри этого правила можно указать, при каких событиях и для какого конкретно устройства (условие для срабатывания) мы будем выполнять определенную команду или устанавливать некоторое значение. Это очень @@ -591,8 +591,8 @@ ZRAM тоже в 4 Гб. Вы полностью забиваете всю св который очевидно будет меньше в 2-3 раза. Именно поэтому я рекомендую вам установить объем блочного устройства ZRAM, который в два раза больше, чем объем всей вашей памяти (Значение ``8Gb`` - **это лишь -пример**, замените его на то, сколько у объем вашей памяти и умножьте -это на два**). Конечно, здесь нужно оговориться, что не все страницы +пример**, замените его на то, какой объем вашей памяти и умножьте +это на **два**). Конечно, здесь нужно оговориться, что не все страницы бывают так уж хорошо сжимаемыми, но в большинстве случаев они будут помещаться без каких-либо проблем. @@ -899,7 +899,7 @@ MGLRU предотвращает вытеснение "рабочего набо максимально возможный объем грязных страниц. Она определяется значением параметра ``vm.dirty_ratio``, либо ``vm.dirty_bytes``. Если к тому времени, когда потоки ``pdflush`` начали свою работу, объем -грязных страниц продолжал увеличиватся с такой скоростью, что ядро +грязных страниц продолжал увеличиваться с такой скоростью, что ядро просто не успевало записать все поступающие изменения на диск, то возникает так называемый "троттлинг" ввода/вывода. @@ -909,7 +909,7 @@ MGLRU предотвращает вытеснение "рабочего набо тех пор пока потоки ``pdflush`` полностью не запишут уже накопленные ранее изменения на диск. Это приводило к очень печальным последствиям, в том числе известный баг в ядре `12309 -`_ был связан с +`_ был связан именно с тем, что интенсивная запись каким-либо процессом на носитель с очень низкой скоростью (вроде простой USB флешки) приводила к ярко выраженным зависаниям всей системы, так как операции I/O @@ -1011,7 +1011,7 @@ tmpfs, и в этом случае объем грязных уже будет людей хоть и чисто номинально составляет 100 Мб/c, однако в ряде случаев оказывается куда ниже, так что сверх большие объемы грязных страниц указывать просто нет смысла. В качестве начальных значений, на -которые можно было бы оперется, автор рекомендует взять 32 или 64 Мб в +которые можно было бы опереться, автор рекомендует взять 32 или 64 Мб в качестве ``dirty_background_bytes`` и 256 Мб в качестве ``dirty_bytes``: @@ -1021,7 +1021,7 @@ tmpfs, и в этом случае объем грязных уже будет vm.dirty_background_bytes=67108864 vm.dirty_bytes=268435456 -Вы в праве кратно уменьшить значение параметра ``vm.dirty_bytes``, +Вы вправе кратно уменьшить значение параметра ``vm.dirty_bytes``, если у вас медленный HDD, или же наоборот увеличить вплоть до 1-2 Гб, если имеете сверхбыстрый носитель и высокую скорость передачи данных по сети. @@ -1032,8 +1032,8 @@ tmpfs, и в этом случае объем грязных уже будет сильно завышены. Ожидать 30 секунд, как предписывает значение по умолчанию параметра ``vm.dirty_expire_centisecs``, перед тем чтобы позволить записывать ``pdflush`` новую грязную страницу кажется -чрезмерным, поэтому разумно уменьшить значение данного параметра в -двое, то есть сократить период ожидания до 15 секунд, либо же ещё +чрезмерным, поэтому разумно уменьшить значение данного параметра вдвое, +то есть сократить период ожидания до 15 секунд, либо же ещё меньше, но устанавливать сверх низкие значения вроде 1-3 секунд также не рекомендуется, так как это может свести на нет все преимущества кэширования при записи. Оптимальным, по мнению автора, является @@ -1086,7 +1086,7 @@ tmpfs, и в этом случае объем грязных уже будет имея который можно обратиться к данным файла. Поэтому ядро кэширует все используемые во время работы системы дескрипторы и информацию о директориях внутри VFS [#]_ кэша, для того чтобы сделать все -последующие обращения к файлами быстрыми, потому что ядро уже будет +последующие обращения к файлам быстрыми, потому что ядро уже будет знать про них всё, что нужно. Но все эти метаданные так или иначе занимают место внутри памяти,