<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Cgroups on Morfitronik</title>
    <link>https://morfikov.github.io/tags/cgroups/</link>
    <description>Recent content in Cgroups on Morfitronik</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>pl-PL</language>
    <lastBuildDate>Tue, 15 Dec 2015 20:40:52 +0000</lastBuildDate><atom:link href="https://morfikov.github.io/tags/cgroups/feed.xml" rel="self" type="application/rss+xml" />
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Kształtowanie ruchu sieciowego (Traffic Control)</title>
      <link>https://morfikov.github.io/post/ksztaltowanie-ruchu-sieciowego-traffic-control/</link>
      <pubDate>Tue, 15 Dec 2015 20:40:52 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/ksztaltowanie-ruchu-sieciowego-traffic-control/</guid>
      <description>&lt;p&gt;Każdy z nas chciałby, aby jego sieć działała możliwie szybko i bezproblemowo. W przypadku, gdy łącze
nie jest zbytnio obciążone, a my jesteśmy jedynym użytkownikiem internetu, to nie doświadczymy
raczej żadnych problemów z połączeniem. Rzecz w tym, że im więcej użytkowników ma nasza sieć, tym
większe prawdopodobieństwo, że zostanie ona przeciążona, tj. będziemy chcieli przesyłać więcej
danych niż sieć jest w stanie obsłużyć. W ten sposób zaczną pojawiać się kolejki pakietów na
interfejsach, których obsługa zajmuje trochę czasu. Rosą zatem opóźnienia, które są bardzo
odczuwalne w momencie, gdy ktoś lubi sobie pograć w różnego rodzaju gry online. Innym problemem może
być sieć P2P, gdzie pojedynczy host z naszej sieci może nawiązywać dziesiątki czy nawet setki
połączeń i tym samym zapychać łącze nie dając szansy innym użytkownikom na komfortowe korzystanie
z internetu. W obu przypadkach może nam pomóc &lt;a href=&#34;http://lartc.org/lartc.html&#34;&gt;kształtowanie ruchu
sieciowego&lt;/a&gt; (Traffic Control), która jest w stanie nadać pakietom
odpowiedni priorytet, tak by część z nich nie musiała czekać zbyt długo w kolejce. W tym wpisie
przyjrzymy się bliżej temu mechanizmowi.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Ograniczanie zasobów procesom przez cgroups</title>
      <link>https://morfikov.github.io/post/ograniczanie-zasobow-procesom-przez-cgroups/</link>
      <pubDate>Tue, 08 Dec 2015 21:21:53 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/ograniczanie-zasobow-procesom-przez-cgroups/</guid>
      <description>&lt;p&gt;Nasze komputery obecnie mają dość pokaźne zasoby obliczeniowe. Jeszcze nie tak dawno temu
wyposażenie maszyny w 32 GiB pamięci RAM, czy też 8 rdzeni było czystą abstrakcją. Wydawałoby się,
że te powyższe parametry zaspokoją każdego. Niemniej jednak, nie ważne jak szybki i rozbudowany
będzie nasz PC, to nam zawsze będzie mało. Mamy dwa rdzenie, to chcemy cztery. Mamy cztery, to
chcemy osiem, itd. Poza tym, szereg aplikacji realizuje co raz więcej zadań i staje się bardziej
wymagająca z każdym mijającym rokiem. Jeśli nie przeprowadzamy modernizacji sprzętu, to może się
okazać, że w niedługim czasie zabraknie nam pamięci albo pewne operacje będą wykonywane bardzo
wolno. W sporej części przypadków nie obędzie się bez wymiany podzespołów ale nawet w przypadku, gdy
mamy spory zapas zasobów systemowych, to poszczególne procesy rywalizują o nie ze sobą. Często bywa
tak, że chcielibyśmy, aby konkretny proces wykonał się szybciej, a to pociąga za sobą, np. zmianę
priorytetów w dostępie do rdzeni procesora. W linux&#39;ie jest mechanizm zwany
&lt;a href=&#34;https://en.wikipedia.org/wiki/Cgroups&#34;&gt;cgroups&lt;/a&gt;, który potrafi ograniczyć zasoby całym aplikacjom
bez względu na to ile ona by miała procesów. W tym wpisie postaramy się przebrnąć przez proces
konfiguracji tego mechanizmu i spróbujemy wyprofilować sobie nasz system.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
