Forum Debian Users Gang

 16 /usr/src/linux/Documentation/sysctl/00-INDEX
   54 /usr/src/linux/Documentation/sysctl/abi.txt
  300 /usr/src/linux/Documentation/sysctl/fs.txt
  819 /usr/src/linux/Documentation/sysctl/kernel.txt
  254 /usr/src/linux/Documentation/sysctl/net.txt
   75 /usr/src/linux/Documentation/sysctl/README
   20 /usr/src/linux/Documentation/sysctl/sunrpc.txt
  776 /usr/src/linux/Documentation/sysctl/vm.txt
 2314 razem

# Ta opcja włącza zabijanie procesów w sytuacjach OOM. W przypadku ustawienia tego parametru na 0, kernel 
# przeskanuje procesy i ubije ten co zjada najwięcej zasobów pamięci RAM. Gdy zostanie ustawiona wartość "1",
# kernel ubije tę aplikację, która doprowadziła do stanu OOM, przy czym nie koniecznie musi to był nowo
# uruchomiony program, co może doprowadzić do zabijania pożytecznych procesów, które wcale nie zagrażają
# systemowi. W przypadku posiadania partycji SWAP, dane będą tam zrzucane i żaden proces nie zostanie zabity. 
#  
vm.oom_kill_allocating_task = 0
#
# Włącza zrzut wszystkich zadań w systemie za wyjątkiem wątków kernela w chwili gdy kernel dokonuje zabijania
# żarłocznych procesów (OOM-killing). W tym zrzucie zawarte są informacje takie jak pid, uid, tgid, vm size,
# rss, nr_ptes, swapents, oom_score_adj score, oraz name. Jest to pomocne w celu zidentyfikowania procesu,
# który zainicjował OOM killera. Dodatkowo zostanie wypisanie info dlaczego OOM killer wybrał akurat to
# zadanie do zabicia. Ustawienie tej wartości na "0" spowoduje, że ta informacja nie zostanie wyświetlona. W
# przypadku wielkich systemów z tysiącami procesów, tego typu zrzut może okazać się niezbyt dobrym pomysłem. 
vm.oom_dump_tasks = 1
#
# W przypadku ustawienia "1", kernel spanikuje za każdym razem gdy dojdzie do sytuacji OOM. W przypadku
# gdy proces limituje nody przez mempolicy/cpusets i te nody zaczną wyczerpywać pamięć RAM, sam proces może
# zostać zabity przez OMM killera. W takim przypadku kernel nie spanikuje, bo nody pamięci zostaną uwolnione.
# Gdy ten parametr zostanie ustawiony na "2", kernel spanikuje w każdej sytuacji.
vm.panic_on_oom = 0

# W przypadku pewnych sytuacji, kernel napotyka problem, który jest na tyle poważny, że może zachwiać dalszym
# funkcjonowaniem maszyny. W takich przypadkach kernel zwyczajnie przestaje odpowiadać, a cała sytuacja jest
# znana bardziej jako kernel panic. Poniższy parametr określa ilość czasu (w sekundach), po którym system
# zostanie uruchomiony ponownie w przypadku paniki kernela. Jeśli ten parametr zostanie ustawiony na "0",
# reboot zostanie wyłączony.
kernel.panic = 60
#
# Mniej poważne błędy kernela są nazywane "oops". Nie doprowadzają one bezpośrednio do paniki kernela, gdyż
# ten może się obronić ubijając złowrogi proces. W sporej części przypadków "oops", system z mniejszym lub
# większym powodzeniem może pracować dalej. Poniższa opcja, jeśli ustawiona na "0", sprawi, że kernel będzie
# próbował funkcjonować dalej. Jeśli zaś zostanie ustawiona na "1", kernel spanikuje natychmiast. Dodatkowo,
# jeśli parametr panic jest ustawiony na niezerową wartość, system zostanie zresetowany.
kernel.panic_on_oops = 0

# Określa ilość prób wysłania pakietów z ustawioną flagą SYN przy nawiązaniu połączenia zanim kernel się podda
# i zrezygnuje. 
net.ipv4.tcp_syn_retries = 6

