Linux Cgroups (Control Groups) nedir, sistem kaynaklar\u0131n\u0131 nas\u0131l y\u00f6netir ve uygulamalar\u0131n performans\u0131n\u0131 nas\u0131l izole eder? Bu detayl\u0131 rehberde, Cgroups’un temellerini, yap\u0131land\u0131rma ad\u0131mlar\u0131n\u0131 ve ger\u00e7ek d\u00fcnya senaryolar\u0131n\u0131 ke\u015ffedin. Sistem y\u00f6neticileri ve geli\u015ftiriciler i\u00e7in kritik \u00f6neme sahip bu teknoloji, sunucu performans\u0131n\u0131 optimize etmenin anahtar\u0131d\u0131r.<\/p>\n
Modern sunucu ortamlar\u0131nda birden fazla uygulama ve hizmetin ayn\u0131 anda \u00e7al\u0131\u015ft\u0131\u011f\u0131 durumlar olduk\u00e7a yayg\u0131nd\u0131r. Bir web sunucusu, bir veritaban\u0131, bir mesaj kuyru\u011fu sistemi ve belki de baz\u0131 arka plan i\u015fleme servisleri… T\u00fcm bu bile\u015fenler, sistemin s\u0131n\u0131rl\u0131 kaynaklar\u0131 (CPU, bellek, disk G\/\u00c7, a\u011f bant geni\u015fli\u011fi) i\u00e7in s\u00fcrekli bir rekabet halindedir. Peki, bu kaynak \u00e7at\u0131\u015fmalar\u0131 performans\u0131 nas\u0131l etkiler? Diyelim ki bir uygulaman\u0131zda beklenmedik bir bellek s\u0131z\u0131nt\u0131s\u0131 ya\u015fand\u0131 veya bir hesaplama i\u015flemi aniden t\u00fcm CPU \u00e7ekirdeklerini %100 kullanmaya ba\u015flad\u0131. Ne yaz\u0131k ki, bu durumlar di\u011fer kritik servislerin yava\u015flamas\u0131na, yan\u0131t vermemesine ve hatta tamamen \u00e7\u00f6kmesine neden olabilir. \u0130\u015fte tam da bu noktada, kaynak y\u00f6netimini etkin bir \u015fekilde sa\u011flamak hayati \u00f6nem ta\u015f\u0131r. Bu, sadece bir sistemin stabil \u00e7al\u0131\u015fmas\u0131n\u0131 garanti etmekle kalmaz, ayn\u0131 zamanda her bir uygulaman\u0131n kendisine ayr\u0131lan kaynaklarla maksimum verimlilikte \u00e7al\u0131\u015fabilmesini sa\u011flar.<\/p>\n
Linux Cgroups (Control Groups), tam olarak bu t\u00fcr sorunlara \u00e7\u00f6z\u00fcm sunmak i\u00e7in tasarlanm\u0131\u015f g\u00fc\u00e7l\u00fc bir Linux \u00e7ekirde\u011fi \u00f6zelli\u011fidir. Temel olarak Cgroups, bir grup s\u00fcrece belirli sistem kaynaklar\u0131na eri\u015fimlerini k\u0131s\u0131tlama, \u00f6nceliklendirme ve izleme yetene\u011fi sa\u011flar. \u00d6rne\u011fin, bir test sunucusunda yeni bir geli\u015ftirme ortam\u0131 kurdu\u011funuzda, bu ortam\u0131n di\u011fer \u00fcretim servislerini etkilemesini istemezsiniz. Cgroups sayesinde, bu yeni ortama belirli bir CPU s\u00fcresi veya bellek tahsis edebilir, b\u00f6ylece olas\u0131 kaynak k\u0131tl\u0131klar\u0131n\u0131n \u00f6n\u00fcne ge\u00e7ebilirsiniz. Ayr\u0131ca, konteyner teknolojileri olan Docker ve Kubernetes gibi g\u00fcncel yakla\u015f\u0131mlar\u0131n temelinde yatan mekanizmalardan biri de Cgroups’tur. Onlar da uygulamalar\u0131 izole etmek ve kaynaklar\u0131n\u0131 y\u00f6netmek i\u00e7in Cgroups’u yo\u011fun bir \u015fekilde kullan\u0131r. Bu rehberde, Cgroups’un nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131, neden bu kadar \u00f6nemli oldu\u011funu ve ger\u00e7ek d\u00fcnya senaryolar\u0131nda nas\u0131l kullan\u0131labilece\u011fini ad\u0131m ad\u0131m inceleyece\u011fiz. B\u00f6ylece, sistemlerinizdeki kaynak kullan\u0131m\u0131n\u0131 daha bilin\u00e7li ve kontroll\u00fc bir \u015fekilde y\u00f6netebileceksiniz.<\/p>\n
Linux Cgroups, yani Kontrol Gruplar\u0131, Linux \u00e7ekirde\u011finin s\u00fcre\u00e7leri hiyerar\u015fik bir \u015fekilde gruplamam\u0131z\u0131 ve bu gruplar \u00fczerinde kaynak k\u0131s\u0131tlamalar\u0131 ve \u00f6nceliklendirmeleri uygulamam\u0131z\u0131 sa\u011flayan bir \u00f6zelli\u011fidir. \u0130lk olarak Google m\u00fchendisleri taraf\u0131ndan geli\u015ftirilen ve 2.6.24 Linux \u00e7ekirde\u011finden itibaren ana \u00e7ekirde\u011fe dahil edilen Cgroups, sistem y\u00f6neticilerine ve geli\u015ftiricilere s\u00fcre\u00e7lerin CPU, bellek, disk G\/\u00c7 ve a\u011f gibi kaynaklar\u0131 nas\u0131l t\u00fcketti\u011fi \u00fczerinde hassas bir kontrol imkan\u0131 sunar. Temel amac\u0131, bir s\u00fcrecin veya s\u00fcre\u00e7 grubunun sistemdeki di\u011fer s\u00fcre\u00e7leri etkilemeden kendilerine atanan kaynaklar\u0131 kullanmas\u0131n\u0131 sa\u011flamakt\u0131r. Bu, \u00f6zellikle payla\u015f\u0131ml\u0131 sunucu ortamlar\u0131nda veya \u00e7oklu kirac\u0131l\u0131k (multi-tenancy) mimarilerinde sistem stabilizasyonunu ve adil kaynak da\u011f\u0131t\u0131m\u0131n\u0131 garantilemek i\u00e7in hayati bir ara\u00e7t\u0131r.<\/p>\n
Cgroups’un \u00e7al\u0131\u015fma prensibi olduk\u00e7a basittir ancak g\u00fc\u00e7l\u00fc bir yap\u0131ya sahiptir. Her bir kontrol grubu, bir veya daha fazla “altsisteme” (subsystem veya controller) ba\u011flan\u0131r. Altsistemler, belirli bir kaynak t\u00fcr\u00fcn\u00fc (\u00f6rne\u011fin CPU, bellek) kontrol eden \u00e7ekirdek mod\u00fclleridir. Her altsistem, kendi Cgroup hiyerar\u015fisine sahiptir ve bu hiyerar\u015fi, bir dosya sistemi aray\u00fcz\u00fc arac\u0131l\u0131\u011f\u0131yla kullan\u0131c\u0131lara sunulur. Genellikle Peki, bir Cgroup hiyerar\u015fisi nas\u0131l \u00e7al\u0131\u015f\u0131r? En \u00fcstte k\u00f6k Cgroup bulunur. T\u00fcm s\u00fcre\u00e7ler ba\u015flang\u0131\u00e7ta bu k\u00f6k Cgroup’un bir par\u00e7as\u0131d\u0131r. K\u00f6k Cgroup alt\u0131nda yeni alt Cgroups olu\u015fturabilir ve bu alt Cgroups’a s\u00fcre\u00e7ler ekleyebilirsiniz. Bir Cgroup’a uygulanan kurallar, onun t\u00fcm alt Cgroup’lar\u0131n\u0131 ve bu alt Cgroup’lar\u0131n i\u00e7indeki t\u00fcm s\u00fcre\u00e7leri etkiler. Ancak, alt Cgroup’lar kendi \u00f6zel kurallar\u0131n\u0131 tan\u0131mlayarak \u00fcst Cgroup’un kurallar\u0131n\u0131 daha da k\u0131s\u0131tlayabilir. Bu hiyerar\u015fik yap\u0131, karma\u015f\u0131k sistemlerde bile esnek ve ince ayar yap\u0131labilir bir kaynak y\u00f6netimini m\u00fcmk\u00fcn k\u0131lar. \u00d6rne\u011fin, genel bir Cgroup ile t\u00fcm web sunucular\u0131n\u0131za belirli bir bellek limiti koyabilir, ancak bu web sunucular\u0131ndan birine \u00f6zel olarak daha fazla bellek ay\u0131rman\u0131z gerekti\u011finde, onun i\u00e7in ayr\u0131 bir alt Cgroup olu\u015fturup daha y\u00fcksek bir limit belirleyebilirsiniz. Bu sayede, kaynak tahsisinde hem genel politikalar\u0131 uygulayabilir hem de \u00f6zel durumlar i\u00e7in istisnalar yaratabilirsiniz. Cgroups v1 ve Cgroups v2 olmak \u00fczere iki ana versiyon bulunmaktad\u0131r. Cgroups v1, ayr\u0131 hiyerar\u015filer sunarken, Cgroups v2 tek bir birle\u015fik hiyerar\u015fi ile daha tutarl\u0131 ve anla\u015f\u0131l\u0131r bir model sa\u011flar. Modern Linux da\u011f\u0131t\u0131mlar\u0131 ve konteyner orkestrasyon ara\u00e7lar\u0131 genellikle Cgroups v2’yi benimsemeye ba\u015flam\u0131\u015ft\u0131r. \u0130lerleyen b\u00f6l\u00fcmlerde bu altsistemlerin ve kullan\u0131mlar\u0131n\u0131n detaylar\u0131na daha yak\u0131ndan bakaca\u011f\u0131z.<\/p>\n Cgroups’un temel g\u00fcc\u00fc, farkl\u0131 kaynak t\u00fcrleri i\u00e7in \u00f6zelle\u015fmi\u015f altsistemlerden (subsystems veya controllers) gelmektedir. Her altsistem, belirli bir kaynak t\u00fcr\u00fcn\u00fc izlemek ve kontrol etmek i\u00e7in sorumludur. Bu altsistemler sayesinde, CPU kullan\u0131m\u0131ndan belle\u011fe, disk G\/\u00c7’sinden s\u00fcre\u00e7 say\u0131s\u0131na kadar geni\u015f bir yelpazede kaynak y\u00f6netimi yap\u0131labilir. Gelin, en yayg\u0131n ve \u00f6nemli Cgroups altsistemlerini detayl\u0131ca inceleyelim:<\/p>\n Bu altsistemlerin her biri, kaynak y\u00f6netiminde belirli bir ihtiyaca yan\u0131t verir ve bir araya geldiklerinde, bir Linux sistemindeki t\u00fcm kaynaklar \u00fczerinde kapsaml\u0131 bir kontrol sa\u011flamak m\u00fcmk\u00fcn hale gelir. Cgroups’u manuel olarak y\u00f6netirken, hangi altsistemin hangi parametrelerinin sizin i\u00e7in kritik oldu\u011funu anlamak, etkili bir kaynak y\u00f6netimi stratejisi olu\u015fturman\u0131n ilk ad\u0131m\u0131d\u0131r. Unutulmamal\u0131d\u0131r ki Cgroups v2’de baz\u0131 altsistemler birle\u015ftirilmi\u015f veya \u00e7al\u0131\u015fma \u015fekilleri de\u011fi\u015ftirilmi\u015ftir. \u00d6rne\u011fin, Cgroups v2’de her bir kaynak i\u00e7in ayr\u0131 hiyerar\u015filer yerine tek birle\u015fik bir hiyerar\u015fi bulunur ve bu, y\u00f6netimi baz\u0131 a\u00e7\u0131lardan basitle\u015ftirir. Ancak temel prensipler ve kaynak kontrol mekanizmalar\u0131 benzer kal\u0131r.<\/p>\n Cgroups’u teorik olarak anlamak \u00f6nemli olsa da, ger\u00e7ek d\u00fcnyada nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 pratik \u00f6rneklerle g\u00f6rmek \u00e7ok daha \u00f6\u011freticidir. Bu b\u00f6l\u00fcmde, iki farkl\u0131 senaryo \u00fczerinden Cgroups’u ad\u0131m ad\u0131m nas\u0131l yap\u0131land\u0131raca\u011f\u0131m\u0131z\u0131 ve bir uygulaman\u0131n kaynak t\u00fcketimini nas\u0131l k\u0131s\u0131tlayaca\u011f\u0131m\u0131z\u0131 inceleyece\u011fiz. Bu \u00f6rnekler, okuyucunun konuya hakimiyetini art\u0131r\u0131rken, potansiyel sorunlara kar\u015f\u0131 somut \u00e7\u00f6z\u00fcmler sunacakt\u0131r.<\/p>\n Bir uygulaman\u0131z\u0131n beklenenden \u00e7ok daha fazla bellek t\u00fcketti\u011fini ve bu durumun sunucunuzdaki di\u011fer servisleri olumsuz etkiledi\u011fini varsayal\u0131m. Bu, genellikle hatal\u0131 yaz\u0131lm\u0131\u015f bir koddan veya bir bellek s\u0131z\u0131nt\u0131s\u0131ndan kaynaklanabilir. Cgroups kullanarak bu uygulamay\u0131 belirli bir bellek limitiyle s\u0131n\u0131rlayabiliriz. Bu vaka analizinde, ‘stress’ arac\u0131n\u0131 (veya basit bir Python beti\u011fini) kullanarak bir bellek t\u00fcketim senaryosu olu\u015fturup Cgroups ile nas\u0131l y\u00f6netece\u011fimizi g\u00f6rece\u011fiz.<\/p>\n \u00d6ncelikle, Cgroups y\u00f6netim ara\u00e7lar\u0131n\u0131n (cgroup-tools) kurulu oldu\u011fundan emin olun. Ubuntu\/Debian tabanl\u0131 sistemlerde:<\/p>\n <\/code><\/p>\n \u015eimdi, bellek i\u00e7in yeni bir Cgroup olu\u015ftural\u0131m. Ad\u0131 \"bellek_limiti_grubu\" olsun:<\/p>\n <\/code><\/p>\n Bu komut, <\/code><\/p>\n Bu limit, grup i\u00e7indeki t\u00fcm s\u00fcre\u00e7lerin toplamda 100 MB'tan fazla bellek kullanamayaca\u011f\u0131 anlam\u0131na gelir. \u015eimdi, bu grubun i\u00e7ine bellek t\u00fcketen bir uygulama ( <\/code><\/p>\n Uygulamay\u0131 \u00e7al\u0131\u015ft\u0131rd\u0131ktan sonra, k\u0131sa bir s\u00fcre sonra uygulama ya sonland\u0131r\u0131lacak ya da bellek tahsisinde ba\u015far\u0131s\u0131z olacakt\u0131r. OOM Killer'\u0131n devriye gezdi\u011fini ve s\u00fcreci bellek limiti nedeniyle sonland\u0131rd\u0131\u011f\u0131n\u0131 sistem g\u00fcnl\u00fcklerinde ( <\/code><\/p>\n Bu komut, Cgroup'un kulland\u0131\u011f\u0131 bellek miktar\u0131n\u0131 bayt cinsinden g\u00f6sterecektir. Limitinize yak\u0131n bir de\u011fer g\u00f6rmelisiniz, \u00e7\u00fcnk\u00fc s\u00fcre\u00e7 bu limiti a\u015fmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131nda durdurulmu\u015ftur. \u0130\u015flem bittikten sonra, Cgroup'u temizlemeyi unutmay\u0131n:<\/p>\n <\/code><\/p>\n Bir di\u011fer yayg\u0131n senaryo, tek bir uygulaman\u0131n t\u00fcm CPU kaynaklar\u0131n\u0131 t\u00fcketerek di\u011fer servislerin yava\u015flamas\u0131na neden olmas\u0131d\u0131r. Bu durum, \u00f6zellikle \u00e7oklu \u00e7ekirdekli sistemlerde, bir uygulaman\u0131n gereksiz yere birden fazla \u00e7ekirde\u011fi me\u015fgul etmesiyle ortaya \u00e7\u0131kabilir. Cgroups ile bir uygulaman\u0131n kullanabilece\u011fi CPU miktar\u0131n\u0131 belirli bir y\u00fczdeyle s\u0131n\u0131rlayabiliriz.<\/p>\n \u015eimdi CPU i\u00e7in yeni bir Cgroup olu\u015ftural\u0131m. Ad\u0131 \"cpu_limiti_grubu\" olsun:<\/p>\n <\/code><\/p>\n Bu gruba CPU limiti atayal\u0131m. \u00d6rne\u011fin, CPU'nun %50'sini kullanmas\u0131na izin verelim. Bunun i\u00e7in <\/code><\/p>\n \u015eimdi bu grubun i\u00e7ine yo\u011fun CPU kullanan bir uygulama ( <\/code><\/p>\n Bu komutu \u00e7al\u0131\u015ft\u0131rd\u0131ktan sonra, ba\u015fka bir terminalde <\/code><\/p>\n Bu dosya, Cgroup'un CPU kullan\u0131m istatistiklerini g\u00f6sterir. <\/code><\/p>\n Bu vaka analizleri, Cgroups'un g\u00fcc\u00fcn\u00fc ve esnekli\u011fini g\u00f6stermektedir. Bellek veya CPU gibi kritik kaynaklar\u0131 y\u00f6netmek, sunucu stabilitesini ve uygulama performans\u0131n\u0131 do\u011frudan etkiler. Bu temel ad\u0131mlar\u0131 uygulayarak, sisteminizdeki kaynak tahsisini \u00e7ok daha etkin bir \u015fekilde kontrol edebilirsiniz.<\/p>\n Uzman \u0130pucu: Cgroups ile sadece limitler belirlemekle kalmaz, ayn\u0131 zamanda Cgroups, yaln\u0131zca manuel olarak s\u00fcre\u00e7leri izole etmek i\u00e7in de\u011fil, ayn\u0131 zamanda modern sanalla\u015ft\u0131rma ve konteyner teknolojilerinin de temel ta\u015flar\u0131ndan biridir. \u00d6zellikle Docker ve Kubernetes gibi platformlar, uygulamalar\u0131n kaynaklar\u0131n\u0131 izole etmek ve y\u00f6netmek i\u00e7in Cgroups'u yo\u011fun bir \u015fekilde kullan\u0131r. Bu durum, \u00e7oklu kirac\u0131l\u0131k (multi-tenancy) ortamlar\u0131nda veya karma\u015f\u0131k mikroservis mimarilerinde sistem stabilitesi ve performans\u0131 i\u00e7in vazge\u00e7ilmezdir.<\/p>\n Docker, bir uygulaman\u0131n t\u00fcm ba\u011f\u0131ml\u0131l\u0131klar\u0131yla birlikte hafif, ta\u015f\u0131nabilir bir konteyner i\u00e7inde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flayan pop\u00fcler bir konteynerizasyon platformudur. Docker'\u0131n sundu\u011fu izolasyon yetenekleri (dosya sistemi, a\u011f ve s\u00fcre\u00e7 izolasyonu) genellikle Linux Namespaces taraf\u0131ndan sa\u011flan\u0131rken, kaynak k\u0131s\u0131tlama ve y\u00f6netim yetenekleri Cgroups taraf\u0131ndan sa\u011flan\u0131r. \u00d6rne\u011fin, bir Docker konteyneri olu\u015ftururken <\/code><\/p>\n Yukar\u0131daki komutta:<\/p>\n Bu sayede, bir Nginx konteyneri sistemdeki di\u011fer konteynerler veya host s\u00fcre\u00e7leri \u00fczerinde a\u015f\u0131r\u0131 y\u00fck olu\u015fturmadan, kendisine ayr\u0131lan kaynaklarla \u00e7al\u0131\u015fmaya devam eder. Bu, \u00f6zellikle ayn\u0131 sunucuda birden fazla farkl\u0131 uygulaman\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 durumlarda kritik \u00f6neme sahiptir.<\/p>\n Kubernetes, konteynerle\u015ftirilmi\u015f i\u015f y\u00fcklerini ve hizmetleri y\u00f6netmek i\u00e7in tasarlanm\u0131\u015f a\u00e7\u0131k kaynakl\u0131 bir platformdur. Kubernetes'te, uygulamalar \"Pod\" ad\u0131 verilen mant\u0131ksal birimler i\u00e7inde \u00e7al\u0131\u015f\u0131r. Her Pod, bir veya daha fazla konteyner i\u00e7erir ve Kubernetes, bu Pod'lar\u0131n kaynaklar\u0131n\u0131 y\u00f6netmek i\u00e7in altta yatan Cgroups mekanizmas\u0131n\u0131 kullan\u0131r. Kubernetes'te kaynak y\u00f6netimi, Pod tan\u0131m\u0131nda <\/code><\/p>\n Bu YAML tan\u0131m\u0131nda:<\/p>\n Kubernetes, Pod'lar\u0131 her bir d\u00fc\u011f\u00fcmdeki (node) Cgroups hiyerar\u015fisine yerle\u015ftirerek, kaynaklar\u0131 adil bir \u015fekilde da\u011f\u0131t\u0131r ve bir Pod'un di\u011ferlerini \"bo\u011fmas\u0131n\u0131\" engeller. Bu, b\u00fcy\u00fck \u00f6l\u00e7ekli ve dinamik bulut ortamlar\u0131nda stabiliteyi ve \u00f6ng\u00f6r\u00fclebilir performans\u0131 sa\u011flamak i\u00e7in kritik bir \u00f6zelliktir. \u00d6rne\u011fin, bir sunucu yo\u011fun y\u00fcke maruz kald\u0131\u011f\u0131nda, Cgroups sayesinde d\u00fc\u015f\u00fck \u00f6ncelikli Pod'lar\u0131n kaynak kullan\u0131m\u0131 k\u0131s\u0131tlan\u0131rken, kritik Pod'lar\u0131n \u00e7al\u0131\u015fmaya devam etmesi sa\u011flanabilir.<\/p>\n Bu ger\u00e7ek d\u00fcnya senaryolar\u0131, Cgroups'un modern bulut bili\u015fim ve DevOps d\u00fcnyas\u0131ndaki vazge\u00e7ilmez rol\u00fcn\u00fc a\u00e7\u0131k\u00e7a g\u00f6stermektedir. Konteynerizasyonun ve mikroservis mimarilerinin yayg\u0131nla\u015fmas\u0131yla birlikte, Cgroups bilgisi, sistem performans\u0131n\u0131 optimize etmek ve stabiliteyi sa\u011flamak isteyen her profesyonel i\u00e7in temel bir beceri haline gelmi\u015ftir.<\/p>\n\/sys\/fs\/cgroup<\/code> alt\u0131nda konumlanan bu sanal dosya sistemi, dizinler ve dosyalar arac\u0131l\u0131\u011f\u0131yla Cgroups’u y\u00f6netmemizi sa\u011flar. Bir dizin bir Cgroup’u temsil ederken, dizinin i\u00e7indeki dosyalar o Cgroup’a ait parametreleri (limitler, \u00f6ncelikler vb.) yap\u0131land\u0131rmak i\u00e7in kullan\u0131l\u0131r. \u00d6rne\u011fin, bir Cgroup olu\u015fturdu\u011funuzda, asl\u0131nda bu sanal dosya sisteminde yeni bir dizin olu\u015fturmu\u015f olursunuz. S\u00fcre\u00e7leri bu Cgroup’a atad\u0131\u011f\u0131n\u0131zda ise, \u00e7ekirdek bu s\u00fcre\u00e7lerin kaynak kullan\u0131m\u0131n\u0131 o Cgroup’a tan\u0131mlad\u0131\u011f\u0131n\u0131z kurallara g\u00f6re y\u00f6netmeye ba\u015flar.<\/p>\nCgroups Altsistemleri Nelerdir ve Ne \u0130\u015fe Yarar?<\/h3>\n
\n
\n
cpu.shares<\/code>: Bir Cgroup’a atanan CPU zaman\u0131n\u0131n oran\u0131n\u0131 belirtir. \u00d6rne\u011fin, bir grupta 1024 shares, di\u011ferinde 512 shares varsa, ilk grup CPU’nun iki kat\u0131 kadar\u0131n\u0131 almaya e\u011filimli olacakt\u0131r. Ancak bu bir garanti de\u011fildir; sistem yo\u011fun de\u011filse her iki grup da ihtiya\u00e7 duydu\u011fu t\u00fcm CPU’yu kullanabilir.<\/li>\ncpu.cfs_period_us<\/code> ve cpu.cfs_quota_us<\/code>: Bu parametreler, Cgroup’un belirli bir s\u00fcre (period) i\u00e7inde kullanabilece\u011fi CPU s\u00fcresi (quota) miktar\u0131n\u0131 mikro saniye (us) cinsinden ayarlar. \u00d6rne\u011fin, cpu.cfs_period_us=100000<\/code> (100ms) ve cpu.cfs_quota_us=50000<\/code> (50ms) ayarlar\u0131, Cgroup’taki s\u00fcre\u00e7lerin her 100ms’lik dilimde en fazla 50ms CPU kullanabilece\u011fi anlam\u0131na gelir ki bu da CPU’nun %50’si demektir. Bu, belirli bir y\u00fczde CPU kullan\u0131m\u0131 garanti etmek i\u00e7in kullan\u0131l\u0131r.<\/li>\n<\/ul>\n<\/li>\n\n
memory.limit_in_bytes<\/code>: Bir Cgroup’un kullanabilece\u011fi maksimum bellek miktar\u0131n\u0131 bayt cinsinden belirtir. Bu s\u0131n\u0131ra ula\u015f\u0131ld\u0131\u011f\u0131nda, sistem OOM (Out Of Memory) Killer’\u0131 \u00e7a\u011f\u0131rarak Cgroup i\u00e7indeki s\u00fcre\u00e7leri sonland\u0131rabilir.<\/li>\nmemory.swappiness<\/code>: Cgroup i\u00e7indeki s\u00fcre\u00e7lerin ne kadar s\u0131kl\u0131kla diske (swap alan\u0131na) veri yazaca\u011f\u0131n\u0131 kontrol eder. Daha y\u00fcksek de\u011ferler, daha fazla swap kullan\u0131m\u0131na yol a\u00e7ar.<\/li>\nmemory.usage_in_bytes<\/code>: Bir Cgroup taraf\u0131ndan kullan\u0131lan mevcut bellek miktar\u0131n\u0131 g\u00f6sterir.<\/li>\n<\/ul>\n<\/li>\n\n
blkio.weight<\/code>: Bir Cgroup’un disk G\/\u00c7 \u00f6nceli\u011fini belirler. Daha y\u00fcksek bir a\u011f\u0131rl\u0131k, daha fazla G\/\u00c7 kapasitesi demektir.<\/li>\nblkio.throttle.read_bps_device<\/code> ve blkio.throttle.write_bps_device<\/code>: Belirli bir cihaz (\u00f6rne\u011fin \/dev\/sda<\/code>) i\u00e7in saniyede okunan\/yaz\u0131lan maksimum bayt miktar\u0131n\u0131 belirterek daha hassas bir k\u0131s\u0131tlama sa\u011flar.<\/li>\n<\/ul>\n<\/li>\n\n
pids.max<\/code>: Cgroup i\u00e7inde izin verilen maksimum PID (s\u00fcre\u00e7 ID) say\u0131s\u0131n\u0131 belirler. Bu s\u0131n\u0131ra ula\u015f\u0131ld\u0131\u011f\u0131nda, yeni s\u00fcre\u00e7 olu\u015fturma giri\u015fimleri ba\u015far\u0131s\u0131z olur.<\/li>\n<\/ul>\n<\/li>\ntc<\/code>) arac\u0131yla entegre olarak \u00e7al\u0131\u015f\u0131r ve belirli Cgroups’tan gelen a\u011f paketlerini i\u015faretleyerek tc<\/code>‘nin bu paketlere \u00f6zel kurallar uygulamas\u0131n\u0131 m\u00fcmk\u00fcn k\u0131lar.\n\n
net_cls.classid<\/code>: Cgroup’taki paketlere atanacak benzersiz bir s\u0131n\u0131f ID’si belirler. tc<\/code> bu ID’yi kullanarak paketleri farkl\u0131 kurallara g\u00f6re i\u015fleyebilir (\u00f6rne\u011fin, bant geni\u015fli\u011fi k\u0131s\u0131tlamas\u0131).<\/li>\nnet_prio.prioidx<\/code>: Cgroup’taki s\u00fcre\u00e7lerden gelen a\u011f trafi\u011fine belirli bir \u00f6ncelik atar.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nAd\u0131m Ad\u0131m Cgroups Yap\u0131land\u0131rmas\u0131: Bir Uygulamay\u0131 Kaynak K\u0131s\u0131tlamas\u0131na Nas\u0131l Sokars\u0131n\u0131z?<\/h2>\n
Vaka Analizi 1: Bellek Canavar\u0131 Bir Uygulamay\u0131 S\u0131n\u0131rlama<\/h3>\n
\nsudo apt update\nsudo apt install cgroup-tools stress\n<\/pre>\n\nsudo cgcreate -g memory:bellek_limiti_grubu\n<\/pre>\n\/sys\/fs\/cgroup\/memory\/bellek_limiti_grubu<\/code> dizinini ve ilgili kontrol dosyalar\u0131n\u0131 olu\u015fturacakt\u0131r. Ard\u0131ndan, bu gruba bir bellek limiti atayal\u0131m. \u00d6rne\u011fin, 100 megabayt (MB) limit verelim:<\/p>\n\nsudo cgset -r memory.limit_in_bytes=100M bellek_limiti_grubu\n<\/pre>\nstress<\/code>) ba\u015flatal\u0131m ve 200 MB bellek ay\u0131rmaya \u00e7al\u0131\u015fmas\u0131n\u0131 isteyelim (ki bu limitimizin iki kat\u0131d\u0131r):<\/p>\n\nsudo cgexec -g memory:bellek_limiti_grubu stress --vm 1 --vm-bytes 200M --vm-hang 0 --timeout 60s\n<\/pre>\ndmesg<\/code>) g\u00f6rebilirsiniz. Grubun mevcut bellek kullan\u0131m\u0131n\u0131 kontrol etmek i\u00e7in:<\/p>\n\ncat \/sys\/fs\/cgroup\/memory\/bellek_limiti_grubu\/memory.usage_in_bytes\n<\/pre>\n\nsudo cgdelete memory:bellek_limiti_grubu\n<\/pre>\nVaka Analizi 2: CPU Yo\u011fun Bir \u0130\u015flemi Kontrol Alt\u0131na Alma<\/h3>\n
\nsudo cgcreate -g cpu:cpu_limiti_grubu\n<\/pre>\ncpu.cfs_period_us<\/code> ve cpu.cfs_quota_us<\/code> parametrelerini kullanaca\u011f\u0131z. cfs_period_us<\/code> genellikle 100ms (100000 mikro saniye) olarak ayarlan\u0131r. %50 CPU i\u00e7in, cfs_quota_us<\/code> de\u011feri 50ms (50000 mikro saniye) olmal\u0131d\u0131r:<\/p>\n\nsudo cgset -r cpu.cfs_period_us=100000 -r cpu.cfs_quota_us=50000 cpu_limiti_grubu\n<\/pre>\nstress<\/code>) ba\u015flatal\u0131m. stress -c 1<\/code> komutu, tek bir CPU \u00e7ekirde\u011fini %100 kullanmaya \u00e7al\u0131\u015f\u0131r:<\/p>\n\nsudo cgexec -g cpu:cpu_limiti_grubu stress -c 1 --timeout 60s\n<\/pre>\ntop<\/code> veya htop<\/code> gibi bir izleme arac\u0131 a\u00e7\u0131n. stress<\/code> s\u00fcrecinin CPU kullan\u0131m\u0131n\u0131 g\u00f6zlemleyin. Beklentiniz, tek bir \u00e7ekirde\u011fi %100 yerine, \u00e7ekirde\u011fin sadece %50'sini (veya toplam sistem CPU'sunun %50'sini) kullan\u0131yor olmas\u0131d\u0131r. Bu, Cgroup'un CPU kaynaklar\u0131n\u0131 ba\u015far\u0131yla k\u0131s\u0131tlad\u0131\u011f\u0131n\u0131 g\u00f6sterir. Uygulaman\u0131n CPU kullan\u0131m\u0131na yak\u0131ndan bakmak i\u00e7in:<\/p>\n\ncat \/sys\/fs\/cgroup\/cpu\/cpu_limiti_grubu\/cpu.stat\n<\/pre>\nusage_usec<\/code> parametresi toplam CPU kullan\u0131m\u0131n\u0131 mikro saniye cinsinden belirtir. \u0130\u015flem bittikten sonra, yine Cgroup'u temizlemeyi unutmay\u0131n:<\/p>\n\nsudo cgdelete cpu:cpu_limiti_grubu\n<\/pre>\ncpu.shares<\/code> gibi parametrelerle kaynaklara \u00f6ncelik de atayabilirsiniz. D\u00fc\u015f\u00fck \u00f6ncelikli arka plan g\u00f6revlerinin, y\u00fcksek \u00f6ncelikli \u00f6n u\u00e7 uygulamalar\u0131n\u0131 etkilemesini engellemek i\u00e7in bu \u00f6zelli\u011fi kullan\u0131n.<\/p>\nGer\u00e7ek D\u00fcnya Senaryolar\u0131: Docker ve Kubernetes'te Cgroups Kullan\u0131m\u0131 Neden Kritik?<\/h2>\n
Docker ve Cgroups: Konteyner \u0130zolasyonunun Arkas\u0131ndaki G\u00fc\u00e7<\/h3>\n
--memory<\/code> veya --cpu<\/code> gibi parametreler kullanarak kaynak limitleri belirleyebilirsiniz. Docker motoru, arka planda bu limitleri Cgroups altsistemlerine kar\u015f\u0131l\u0131k gelen dosyalar \u00fczerinden ayarlar.<\/p>\n\ndocker run --name benim-web-uygulamam --memory=\"512m\" --cpus=\"0.5\" nginx\n<\/pre>\n\n
--memory=\"512m\"<\/code>: Docker, bu konteyner i\u00e7in 512 megabayt bellek limiti atamak \u00fczere Cgroups'un memory.limit_in_bytes<\/code> parametresini kullan\u0131r. Konteyner bu s\u0131n\u0131r\u0131 a\u015ft\u0131\u011f\u0131nda, OOM Killer devreye girebilir.<\/li>\n--cpus=\"0.5\"<\/code>: Docker, bu konteynerin CPU kaynaklar\u0131n\u0131n yar\u0131s\u0131n\u0131 (bir \u00e7ekirde\u011fin %50'si) kullanabilece\u011fini belirtir. Bu, Cgroups'un cpu.cfs_quota_us<\/code> ve cpu.cfs_period_us<\/code> parametrelerine \u00e7evrilir.<\/li>\n<\/ul>\nKubernetes ve Cgroups: Pod Kaynak Y\u00f6netimi<\/h3>\n
requests<\/code> (istenen kaynaklar) ve limits<\/code> (maksimum kaynaklar) belirterek yap\u0131l\u0131r:<\/p>\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: benim-uygulamam\nspec:\n containers:\n - name: webserver\n image: nginx\n resources:\n requests:\n memory: \"64Mi\"\n cpu: \"250m\" # 0.25 CPU\n limits:\n memory: \"128Mi\"\n cpu: \"500m\" # 0.5 CPU\n<\/pre>\n\n
requests<\/code>: Kubernetes zamanlay\u0131c\u0131s\u0131, Pod'u yeterli kayna\u011fa sahip bir d\u00fc\u011f\u00fcme (node) yerle\u015ftirmeye \u00e7al\u0131\u015f\u0131r. Bu de\u011ferler, Pod'un minimum ihtiya\u00e7lar\u0131n\u0131 belirtir.<\/li>\nlimits<\/code>: Bu de\u011ferler, Pod'un a\u015fmas\u0131na izin verilmeyen maksimum kaynaklar\u0131 tan\u0131mlar. Kubernetes, bu limitleri Cgroups'a \u00e7evirir. E\u011fer bir konteyner bellek limitini a\u015farsa, Kubernetes onu sonland\u0131rabilir. CPU limiti a\u015f\u0131ld\u0131\u011f\u0131nda ise, konteynerin CPU kullan\u0131m\u0131 k\u0131s\u0131tlan\u0131r ancak genellikle sonland\u0131r\u0131lmaz.<\/li>\n<\/ul>\n