ulimit ile Kaynak Limitlerini Yönetme

Bir Linux sunucusunda her sürecin ne kadar dosya açabileceği, ne kadar bellek kullanabileceği ve kaç alt süreç yaratabileceği görünmez tavanlarla sınırlandırılmıştır. Bu tavanlar boşta duran küçük bir sitede hiç fark edilmez; ama trafik arttığında, veritabanı bağlantıları biriktiğinde ya da Nginx binlerce eş zamanlı istekle uğraşırken aniden karşınıza çıkar. Genellikle logda beliren "too many open files" satırıyla ya da servisin sessizce yeni bağlantı kabul etmeyi bırakmasıyla kendini gösterir. Çoğu sistem yöneticisi bu hatayı ilk gördüğünde donanımı ya da kodu suçlar; oysa sorun neredeyse her zaman çekirdeğin süreç başına dayattığı ulimit değerinin çok düşük kalmasıdır.

Bu rehberde bu limitlerin ne olduğunu, ulimit komutuyla nasıl görüntülenip değiştirileceğini, soft ve hard limit ayrımını, en kritik iki değer olan nofile ve nproc limitlerini ve "too many open files" hatasının gerçek kökenini anlatacağım. Ardından yaptığınız ayarın oturum kapanınca sıfırlanmaması için /etc/security/limits.conf ve systemd LimitNOFILE ile limitleri nasıl kalıcı hale getireceğinizi, Nginx ve veritabanı sunucuları için gerçekçi yüksek limit örnekleriyle göstereceğim. Amaç, sunucunuzun kaynak çerçevesini kıdemli bir yöneticinin baktığı gözle okuyabilmeniz ve limit aşımını sorun büyümeden önlemenizdir.

Kaynak Limiti Nedir ve ulimit Neyi Kontrol Eder#

Linux çekirdeği, tek bir kullanıcının ya da kaçak bir sürecin sunucunun tüm kaynaklarını tüketip diğer her şeyi çökertmesini engellemek için süreç başına kaynak sınırları uygular. Bu sınırlar, bir kabuk oturumundan başlatılan tüm süreçlere miras kalır ve ulimit komutuyla yönetilir. ulimit aslında bash kabuğunun dahili bir komutudur; arka planda çekirdeğin getrlimit/setrlimit sistem çağrılarını kullanır. Yani bir dairenin sigortası gibi düşünebilirsiniz: her kiracıya ayrı bir tavan tanımlanır ve o tavana çarpan yalnızca kendi işini yavaşlatır ya da durdurur, komşusunu etkilemez.

Bu limitler tek bir değerden ibaret değildir; her biri farklı bir kaynağı ölçen ayrı bir kalemdir. En sık karşılaşacağınız kalemler açık dosya sayısı (nofile), süreç/thread sayısı (nproc), yığın belleği (stack), çekirdek dosyası boyutu (core) ve kilitli bellek (memlock) gibi değerlerdir. Aşağıdaki tablo günlük hayatta en çok işinize yarayacak olanları özetliyor.

Buradaki en kritik satır neredeyse her zaman nofile yani açık dosya limitidir, çünkü Linux'ta yalnızca gerçek dosyalar değil; her ağ soketi, her boru (pipe) ve her veritabanı bağlantısı da bir "açık dosya tanımlayıcısı" (file descriptor) sayılır. Web sunucusundan veritabanına kadar yük altındaki her servis, bu limite ilk çarpandır.

ulimit -a ile Mevcut Limitleri Görme#

Bir sunucuya yeni bağlandığınızda ilk yapmanız gereken, mevcut limitleri okumaktır. Tek bir komut, o oturumdaki tüm etkin sınırları önünüze serer.

# Geçerli oturumun tüm limitlerini listele
ulimit -a

# Sadece açık dosya (nofile) limitini göster
ulimit -n

# Soft ve hard nofile limitini ayrı ayrı gör
ulimit -Sn    # soft limit
ulimit -Hn    # hard limit

ulimit -a çıktısı tipik olarak şuna benzer:

open files                      (-n) 1024
max user processes              (-u) 15039
stack size              (kbytes, -s) 8192
core file size          (blocks, -c) 0
max locked memory       (kbytes, -l) 65536