# Aktywuje TCP Fast Open, co ma na celu wyeliminowanie początkowego RTT przy nawiązywaniu połączenia podczas
# three-way handshake i tym samym zmniejszenie opóźnień, bo część pakietu SYN będzie zawierać faktyczne dane.
# Może to poprawić wydajność łącza nawet o 40% przy przeglądaniu stron www. Jednak system ten opiera się o
# generowane ciasteczka weryfikujące tożsamość klienta, a to niestety pociąga za sobą lekkie utylizowanie
# procesora. By ten mechanizm zadziałał, aplikacje również muszą mieć zaimplementowaną jego obsługę.
# Jeśli w poniższym parametrze zostanie ustawiona wartość "1", aplikacja będzie mogła żądać ciasteczek i tym
# samym wysyłać dane w pakietach inicjujących połączenie (SYN) ze stacji klienckich. Z kolei wartość "2"
# umożliwia serwerowi generowanie ciasteczek i akceptowanie tego typu żądań zanim three-way handshake zostanie
# ukończone. Wartość "3" włącza funkcjonalność zarówno serwera jak i klienta na danej maszynie. Istnieje także
# możliwość sprecyzowania wartości "4" i w takim wypadku dane mogą być przesyłane bez względu na dostępność
# ciasteczek i w ogóle bez precyzowania tej opcji.
# -- http://lwn.net/Articles/508865/
net.ipv4.tcp_fastopen = 1

net.ipv4.route.error_burst = 1250
net.ipv4.route.error_cost = 250
net.ipv4.route.gc_elasticity = 8
net.ipv4.route.gc_interval = 60
net.ipv4.route.gc_min_interval = 0
net.ipv4.route.gc_min_interval_ms = 500
net.ipv4.route.gc_thresh = -1
net.ipv4.route.gc_timeout = 300
net.ipv4.route.max_size = 2147483647
net.ipv4.route.min_adv_mss = 256
net.ipv4.route.min_pmtu = 552
net.ipv4.route.mtu_expires = 600
net.ipv4.route.redirect_load = 5
net.ipv4.route.redirect_number = 9
net.ipv4.route.redirect_silence = 5120

# Zrzut pamięci (coredump) jest to skopiowanie na bardziej wiarygodne medium (dysk twardy) zawartości pamięci
# RAM w chwili gdy dochodzi do jakiegoś zdarzenia, np. poważnego błędu aplikacji. Nazwy, pod jakimi
# zachowywany jest plik, można zmienić, tak samo jak i lokalizację do zapisu tych plików. Obecną konfigurację
# można przetestować przez wydanie poniższych poleceń:
#
#    $ ulimit -c unlimited
#    $ kill -s SIGSEGV $$
#
# Doprowadzą one do segmentation fault shella, w którym zostaną wydane, a sam zrzut będzie zapisany w
# aktualnej lokalizacji powłoki, w której się użytkownik znajdował przed wystąpieniem błędu.
#
# Domyślną nazwą dla pliku ze zrzutem pamięci jest "core". Przez ustawienie poniższego parametru na wartość
# "1", nazwa pliku ulegnie zmianie na "core.PID". Jeśli core_pattern nie zawiera "%p" oraz core_uses_pid jest
# ustawiony na "1", wtedy ".PID" zostanie dołączony do nazwy pliku. Przydatne przy debugowaniu wielowątkowych
# aplikacji.
kernel.core_uses_pid = 0
#
# Poniższy parametr jest używany do sprecyzowania wzoru nazwy dla pliku zawierającego zrzut pamięci. 
# Maksymalna ilość znaków to 128, domyślna wartość to "core". Poniżej są rozpisane parametry, które można
# wykorzystać przy tworzeniu nazwy dla pliku:
#
#    %<NUL>    '%' is dropped
#    %%    output one '%'
#    %p    pid
#    %P    global pid (init PID namespace)
#    %u    uid
#    %g    gid
#    %d    dump mode, matches PR_SET_DUMPABLE and
#        /proc/sys/fs/suid_dumpable
#    %s    signal number
#    %t    UNIX time of dump
#    %h    hostname
#    %e    executable filename (may be shortened)
#    %E    executable path
#    %<OTHER> both are dropped
#
# Jeśli pierwszym znakiem we wzorze jest "|", kernel będzie traktował dalszy jego ciąg jako polecenie do
# wykonania i zrzut pamięci będzie zapisany na standardowe wejście tego programu, a nie do pliku. Można również
# sprecyzować miejsce zapisu pliku przez rozpoczęcie nazwy od "/".
kernel.core_pattern = /tmp/core.%t.%h.%e.%p

