{"id":20340,"date":"2026-08-05T08:33:04","date_gmt":"2026-08-05T06:33:04","guid":{"rendered":"https:\/\/webhosting.de\/sysctl-tuning-webhosting-server-performance\/"},"modified":"2026-08-05T08:33:04","modified_gmt":"2026-08-05T06:33:04","slug":"optymalizacja-wydajnosci-serwera-hostingowego-za-pomoca-sysctl","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/sysctl-tuning-webhosting-server-performance\/","title":{"rendered":"Optymalizacja za pomoc\u0105 sysctl na serwerach hostingowych: optymalizacja wydajno\u015bci systemu Linux"},"content":{"rendered":"<p>Dzi\u0119ki ukierunkowanemu <strong>optymalizacja sysctl<\/strong> zwi\u0119kszam szybko\u015b\u0107 przyjmowania i przetwarzania po\u0142\u0105cze\u0144, skracam czas odpowiedzi oraz zapewniam niezawodn\u0105 prac\u0119 serwer\u00f3w hostingowych nawet pod obci\u0105\u017ceniem. W niniejszym przewodniku przedstawiono konkretne parametry j\u0105dra, bezpieczny proces testowania oraz warto\u015bci pocz\u0105tkowe, z kt\u00f3rych korzystam w przypadku stos\u00f3w Apache, Nginx i PHP-FPM, aby <strong>Wydajno\u015b\u0107 systemu Linux<\/strong> \u0142atwo skalowa\u0107.<\/p>\n\n<h2>Punkty centralne<\/h2>\n\n<ul>\n  <li><strong>Najpierw analiza<\/strong>: Zbada\u0107 stan aktualny, dok\u0142adnie go udokumentowa\u0107, przeprowadzi\u0107 testy stagingowe przed wdro\u017ceniem do \u015brodowiska produkcyjnego.<\/li>\n  <li><strong>Kolejki sieciowe<\/strong>: zwi\u0119kszy\u0107 warto\u015bci parametr\u00f3w somaxconn, tcp_max_syn_backlog i netdev_max_backlog na wypadek szczytowego obci\u0105\u017cenia.<\/li>\n  <li><strong>Pami\u0119\u0107<\/strong>: dostosowanie parametr\u00f3w swappiness i dirty oraz pami\u0119ci podr\u0119cznej stron w celu skr\u00f3cenia czasu odpowiedzi.<\/li>\n  <li><strong>Ograniczenia<\/strong>: Nale\u017cy odpowiednio ustawi\u0107 warto\u015bci fs.file-max i pid_max, aby zapewni\u0107 prawid\u0142owe dzia\u0142anie du\u017cej liczby proces\u00f3w roboczych.<\/li>\n  <li><strong>Obserwowa\u0107<\/strong>: Nale\u017cy konsekwentnie mierzy\u0107 op\u00f3\u017anienia, zaleg\u0142o\u015bci, operacje swap, utraty i wska\u017aniki b\u0142\u0119d\u00f3w.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-server-optimierung-8374.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dlaczego optymalizacja za pomoc\u0105 sysctl przyspiesza dzia\u0142anie hostingu internetowego<\/h2>\n\n<p>Konfiguruj\u0119 parametry j\u0105dra tak, aby serwery WWW dzia\u0142a\u0142y przy wysokim stopniu r\u00f3wnoleg\u0142o\u015bci <strong>Po\u0142\u0105czenia<\/strong> lepsze buforowanie i szybsze przetwarzanie. Bez tych dostosowa\u0144 zaleg\u0142o\u015bci si\u0119 kumuluj\u0105, sesje blokuj\u0105 procesy robocze, a czasy odpowiedzi wyra\u017anie si\u0119 wyd\u0142u\u017caj\u0105. Dzi\u0119ki wy\u017cszym limitom kolejek, odpowiednim buforom TCP i w\u0142a\u015bciwym interwa\u0142om keepalive utrzymuj\u0119 potok w zwi\u0119z\u0142ej formie i \u0142atwej do planowania. Efekty odczuwam natychmiast: mniej utraty pakiet\u00f3w SYN, stabilniejsze uzgodnienia TLS, mniej retransmisji. W ten spos\u00f3b stos internetowy uwalnia sw\u00f3j potencja\u0142, poniewa\u017c <strong>J\u0105dro<\/strong> Nie tworzy si\u0119 ju\u017c sztucznie w\u0105skich garde\u0142.<\/p>\n\n<h2>Uporz\u0105dkowany przebieg pracy: pomiar, testowanie, wdro\u017cenie<\/h2>\n\n<p>Przed ka\u017cd\u0105 zmian\u0105 zapisuj\u0119 stan za pomoc\u0105 <code>sysctl -a<\/code> i dokumentuj\u0119 rzucaj\u0105ce si\u0119 w oczy <strong>Warto\u015bci<\/strong>. Najpierw testuj\u0119 nowe parametry z <code>sysctl -w<\/code> i obserwuj\u0119 wska\u017aniki pod obci\u0105\u017ceniem w maszynie wirtualnej stagingowej. Dopiero gdy op\u00f3\u017anienia, utraty pakiet\u00f3w i obci\u0105\u017cenie pami\u0119ci wydaj\u0105 si\u0119 wiarygodne, zapisuj\u0119 sta\u0142e ustawienia <code>\/etc\/sysctl.d\/*.conf<\/code>. Nast\u0119pnie \u0142aduj\u0119 je w kontrolowany spos\u00f3b za pomoc\u0105 <code>sysctl --system<\/code> oraz ustawiam wska\u017aniki w systemie monitorowania, aby wykrywa\u0107 skutki uboczne. Procedura ta zmniejsza ryzyko, zwi\u0119ksza <strong>Identyfikowalno\u015b\u0107<\/strong> i sprawia, \u017ce przywracanie poprzednich wersji staje si\u0119 dziecinnie proste.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_sysctl_tuning_mtng_3842.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kolejki sieciowe zapewniaj\u0105ce wysok\u0105 wsp\u00f3\u0142bie\u017cno\u015b\u0107<\/h2>\n\n<p>Cz\u0119sto dochodzi do zatoru w zaleg\u0142o\u015bciach listy zada\u0144, gdy wielu klient\u00f3w zg\u0142asza si\u0119 jednocze\u015bnie, a <strong>Serwer sieciowy<\/strong> na chwil\u0119 zablokowane. Wtedy zwi\u0119kszam <code>net.core.somaxconn<\/code>, aby wi\u0119cej po\u0142\u0105cze\u0144 przychodz\u0105cych trafia\u0142o do kolejki. R\u00f3wnolegle zwi\u0119kszam <code>net.ipv4.tcp_max_syn_backlog<\/code>, aby przechwyci\u0107 po\u0142\u0105czenia p\u00f3\u0142otwarte w przypadku skok\u00f3w ruchu TLS lub bot\u00f3w. Dodatkowo pomocne jest wy\u017csze <code>net.core.netdev_max_backlog<\/code>, gdy pakiety docieraj\u0105 szybciej, ni\u017c stos jest w stanie je przetworzy\u0107. Ci, kt\u00f3rzy chc\u0105 zag\u0142\u0119bi\u0107 si\u0119 w ten temat, znajd\u0105 zwi\u0119z\u0142y <a href=\"https:\/\/webhosting.de\/pl\/tuning-jadra-linux-sysctl-parametr-serverboost-opti\/\">Przegl\u0105d g\u0142\u00f3wnych parametr\u00f3w sysctl<\/a>, kt\u00f3re traktuj\u0119 jako punkt wyj\u015bcia, aby <strong>Szczyty<\/strong> utrzyma\u0107 elastyczno\u015b\u0107.<\/p>\n\n<h2>W\u0142a\u015bciwy dob\u00f3r bufora TCP i skalowania okna<\/h2>\n\n<p>W przypadku wielu r\u00f3wnoleg\u0142ych transfer\u00f3w wp\u0142ywaj\u0105 <strong>tcp_rmem<\/strong> oraz <strong>tcp_wmem<\/strong> ma bezpo\u015bredni wp\u0142yw na przepustowo\u015b\u0107 i op\u00f3\u017anienie. Ustawiam warto\u015bci Min\/Default\/Max tak, aby kr\u00f3tkie odpowiedzi nie utkn\u0119\u0142y w zbyt du\u017cych buforach, a d\u0142ugotrwa\u0142e po\u0142\u0105czenia mia\u0142y wystarczaj\u0105co du\u017co przestrzeni. Kluczowe znaczenie ma skalowanie okna (Window Scaling), w przeciwnym razie przepustowo\u015b\u0107 zostanie wcze\u015bnie ograniczona przy wy\u017cszym RTT. Je\u015bli chodzi o podstawy skalowania i przepustowo\u015bci, pomocny jest dla mnie ten zwi\u0119z\u0142y artyku\u0142 praktyczny na temat <a href=\"https:\/\/webhosting.de\/pl\/serwer-tcp-skalowanie-okna-optymalizacja-przepustowosci-dostrajanie-sieci\/\">Skalowanie okna TCP<\/a>. Dzi\u0119ki odpowiednio dostosowanym buforom zmniejsza si\u0119 liczba retransmisji, a <strong>Dobra wydajno\u015b\u0107<\/strong>\u2011Krzywa zachowuje wi\u0119ksz\u0105 stabilno\u015b\u0107 pod obci\u0105\u017ceniem.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-server-optimization-4578.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Zarz\u0105dzanie pami\u0119ci\u0105: wsp\u00f3\u0142czynnik swappiness, brudne strony i pami\u0119\u0107 podr\u0119czna stron<\/h2>\n\n<p>Swap zauwa\u017calnie spowalnia dzia\u0142anie us\u0142ug internetowych, dlatego go zmniejszam <strong>vm.swappiness<\/strong> cz\u0119sto ustawiam t\u0119 warto\u015b\u0107 na 10\u201320, aby j\u0105dro d\u0142u\u017cej korzysta\u0142o z pami\u0119ci RAM. Dodatkowo reguluj\u0119 szczyty zapisu za pomoc\u0105 <code>vm.dirty_ratio<\/code> oraz <code>vm.dirty_background_ratio<\/code>, aby du\u017ce operacje flush nie zatyka\u0142y potoku wej\u015bcia\/wyj\u015bcia. W przypadku cz\u0119stego dost\u0119pu do plik\u00f3w monitoruj\u0119 pami\u0119\u0107 podr\u0119czn\u0105 stron i upewniam si\u0119, \u017ce j\u0105dro systemu Linux nie usuwa jej przedwcze\u015bnie. Bardziej szczeg\u00f3\u0142owe informacje na temat sterowania usuwaniem danych z pami\u0119ci podr\u0119cznej dostarcza mi ten artyku\u0142 na temat <a href=\"https:\/\/webhosting.de\/pl\/usuwanie-pamieci-podrecznej-stron-serwera-linux-optymalizacja-drukowania-insight\/\">Usuwanie danych z pami\u0119ci podr\u0119cznej stron<\/a>. Wi\u0119c trzymam <strong>Czasy reakcji<\/strong> kr\u00f3tko m\u00f3wi\u0105c, nawet je\u015bli uruchomione s\u0105 zadania Cron, tworzenie kopii zapasowych lub przesy\u0142anie plik\u00f3w multimedialnych.<\/p>\n\n<h2>Identyfikatory plik\u00f3w i limity proces\u00f3w: fs.file-max i pid_max<\/h2>\n\n<p>Wiele wirtualnych host\u00f3w, pul PHP-FPM, pami\u0119ci podr\u0119cznych i gniazd wymaga du\u017cej ilo\u015bci <strong>Deskryptory plik\u00f3w<\/strong>. W zwi\u0105zku z tym zwi\u0119kszam <code>fs.file-max<\/code> z du\u017cym zapasem, aby nie przekroczy\u0107 limit\u00f3w podczas rejestrowania, przesy\u0142ania danych i nawi\u0105zywania po\u0142\u0105cze\u0144 TLS. W \u015brodowiskach z du\u017c\u0105 liczb\u0105 proces\u00f3w roboczych uruchamiam <code>kernel.pid_max<\/code> wysoki, aby unikn\u0105\u0107 kolizji identyfikator\u00f3w proces\u00f3w. Dodatkowo sprawdzam limity us\u0142ug (np. <code>LimitNOFILE<\/code> w systemd), aby zwi\u0119kszenie wersji j\u0105dra zosta\u0142o uwzgl\u0119dnione r\u00f3wnie\u017c w us\u0142ugach. Te proste ustawienia zapobiegaj\u0105 <strong>B\u0142\u0105d<\/strong> tak samo niezawodnie jak komunikat \u201eToo many open files\u201c.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/sysctl_tuning_linux_server_8239.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Przegl\u0105d przydatnych warto\u015bci orientacyjnych<\/h2>\n\n<p>Poni\u017csza tabela przedstawia warto\u015bci pocz\u0105tkowe, kt\u00f3re ustali\u0142em na serwerach zbli\u017conych do produkcyjnych w rzeczywistych warunkach <strong>Obci\u0105\u017cenie<\/strong> sprawdzam. Nie zast\u0119puj\u0105 one pomiar\u00f3w, ale pozwalaj\u0105 szybko rozpocz\u0105\u0107 prac\u0119. Kto zaczyna ostro\u017cnie i stopniowo zwi\u0119ksza warto\u015bci, zmniejsza ryzyko i szybciej dostrzega skutki uboczne. Po ka\u017cdej zmianie sprawdzam op\u00f3\u017anienia, utracone pakiety, retransmisje i aktywno\u015b\u0107 swapowania. Je\u015bli trendy s\u0105 odpowiednie, warto\u015b\u0107 trafia do mojego <strong>Profil podstawowy<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametry<\/th>\n      <th>Efekt<\/th>\n      <th>warto\u015b\u0107 pocz\u0105tkowa<\/th>\n      <th>Uwagi<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>net.core.somaxconn<\/td>\n      <td>Kolejka nowych po\u0142\u0105cze\u0144<\/td>\n      <td>65535<\/td>\n      <td>Zsynchronizowa\u0107 z list\u0105 zada\u0144 serwera WWW<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_max_syn_backlog<\/td>\n      <td>P\u00f3\u0142otwarte po\u0142\u0105czenia TCP<\/td>\n      <td>4096<\/td>\n      <td>Pomaga w radzeniu sobie ze szczytami ruchu generowanego przez boty TLS<\/td>\n    <\/tr>\n    <tr>\n      <td>net.core.netdev_max_backlog<\/td>\n      <td>Bufor przed stosem sieciowym<\/td>\n      <td>16384<\/td>\n      <td>Zwr\u00f3\u0107 uwag\u0119 na wydajno\u015b\u0107 NIC\/IRQ<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_rmem<\/td>\n      <td>Bufor odbiorczy (min.\/domy\u015blny\/maks.)<\/td>\n      <td>4096 87380 134217728<\/td>\n      <td>Sprawd\u017a RTT\/przepustowo\u015b\u0107<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_wmem<\/td>\n      <td>Bufor wysy\u0142ania (min\/domy\u015blny\/maks.)<\/td>\n      <td>4096 65536 134217728<\/td>\n      <td>Uwzgl\u0119dnienie skalowania okien<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.swappiness<\/td>\n      <td>Sk\u0142onno\u015b\u0107 do swap\u00f3w<\/td>\n      <td>10<\/td>\n      <td>Dostosowa\u0107 do pojemno\u015bci pami\u0119ci RAM<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>Wyg\u0142adzanie ko\u0144c\u00f3wek pisak\u00f3w<\/td>\n      <td>10\u201315<\/td>\n      <td>Monitorowanie obci\u0105\u017cenia IO<\/td>\n    <\/tr>\n    <tr>\n      <td>fs.file-max<\/td>\n      <td>Globalne uchwyty plik\u00f3w<\/td>\n      <td>500000<\/td>\n      <td>Dostosuj limity us\u0142ug<\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.pid_max<\/td>\n      <td>Maksymalna liczba identyfikator\u00f3w proces\u00f3w<\/td>\n      <td>4194304<\/td>\n      <td>Zapewnienie bezpiecze\u0144stwa przy du\u017cej g\u0119sto\u015bci host\u00f3w<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_keepalive_time<\/td>\n      <td>Od trybu bezczynno\u015bci do Keepalive<\/td>\n      <td>600<\/td>\n      <td>Sprawd\u017a wytyczne dotycz\u0105ce frontendu\/proxy<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Te warto\u015bci pocz\u0105tkowe dostosowuj\u0119 w zale\u017cno\u015bci od sprz\u0119tu, struktury ruchu i stosu, aby <strong>Zasoby<\/strong> nale\u017cy je racjonalnie wykorzystywa\u0107. Ma\u0142e systemy VPS cz\u0119sto wymagaj\u0105 ni\u017cszych limit\u00f3w, natomiast serwery dedykowane mog\u0105 wytrzyma\u0107 wy\u017csze. Przy wysokim RTT i du\u017cej przepustowo\u015bci zwi\u0119kszam maksymalne bufory, natomiast w przypadku interfejs\u00f3w API, dla kt\u00f3rych op\u00f3\u017anienie ma kluczowe znaczenie, utrzymuj\u0119 je na umiarkowanym poziomie. Kluczowe znaczenie ma ci\u0105g\u0142e mierzenie odpowiednich wska\u017anik\u00f3w. Tylko to, co mo\u017cna zmierzy\u0107 i co ulega poprawie, pozostaje trwale jako <strong>Ustawienie<\/strong>.<\/p>\n\n<h2>Monitorowanie po tuningu: co mierz\u0119<\/h2>\n\n<p>Po ka\u017cdej zmianie najpierw sprawdzam wska\u017aniki SYN, Accept i Error w <strong>Serwer sieciowy<\/strong>. Nast\u0119pnie mierz\u0119 liczb\u0119 retransmisji TCP, pakiety w nieprawid\u0142owej kolejno\u015bci oraz wska\u017anik utraty pakiet\u00f3w na interfejsach sieciowych. Dodatkowo obserwuj\u0119 zjawisko \u201eCPU-Steal\u201d, d\u0142ugo\u015bci kolejek Run-Queue oraz czas oczekiwania na operacje wej\u015bcia\/wyj\u015bcia (IO), aby zidentyfikowa\u0107 rzeczywiste w\u0105skie gard\u0142a. Je\u015bli chodzi o pami\u0119\u0107, interesuj\u0105 mnie b\u0142\u0119dy stron (page faults), trafienia w pami\u0119ci podr\u0119cznej oraz operacje swap-in\/swap-out. Dopiero gdy trendy s\u0105 sp\u00f3jne w kilku oknach obci\u0105\u017cenia, wyja\u015bniam to <strong>Strojenie<\/strong> za udane.<\/p>\n\n<h2>Optymalizacja i stosy serwer\u00f3w WWW: Nginx, Apache, PHP-FPM<\/h2>\n\n<p>Nginx czerpie korzy\u015bci z wysokich <strong>Dane dotycz\u0105ce po\u0142\u0105cze\u0144<\/strong>, je\u015bli uwzgl\u0119dni si\u0119 kolejki j\u0105dra i bufory. W przypadku Apache\u2019a wiele zale\u017cy od modu\u0142u MPM: event radzi sobie lepiej z du\u017c\u0105 liczb\u0105 klient\u00f3w intensywnie korzystaj\u0105cych z keepalive ni\u017c prefork. PHP-FPM wymaga wystarczaj\u0105cej liczby uchwyt\u00f3w plik\u00f3w i proces\u00f3w, ale zachowuje niskie op\u00f3\u017anienia, o ile bufory j\u0105dra nie prze\u0142adowuj\u0105 systemu. Koordynuj\u0119 limity mi\u0119dzy serwerem WWW, PHP-FPM, baz\u0105 danych i j\u0105drem; dopiero taka wsp\u00f3\u0142praca zapobiega powstawaniu kolejek. W ten spos\u00f3b stos wykorzystuje dost\u0119pne <strong>Sprz\u0119t<\/strong> efektywnie, zamiast wzajemnie si\u0119 hamowa\u0107.<\/p>\n\n<h2>Strategia wdra\u017cania i profile: podstawowe a specjalistyczne<\/h2>\n\n<p>Wyznaj\u0119 konserwatywne podej\u015bcie <strong>Profil podstawowy<\/strong> z konserwatywnymi warto\u015bciami dla pracy ci\u0105g\u0142ej. Dla sklep\u00f3w generuj\u0105cych du\u017ce ilo\u015bci danych, pul FPM z wieloma procesami roboczymi lub w\u0119z\u0142\u00f3w API tworz\u0119 dodatkowe profile. Zmiany s\u0105 przenoszone za pomoc\u0105 systemu zarz\u0105dzania konfiguracj\u0105 na \u015brodowisko testowe, przechodz\u0105 testy obci\u0105\u017ceniowe i dopiero potem trafiaj\u0105 do \u015brodowiska produkcyjnego. Dokumentuj\u0119 r\u00f3\u017cnice dla poszczeg\u00f3lnych r\u00f3l host\u00f3w i przygotowuj\u0119 jasny plan awaryjny. Ta dyscyplina pozwala mi unikn\u0105\u0107 awarii i u\u0142atwia p\u00f3\u017aniejsze <strong>Konserwacja<\/strong> znacznie l\u017cejsze.<\/p>\n\n<h2>Keepalive i limity czasu: szybkie zwalnianie zasob\u00f3w<\/h2>\n\n<p>W interfejsach hostingowych przedstawiam <strong>Keepalive<\/strong> ustawi\u0107 na warto\u015b\u0107 konserwatywn\u0105, aby unikn\u0105\u0107 sesji typu \u201ezombie\u201d. <code>net.ipv4.tcp_keepalive_time<\/code>, <code>_intvl<\/code> oraz <code>_proby<\/code> Pomagam skonfigurowa\u0107 system tak, aby nieaktywne po\u0142\u0105czenia by\u0142y szybko usuwane. Za serwerami proxy lub modu\u0142ami r\u00f3wnowa\u017cenia obci\u0105\u017cenia dostosowuj\u0119 limity czasu serwer\u00f3w i po\u0142\u0105cze\u0144 upstream, aby nikt nie utrzymywa\u0142 po\u0142\u0105czenia sztucznie. Kr\u00f3tsze limity czasu zmniejszaj\u0105 obci\u0105\u017cenie pami\u0119ci i liczb\u0119 otwartych po\u0142\u0105cze\u0144 (FD), nie zra\u017caj\u0105c przy tym prawdziwych u\u017cytkownik\u00f3w. Wa\u017cne pozostaje sprawdzanie w odniesieniu do CDN i <strong>WAF<\/strong>\u2011wytyczne, \u017ceby nikt nie mia\u0142 zastrze\u017ce\u0144.<\/p>\n\n<h2>Przewodnik praktyczny: Jak bezpiecznie wprowadza\u0107 zmiany<\/h2>\n\n<p>Zaczn\u0119 na pr\u00f3b\u0119 od kilku, \u0142atwych do zaobserwowania <strong>Parametry<\/strong> i zwi\u0119kszaj pozycj\u0119 dopiero po pojawieniu si\u0119 pozytywnego trendu. Tymczasowo: <code>sysctl -w net.core.somaxconn=65535<\/code>, <code>sysctl -w net.ipv4.tcp_max_syn_backlog=4096<\/code>, <code>sysctl -w vm.swappiness=10<\/code>. Na sta\u0142e zapisuj\u0119 je w <code>\/etc\/sysctl.d\/99-hosting.conf<\/code> i za\u0142aduj je za pomoc\u0105 <code>sysctl --system<\/code>. Je\u015bli pojawi si\u0119 efekt uboczny, selektywnie cofam zmiany i odnotowuj\u0119 wyniki, wska\u017aniki oraz czas wyst\u0105pienia. Ten ma\u0142y <strong>Proces<\/strong> zapewnia czysto\u015b\u0107 system\u00f3w i mo\u017cliwo\u015b\u0107 ich kontroli.<\/p>\n\n<h2>Kontrola zator\u00f3w i dyscyplina w kolejkach: BBR, CUBIC i fq<\/h2>\n\n<p>Opr\u00f3cz bufor\u00f3w \u015bwiadomie podejmuj\u0119 decyzje dotycz\u0105ce kontroli zat\u0142oczenia i planowania przesy\u0142ek. Z <code>net.ipv4.tcp_congestion_control<\/code> Wybieram CUBIC (domy\u015blny w wielu dystrybucjach) lub celowo testuj\u0119 BBR na serwerach o wysokim RTT lub silnie zmiennej przepustowo\u015bci. Wa\u017cny jest przy tym odpowiedni harmonogram dyscypliny kolejki: poprzez <code>net.core.default_qdisc=fq<\/code> W\u0142\u0105czam kolejkowanie przep\u0142yw\u00f3w z regulacj\u0105 tempa (Pacing), kt\u00f3re sprawnie obs\u0142uguje kr\u00f3tkie odpowiedzi i wiele r\u00f3wnoczesnych przep\u0142yw\u00f3w. Mierz\u0119 sprawiedliwo\u015b\u0107 (op\u00f3\u017anienia p50\/p99) oraz przepustowo\u015b\u0107 efektywn\u0105 z BBR i bez niego, zachowuj\u0105c ostro\u017cno\u015b\u0107, gdy urz\u0105dzenia po\u015brednicz\u0105ce lub starsze modele reaguj\u0105 w nietypowy spos\u00f3b. W przypadku interfejs\u00f3w API, dla kt\u00f3rych op\u00f3\u017anienia maj\u0105 kluczowe znaczenie, kombinacja fq+cubic cz\u0119sto sprawdza si\u0119 jako solidny punkt wyj\u015bcia; BBR testuj\u0119 stopniowo na niewielkiej liczbie w\u0119z\u0142\u00f3w, zanim wdro\u017c\u0119 go na szerok\u0105 skal\u0119.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/sysctl_tuning_8910.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>UDP\/QUIC i HTTP\/3: Prawid\u0142owe wymiarowanie bufora UDP<\/h2>\n\n<p>Ka\u017cdy, kto wdra\u017ca HTTP\/3\/QUIC, powinien wyra\u017anie uwzgl\u0119dni\u0107 protok\u00f3\u0142 UDP. Podkre\u015blam <code>net.core.rmem_max<\/code> oraz <code>net.core.wmem_max<\/code> aby gniazda QUIC nie ogranicza\u0142y sztucznie przepustowo\u015bci przy wysokich szybko\u015bciach transmisji. Jednocze\u015bnie dostosowuj\u0119 <code>net.ipv4.udp_mem<\/code> oraz bufory domy\u015blne (<code>net.core.rmem_default<\/code>, <code>net.core.wmem_default<\/code>) w umiarkowanym stopniu. Cel: zapewnienie wystarczaj\u0105cego bufora, aby nie dochodzi\u0142o do utraty pakiet\u00f3w w okresach wzmo\u017conego ruchu, ale bez nadmiernych warto\u015bci domy\u015blnych, kt\u00f3re zajmuj\u0105 pami\u0119\u0107. U\u017cycie fq jako qdisc pomaga w regulacji tempa r\u00f3wnie\u017c w przypadku protoko\u0142u UDP. Kluczowe znaczenie maj\u0105 utraty pakiet\u00f3w w kolejkach kart sieciowych: sprawdzam <code>netdev_max_backlog<\/code>, obci\u0105\u017cenie IRQ oraz ustawienia GRO\/TSO w kontek\u015bcie karty. W sekcji \u201eObci\u0105\u017cenie\u201d sprawdzam <em>b\u0142\u0119dy odbioru<\/em> oraz licznik UDP-drop, aby wcze\u015bnie wykrywa\u0107 w\u0105skie gard\u0142a.<\/p>\n\n<h2>Porty efemeryczne, obs\u0142uga stan\u00f3w TIME\u2011WAIT i FIN<\/h2>\n\n<p>W przypadku wielu po\u0142\u0105cze\u0144 wychodz\u0105cych przydzia\u0142 port\u00f3w szybko si\u0119 wyczerpuje. Rozszerzam <code>net.ipv4.ip_local_port_range<\/code> (np. do 10000\u201365535) i skr\u00f3\u0107 <code>net.ipv4.tcp_fin_timeout<\/code> ostro\u017cnie (np. 30 s), aby zasoby zosta\u0142y szybko zwolnione. Historyczne poprawki, takie jak <em>tcp_tw_recycle<\/em> trzymam si\u0119 od nich z daleka \u2013 s\u0105 one odleg\u0142e lub k\u0142opotliwe. Jednocze\u015bnie sprawdzam na poziomie aplikacji SO_REUSEPORT i pul\u0119 po\u0142\u0105cze\u0144, poniewa\u017c s\u0105 one skuteczniejsze ni\u017c agresywne sztuczki na poziomie j\u0105dra. Podczas pracy obserwuj\u0119 odsetek stan\u00f3w TIME-WAIT za pomoc\u0105 <code>ss<\/code>; je\u015bli warto\u015bci te gwa\u0142townie wzrosn\u0105, najpierw sprawdzam sp\u00f3jno\u015b\u0107 ustawie\u0144 Keepalive\/Timeout mi\u0119dzy serwerem proxy a serwerem \u017ar\u00f3d\u0142owym, zanim zwi\u0119ksz\u0119 warto\u015bci w sysctl.<\/p>\n\n<h2>Conntrack w skr\u00f3cie: lepiej unika\u0107 spadk\u00f3w ni\u017c d\u0105\u017cy\u0107 do skalowania za wszelk\u0105 cen\u0119<\/h2>\n\n<p>Je\u015bli przed hostem znajduje si\u0119 zapora sieciowa\/NAT lub lokalnie dzia\u0142a iptables\/nftables, cz\u0119sto ogranicza to tabel\u0119 \u015bledzenia po\u0142\u0105cze\u0144. Ustawiam <code>net.netfilter.nf_conntrack_max<\/code> oraz rozmiar skr\u00f3tu dostosowany do pojemno\u015bci pami\u0119ci RAM i przewidywanego profilu po\u0142\u0105cze\u0144. Istotne znaczenie maj\u0105 limity czasu: zbyt d\u0142ugo utrzymywane sesje zajmuj\u0105 sloty, zbyt kr\u00f3tkie warto\u015bci powoduj\u0105 <em>przedwczesne wyga\u015bni\u0119cie<\/em>. Mierz\u0119 <em>wpisy<\/em>, <em>wyszukiwania<\/em>, <em>znaleziono<\/em> a przede wszystkim <em>krople<\/em> w statystykach Conntrack. Dopiero gdy aplikacja zostanie prawid\u0142owo zsynchronizowana z keepalive i limitami czasu, powi\u0119kszam tabel\u0119 \u2013 w ten spos\u00f3b skaluj\u0119 j\u0105 efektywnie, zamiast po prostu zape\u0142nia\u0107 pami\u0119\u0107.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/hosting-serverraum-9483.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>IPv6 i pami\u0119ci podr\u0119czne s\u0105siedztwa: stabilno\u015b\u0107 przy du\u017cej liczbie w\u0119z\u0142\u00f3w r\u00f3wnorz\u0119dnych<\/h2>\n\n<p>W trybie Dual-Stack wiele prze\u0142\u0105cznik\u00f3w TCP zachowuje si\u0119 identycznie, jednak warto zwr\u00f3ci\u0107 uwag\u0119 na pami\u0119ci podr\u0119czne s\u0105siedztwa. W przypadku host\u00f3w z du\u017c\u0105 liczb\u0105 jednoczesnych po\u0142\u0105cze\u0144 z innymi urz\u0105dzeniami, na wszelki wypadek zwi\u0119kszam progi tabel ARP\/ND (<code>net.ipv4.neigh.default.gc_thresh{1,2,3}<\/code> oraz ich odpowiedniki w protokole IPv6), aby \u017cadne wpisy nie zosta\u0142y przedwcze\u015bnie zast\u0105pione. Na serwerach wy\u0142\u0105czam przetwarzanie przekierowa\u0144 (<code>send_redirects<\/code> Odpowiednio <code>accept_redirects<\/code>) i dbaj o sp\u00f3jno\u015b\u0107 <code>accept_ra<\/code>\u2014 Zachowanie stosowane w przypadku, gdy og\u0142oszenia router\u00f3w s\u0105 niepo\u017c\u0105dane. Ogranicza to zb\u0119dn\u0105 prac\u0119 w stosie i pozwala unikn\u0105\u0107 tajemniczych op\u00f3\u017anie\u0144, gdy proces ustalania s\u0105siedztwa zaczyna si\u0119 zak\u0142\u00f3ca\u0107.<\/p>\n\n<h2>Elementy zwi\u0105zane z bezpiecze\u0144stwem: pliki cookie SYN, znaczniki czasu i ECN<\/h2>\n\n<p>W sekcji \u201ePeaks\u201d lub \u201eSzczyty aktywno\u015bci bot\u00f3w\u201d w\u0142\u0105czam <code>net.ipv4.tcp_syncookies=1<\/code> jako zabezpieczenie przed atakami typu SYN-flood. Pozwalam <code>tcp_timestamps<\/code> oraz <code>tcp_sack<\/code> zazwyczaj s\u0105 w\u0142\u0105czone, poniewa\u017c pozwalaj\u0105 na precyzyjniejsze sterowanie retransmisj\u0105; ich wy\u0142\u0105czenie rzadko przynosi rzeczywiste korzy\u015bci. <code>tcp_ecn<\/code> Testuj\u0119 to wybi\u00f3rczo: w dobrze kontrolowanych sieciach ECN mo\u017ce skr\u00f3ci\u0107 op\u00f3\u017anienia, ale czasami napotyka na przestarza\u0142e urz\u0105dzenia po\u015brednicz\u0105ce. Moje podej\u015bcie pozostaje takie samo: najpierw pomiary, potem stopniowe wdra\u017canie \u2013 bezpiecze\u0144stwo i wydajno\u015b\u0107 s\u0105 tu \u015bci\u015ble powi\u0105zane.<\/p>\n\n<h2>Precyzyjna regulacja pami\u0119ci podr\u0119cznej: vfs_cache_pressure, dirty_bytes i max_map_count<\/h2>\n\n<p>Serwery WWW czerpi\u0105 znaczne korzy\u015bci z ciep\u0142ych pami\u0119ci podr\u0119cznych Dentry\/inode. Dzi\u0119ki <code>vm.vfs_cache_pressure<\/code> zapobiegam zbyt agresywnemu opr\u00f3\u017cnianiu tych pami\u0119ci podr\u0119cznych przez j\u0105dro (warto\u015b\u0107 pocz\u0105tkowa 50\u2013100). Na komputerach z du\u017c\u0105 ilo\u015bci\u0105 pami\u0119ci RAM preferuj\u0119 <code>vm.dirty_bytes<\/code> oraz <code>vm.dirty_background_bytes<\/code> zamiast warto\u015bci procentowych, aby ustali\u0107 absolutne limity wielko\u015bci operacji Flush; dzi\u0119ki temu mo\u017cna kontrolowa\u0107 szybko\u015b\u0107 zapisu. Wiele proces\u00f3w roboczych i j\u0119zyk\u00f3w dynamicznych przydziela znaczne obszary pami\u0119ci \u2013 w tym miejscu przedstawiam <code>vm.max_map_count<\/code> dostosowuj\u0119 odpowiednio, aby wdro\u017cenia z du\u017c\u0105 liczb\u0105 proces\u00f3w\/w\u0105tk\u00f3w nie ko\u0144czy\u0142y si\u0119 niepowodzeniem z powodu ogranicze\u0144 mapowania. Po wprowadzeniu zmian sprawdzam wska\u017aniki trafie\u0144 w pami\u0119ci podr\u0119cznej stron oraz czas oczekiwania na operacje wej\u015bcia\/wyj\u015bcia, aby optymalizacja pozostawa\u0142a mierzalna.<\/p>\n\n<h2>Metody pomiarowe: odtwarzalne obci\u0105\u017cenie i podej\u015bcie j\u0105drowe<\/h2>\n\n<p>Aby optymalizacja przynios\u0142a efekty, symuluj\u0119 realistyczne profile u\u017cytkownik\u00f3w: ma\u0142e zasoby, d\u0142ugie pobieranie, uzgodnienia TLS, multipleksowanie HTTP\/2. Za pomoc\u0105 narz\u0119dzi do generowania obci\u0105\u017cenia ustalam warto\u015bci docelowe p50\/p95\/p99, jednocze\u015bnie mierz\u0105c obci\u0105\u017cenie j\u0105dra systemu: <code>ss -s<\/code>, <code>ss -tin<\/code>, <code>nstat<\/code>, <code>sar<\/code>, <code>mpstat<\/code> a liczniki interfejsu wskazuj\u0105 mi, gdzie wyst\u0119puje problem. Za pomoc\u0105 <code>tc netem<\/code> Symuluj\u0119 RTT, jitter i utrat\u0119 pakiet\u00f3w, aby realistycznie zweryfikowa\u0107 zestawy bufor\u00f3w. Rejestruj\u0119 ka\u017cd\u0105 zmian\u0119 wraz z sygnatur\u0105 czasow\u0105, wynikami test\u00f3w por\u00f3wnawczych i pomiarami kontrolnymi \u2013 tylko w ten spos\u00f3b mo\u017cna wiarygodnie rozpozna\u0107 korelacje i podj\u0105\u0107 uzasadnione decyzje dotycz\u0105ce przywr\u00f3cenia poprzedniego stanu.<\/p>\n\n<h2>Go\u015bcie i kontenery: zna\u0107 granice, zapewni\u0107 skuteczno\u015b\u0107<\/h2>\n\n<p>W przypadku maszyn wirtualnych zwracam uwag\u0119 na <em>Przej\u0119cie procesora<\/em> oraz warstwa wirtualizacji: idealny profil sysctl niewiele daje, je\u015bli hiperwizor spowalnia dzia\u0142anie systemu. Rozk\u0142adam obci\u0105\u017cenie IRQ i sprawdzam, czy ustawienia RPS\/XPS oraz GRO s\u0105 dostosowane do karty sieciowej i topologii vCPU. W przypadku kontener\u00f3w obowi\u0105zuje zasada: na poziomie poda dzia\u0142aj\u0105 tylko dozwolone (bezpieczne) ustawienia sysctl; dlatego wiele z nich konfiguruj\u0119 na ho\u015bcie. Dostosowuj\u0119 limity j\u0105dra do limit\u00f3w cgroup (limity FD, pami\u0119\u0107), aby aplikacja mog\u0142a faktycznie wykorzysta\u0107 zwi\u0119kszone rezerwy. O efekcie decyduje wsp\u00f3\u0142dzia\u0142anie optymalizacji hosta, zasad orkiestratora i limit\u00f3w us\u0142ug \u2013 a nie pojedyncza warto\u015b\u0107.<\/p>\n\n<h2>Kr\u00f3tkie podsumowanie: Hosting o wy\u017cszej wydajno\u015bci<\/h2>\n\n<p>Z ukierunkowanym <strong>sysctl<\/strong>Dzi\u0119ki optymalizacji zapewniam kr\u00f3tkie czasy odpowiedzi, przewidywalne kolejki i stabilne profile obci\u0105\u017cenia. Backlogi sieciowe, bufory TCP, warto\u015bci keepalive, swappiness oraz limity plik\u00f3w i proces\u00f3w wsp\u00f3\u0142dzia\u0142aj\u0105 ze sob\u0105, dzi\u0119ki czemu us\u0142ugi internetowe nie trac\u0105 rytmu nawet w okresach szczytowego obci\u0105\u017cenia. Nigdy nie zmieniam warto\u015bci na \u015blepo, lecz najpierw mierz\u0119 efekty, zanim ustawi\u0119 je na sta\u0142e. Takie podej\u015bcie pozwala zwi\u0119kszy\u0107 przepustowo\u015b\u0107 i stabilno\u015b\u0107 bez marnowania zasob\u00f3w. W\u0142a\u015bnie to podej\u015bcie sprawia, \u017ce serwery hostingowe s\u0105 w codziennej eksploatacji szybsze, bardziej przewidywalne i dostosowane do rzeczywistych <strong>Ruch uliczny<\/strong>-przygotowano ko\u0144c\u00f3wki.<\/p>","protected":false},"excerpt":{"rendered":"<p>Optymalizacja sysctl dla serwer\u00f3w hostingowych: jak poprawi\u0107 wydajno\u015b\u0107 i stabilno\u015b\u0107 systemu Linux pod obci\u0105\u017ceniem dzi\u0119ki odpowiednim parametrom j\u0105dra.<\/p>","protected":false},"author":1,"featured_media":20333,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20340","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"111","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"sysctl tuning","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20333","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/20340","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/comments?post=20340"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/20340\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/20333"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=20340"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=20340"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=20340"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}