Bu çıktı size o an içinde bulunduğunuz kabuğun limitlerini verir. Önemli bir ayrıntı şudur: ulimit gösterdiği değer, o oturumu başlatan sürecin limitlerini yansıtır. Örneğin bir servisi systemd başlattıysa, sizin SSH oturumunuzdaki ulimit -n çıktısı ile o servisin gerçek limiti farklı olabilir. Çalışan bir sürecin gerçek limitini görmek için /proc dosya sistemine bakmak en güvenilir yöntemdir.

# Nginx master sürecinin PID'sini bul
pidof nginx

# O sürecin gerçek limitlerini oku (örnek PID 1423)
cat /proc/1423/limits

/proc/PID/limits çıktısı, hem soft (Soft Limit) hem hard (Hard Limit) sütunlarını yan yana gösterir ve bir sorunu teşhis ederken en çok güvenmeniz gereken kaynaktır; çünkü servisin gerçekte hangi tavanla çalıştığını doğrudan çekirdekten okur, tahmine yer bırakmaz.

Soft Limit ve Hard Limit Farkı#

ulimit mantığını gerçekten kavramak için soft ve hard limit ayrımını sindirmek şarttır, çünkü ayarların neden bazen "tutmadığını" bu ikisi açıklar. Her kaynağın iki tavanı vardır. Soft limit, o an fiilen uygulanan değerdir; bir süreç bu sınıra çarptığında hatayı alır. Hard limit ise soft limitin çıkabileceği en yüksek nokta, yani tavanın tavanıdır.

Kural şudur: sıradan (root olmayan) bir kullanıcı soft limitini hard limitine kadar serbestçe yükseltebilir, ama hard limiti asla artıramaz; yalnızca düşürebilir. Hard limiti yükseltme yetkisi sadece root'a aittir. Bu yüzden bir kullanıcı olarak ulimit -n 100000 komutu "operation not permitted" hatası veriyorsa, sebep neredeyse her zaman hard limitin bu değerin altında kalmasıdır.

# Soft limiti hard limite kadar yükselt (yaygın kullanım)
ulimit -Sn 8192

# Hard limiti değiştir (yalnızca root, oturum için geçerli)
ulimit -Hn 65536

# Hem soft hem hard'ı aynı anda ayarla
ulimit -n 65536

Aşağıdaki tablo iki kavramı yan yana koyar.

Bu ayrımı akılda tutmak, ilerideki kalıcı ayarlarda soft ve hard satırlarını neden ayrı ayrı yazdığımızı da açıklar. Genel pratik, soft limiti günlük ihtiyaca göre makul tutup hard limiti biraz daha yüksek bırakarak servislere manevra alanı vermektir.

nofile ve nproc — En Kritik İki Limit#

Üretim sunucularında dertlerin yüzde doksanı iki limitten çıkar: nofile ve nproc. Bunları ayrı ayrı tanımak, doğru limiti doğru yere koymanızı sağlar.

nofile, bir sürecin aynı anda açık tutabileceği dosya tanımlayıcısı sayısıdır. Linux felsefesinde "her şey bir dosyadır" ilkesi gereği bu sayaç yalnızca disk dosyalarını değil, açık TCP soketlerini, unix soketlerini, boruları ve epoll örneklerini de kapsar. Yoğun bir Nginx her aktif bağlantı için en az bir soket tanımlayıcısı, çoğu zaman upstream'e giden ikinci bir bağlantı ve statik dosya için ek tanımlayıcılar açar. 1024'lük varsayılan bir nofile limiti, birkaç yüz eş zamanlı bağlantıda bile tükenir. Bu yüzden yük alan web ve veritabanı sunucularında nofile limitini onbinlere çıkarmak neredeyse zorunludur.

nproc, bir kullanıcının çalıştırabileceği toplam süreç ve thread sayısıdır. Java, PHP-FPM havuzları ve çok thread'li uygulamalar bu limite hızla dayanabilir. nproc tükendiğinde tipik belirti "fork: retry: Resource temporarily unavailable" ya da "Cannot allocate memory" gibi yanıltıcı mesajlardır; bellek bol olmasına rağmen çekirdek yeni süreç yaratmayı reddeder. Bir önemli tuzak da şudur: nproc limiti çoğu dağıtımda kullanıcı bazında sayılır. Yani aynı kullanıcı altında çalışan iki farklı servis, ortak nproc havuzunu paylaşır ve biri diğerini aç bırakabilir.