# Gdy jakiś plik zostaje otwarty, system operacyjny tworzy wpis reprezentujący ten plik i przechowujący
# informacje na jego temat. Jeśli otwartych zostało 100 plików, będzie istnieć 100 wpisów w kernelu. Te wpisy
# są określane przy pomocy liczb, np. 100, 101, 102, etc. To są deskryptory plików. Ponadto, domyślnie każdy
# proces po uruchomieniu ma otwarte 3 standardowe deskryptory plików: STDIN(0), STDOUT(1), STDERR(2) . To
# jakie deskryptory ma otwarte jakaś aplikacja, można sprawdzić przez:
#
#    $ ls -al  /proc/$(pidof firefox)/fd/
#
# Deskryptor pliku może odnosić się do pliku, katalogu, urządzenia blokowego lub urządzenia znakowego,
# gniazda, kolejki FIFO, nienazwanego strumienia lub dowiązania symbolicznego. 
#
# Wartość w file-max określa maksymalną liczbę deskryptorów plików w systemie. Gdy tablica się zapełni, w logu
# kernela można znaleźć komunikaty typu: "VFS: file-max limit <number> reached" . W takim przypadku trzeba
# zwiększyć wartość tego parametru.
#fs.file-max = 99970
#
# Te trzy wartości określają kolejno liczbę zaalokowanych, liczbę zaalokowanych ale nieużywanych oraz 
# maksymalną liczbę deskryptorów w systemie.
#fs.file-nr = 4384       0       99970
#
# Określa maksymalną liczbę deskryptorów jakie pojedynczy proces może zaalokować.
fs.nr_open = 1048576

# Poniższy parametr określa rozmiar kolejki nasłuchu (listen queue), czyli gniazd w stanie LISTEN . Jest to
# liczba jednoczesnych połączeń, które serwer stara się skonfigurować. Gdy połączenie zostanie ustanowione,
# nie występuje już w tej kolejce i ta liczba nie ma już większego znaczenia. Jeśli kolejka nasłuchu zostanie
# zapełniona w wyniku zbyt wielu jednoczesnych prób połączeń, kolejne próby będą zrzucane. Większe kolejki
# lepiej się sprawują w unikaniu ataków DoS (Denial of Service).
net.core.somaxconn = 128

# Określa limit dla liczby procesów w systemie -- wątki (threads) są w istocie procesami, które dzielą
# przestrzeń adresową.
#kernel.threads-max = 15725

# Kontroluje liczbę stron, które mogą być jednocześnie odczytane ze SWAP. W przypadku gdy SWAP jest dość
# intensywnie wykorzystywany, zwiększenie wartości tego parametru może polepszyć wydajność.
# 
#   wartość | ilość stron |   rozmiar (bajty)
#  -------------------------------------------
#       0   |       1     | 1*4096  =4096
#       1   |       2     | 2*4096  =8192
#       2   |       4     | 4*4096  =16384
#       3   |       8     | 8*4096  =32768
#       4   |      16     | 16*4096 =65536
#       5   |      32     | 32*4096 =131072
#      ...  |     ....    |       ...
#
# Wartość "10" pozwala na odczyt 4MiB danych.
vm.page-cluster = 10

# Każda maszyna posiada pamięć fizyczną, czyli taką, która jest w niej zainstalowana. Dodatkowo posiada
# również przestrzeń adresową, która to jest mapą możliwej do zaadresowania przez proces pamięci. Nie cały
# jej obszar musi mieć swój odpowiednik w pamięci fizycznej, co jest implementowane za pomocą pamięci
# wirtualnej (SWAP). Dane na temat zaalokowanej pamięci można odczytać z /proc/meminfo :
#
#    $ cat /proc/meminfo | grep -i comm
#    CommitLimit:     2609604 kB
#    Committed_AS:    1404848 kB
#
# -- http://www.win.tue.nl/~aeb/linux/lk/lk-9.html
#
# Gdy ustawione na "0", kernel próbuje ustalić ilość wolnej pamięci w przypadku gdy przestrzeń użytkownika
# prosi o kolejne zasoby. W przypadku ustawienia "1", kernel udaje, że zawsze ma wystarczającą ilość pamięci
# aż do momentu gdy jej faktycznie zabranie. Z kolei wartość "2" sprawi, że kernel będzie próbował nie
# dopuścić do sytuacji, w której możliwe by było zaalokowanie więcej zasobów niż faktycznie jest dostępnych.
# Ta opcja może być bardzo użyteczna, bo wiele programów rezerwuje duże ilości pamięci "na wszelki wypadek",
# a w rzeczywistości z większości tych zasobów wcale nie korzysta.
vm.overcommit_memory = 0
#
# W przypadku gdy overcommit_memory jest ustawiony na "2", przestrzeń adresowa do zaalokowana nie może
# przekroczyć sumy wartości dostępnej ilości SWAP oraz procentu pamięci fizycznej ustawionej w tym parametrze.
# Przykładowo, jeśli system posiada do dyspozycji 1GiB pamięci RAM i do tego SWAP ma 1GiB, po sprecyzowaniu
# w overcommit_ratio wartości "50", możliwe będzie do zaalokowanie 1,5GiB.
#vm.overcommit_kbytes = 0
#vm.overcommit_ratio = 100

