Skip to content

Commit

Permalink
Corrections text
Browse files Browse the repository at this point in the history
  • Loading branch information
dpol authored and ventureoo committed Jan 3, 2025
1 parent fa30d85 commit d75feac
Showing 1 changed file with 11 additions and 11 deletions.
22 changes: 11 additions & 11 deletions docs/source/kernel-parameters.rst
Original file line number Diff line number Diff line change
Expand Up @@ -157,7 +157,7 @@ sysctl

kernel.sysrq = 1

Собственно именно добавлением таким строк мы и будем применять
Собственно именно добавлением таких строк мы и будем применять
соответствующие настройки.

.. warning:: Настройки прописываемые в файле ``/etc/sysctl.conf`` не
Expand Down Expand Up @@ -213,7 +213,7 @@ udev
Udev [#]_ - менеджер для управления вашими устройствами, который
отслеживает их подключение/выключение, и предоставляет возможность
создавать так называемые "правила", которые вызываются каждый раз,
когда происходит определенной действие с тем или иным устройством.
когда происходит определенное действие с тем или иным устройством.
Внутри этого правила можно указать, при каких событиях и для какого
конкретно устройства (условие для срабатывания) мы будем выполнять
определенную команду или устанавливать некоторое значение. Это очень
Expand Down Expand Up @@ -591,8 +591,8 @@ ZRAM тоже в 4 Гб. Вы полностью забиваете всю св
который очевидно будет меньше в 2-3 раза. Именно поэтому я рекомендую
вам установить объем блочного устройства ZRAM, который в два раза
больше, чем объем всей вашей памяти (Значение ``8Gb`` - **это лишь
пример**, замените его на то, сколько у объем вашей памяти и умножьте
это на два**). Конечно, здесь нужно оговориться, что не все страницы
пример**, замените его на то, какой объем вашей памяти и умножьте
это на **два**). Конечно, здесь нужно оговориться, что не все страницы
бывают так уж хорошо сжимаемыми, но в большинстве случаев они будут
помещаться без каких-либо проблем.

Expand Down Expand Up @@ -899,7 +899,7 @@ MGLRU предотвращает вытеснение "рабочего набо
максимально возможный объем грязных страниц. Она определяется
значением параметра ``vm.dirty_ratio``, либо ``vm.dirty_bytes``. Если
к тому времени, когда потоки ``pdflush`` начали свою работу, объем
грязных страниц продолжал увеличиватся с такой скоростью, что ядро
грязных страниц продолжал увеличиваться с такой скоростью, что ядро
просто не успевало записать все поступающие изменения на диск, то
возникает так называемый "троттлинг" ввода/вывода.

Expand All @@ -909,7 +909,7 @@ MGLRU предотвращает вытеснение "рабочего набо
тех пор пока потоки ``pdflush`` полностью не запишут уже накопленные
ранее изменения на диск. Это приводило к очень печальным последствиям,
в том числе известный баг в ядре `12309
<https://bugzilla.kernel.org/show_bug.cgi?id=12309>`_ был связан с
<https://bugzilla.kernel.org/show_bug.cgi?id=12309>`_ был связан
именно с тем, что интенсивная запись каким-либо процессом на носитель
с очень низкой скоростью (вроде простой USB флешки) приводила к ярко
выраженным зависаниям всей системы, так как операции I/O
Expand Down Expand Up @@ -1011,7 +1011,7 @@ tmpfs, и в этом случае объем грязных уже будет
людей хоть и чисто номинально составляет 100 Мб/c, однако в ряде
случаев оказывается куда ниже, так что сверх большие объемы грязных
страниц указывать просто нет смысла. В качестве начальных значений, на
которые можно было бы оперется, автор рекомендует взять 32 или 64 Мб в
которые можно было бы опереться, автор рекомендует взять 32 или 64 Мб в
качестве ``dirty_background_bytes`` и 256 Мб в качестве
``dirty_bytes``:

Expand All @@ -1021,7 +1021,7 @@ tmpfs, и в этом случае объем грязных уже будет
vm.dirty_background_bytes=67108864
vm.dirty_bytes=268435456
Вы в праве кратно уменьшить значение параметра ``vm.dirty_bytes``,
Вы вправе кратно уменьшить значение параметра ``vm.dirty_bytes``,
если у вас медленный HDD, или же наоборот увеличить вплоть до 1-2 Гб,
если имеете сверхбыстрый носитель и высокую скорость передачи данных
по сети.
Expand All @@ -1032,8 +1032,8 @@ tmpfs, и в этом случае объем грязных уже будет
сильно завышены. Ожидать 30 секунд, как предписывает значение по
умолчанию параметра ``vm.dirty_expire_centisecs``, перед тем чтобы
позволить записывать ``pdflush`` новую грязную страницу кажется
чрезмерным, поэтому разумно уменьшить значение данного параметра в
двое, то есть сократить период ожидания до 15 секунд, либо же ещё
чрезмерным, поэтому разумно уменьшить значение данного параметра вдвое,
то есть сократить период ожидания до 15 секунд, либо же ещё
меньше, но устанавливать сверх низкие значения вроде 1-3 секунд также
не рекомендуется, так как это может свести на нет все преимущества
кэширования при записи. Оптимальным, по мнению автора, является
Expand Down Expand Up @@ -1086,7 +1086,7 @@ tmpfs, и в этом случае объем грязных уже будет
имея который можно обратиться к данным файла. Поэтому ядро кэширует
все используемые во время работы системы дескрипторы и информацию о
директориях внутри VFS [#]_ кэша, для того чтобы сделать все
последующие обращения к файлами быстрыми, потому что ядро уже будет
последующие обращения к файлам быстрыми, потому что ядро уже будет
знать про них всё, что нужно.

Но все эти метаданные так или иначе занимают место внутри памяти,
Expand Down

0 comments on commit d75feac

Please sign in to comment.