# Bir kullanıcının o an açık kaç süreci olduğunu say
ps -u www-data --no-headers | wc -l

# Sistem genelinde açık dosya tanımlayıcısı sayısını gör
cat /proc/sys/fs/file-nr
# Çıktı: kullanılan  ayrılmış  sistem-tavanı

Buradaki fs.file-nr çıktısının üçüncü sütunu, sistemin tamamı için geçerli çekirdek düzeyindeki tavandır (fs.file-max). ulimit süreç başına sınırı belirlerken bu değer tüm sistemin toplamını tutar; ikisini karıştırmamak gerekir. Modern sunucularda fs.file-max genelde milyonlarca olarak ayarlıdır, dolayısıyla darboğaz neredeyse her zaman süreç başına düşen ulimit -n değeridir, sistem tavanı değil.

Too Many Open Files Hatasının Kökeni#

Sistem yöneticilerinin en sık gördüğü hatalardan biri budur ve tam olarak ne anlama geldiğini bilmek, saatlerce yanlış yerde arama yapmaktan kurtarır. "too many open files" hatası, bir sürecin nofile soft limitine dayanıp yeni bir dosya tanımlayıcısı açmaya çalıştığında çekirdeğin verdiği EMFILE yanıtıdır. Yani hata bir disk sorunu ya da bozuk dosya değil; sürecin kotasının dolmasıdır.

Nginx'te bu hata error logunda accept4() failed (24: Too many open files) biçiminde belirir ve sonucu ölümcüldür: sunucu yeni bağlantı kabul edemez, ziyaretçiler zaman aşımı ya da bağlantı reddi görür. MySQL/MariaDB tarafında ise Error 24: Out of resources when opening file şeklinde çıkar ve sorgular tabloları açamaz. İlk teşhis adımı, sürecin gerçek limitini ve o an kaç tanımlayıcı açtığını yan yana koymaktır.

# Sürecin nofile limitini gör
cat /proc/$(pidof nginx | cut -d' ' -f1)/limits | grep "open files"

# Sürecin o an açık kaç tanımlayıcısı var
ls /proc/$(pidof nginx | cut -d' ' -f1)/fd | wc -l

İkinci sayı birinciye yaklaşıyorsa teşhis nettir: limiti yükseltmeniz gerekir. Ancak burada iki farklı senaryoyu ayırt etmek önemlidir. Eğer açık tanımlayıcı sayısı gerçek trafikle orantılıysa limit gerçekten yetersizdir ve artırmalısınız. Fakat sayı durmadan yükseliyor, düşmüyorsa bir tanımlayıcı sızıntısı (fd leak) söz konusu olabilir: uygulama açtığı bağlantıları ya da dosyaları kapatmıyordur. Bu durumda limiti artırmak yalnızca çökmeyi geciktirir, kalıcı çözüm koddadır. Hangi senaryoda olduğunuzu anlamak için lsof ile açık tanımlayıcıları türlerine göre incelemek çok işe yarar.

# Bir sürecin açtığı tanımlayıcıları türe göre say
lsof -p <PID> | awk '{print $5}' | sort | uniq -c | sort -rn

sock ve IPv4 satırlarının anormal büyümesi ağ sızıntısına, REG (regular file) satırının büyümesi ise dosya sızıntısına işaret eder. Sağlıklı bir teşhis, limiti körlemesine yükseltmekten her zaman daha kalıcı sonuç verir.

limits.conf ile Kalıcı Limit Ayarı#

ulimit -n 65536 komutunu terminale yazdığınızda ayar yalnızca o oturum ve ondan doğan süreçler için geçerli olur; oturumu kapatınca ya da sunucu yeniden başlayınca varsayılana döner. Kalıcı çözüm, PAM (Pluggable Authentication Modules) katmanının okuduğu /etc/security/limits.conf dosyasını düzenlemektir. Bu dosya, kullanıcı ya da grup bazında soft ve hard limitleri tanımlar ve kullanıcı sisteme giriş yaptığında otomatik uygulanır.

Dosyanın söz dizimi dört sütundan oluşur: <domain> <type> <item> <value>. Domain bir kullanıcı adı, bir grup (@grup) ya da tüm kullanıcılar için * olabilir; type soft veya hard; item nofile, nproc gibi limit adı; value ise sayısal değerdir.