# MMAP to wywołanie systemowe nakazujące systemowi operacyjnemu odwzorowanie danej części wybranego pliku w
# przestrzeni adresowej procesu. Operacja ta powoduje, że do obszaru pliku można odnosić się jak do zwykłej
# tablicy bajtów w pamięci, eliminując potrzebę korzystania z dodatkowych wywołań systemowych typu read lub
# write. Z tego powodu często używa się tej operacji do przyspieszenia działania na dużych plikach. Poniższy
# parametr określa przestrzeń adresową, której procesy użytkownika nie będą mogły mapować. W przypadku gdyby
# pozwolono na mapowanie niższych wartości niż 64KiB, mogą wystąpić problemy z bezpieczeństwem systemu znane
# jako "kernel NULL pointer dereference". Ponieważ kernel w wyniku błędu może operować przez przypadek na
# informacjach zawartych na pierwszych kilku stronach pamięci, to procesom w przestrzeni użytkownika nie
# powinno się zezwalać na ich zapisywanie. Może do doprowadzić do powieszenia się systemu lub niestabilnej
# jego pracy. Dodatkowo, jeśli użytkownik jest w stanie mapować niższe porcje przestrzeni adresowej, może
# także zwiększyć swoje uprawnienia. Część aplikacji do poprawnej pracy wymaga by ustawić tutaj "0", jednak 
# pozostałe bez problemu działają przy określeniu wartości "65536".
# -- https://wiki.debian.org/mmap_min_addr
vm.mmap_min_addr = 65536

# W przypadku aplikacji z ustawionym bitem setuid, zrzut pamięci w chwili błędu takiego programu może zawierać
# poufne informacje, co stanowi zagrożenie dla bezpieczeństwa systemu, bo bit setuid na pliku wykonywalnym
# umożliwia uruchomienie danego programu przez innych użytkowników systemu z prawami właściciela tego
# pliku -- jeśli bit setuid jest ustawiony na programie, którego właścicielem jest root, nie ważne kto go
# wykona, ten program będzie się zachowywał tak jakby go uruchomił root. Jeśli ten parametr przyjmie wartość
# "0", to w przypadku gdy dojdzie do jakiejkolwiek zmiany uprawnień podczas startowania aplikacji, nie będzie
# można wykonać zrzutu pamięci. W przypadku "1", wszelkie kwestie bezpieczeństwa są odstawione na boczny
# tor -- ta wartość ma służyć tylko do debugowania. Można także sprecyzować wartość "2", która odpowiada za
# zrzut pamięci binarek, który normalnie by nie miał miejsca ale jeśli core_pattern będzie ścieżką absolutną
# (zaczynającą się znakiem "/") lub potokiem, to zrzut zostanie dokonany.
# -- http://manpages.ubuntu.com/manpages/trusty/pl/man5/core.5.html
fs.suid_dumpable = 0

# Poniższy parametr ustawia próg limitu dla liczby pseudoterminali (tych odpalanych w graficznym środowisku).
kernel.pty.max = 4096
#
# Wartość tylko do odczytu przechowująca informacje na temat liczby aktualnie otworzonych pseudoterminali.
#kernel.pty.nr = 6

