{"id":1935,"date":"2025-11-16T20:22:48","date_gmt":"2025-11-16T17:22:48","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/ofiste-bir-aksam-disk-isiginin-ritmi-ve-zfs-ile-barisma\/"},"modified":"2025-11-16T20:22:48","modified_gmt":"2025-11-16T17:22:48","slug":"ofiste-bir-aksam-disk-isiginin-ritmi-ve-zfs-ile-barisma","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/ofiste-bir-aksam-disk-isiginin-ritmi-ve-zfs-ile-barisma\/","title":{"rendered":"Ofiste Bir Ak\u015fam: Disk I\u015f\u0131\u011f\u0131n\u0131n Ritmi ve ZFS ile Bar\u0131\u015fma"},"content":{"rendered":"

{
\n “title”: “ZFS ile Linux Sunucularda Performans ve Dayan\u0131kl\u0131l\u0131k: ARC, ZIL, SLOG, Snapshot ve send\/receive Nas\u0131l Tatl\u0131 Tatl\u0131 Ayarlan\u0131r?”,
\n “content”: “n<\/p>\n

Hi\u00e7, gece ge\u00e7 saatte ofiste tek ba\u015f\u0131na kal\u0131p disk \u0131\u015f\u0131klar\u0131n\u0131n ritmini dinlediniz mi? Ben kald\u0131m. O g\u00fcn bir VM bir t\u00fcrl\u00fc aya\u011fa kalkm\u0131yor, I\/O gecikmeleri dalgalan\u0131yor, grafikte dikenler \u00e7\u0131k\u0131yor, CPU bo\u015fta ama kullan\u0131c\u0131lar homurdan\u0131yordu. Bende \u015fu his uyand\u0131: \u201cBu i\u015f diskte bitiyor, ZFS\u2019i biraz daha yak\u0131ndan dinlemeliyim.\u201d ZFS\u2019in b\u00fcy\u00fcs\u00fc o ak\u015fam a\u00e7\u0131ld\u0131 diyebilirim. ARC\u2019nin belle\u011fi nas\u0131l sevdi\u011fini, ZIL\u2019in senkron yaz\u0131lardaki gizli rol\u00fcn\u00fc, SLOG\u2019un do\u011fru donan\u0131mla nas\u0131l fark yaratt\u0131\u011f\u0131n\u0131 ad\u0131m ad\u0131m g\u00f6rd\u00fcm.<\/p>\n

n<\/p>\n

\u015e\u00f6yle d\u00fc\u015f\u00fcn\u00fcn: Sunucunuz k\u00fc\u00e7\u00fck bir \u015fehir, veri ise o \u015fehrin trafi\u011fi. ARC geni\u015f bir \u00e7evre yolu, ZIL \u0131\u015f\u0131klar\u0131n senkronizasyonu, SLOG ise kav\u015faktaki ak\u0131ll\u0131 sistem. Yanl\u0131\u015f ayarlarla trafik s\u0131k\u0131\u015f\u0131r; do\u011fru ayarlarla ak\u0131\u015f p\u00fcr\u00fczs\u00fczle\u015fir. Bu yaz\u0131da hik\u00e2yenin i\u00e7inden gidip ZFS\u2019i sahada nas\u0131l ayarlad\u0131\u011f\u0131m\u0131, hangi ayar\u0131n hangi durumda nefes ald\u0131rd\u0131\u011f\u0131n\u0131, snapshot ve send\/receive ile yedekleri nas\u0131l g\u00fcvenle d\u0131\u015far\u0131 ta\u015f\u0131d\u0131\u011f\u0131m\u0131 anlataca\u011f\u0131m. Baz\u0131 yerlerde \u201cmesela \u015f\u00f6yle\u201d diye durup sade \u00f6rnekler verece\u011fim. Kendi deneyimimden, hatalar\u0131mdan ve \u201cah ke\u015fke\u201d dedirten anlardan s\u00f6z edece\u011fim.<\/p>\n

n<\/p>\n

Hedef basit: Linux \u00fczerinde ZFS ile hem performans\u0131 toparlamak hem de dayan\u0131kl\u0131l\u0131\u011f\u0131 art\u0131rmak. ARC\/ZIL\/SLOG ayarlar\u0131yla ba\u015fl\u0131yoruz, ard\u0131ndan dataset ufak dokunu\u015flar\u0131, en sonda snapshot ve send\/receive ile yedeklerin ak\u0131\u015f\u0131n\u0131 kuruyoruz. Yol boyunca k\u0131sa notlar, k\u00fc\u00e7\u00fck t\u00fcyolar, gereksiz risklerden ka\u00e7\u0131nma taktikleri\u2026 Hadi ba\u015flayal\u0131m.<\/p>\n

nn<\/p>\n

ZFS\u2019i Kafada Oturtmak: ARC, ZIL ve SLOG Ne \u0130\u015fe Yarar?<\/h2>\n

n<\/p>\n

ZFS\u2019i sevdim \u00e7\u00fcnk\u00fc d\u00fc\u015f\u00fcnce bi\u00e7imi net. \u00d6nce belle\u011fi iyi kullan\u0131yor. ARC dedi\u011fimiz \u00f6nbellek RAM\u2019de ya\u015far ve s\u0131k okunan veriyi elde tutar. Mesela bir web sunucunuz var, s\u00fcrekli ayn\u0131 statik dosyalar isteniyor. ARC bu dosyalar\u0131 RAM\u2019de s\u0131cak tutarak diske inmeyi azalt\u0131r. En bariz hissi: Okuma gecikmeleri d\u00fc\u015fer ve sistem daha esnek hale gelir. \u201cDaha \u00e7ok RAM, daha mutlu ARC\u201d gibi d\u00fc\u015f\u00fcnebilirsiniz ama fazlas\u0131 her zaman iyi de\u011fildir; birazdan nedenini konu\u015faca\u011f\u0131z.<\/p>\n

n<\/p>\n

Sonra ZIL var: ZFS Intent Log. Senkron yaz\u0131lar\u0131n g\u00fcvenli\u011fini sa\u011flar. D\u00fc\u015f\u00fcn\u00fcn, veritaban\u0131 bir yaz\u0131y\u0131 \u201ctamamland\u0131\u201d demeden \u00f6nce disk \u00fczerinde garantilemek ister. ZIL bu noktada devreye girer. Peki SLOG nedir? ZIL\u2019i h\u0131zland\u0131rmak i\u00e7in ay\u0131rd\u0131\u011f\u0131n\u0131z \u00f6zel bir cihaz. Asl\u0131nda ZIL her zaman vard\u0131r; SLOG ise onu ayr\u0131 ve h\u0131zl\u0131 bir yere almak demek. E\u011fer senkron yaz\u0131lar yo\u011fun de\u011filse SLOG takmak \u015fart de\u011fil. Ama NFS sunucusu, veritaban\u0131 veya VM diskleri gibi \u201cfsync\u201d seven i\u015f y\u00fcklerinde SLOG, geceyle g\u00fcnd\u00fcz aras\u0131ndaki fark\u0131 yarat\u0131r. K\u00fc\u00e7\u00fck bir uyar\u0131: SLOG i\u00e7in se\u00e7ti\u011finiz SSD\u2019nin elektrik kesintisinde veri korumas\u0131 olmal\u0131, yani g\u00fc\u00e7 kayb\u0131 korumal\u0131 bir model. Yoksa h\u0131zlanay\u0131m derken risk al\u0131rs\u0131n\u0131z.<\/p>\n

n<\/p>\n

Bu \u00fc\u00e7l\u00fcy\u00fc ak\u0131lda \u015f\u00f6yle canland\u0131r\u0131n: ARC okuma h\u0131z\u0131n\u0131 y\u00fckseltir; ZIL g\u00fcvenli\u011fi sa\u011flar, SLOG ise ZIL\u2019i h\u0131zland\u0131r\u0131r. Hepsi ayn\u0131 anda sahnede de\u011fildir; i\u015f y\u00fck\u00fcn\u00fcz hangisine ihtiya\u00e7 duyuyorsa onu \u00f6ne \u00e7eker. Bir gecelik performans d\u00fc\u011f\u00fcn\u00fcnde DJ\u2019yi do\u011fru se\u00e7mek gibi.<\/p>\n

nn<\/p>\n

ARC Tuning: RAM\u2019i Sevdiren Ayarlar, Abartmadan<\/h2>\n

n<\/p>\n

Bir keresinde sunucuda hem veritaban\u0131 hem de \u00e7ok say\u0131da PHP-FPM s\u00fcreci vard\u0131. RAM boldu ama hepsini ARC\u2019ye b\u0131rak\u0131nca di\u011fer s\u00fcre\u00e7ler nefes alamad\u0131. Ders basit: ARC g\u00fc\u00e7l\u00fcd\u00fcr, evet, ama evde tek o ya\u015famaz. ZFS\u2019in Linux taraf\u0131nda zfs_arc_max<\/strong> ile ARC\u2019nin tavan\u0131n\u0131, zfs_arc_min<\/strong> ile taban\u0131n\u0131 ayarlayabilirsiniz. Amac\u0131n\u0131z, i\u015f y\u00fck\u00fcn\u00fcz\u00fcn geri kalan\u0131yla kavga etmeyen bir denge kurmak. Mesela toplam RAM\u2019in makul bir b\u00f6l\u00fcm\u00fcn\u00fc ARC\u2019ye ay\u0131r\u0131p di\u011fer servisler i\u00e7in alan b\u0131rakmak \u00e7o\u011fu zaman do\u011fru ad\u0131m olur.<\/p>\n

n<\/p>\n

Ayarlama i\u015fi genellikle mod\u00fcl parametreleriyle yap\u0131l\u0131r. Kal\u0131c\u0131 bir d\u00fczenleme i\u00e7in \u015funa benzer bir dosya olu\u015fturabilirsiniz:<\/p>\n

n<\/p>\n

# \/etc\/modprobe.d\/zfs.confnoptions zfs zfs_arc_max=8589934592noptions zfs zfs_arc_min=2147483648n<\/code><\/pre>\n
n<\/p>\n
Buradaki de\u011ferler bayt cinsinden. Sistem yeniden y\u00fcklendi\u011finde devreye girer. Ge\u00e7ici testler i\u00e7in sysfs \u00fczerinden denemek m\u00fcmk\u00fcn, ama kal\u0131c\u0131 d\u00fczen iyidir. Ayar\u0131 yap\u0131nca \u201coh tamam\u201d demeyin; g\u00f6zlemleyin. zpool iostat<\/em>, arcstat<\/em> ve sistem genel bellek kullan\u0131m\u0131n\u0131 takip edin. ARC\u2019nin \u00e7ok b\u00fcy\u00fcy\u00fcp sistemin swap\u2019e d\u00fc\u015fmesine izin vermeyin. Bir iki g\u00fcn ak\u0131\u015fa bak\u0131n, sonra ufak dokunu\u015flarla ayar\u0131 yerine oturtun.<\/p>\n
n<\/p>\n
ARC\u2019ye e\u015flik eden ba\u015fka ince ayarlar da var. primarycache<\/strong> ve secondarycache<\/strong> mesela. Bir VM imajlar\u0131n\u0131 dosya olarak tuttu\u011funuz dataset\u2019te primarycache=metadata<\/strong> se\u00e7erek RAM\u2019i biraz ferahlatabilirsiniz. Okumalar\u0131n \u00e7o\u011fu rastgele ve b\u00fcy\u00fck de\u011filse, t\u00fcm veriyi \u00f6nbelle\u011fe alman\u0131n faydas\u0131 s\u0131n\u0131rl\u0131 olur. Metadata\u2019y\u0131 s\u0131cak tutmak, verinin ak\u0131\u015f\u0131n\u0131 yeterince h\u0131zland\u0131rabilir. \u00d6te yandan, s\u0131k okunan statik dosyalar i\u00e7in primarycache=all<\/strong> olduk\u00e7a mant\u0131kl\u0131d\u0131r. \u0130\u015f y\u00fck\u00fcn\u00fc g\u00f6zlemleyerek karar verin.<\/p>\n
n<\/p>\n
Bir di\u011fer faydal\u0131 dokunu\u015f s\u0131k eri\u015filen dataset\u2019lerde compression=lz4<\/strong> kullanmakt\u0131r. LZ4 hem h\u0131zl\u0131 hem de nefes ald\u0131r\u0131r. Daha az veri, daha az disk i\u015fi demektir. Kazan\u0131lan alan kadar I\/O da azal\u0131r ve ARC daha verimli \u00e7al\u0131\u015f\u0131r. Her yerde de\u011fil, ama \u00e7o\u011fu dosya i\u00e7in g\u00fcvenli bir kazan\u0131m sa\u011flar. Mesela log dosyalar\u0131, yap\u0131 \u00e7\u0131kt\u0131lar\u0131, metin i\u00e7erikler. Medya dosyalar\u0131nda az fark edilebilir ama zarar vermez.<\/p>\n
nn<\/p>\n
ZIL ve SLOG: Senkron Yaz\u0131lar\u0131n \u0130nce Hesab\u0131<\/h2>\n
n<\/p>\n
Bir g\u00fcn bir NFS sunucusunu devrald\u0131m. Kullan\u0131c\u0131lar \u201cdosyay\u0131 kaydediyorum ama anl\u0131k duraksama var\u201d diyordu. Kontrol ettim, i\u015f y\u00fck\u00fc bolca senkron yaz\u0131 \u00fcretiyordu. ZIL zaten i\u015fini yap\u0131yordu ama sistem diskleri bu yo\u011funlu\u011fu kald\u0131ram\u0131yordu. \u00c7\u00f6z\u00fcm olarak SLOG ekledik. G\u00fc\u00e7 kayb\u0131 korumal\u0131 bir NVMe ald\u0131k, k\u00fc\u00e7\u00fck bir dilimi ZIL i\u00e7in ay\u0131rd\u0131k. Sonu\u00e7 belirgindi: o k\u00fc\u00e7\u00fck duraksamalar yok oldu, ak\u0131\u015f p\u00fcr\u00fczs\u00fczle\u015fti.<\/p>\n
n<\/p>\n
Bu noktada iki ayar\u0131 hat\u0131rlay\u0131n: logbias<\/strong> ve sync<\/strong>. logbias=latency<\/strong> senkron yaz\u0131lara \u00f6ncelik verir, \u201cgecikmeme\u201d odakl\u0131d\u0131r. B\u00fcy\u00fck ard\u0131\u015f\u0131k yaz\u0131larda ise logbias=throughput<\/strong> farkl\u0131 davran\u0131r, bu da baz\u0131 yedekleme i\u015flerinde i\u015finize yarar. sync=disabled<\/strong> se\u00e7ene\u011fini duydunuz mu? H\u0131z verir ancak riski b\u00fcy\u00fckt\u00fcr. Elektrik kesildi\u011finde veya sistem \u00e7\u00f6kt\u00fc\u011f\u00fcnde son yaz\u0131lar\u0131n garanti alt\u0131nda olmamas\u0131 kabul edilebilir bir \u015fey de\u011filse, bunu ka\u00e7\u0131n\u0131n. Test ortam\u0131nda belki, \u00fcretimde asla. G\u00fcvenli bir yol: sync=standard<\/strong> ile ak\u0131\u015f\u0131 korumak ve gerekliyse SLOG ile h\u0131zland\u0131rmak.<\/p>\n
n<\/p>\n
SLOG eklemek kolayd\u0131r. Ayn\u0131 anda verinizi riske atmamak i\u00e7in SLOG\u2019u m\u00fcmk\u00fcnse yans\u0131l\u0131 (mirror) kurun. Basit bir \u00f6rnek:<\/p>\n
n<\/p>\n
# SLOG olarak iki NVMe'yi ayna \u015feklinde eklemeknzpool add tank log mirror \/dev\/nvme0n1 \/dev\/nvme1n1nn# Dataset baz\u0131nda logbias ayar\u0131 nzfs set logbias=latency tank\/nfsn<\/code><\/pre>\n
n<\/p>\n
SLOG cihaz\u0131 k\u00fc\u00e7\u00fck tutulabilir; ZIL, sonradan veriyi as\u0131l pool\u2019a yazar. Fakat cihaz se\u00e7imi \u00f6nemlidir, \u00e7\u00fcnk\u00fc bu yaz\u0131lar \u00e7ok k\u00fc\u00e7\u00fck ve s\u0131k aral\u0131kl\u0131d\u0131r. G\u00fc\u00e7 kayb\u0131 korumal\u0131, d\u00fc\u015f\u00fck gecikmeli bir cihaz aray\u0131n. Bu konularda sahada \u00e7ok kafa yormu\u015f ki\u015filerin notlar\u0131n\u0131 okumak isterseniz ZFS Evil Tuning Guide<\/a> g\u00fczel bir perspektif sunar. Sakin ve temkinli ilerlemek, \u201chadi bir de bunu a\u00e7al\u0131m\u201d heyecan\u0131na kap\u0131lmamak, ZFS ile uzun vadede daha sa\u011fl\u0131kl\u0131d\u0131r.<\/p>\n
nn<\/p>\n
Dataset Dokunu\u015flar\u0131: recordsize, volblocksize, ashift, atime ve K\u00fc\u00e7\u00fck S\u0131rlar<\/h2>\n
n<\/p>\n
Performans\u0131n b\u00fcy\u00fck k\u0131sm\u0131n\u0131 k\u00fc\u00e7\u00fck ayarlar belirler. Bir dosya sistemi dataset\u2019lerle konu\u015fur; her dataset\u2019in yap\u0131s\u0131 i\u015f y\u00fck\u00fcne g\u00f6re bi\u00e7imlenebilir. Mesela veritaban\u0131 dosyalar\u0131. Genelde daha k\u00fc\u00e7\u00fck bloklar severler. Postgres i\u00e7in 8K-16K aral\u0131\u011f\u0131 kula\u011fa tan\u0131d\u0131k gelir. B\u00fcy\u00fck medya dosyalar\u0131 ise b\u00fcy\u00fck bloklar\u0131 sever; 1M gibi de\u011ferler ho\u015flar\u0131na gider. Bu blok ayar\u0131n\u0131 dosya tabanl\u0131 depoda recordsize<\/strong> ile yapars\u0131n\u0131z. \u00d6rnek:<\/p>\n
n<\/p>\n
# Veritaban\u0131 dataset'i i\u00e7in daha k\u00fc\u00e7\u00fck recordsizenzfs set recordsize=16K tank\/dbnn# Medya ar\u015fivi i\u00e7in b\u00fcy\u00fck recordsizenzfs set recordsize=1M tank\/median<\/code><\/pre>\n
n<\/p>\n
VM diskleri i\u00e7in iki yol var. Dosya olarak tutuyorsan\u0131z recordsize ile oynars\u0131n\u0131z; zvol olarak blok ayg\u0131t\u0131 \u015feklinde veriyorsan\u0131z volblocksize<\/strong> devreye girer. Bu ayar\u0131 sonradan de\u011fi\u015ftirmek zahmetlidir; ba\u015ftan planlamak daha iyi. Blok boyutu disk imaj\u0131n\u0131n eri\u015fim desenine yak\u0131n olmal\u0131. Rastgele k\u00fc\u00e7\u00fck yaz\u0131 a\u011f\u0131rl\u0131kl\u0131 VM\u2019lerde gereksiz b\u00fcy\u00fck bloklar \u201cyaz-kopyala\u201d y\u00fck\u00fc yarat\u0131r. \u00d6l\u00e7\u00fcn, deneyin ve ufak ad\u0131mlarla ilerleyin.<\/p>\n
n<\/p>\n
Bir de ashift<\/strong> var. Pool kurulurken disklerin fiziksel sekt\u00f6r boyutuna g\u00f6re se\u00e7ilir. Modern disklerde genelde 4K sekt\u00f6r kullan\u0131l\u0131r ve ashift 12 (2^12=4096) g\u00fcvenli bir tercih olur. Bunu sonradan de\u011fi\u015ftirmek kolay de\u011fildir, bu y\u00fczden havuza ba\u015flarken do\u011fru ayar\u0131 se\u00e7mek \u00f6nemlidir. Yanl\u0131\u015f ashift gere\u011finden fazla yazma i\u015fi do\u011furur, performans d\u00fc\u015fer, SSD \u00f6mr\u00fc de gereksiz t\u00fcketilir.<\/p>\n
n<\/p>\n
K\u00fc\u00e7\u00fck ama etkili iki dokunu\u015f daha: atime<\/strong> ve xattr<\/strong>. atime, dosyaya her eri\u015fimde zaman damgas\u0131 g\u00fcnceller. E\u011fer bu bilgiye ihtiyac\u0131n\u0131z yoksa atime=off<\/strong> demek disk \u00fczerindeki k\u00fc\u00e7\u00fck yaz\u0131lar\u0131 azalt\u0131r. Gerekliyse relatime<\/strong> da bir denge se\u00e7ene\u011fi sunar. xattr i\u00e7in xattr=sa<\/strong> baz\u0131 i\u015f y\u00fcklerinde h\u0131z kazand\u0131r\u0131r, \u00e7\u00fcnk\u00fc geni\u015fletilmi\u015f \u00f6znitelikleri ayr\u0131 bir yerde de\u011fil verinin i\u00e7inde saklar. Kulland\u0131\u011f\u0131n\u0131z da\u011f\u0131t\u0131ma ve \u00e7ekirdek versiyonuna g\u00f6re davran\u0131\u015f de\u011fi\u015febilir; ufak bir test iyi gider.<\/p>\n
n<\/p>\n
Disk ya\u015fam d\u00f6ng\u00fcs\u00fc i\u00e7in autotrim=on<\/strong> havuza nefes ald\u0131r\u0131r. SSD\u2019lerin \u00e7\u00f6p toplama d\u00fczeni TRIM ile daha rahat \u00e7al\u0131\u015f\u0131r. Ayn\u0131 \u015fekilde, compression=lz4<\/strong> genelde varsay\u0131lan olmal\u0131. Daha agresif s\u0131k\u0131\u015ft\u0131rmalar baz\u0131 i\u015flerde faydal\u0131 g\u00f6r\u00fcnse de CPU y\u00fck\u00fc ve gecikmeyi d\u00fc\u015f\u00fcnmek gerekir. LZ4, \u201caz risk, s\u0131k s\u0131k kazan\u00e7\u201d \u00e7izgisini g\u00fczel tutar.<\/p>\n
nn<\/p>\n
Snapshot ve send\/receive: Zaman\u0131 Durdurup G\u00fcvenle Ta\u015f\u0131mak<\/h2>\n
n<\/p>\n
Bir sistemi rahat uyutan \u015fey nedir biliyor musunuz? Yedeklerin d\u00fczenli ve geri d\u00f6nd\u00fcr\u00fclebilir olmas\u0131. Snapshot tam burada g\u00fcl\u00fcmser. ZFS snapshot\u2019lar\u0131 anl\u0131k bir foto\u011fraf gibi. Yaratmas\u0131 h\u0131zl\u0131, etkisi sihirli. As\u0131l g\u00fczellik, bu snapshot\u2019lardan zfs send<\/strong> ile ak\u0131\u015f \u00fcretip ba\u015fka yere zfs receive<\/strong> ile ta\u015f\u0131yabilmeniz. \u0130lk ak\u0131\u015f tamd\u0131r, sonrakiler incremental<\/strong>, yani de\u011fi\u015fen bloklar kadard\u0131r. Bu sayede bant geni\u015fli\u011fi ve s\u00fcre makul kal\u0131r.<\/p>\n
n<\/p>\n
Basit bir ak\u0131\u015f \u00f6rne\u011fi verelim. Diyelim tank\/prod dataset\u2019inde her saat snapshot al\u0131yorsunuz ve ba\u015fka bir sunucuya aktarmak istiyorsunuz:<\/p>\n
n<\/p>\n
# Snapshot isimleri i\u00e7in bir \u015fablon yak\u0131\u015f\u0131rnzfs snapshot tank\/prod@hourly-2025-11-16-10nn# \u0130lk tam g\u00f6nderimnzfs send tank\/prod@hourly-2025-11-16-10 | ssh backup "zfs receive backup\/prod"nn# Bir sonraki snapshot'tan sadece fark\u0131 yollamaknzfs send -i tank\/prod@hourly-2025-11-16-10 tank\/prod@hourly-2025-11-16-11 | \\n  ssh backup "zfs receive backup\/prod"n<\/code><\/pre>\n
n<\/p>\n
Naming \u00f6nemlidir. Tarih ve periyot bilgisini eklemek hem listeyi okunur k\u0131lar hem de silme politikas\u0131 y\u00fcr\u00fctmeyi kolayla\u015ft\u0131r\u0131r. Snapshot silmek, referans\u0131 kald\u0131rmak gibidir; veri, ba\u015fka bir snapshot taraf\u0131ndan tutulmuyorsa alan geri kazan\u0131l\u0131r. \u201cSnapshot diskimi \u015fi\u015firir mi?\u201d sorusunun cevab\u0131 i\u015f y\u00fck\u00fcne ba\u011fl\u0131d\u0131r. \u00c7ok de\u011fi\u015fiklik yaparsan\u0131z, evet, al\u0131\u015f\u0131lm\u0131\u015ftan daha fazla yer tutar. Ama ayn\u0131 zamanda geri d\u00f6n\u00fc\u015f\u00fcn sigortas\u0131d\u0131r. Bu y\u00fczden ak\u0131ll\u0131 bir tutma politikas\u0131 \u015fart. G\u00fcnl\u00fckler i\u00e7in birka\u00e7 saatlik, g\u00fcn sonu i\u00e7in birka\u00e7 g\u00fcnl\u00fck, haftal\u0131k ve ayl\u0131k gibi katmanl\u0131 bir yakla\u015f\u0131m pratik olur.<\/p>\n
n<\/p>\n
ZFS\u2019in \u015f\u0131k taraf\u0131, yeniden ba\u015flatmaya ra\u011fmen devam edebilen<\/strong> send ak\u0131\u015flar\u0131 i\u00e7in resume token<\/em> deste\u011fi sunmas\u0131d\u0131r. Bir kopyalama yar\u0131da kesilirse, token\u2019\u0131 al\u0131p kald\u0131\u011f\u0131n\u0131z yerden devam etmek m\u00fcmk\u00fcn. \u015eifreli dataset\u2019lerde ham g\u00f6nderim (zfs send -w<\/strong>) ile i\u00e7eri\u011fi ham haliyle aktarmak, uzak tarafta \u00e7\u00f6z\u00fcmlenmesini sa\u011flamak da ho\u015f bir g\u00fcvenlik \u00f6zelli\u011fidir.<\/p>\n
n<\/p>\n
Otomasyon i\u00e7in \u00e7ok pratik ara\u00e7lar var. \u00d6rne\u011fin Sanoid ve Syncoid ile otomatik snapshot ve replikasyon<\/a> kurmak dakikalar al\u0131r. Snapshot verme, tutma, uzak kopya olu\u015fturma ve silme politikalar\u0131n\u0131 insan hatas\u0131na b\u0131rakmadan y\u00fcr\u00fct\u00fcr. Ben genelde Sanoid ile yerel snapshotlar\u0131, Syncoid ile uzak sunucuya ak\u0131\u015f\u0131 y\u00f6netiyorum. Loglar\u0131 takip edip ufak aksakl\u0131klarda e-posta atmas\u0131n\u0131 sa\u011flamak g\u00fczel bir g\u00fcven duygusu veriyor.<\/p>\n
n<\/p>\n
Uzak kopyay\u0131 yaln\u0131zca ba\u015fka bir ZFS havuzuna almak zorunda de\u011filsiniz. Bazen i\u015finize, \u201car\u015fiv\u201d olarak zfs send<\/strong> ak\u0131\u015f\u0131n\u0131 dosyaya al\u0131p nesne depoya y\u00fcklemek yarar. Bu noktada, S3 uyumlu bir depoya ta\u015f\u0131mak isterseniz, kendi altyap\u0131n\u0131zda S3 kurman\u0131n bir yolu da var. Benim ad\u0131m ad\u0131m anlatt\u0131\u011f\u0131m VPS \u00fczerinde MinIO ile S3\u2011uyumlu depolama kurma rehberi<\/a> tam bu noktada elinizi g\u00fc\u00e7lendirebilir. B\u00f6ylece \u201coffsite\u201d kopyalar\u0131 kendi kontrol\u00fcn\u00fczde, uygun maliyetle ve otomasyonla y\u00f6netebilirsiniz.<\/p>\n
nn<\/p>\n
Ger\u00e7ek Bir Senaryo: K\u00fc\u00e7\u00fck Bir Hosting Sunucusunda B\u00fcy\u00fck Fark<\/h2>\n
n<\/p>\n
Bir m\u00fc\u015fteride, tek bir fiziksel sunucu \u00fczerinde birka\u00e7 VM ve bir veritaban\u0131 hizmeti \u00e7al\u0131\u015f\u0131yordu. \u015eik\u00e2yet basitti: \u201cBaz\u0131 saatlerde sistem tak\u0131l\u0131yor, sonra ak\u0131yor.\u201d \u0130lk bak\u0131\u015fta CPU ve RAM boldu. ZFS ise varsay\u0131lan ayarlardayd\u0131. \u00d6nce ARC\u2019yi k\u0131smen dizginledik; toplam RAM\u2019in b\u00fcy\u00fck k\u0131sm\u0131n\u0131 ARC\u2019ye b\u0131rakmak yerine g\u00fcvenli bir tavan belirledik. VM imajlar\u0131n\u0131 ta\u015f\u0131yan dataset\u2019te primarycache=metadata<\/strong> yapt\u0131k. Random okumalarda ARC\u2019yi zorlamay\u0131p meta veride fayda g\u00f6rd\u00fck. Veritaban\u0131na bakan dataset\u2019te recordsize=16K<\/strong> ve compression=lz4<\/strong> ile k\u00fc\u00e7\u00fck blok ve hafif s\u0131k\u0131\u015ft\u0131rma ikilisini kulland\u0131k.<\/p>\n
n<\/p>\n
\u015eik\u00e2yetin ikinci baca\u011f\u0131 senkron yaz\u0131lard\u0131. NFS ve veritaban\u0131 birlikte, \u201ck\u0131rp\u0131k\u201d yaz\u0131 f\u0131rt\u0131nas\u0131 yarat\u0131yordu. SLOG i\u00e7in g\u00fc\u00e7 kayb\u0131 korumal\u0131 bir NVMe ekledik, yans\u0131l\u0131 kurduk, dataset\u2019lerde logbias=latency<\/strong> se\u00e7tik. sync=disabled<\/strong> tuza\u011f\u0131na d\u00fc\u015fmedik; h\u0131z pahas\u0131na g\u00fcvenlikten vazge\u00e7meyi istemedik. SLOG\u2019dan sonra k\u00fc\u00e7\u00fck dalgalanmalar g\u00f6ze g\u00f6r\u00fcnmez hale geldi. Kullan\u0131c\u0131 taraf\u0131nda hissedilen \u015fey \u201cak\u0131\u015fkanl\u0131k\u201d oldu.<\/p>\n
n<\/p>\n
Yedek taraf\u0131nda, saatlik snapshot ve g\u00fcnl\u00fck replikasyon kurduk. \u0130lk g\u00fcn tam g\u00f6nderim uzun s\u00fcrd\u00fc ama sonraki g\u00fcnlerde fark ak\u0131\u015flar\u0131 h\u0131zl\u0131yd\u0131. \u00d6ncesinde \u201cyedek tamam\u201d demek i\u00e7ime sinmiyordu. Sonras\u0131nda, \u201cbir \u015fey olursa \u015fu s\u00fcr\u00fcme d\u00f6neriz\u201d diyebildik. Haftal\u0131k bak\u0131mda zpool scrub<\/strong> \u00e7al\u0131\u015ft\u0131rd\u0131k; sessiz veri \u00e7\u00fcr\u00fcmesine kar\u015f\u0131 d\u00fczenli bir kontrol gibi d\u00fc\u015f\u00fcn\u00fcn. Ayda bir rapor olu\u015fturduk, \u201c\u015fu snapshotlar silindi, \u015fu kadar alan geri kazan\u0131ld\u0131\u201d diye. K\u00fc\u00e7\u00fck ad\u0131mlar, b\u00fcy\u00fck rahatl\u0131klar.<\/p>\n
nn<\/p>\n
\u0130zleme, Temizlik ve Sakinlik: ZFS\u2019te G\u00fcnl\u00fck Hayat<\/h2>\n
n<\/p>\n
Performans ayarlar\u0131 kadar, izleme ve temizlik ritmi de \u00f6nemlidir. Ben genelde a\u015fa\u011f\u0131daki komutlarla nab\u0131z tutar\u0131m:<\/p>\n
n<\/p>\n
# Havuzun sa\u011fl\u0131\u011f\u0131nzpool status -vnn# I\/O deseni ve gecikmelernzpool iostat -v 1nn# ARC davran\u0131\u015f\u0131 (arcstat.py varsa tad\u0131ndan yenmez)narcstat 1nn# Dataset \u00f6zelliklerini g\u00f6rmeknzfs get all tank\/datasetn<\/code><\/pre>\n
n<\/p>\n
Havuzda scrub<\/strong> rutini, ay\u0131n belli bir g\u00fcn\u00fcnde otomati\u011fe ba\u011flan\u0131r. Y\u00fck d\u00fc\u015f\u00fckken yapmak iyidir. SSD havuzlar\u0131nda autotrim=on<\/strong> tutmak genellikle fayda sa\u011flar. Snapshot tutma politikas\u0131 da mevsimlik de\u011fil, g\u00fcnl\u00fck bir pratik olmal\u0131. \u201cKa\u00e7 tane snapshot tutal\u0131m?\u201d sorusunun cevab\u0131 de\u011fi\u015fir; de\u011fi\u015fim h\u0131z\u0131 y\u00fcksek dataset\u2019lerde daha s\u0131k ama k\u0131sa s\u00fcreli, ar\u015fiv dataset\u2019lerinde daha seyrek ama uzun s\u00fcreli tutmak mant\u0131kl\u0131 olur.<\/p>\n
n<\/p>\n
Performans sorunlar\u0131nda ben \u00f6nce \u201ci\u015f y\u00fck\u00fc ne istiyor?\u201d diye sorar\u0131m. Rastgele mi yaz\u0131yor, ard\u0131\u015f\u0131k m\u0131? Senkron mu istiyor, yoksa asenkron ak\u0131\u015fa raz\u0131 m\u0131? Bu sorulara verdi\u011finiz cevaplar ayarlar\u0131 belirler. logbias<\/strong>, recordsize\/volblocksize<\/strong>, primarycache<\/strong> \u00fc\u00e7l\u00fcs\u00fc ile ufak oynamalar \u00e7o\u011fu zaman a\u011f\u0131r sihirlerden daha etkili olur. Zaten ZFS\u2019in g\u00fczelli\u011fi burada. B\u00fct\u00fcn sistemi alt \u00fcst etmeden, dataset seviyesinde hedefli iyile\u015ftirme yapabilmek.<\/p>\n
n<\/p>\n
Daha teknik detaylara merakl\u0131ysan\u0131z, resmi belge tad\u0131nda anlat\u0131mlara bakmak iyi gelir. Ben \u00e7o\u011fu zaman OpenZFS performans ve tuning k\u0131lavuzu<\/a> ile ba\u015flar, sonra sahadaki notlar i\u00e7in tekrar ZFS Evil Tuning Guide<\/a>\u2019a g\u00f6z atar\u0131m. Bir de snapshot\/replication otomasyonu i\u00e7in arada Sanoid\/Syncoid notlar\u0131n\u0131<\/a> yenilerim. Hepsi ayn\u0131 ezgiyi \u00e7alar: \u00f6l\u00e7, k\u00fc\u00e7\u00fck ad\u0131mlarla de\u011fi\u015ftir, tekrar \u00f6l\u00e7.<\/p>\n
nn<\/p>\n
Kapan\u0131\u015f: Ayar De\u011fil, Al\u0131\u015fkanl\u0131k Kurtar\u0131r<\/h2>\n
n<\/p>\n
Bu yaz\u0131y\u0131 yazarken d\u00f6n\u00fcp o geceye bakt\u0131m. Disk \u0131\u015f\u0131\u011f\u0131na bakarken hissetti\u011fim \u015fey \u015fuymu\u015f: ZFS bir teknoloji de\u011fil, bir al\u0131\u015fkanl\u0131klar b\u00fct\u00fcn\u00fc. ARC\u2019yi \u015f\u0131martmadan, ZIL\/SLOG dengesini i\u015f y\u00fck\u00fcne g\u00f6re kurarak, dataset\u2019lerde ufak ama bilin\u00e7li dokunu\u015flarla, snapshot ve send\/receive\u2019i g\u00fcndelik rutinin par\u00e7as\u0131 yapmak\u2026 Teker teker k\u00fc\u00e7\u00fck hamleler. Sonunda sistem bir anda \u201cd\u00fczelmi\u015f\u201d gibi g\u00f6r\u00fcn\u00fcr. Oysa sihir, her g\u00fcn bir damla oksijen vermektedir.<\/p>\n
n<\/p>\n
E\u011fer bug\u00fcn bir yerden ba\u015flamak isterseniz, \u00fc\u00e7 ad\u0131m \u00f6neririm. Birincisi, ARC i\u00e7in makul bir tavan belirleyin ve bir hafta g\u00f6zlem yap\u0131n. \u0130kincisi, i\u015f y\u00fck\u00fcne g\u00f6re recordsize\/volblocksize<\/strong> ve compression=lz4<\/strong> ayarlar\u0131n\u0131 sade sade oturtun. \u00dc\u00e7\u00fcnc\u00fcs\u00fc, snapshot ve incremental send ile uzak kopyay\u0131 kurun; haftal\u0131k bir scrub<\/strong> ekleyin. Hepsi bu. Zamanla neyin size iyi geldi\u011fini sistem s\u00f6yleyecek.<\/p>\n
n<\/p>\n
Umar\u0131m bu yaz\u0131 elinizi rahatlatt\u0131. ZFS, do\u011fru yakla\u015f\u0131mla hem h\u0131z hem g\u00fcven verir. Tak\u0131ld\u0131\u011f\u0131n\u0131z bir nokta olursa, \u201c\u015fu i\u015f y\u00fck\u00fcnde \u015fu ayar nas\u0131l durur?\u201d diye yorumlay\u0131n; \u00f6l\u00e7meden de\u011fi\u015ftirip sonra tekrar \u00f6l\u00e7\u00fcn. Bir dahaki yaz\u0131da, isterseniz daha ileri konulara, mesela native encryption ve ham g\u00f6nderim stratejilerine dalar\u0131z. \u015eimdilik ho\u015f\u00e7a kal\u0131n; o disk \u0131\u015f\u0131\u011f\u0131 art\u0131k daha sakin yan\u0131p s\u00f6ns\u00fcn.<\/p>\n
“,
\n  “focus_keyword”: “ZFS performans ve dayan\u0131kl\u0131l\u0131k”,
\n  “meta_description”: “ZFS ile Linux sunucularda performans ve dayan\u0131kl\u0131l\u0131\u011f\u0131 art\u0131rmak i\u00e7in ARC\/ZIL\/SLOG tuning, recordsize ayarlar\u0131 ve snapshot ile send\/receive yedekleri.”,
\n  “faqs”: [
\n    {
\n      “question”: “SLOG \u015fart m\u0131? Hangi durumda ger\u00e7ek fayda sa\u011flar?”,
\n      “answer”: “Her zaman \u015fart de\u011fil. Senkron yaz\u0131 a\u011f\u0131rl\u0131kl\u0131 i\u015flerde, \u00f6rne\u011fin NFS, veritaban\u0131 veya VM disklerinde belirgin fark yarat\u0131r. G\u00fc\u00e7 kayb\u0131 korumal\u0131, d\u00fc\u015f\u00fck gecikmeli bir SSD se\u00e7ip m\u00fcmk\u00fcnse yans\u0131l\u0131 kurarsan hem h\u0131z hem g\u00fcven kazan\u0131rs\u0131n.”
\n    },
\n    {
\n      “question”: “Snapshot \u00e7ok yer kaplar m\u0131? Sunucuyu yava\u015flat\u0131r m\u0131?”,
\n      “answer”: “Snapshot ilk anda yer kaplamaz; de\u011fi\u015fen bloklar artt\u0131k\u00e7a b\u00fcy\u00fcr. \u00c7ok de\u011fi\u015fen dataset\u2019lerde daha h\u0131zl\u0131 b\u00fcy\u00fcr, bu normal. Uygun bir tutma politikas\u0131yla (saatlik, g\u00fcnl\u00fck, haftal\u0131k) alan\u0131 kontrol edebilirsin. Performans\u0131 do\u011frudan yava\u015flatmaz; as\u0131l etkisi depolanan de\u011fi\u015fiklik miktar\u0131yla ilgilidir.”
\n    },
\n    {
\n      “question”: “ARC i\u00e7in ne kadar RAM ay\u0131rmal\u0131y\u0131m?”,
\n      “answer”: “Kesin bir say\u0131 yok; i\u015f y\u00fck\u00fcne g\u00f6re denge kurmal\u0131s\u0131n. Di\u011fer servislerin rahat \u00e7al\u0131\u015faca\u011f\u0131 pay\u0131 b\u0131rak\u0131p ARC i\u00e7in makul bir tavan belirle, sonra birka\u00e7 g\u00fcn izleyip d\u00fczelt. A\u015f\u0131r\u0131 b\u00fcy\u00fck ARC, sistemin swap\u2019e d\u00fc\u015fmesine yol a\u00e7arsa kazan\u0131m h\u0131zla kaybolur.”
\n    }
\n  ]
\n}<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"
{ “title”: “ZFS ile Linux Sunucularda Performans ve Dayan\u0131kl\u0131l\u0131k: ARC, ZIL, SLOG, Snapshot ve send\/receive Nas\u0131l Tatl\u0131 Tatl\u0131 Ayarlan\u0131r?”, “content”: “n Hi\u00e7, gece ge\u00e7 saatte ofiste tek ba\u015f\u0131na kal\u0131p disk \u0131\u015f\u0131klar\u0131n\u0131n ritmini dinlediniz mi? Ben kald\u0131m. O g\u00fcn bir VM bir t\u00fcrl\u00fc aya\u011fa kalkm\u0131yor, I\/O gecikmeleri dalgalan\u0131yor, grafikte dikenler \u00e7\u0131k\u0131yor, CPU bo\u015fta ama kullan\u0131c\u0131lar homurdan\u0131yordu. […]<\/p>\n","protected":false},"author":1,"featured_media":1936,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-1935","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/posts\/1935","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/comments?post=1935"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/posts\/1935\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/media\/1936"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/media?parent=1935"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/categories?post=1935"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/tags?post=1935"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}