# /etc/security/limits.conf

# Tüm kullanıcılar için açık dosya limiti
*        soft    nofile    65536
*        hard    nofile    131072

# www-data (web sunucusu) kullanıcısı için daha yüksek
www-data soft    nofile    100000
www-data hard    nofile    200000

# Süreç limiti (fork bombası dışı meşru yük için)
*        soft    nproc     8192
*        hard    nproc     16384

Dikkat edilmesi gereken bir nokta: bazı dağıtımlarda nproc için /etc/security/limits.d/ altında ayrı bir dosya (örneğin 90-nproc.conf) bulunur ve ana limits.conf'taki değeri ezer; oradaki değeri de güncellemeniz gerekebilir. Ayrıca limits.conf'un devreye girmesi için PAM'in pam_limits modülünün etkin olması gerekir ki modern sunucularda bu varsayılan olarak açıktır.

Bu dosyanın kritik bir sınırı vardır: yalnızca bir oturum açan (login) süreçler için işler. SSH, konsol girişi ve su/sudo üzerinden başlayan süreçler limitleri alır. Ancak sunucu açılışında systemd tarafından doğrudan başlatılan servisler bir PAM oturumundan geçmez, dolayısıyla limits.conf'u tümüyle görmezden gelir. Nginx, MySQL, PostgreSQL gibi servislerinizi systemd yönettiği için, kalıcı limiti oraya taşımamız gerekir. Bu ayrımı ıskalamak, "limits.conf'a yazdım ama Nginx hâlâ 1024'te" tipindeki en yaygın hatanın kaynağıdır. systemd'nin genel mantığına yabancıysanız systemd ile servis yönetimi yazısı iyi bir zemin sağlar.

systemd Servisleri İçin LimitNOFILE Ayarı#

Modern bir sunucuda web sunucusu, veritabanı ve arka plan işçileri systemd tarafından başlatıldığı için, bunların limitini systemd unit dosyasında belirlemek en doğru yoldur. systemd, her servis için LimitNOFILE, LimitNPROC, LimitCORE gibi yönergelerle limitleri doğrudan tanımlamanıza izin verir ve bu değer limits.conf'tan bağımsız çalışır.

Bir servisin limitini değiştirmek için asıl paket dosyasını elle düzenlemek yerine bir drop-in override oluşturmak en temiz yöntemdir; böylece paket güncellemesi ayarınızı ezmez.

# Nginx için override düzenleyicisini aç
systemctl edit nginx

Açılan editöre yalnızca değiştirmek istediğiniz kısmı yazın:

[Service]
LimitNOFILE=100000
LimitNPROC=16384

Kaydettikten sonra ayarı yeniden yüklemeniz ve servisi yeniden başlatmanız gerekir:

# Yeni unit ayarını sisteme oku
systemctl daemon-reload

# Servisi yeniden başlat (reload çoğu zaman yetmez)
systemctl restart nginx

# Doğrula: gerçek limit uygulandı mı
cat /proc/$(pidof nginx | head -1)/limits | grep "open files"

Nginx'in özel bir ayrıntısı vardır: systemd LimitNOFILE ile işletim sistemi tavanını yükseltseniz bile, Nginx kendi işçi süreçlerine dağıttığı limiti nginx.conf'taki worker_rlimit_nofile yönergesiyle ayrıca belirler. Yani her iki tarafı da hizalamalısınız. Nginx yapılandırmasının bütününe hakim değilseniz Ubuntu'da Nginx kurulumu yazısı iyi bir başlangıçtır.

# /etc/nginx/nginx.conf
worker_rlimit_nofile 100000;

events {
    worker_connections 20480;
}

Burada mantıklı bir kural, worker_rlimit_nofile değerini worker_connections değerinin en az iki katı tutmaktır; çünkü her istemci bağlantısı hem gelen soket hem de upstream'e giden bağlantı için ayrı tanımlayıcı tüketebilir. MySQL/MariaDB tarafında da benzer bir hizalama vardır: systemd LimitNOFILE'ı yükseltirken, MySQL'in kendi open_files_limit ayarını da [mysqld] bölümünde açmanız gerekir, aksi halde MySQL işletim sisteminden aldığı tavanı tam kullanamaz.