# Kernel generuje logi z wykorzystaniem printk(). Te logi są zapisywane w buforze, do którego to można się
# odwołać przez dmesg. Z kolei rozmiar tego bufora jest kontrolowany przez opcję kernela CONFIG_LOG_BUF_SHIFT ,
# której argumentem jest liczba, np. 17 -- oznacza ona rozmiar bufora 128KiB (2^17). Rozmiar pojedynczej
# wiadomości nie może przekraczać 1KiB. W zależności od ważności komunikatu, te dzielimy na:
#
#   0 KERN_EMERG
#   1 KERN_ALERT
#   2 KERN_CRIT
#   3 KERN_ERR
#   4 KERN_WARNING
#   5 KERN_NOTICE
#   6 KERN_INFO
#   7 KERN_DEBUG
#
# Poniższe cztery wartości odpowiadają za console_loglevel, default_message_loglevel, minimum_console_level
# oraz default_console_loglevel . Komunikaty o priorytecie wyższym (niższy numer) niż console_loglevel będą
# wypisywane na konsoli. Komunikaty bez jawnego priorytetu, będą wypisywane z priorytetem ustawionym w
# default_message_level. Z kolei minimum_console_loglevel jest najmniejszą wartością, którą można ustawić w
# console_loglevel, a default_console_loglevel jest domyślną wartością dla console_loglevel. 
kernel.printk = 1 4 1 7
#
# Precyzuje opóźnienie kolejnych komunikatów (czas w milisekundach). Dozwolone wartości z zakresu od 0 do
# 10000.
kernel.printk_delay = 0
#
# Pierwszy parametr definiuje limit wiadomości, po przekroczeniu którego kernel zaprzestanie wypisywać
# komunikaty przez pewien okres czasu, który zostanie sprecyzowany w printk_ratelimit . Ten mechanizm ma
# zastosowanie jedynie w przypadku wykrycia takich samych wiadomości.
# -- http://lwn.net/Articles/66091/
kernel.printk_ratelimit_burst = 10
kernel.printk_ratelimit = 5

# Fizyczna pamięć jest podzielona na strony (pages), które są podstawową jednostką zarządzania pamięcią. Kiedy
# proces uzyskuje dostęp do wirtualnego adresu, procesor musi przetłumaczyć go na adres fizyczny, a robi to w
# oparciu o tablicę stron, którą dostarcza kernel. Zanim jednak procesor może dokonać takiego tłumaczenia,
# musi on przeprowadzić szereg odczytów pamięci fizycznej i uzyskać informację o tej tablicy. By przyśpieszyć
# ten proces dla późniejszych odwołań do tego samego adresu wirtualnego, procesor zapisuje informacje na temat
# ostatnio odwiedzonych adresów w TLB (Translation Lookaside Buffer). TLB jest to mały ale bardzo szybki cache
# CPU i nietrafianie przy odpytywaniu adresów kosztuje sporo czasu. Jednak można zwiększyć liczbę trafień
# przez zmapowanie większych ciągłych obszarów pamięci fizycznej przez zwiększenie rozmiaru strony, który
# domyślnie wynosi 4KiB. Im większe są strony, tym mniej wpisów zawiera tablica, a im mniej wpisów, tym lepsze
# i szybsze jest zarządzanie pamięcią, bo mniej czasu zajmuje odnalezienie zmapowanego obszaru.
#
# Mechanizm, zwany HugePages, pozwala zwiększyć, w zależności od procesora, rozmiar strony do 2MiB lub nawet
# do 1GiB. Jednak HugePages znajdują zastosowanie tylko w przypadku pamięci współdzielonej i jeśli zostanie
# przeznaczony jakiś obszar pamięci pod HugePages, będzie on prealokowany i nigdy nie zostanie przeniesiony
# do SWAP. Aplikacje, które używają tylko zwykłych stron, nie będą mogły się odwoływać do tego zarezerwowanego
# miejsca w pamięci. Wielkość strony można odczytać z /proc/meminfo lub też przez sprawdzenie flag procesora w
# /proc/cpuinfo -- PSE dla 2MiB i PDPE1GB dla 1GiB. Trzeba także posiadać kernel z włączonymi opcjami
# CONFIG_HUGETLBFS , CONFIG_HUGETLB_PAGE .
#
# Wartość tego parametru określa ilość HugePages w systemie.
#vm.nr_hugepages = 200
#
# Poniższy parametr precyzuje jak bardzo może się rozrosnąć przestrzeń pamięci pod HugePages , w przypadku gdy
# jakiś proces potrzebuje zaalokować więcej pamięci ale limit w nr_hugepages został przekroczony. W przypadku
# gdy ten proces straci apetyt na pamięć, te strony zostaną zwolnione.
#vm.nr_overcommit_hugepages = 50
#
# Wartość tego parametru ustala grupę, w skład której wchodzą użytkownicy mogący korzystać z ficzeru
# HugePages. Grupę pierw trzeba stworzyć i następnie dodać do niej określonych użytkowników. Trzeba także
# utworzyć punkt montowania oraz dodać wpis do /etc/fstab w postaci:
#
#    hugetlbfs /hugepages hugetlbfs mode=1770,gid=5555 0 0
#
#vm.hugetlb_shm_group = 5555