# /etc/mysql/my.cnf
[mysqld]
open_files_limit = 65536

Kendi yazdığınız arka plan uygulamaları (Node.js işçisi, Python kuyruk tüketicisi vb.) için de aynı yaklaşım geçerlidir: uygulamanın systemd unit dosyasına LimitNOFILE ekleyip daemon-reload ile yeniden başlatmak yeterlidir. Bu düzeyde ince ayarların kendi sunucunuzu gerektirdiğini unutmayın; paylaşımlı hostingde bu değerler sağlayıcı tarafından sabitlenmiştir. Tam kontrol istiyorsanız root erişimli bir VDS sunucu ya da sanal sunucu doğru zemindir. Bu ayarları yapmaya vaktiniz ya da güveniniz yoksa sunucu yönetimi hizmetimiz tüm limit optimizasyonunu sizin adınıza üstlenir.

Doğrulama, Yaygın Tuzaklar ve Kontrol Listesi#

Limitleri ayarladıktan sonra işin en çok atlanan kısmı doğrulamadır. Ayarı yazmak değil, çalışan sürecin gerçekten yeni limitle koştuğunu kanıtlamak önemlidir. /proc/PID/limits bunun tek güvenilir kaynağıdır; ulimit -n'i kendi SSH oturumunuzda çalıştırmak size servisin değil, yalnızca kabuğunuzun limitini gösterir ve bu ikisi çoğu zaman farklıdır.

Sık düşülen tuzakları bir kontrol listesi olarak toplamak faydalı olur. Aşağıdaki maddeler, "ayarı yaptım ama tutmadı" vakalarının neredeyse tamamını kapsar.

• systemd servisleri limits.conf'u okumaz; onların limitini LimitNOFILE ile unit dosyasına yazın.
• Değişiklikten sonra systemctl daemon-reload ve tam restart yapmadan yeni limit uygulanmaz; salt reload çoğu zaman yetmez.
• Hard limiti yükseltmek root gerektirir; kullanıcı olarak yalnızca soft'u hard'a kadar çıkarabilirsiniz.
• nproc için /etc/security/limits.d/ altındaki ayrı dosya, ana limits.conf'u ezebilir.
• Nginx'te sistem limiti yetse bile worker_rlimit_nofile ayarlanmazsa işçiler eski tavanla koşar.
• Limit sürekli doluyorsa önce sızıntı (fd leak) olup olmadığını lsof ile kontrol edin; körlemesine yükseltmek sorunu erteler.

Bu adımları alışkanlık haline getirdiğinizde "too many open files" sınıfı hatalar üretim ortamınızda pratikte ortadan kalkar; kaldıkları yerde ise nedeni dakikalar içinde teşhis edebilir hale gelirsiniz.

Sıkça Sorulan Sorular#

ulimit değişikliğim neden oturum kapanınca kayboluyor?#

Terminale yazdığınız ulimit komutu yalnızca o kabuk oturumu ve ondan doğan süreçler için geçerlidir; çekirdek bu değeri kalıcı bir yere yazmaz. Oturumu kapattığınızda ya da sunucu yeniden başladığında değer varsayılana döner. Kalıcı yapmak için /etc/security/limits.conf dosyasına satır eklemeniz, systemd servisleri içinse ilgili unit dosyasına LimitNOFILE yönergesi yazmanız gerekir. İki yöntem farklı süreç türlerini kapsadığı için hangi süreci sınırladığınıza göre doğru yeri seçmelisiniz.

limits.conf'a yazdım ama Nginx hâlâ 1024 limitiyle çalışıyor, neden?#

Bunun nedeni neredeyse her zaman şudur: /etc/security/limits.conf yalnızca bir PAM oturumundan geçen giriş süreçlerine uygulanır, oysa Nginx sunucu açılışında systemd tarafından doğrudan başlatılır ve bir oturumdan geçmez. Bu yüzden limits.conf'taki değeri tümüyle görmezden gelir. Doğru çözüm systemctl edit nginx ile bir override oluşturup [Service] bölümüne LimitNOFILE=100000 yazmak, ardından systemctl daemon-reload ve systemctl restart nginx çalıştırmaktır.

Soft limit ile hard limit arasındaki fark tam olarak nedir?#

Soft limit o an fiilen uygulanan tavandır; bir süreç bu değere çarptığında hatayı alır. Hard limit ise soft limitin çıkabileceği en yüksek noktadır, yani tavanın tavanı. Sıradan bir kullanıcı soft limitini hard limitine kadar serbestçe yükseltebilir ama hard limiti asla artıramaz, yalnızca düşürebilir; hard limiti yükseltme yetkisi yalnızca root'a aittir. Bu yüzden yetkisiz bir kullanıcı olarak limiti yükseltemiyorsanız, sorun büyük olasılıkla düşük kalan hard limittir.

nofile limitini çok yüksek bir değere ayarlamanın zararı var mı?#

Makul ölçüde yüksek bir nofile değeri (örneğin yük alan bir sunucuda 65536 veya 100000) neredeyse hiçbir riske yol açmaz; açık dosya tanımlayıcıları çok az bellek tükettiği için tavanı yükseltmek boşta kaynak harcamaz. Asıl tehlike, limiti aşırı yükseltip altta yatan bir tanımlayıcı sızıntısını (fd leak) gizlemektir. Bu durumda çökme ortadan kalkmaz, yalnızca ertelenir. Bu yüzden önce sürecin açık tanımlayıcı sayısının trafikle orantılı olup olmadığını lsof ile doğrulamak, sonra limiti ihtiyacın makul katına ayarlamak en sağlıklısıdır.

Çalışan bir sürecin gerçek limitini nasıl görebilirim?#

En güvenilir yöntem /proc dosya sistemini okumaktır. Sürecin PID'sini bulun (örneğin pidof nginx) ve cat /proc/PID/limits komutunu çalıştırın; bu çıktı hem soft hem hard limitleri sütun sütun, doğrudan çekirdekten okuyarak gösterir. Kendi SSH oturumunuzda ulimit -n çalıştırmak yanıltıcıdır çünkü size servisin değil, yalnızca içinde bulunduğunuz kabuğun limitini verir ve bu iki değer çoğu zaman birbirinden farklıdır.

Paylaşımlı hostingde ulimit değerlerini kendim değiştirebilir miyim?#

Hayır. Paylaşımlı hosting ortamlarında ulimit ve limits.conf değerleri sunucu sağlayıcısı tarafından sabitlenir ve tüm hesaplar için ortak sınırlar içinde tutulur; kullanıcı olarak bu tavanları yükseltme yetkiniz yoktur. Açık dosya ya da süreç limitine sürekli dayanıyorsanız, ya uygulamanızı optimize etmeniz ya da root erişimi veren bir VDS ya da sanal sunucuya geçmeniz gerekir. Yalnızca kök yetkisine sahip olduğunuz bir sunucuda bu limitleri özgürce yapılandırabilirsiniz.

Kapanış#

ulimit, ilk bakışta gizemli görünen ama aslında son derece öngörülebilir bir mekanizmadır: her sürecin ne kadar dosya açabileceğini, kaç süreç yaratabileceğini ve ne kadar bellek kullanabileceğini süreç başına belirleyen çekirdek tavanları. Bu tavanları okumayı (ulimit -a, /proc/PID/limits), soft ve hard ayrımını, nofile ile nproc'un neden bu kadar kritik olduğunu ve limitleri limits.conf ile systemd LimitNOFILE üzerinden kalıcı hale getirmeyi öğrendiğinizde, "too many open files" sınıfı hataların çoğu üretim ortamınıza hiç uğramaz. Kilit ilke şudur: ayarı yazmak yetmez, çalışan sürecin gerçekten yeni limitle koştuğunu doğrulamak gerekir.

Bu ince ayarların tamamı, ancak kök erişimine sahip olduğunuz kendi sunucunuzda mümkündür. Kaynak limitlerini kendiniz yönetmek, yüksek trafikli bir uygulama çalıştırmak ya da veritabanınıza nefes aldıracak geniş tavanlar tanımlamak istiyorsanız, Clou.TR'nin VDS sunucu ve sanal sunucu çözümleri size tam kontrol verir. Sunucu tarafındaki performans ayarlarını uzmana bırakmak isterseniz sunucu yönetimi hizmetimiz limit optimizasyonundan güvenlik sertleştirmesine kadar tüm işi sizin adınıza üstlenir; böylece siz uygulamanıza odaklanırsınız, kaynak çerçevesini biz yönetiriz.