Linux sistemimi daha agresif dosya sistemi önbelleğe almak için yapılandırabilir miyim?


119

RAM kullanımı (yeterince sahip olduğum gibi) veya yanlışlıkla kapanma durumunda veri kaybı hakkında endişelenmiyorum (gücüm desteklendiğinden, sistem güvenilir ve veriler kritik değil). Ancak çok fazla dosya işleme yapıyorum ve performans artırımı kullanabiliyorum.

Bu nedenle, sistemi dosya sistemi okumak ve yazmak için önbellekleme için daha fazla RAM kullanmaya, dosyaları agresif bir şekilde önceden getirmeye ayarlamak istiyorum (örneğin, dosyanın aklı başında veya en azından olması durumunda bir uygulamanın eriştiği dosyanın tamamını okumak aksi halde büyük bir parça okumaya devam edin) ve yazma arabelleklerini daha az sıklıkta yıkayın. Bu nasıl başarılır (mümkün olabilir)?

XUbuntu 11.10 x86 ile ext3 ve ntfs (ntfs çok kullanırım!) Dosya sistemlerini kullanıyorum.


6
Çok miktarda RAM'iniz varsa, performansı çok önemsiyor ve veri kaybını önemsemiyorsanız, tüm verilerinizi bir RAM diskine kopyalayın ve oradan hizmet verin; çökme / kapanma ile ilgili tüm güncellemeleri atın. Bu sizin için işe yaramazsa, RAM için "yeterince" kalifiye olmanız veya verilerin ne kadar kritik olmadığı gerekebilir.
James Youngman

1
@Nils, bilgisayar bir dizüstü bilgisayar, bu yüzden, inanıyorum ki, denetleyici oldukça sıradan.
Ivan

1
Performansı çok arttırmanın bir yolu, verilerin dayanıklılığını atlamaktır. Bazı uygulamalar senkronizasyon için olsa bile, diske senkronizasyonu devre dışı bırakmanız yeterlidir. Bu , depolama cihazınız hiç elektrik kaybına uğrarsa veri kaybına neden olur . Yine de yapmak istiyorsanız, daha yüksek performans için fedakarlığa istekli olduğunuz herhangi bir dosya sistemine dahil etmek için yürütün sudo mount -o ro,nobarrier /path/to/mountpointya da ayarlayın . Ancak, depolama aygıtınızda Intel 320 SSD serisi gibi bir dahili batarya varsa, kullanımı veri kaybına neden olmaz. /etc/fstabnobarriernobarrier
Mikko Rantalainen

1
Yazma engellerinin negatif performans etkisi ihmal edilebildiğinden (yaklaşık olarak% 3) Red Hat Enterprise Linux 6'da artık bariyer kullanımı önerilmez. Yazma engellerinin yararları, genellikle engellemenin performans yararlarından ağır basar. Ek olarak, nobarrier seçeneği hiçbir zaman sanal makinelerde yapılandırılmış depolamada kullanılmamalıdır. access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…
Ivailo Bardarov

1
İki nokta - 1) Puppy Linux ve AntiX Linux gibi Debian veya Ubuntu'ya dayanan linux dağıtımları ve tüm işletim sistemini katmanlı ramdisk bölümlerine (örneğin, AUFS veya bindirmelere) yerleştiren ve şeffaf olarak yöneten birçok dağıtım var. Çok hızlı! - 2) Gerçek dünya tasarımında, kendisine daha fazla önbellek atan PERFORMANSI AZALTABİLECEĞİMİZ. Depolama hızları arttıkça (yani SSD), gereken en uygun önbellek boyutu azalır. Bu büyüklüğün ne olduğunu bilmenin hiçbir yolu kendi sisteminizde deney yapmadan. Artış işe yaramazsa, azaltmayı deneyin.
DocSalvager

Yanıtlar:


107

Genel olarak disk önbellek performansının iyileştirilmesi, tüm sisteminiz RAM'e sığmadığı sürece sadece sistem önbellek boyutunu artırmaktan daha fazlasıdır (bu durumda RAM sürücüyü kullanmanız gerekir ( tmpfsbazı durumlarda RAM'e ihtiyacınız olursa diske düşmenize izin verir çünkü) çalışma zamanı saklama için (ve başlangıçta sistemi depolama biriminden RAM sürücüye kopyalamak için bir initrd komut dosyası olabilir).

Depolama cihazınızın SSD veya HDD olup olmadığını söylemediniz. İşte benim için çalışırken bulduğum şey (benim durumumda sdabir HDD /homeve sdbSSD de monte edilmiş /).

Öncelikle, depolama alanından ön belleğe yüklenen bölümü optimize et:

İşte benim HDD kurulumum: (geçiş yaparsanız, BIOS'ta AHCI + NCQ'nun etkinleştirildiğinden emin olun):

echo cfq > /sys/block/sda/queue/scheduler
echo 10000 > /sys/block/sda/queue/iosched/fifo_expire_async
echo 250 > /sys/block/sda/queue/iosched/fifo_expire_sync
echo 80 > /sys/block/sda/queue/iosched/slice_async
echo 1 > /sys/block/sda/queue/iosched/low_latency
echo 6 > /sys/block/sda/queue/iosched/quantum
echo 5 > /sys/block/sda/queue/iosched/slice_async_rq
echo 3 > /sys/block/sda/queue/iosched/slice_idle
echo 100 > /sys/block/sda/queue/iosched/slice_sync
hdparm -q -M 254 /dev/sda

HDD kutusu için kayda değer, yüksek fifo_expire_async(genellikle yazma) ve slice_synctek bir işlemin yüksek verimlilik elde etmesini sağlamak için uzun süredir ( slice_syncbirden fazla işlemin diskten paralel olarak bazı veriler için beklediği durumlarda vurursanız düşük sayıya ayarlayın ). slice_idleHep HDD'ler için bir uzlaşmadır ama aralığında 3-20 yerde ayarlayarak disk kullanımı ve disk firmware bağlı tamam olmalıdır. Düşük değerleri hedeflemeyi tercih ederim, ancak çok düşük bir değere ayarlamanız veriminizi bozacaktır. quantumAyar throughput çok etkileyen ancak mantıklı düzeyde gecikme tutmak bunu mümkün olduğunca düşük tutmaya çalışın görünüyor. quantumÇok düşük ayar yapmak verimi tahrip eder. 3-8 aralığındaki değerler HDD’lerle iyi çalışıyor gibi görünüyor. Bir okuma için en kötü durum gecikmesi ( quantum* slice_sync) + ( slice_async_rq*slice_async) Eğer çekirdek davranışını doğru anladıysam, ms. Zaman uyumsuz çoğunlukla yazma kullandığı ve diske yazma geciktirmek için istekli beri, hem ayarlanır slice_async_rqve slice_asyncçok düşük sayılar. Bununla birlikte, slice_async_rqçok düşük bir değerin ayarlanması okumaları durdurabilir, çünkü okumalar daha fazla okunduktan sonra geciktirilemez. Ayrıca set güç kaybı üzerinde veri kaybına tahammül beri Benim yapılandırma veri çekirdek geçildikten sonra 10 saniye sonra en fazla diske veri yazmak için çalışıyorum ama olacak fifo_expire_asynckadar 36000001 saat diske gecikme için tamam olduğunu anlatmak için. Sadece slice_asyncdüşük tutun , çünkü aksi halde yüksek okuma gecikmesi elde edebilirsiniz.

hdparmKomut AHCI ve NCQ verir performansın çok öldürmekten AAM önlemek için gereklidir. Diskiniz çok fazla gürültü yapıyorsa, bunu atlayın.

İşte SSD için kurulumum (Intel 320 series):

echo cfq > /sys/block/sdb/queue/scheduler
echo 1 > /sys/block/sdb/queue/iosched/back_seek_penalty
echo 10000 > /sys/block/sdb/queue/iosched/fifo_expire_async
echo 20 > /sys/block/sdb/queue/iosched/fifo_expire_sync
echo 1 > /sys/block/sdb/queue/iosched/low_latency
echo 6 > /sys/block/sdb/queue/iosched/quantum
echo 2 > /sys/block/sdb/queue/iosched/slice_async
echo 10 > /sys/block/sdb/queue/iosched/slice_async_rq
echo 1 > /sys/block/sdb/queue/iosched/slice_idle
echo 20 > /sys/block/sdb/queue/iosched/slice_sync

Burada farklı dilim ayarları için düşük değerleri belirtmekte fayda var. Bir SSD için en önemli ayar slice_idle0-1 olarak ayarlanmalıdır. Sıfıra ayarlanması, tüm sipariş kararlarını yerel NCQ'ya götürürken, 1'e ayarlamak çekirdeğin istek talep etmesine izin verir (ancak NCQ etkinse, donanım çekirdek siparişini kısmen geçersiz kılabilir). Farkı görüp göremediğinizi görmek için her iki değeri de test edin. Intel 320 serisi slide_idleiçin 0, en iyi verimi sağlayacak şekilde ayarlanması , ancak 1en iyi (en düşük) genel gecikmeyle ayarlanması gibi görünüyor .

Bu ayarlar hakkında daha fazla bilgi için, bkz. Http://www.linux-mag.com/id/7572/ .

Şimdi çekirdeği diskten önbelleğe makul bir performansla yükleyecek şekilde yapılandırdığımıza göre, önbellek davranışını ayarlama zamanı:

Yaptığım kıyaslamalara göre, ileriye dönük okuma ayarını hiç rahatsız etmem blockdev. Çekirdek varsayılan ayarları iyi.

Sistemi dosya verilerini uygulama koduyla değiştirmeyi tercih edecek şekilde ayarlayın (bu, tüm dosya sistemini ve tüm uygulama kodunu ve RAM'deki uygulamalar tarafından tahsis edilen tüm sanal belleği saklamak için yeterli RAM'iniz olup olmadığı önemli değildir ). Bu, büyük dosyalara tek bir uygulamadan erişmek için, gecikme yerine farklı uygulamalar arasında geçiş yapma gecikmesini azaltır:

echo 15 > /proc/sys/vm/swappiness

Uygulamaları neredeyse her zaman RAM’de tutmayı tercih ederseniz, bunu 1 olarak ayarlayabilirsiniz. Bunu sıfır olarak ayarlarsanız, OOM’dan kaçınmak için kesinlikle gerekmedikçe çekirdek hiç değişmez. Hafızanız sınırlıysa ve büyük dosyalar (örneğin HD video düzenleme) ile çalışıyorsanız, bunu 100'e yakın ayarlamak mantıklı olabilir.

Bugünlerde (2017), yeterli RAM’iniz varsa, hiçbir takas yapmamayı tercih ediyorum. Takas yapmamak, uzun süre çalışan masaüstü makinede genellikle 200-1000 MB RAM kaybeder. En kötü senaryo gecikmesini önlemek için bu kadarını feda etmeye razıyım (RAM dolduğunda uygulama kodunu değiştirerek). Uygulamada bu, OOM Katilinin değişmesini tercih ettiğim anlamına geliyor. Değişime izin verirseniz / ihtiyaç duyarsanız, /proc/sys/vm/watermark_scale_factorbiraz gecikmeyi önlemek için siz de artırmak isteyebilirsiniz . 100 ve 500 arasında değerler öneririm. Bu ayarı daha düşük takas gecikmesi için alım satım CPU kullanımı olarak düşünebilirsiniz. Varsayılan değer 10 ve mümkün olan maksimum değer 1000'dir. Daha yüksek değer ( çekirdek belgelerine göre ) kswapdişlemler için daha yüksek CPU kullanımı ve daha düşük toplam takas gecikme süresi ile sonuçlanmalıdır .

Daha sonra, çekirdeğe, bazı RAM'lerin serbest bırakılması gerektiğine ilişkin olarak dizin hiyerarşisini bellekte dosya içeriği üzerinde tutmayı tercih etmesini söyleyin (yine de her şey RAM'e uyarsa bu ayar hiçbir şey yapmaz):

echo 10 > /proc/sys/vm/vfs_cache_pressure

Ayar vfs_cache_pressureDüşük değer mantıklıdır, çünkü çoğu durumda çekirdeğin, dizin içeriğini önbellekten gelen dosya içeriğini kullanabilmesi için önce dizin yapısını bilmesi gerekir ve dizin önbelleğini çok kısa sürede temizler, dosya önbelleğini değersiz hale getirir. Çok sayıda küçük dosyanız varsa (sistemimde yaklaşık 150K 10 megapiksel fotoğraf vardır ve "çok sayıda küçük dosya" sistemi olarak sayılır) bu ayarda 1'e kadar inmeyi düşünün. Asla sıfıra ayarlamayın ya da sistem belleği yetersiz olsa bile, dizin yapısı daima bellekte tutulur. Bunu büyük bir değere ayarlamak, yalnızca sürekli olarak yeniden okunmakta olan birkaç büyük dosyanız varsa (yine de yeterli RAM olmadan HD video düzenlemesi örnek bir durum olacaktır). Resmi çekirdek belgelerine göre "

İstisna: gerçekten büyük miktarda dosya ve dizininiz varsa ve vfs_cache_pressure100'den daha yüksek ayarlara sahip tüm dosyalara nadiren dokunuyorsanız / okuyorsanız / listeliyorsanız akıllıca olabilir. Bu, yalnızca yeterli RAM’iniz yoksa ve tüm dizin yapısını RAM’de tutamıyorsa ve normal dosya önbelleği ve işlemleri için hala yeterli RAM’e sahip değilse geçerlidir (örneğin, çok sayıda arşiv içeriğine sahip şirket genelinde dosya sunucusu). vfs_cache_pressure100'ün üstüne çıkmanız gerektiğini düşünüyorsanız, yeterli RAM olmadan çalışıyorsunuz. Artırmak vfs_cache_pressureyardımcı olabilir, ancak tek düzeltici daha fazla RAM elde etmektir. Sonra vfs_cache_pressureyüksek sayıya ayarlayın (yani, gerçekten kötü kötü durum davranıştan kaçınmak ama kötü genel performansı ile uğraşmak zorunda olabilir olduğu) genel daha kararlı bir performansa sahip ortalama performansını feda eder.

Nihayet (için varsayılan yazıyor sürecini yavaşlatan önce RAM% 50'ye varan kullanmak çekirdek yazma için önbellek olarak RAM% 99 kadar kullanabilirsiniz ve talimat çekirdek anlatmak dirty_background_ratioolduğunu 10). Uyarı: Bunu şahsen yapmazdım ama yeterli RAM'e sahip olduğunuzu iddia ettiniz ve veriyi kaybetmeye hazırsınız.

echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio

Ve 1 saat yazma gecikmesinin bile diske bir şeyler yazmaya başlayabildiğini söyle (yine bunu yapmazdım):

echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs

Hepsini koyarsanız /etc/rc.localve sonunda aşağıdakileri eklerseniz , her şey önyüklemeden sonra en kısa sürede önbellekte olur (yalnızca dosya sisteminiz RAM'e gerçekten uyuyorsa bunu yapın):

(nice find / -type f -and -not -path '/sys/*' -and -not -path '/proc/*' -print0 2>/dev/null | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

Ya biraz daha basit bir alternatif olan daha iyi (cache sadece işe yarayabilecek /homeve /usr, eğer sadece bunu sizin /homeve /usrRAM içinde gerçekten fit):

(nice find /home /usr -type f -print0 | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

3
İyi bilgilendirilmiş ve genel olarak kabul edilenden çok daha iyi bir cevap! Bu bir underrated ... Sanırım çoğu insan gerçekten ne yaptıklarını anlamak için zahmet etmeden basit talimatlar istiyorum ...
Vladimir Panteleev

2
@Phpdevpad: Buna ek olarak, soru "RAM kullanımıyla ilgilenmiyorum [...]" demedi - Maemo cihazlarının uygun olduğunu sanmıyorum.
Mikko Rantalainen

1
Noop veya son tarih SSD'ler için daha iyi bir zamanlayıcı değil mi?
rep_movsd

1
@rep_movsd Yalnızca intel SSD sürücüleri kullanıyorum ancak en azından bu sürücüler CFQ gibi daha akıllı zamanlayıcılarla daha iyi bir genel performansa sahip olacak kadar yavaş. SSD sürücünüz 100K'dan fazla rastgele IOPS ile başa çıkabilirse, noop veya son tarih kullanmak hızlı CPU ile bile anlamlı olur. "Hızlı CPU" ile, yalnızca IO için kullanılabilen en az çoklu 3GHz çekirdeğe sahip bir şey demek istiyorum.
Mikko Rantalainen

1
Bu vm ayarlayıcıları hakkında da vm çekirdek dokümanlarından okuyabilirsiniz .
joeytwiddle,

16

Öncelikle, NTFS kullanmaya devam etmenizi önermiyorum, çünkü Linux'ta NTSF uygulaması her zaman performans ve güvenlik sorunu olabilir.

Yapabileceğiniz birkaç şey var:

  • ext4veya gibi daha yeni bazı fs kullanın.btrfs
  • örneğin io planlayıcınızı değiştirmeyi deneyin bfq
  • takas kapat
  • gibi bazı otomatik preloader kullanın preload
  • systemdönyükleme yaparken önyükleme yapmak için kullanmak
  • ... ve daha fazlası

Belki denemek istersiniz :-)


1
Zaten tamamen NTFS'den ext4'e bir kez ext4'e geçtim, sadece NTFS bölümünü Windows sistem bölümü olarak bıraktım. Ancak bu benim için birçok sıkıntı yarattı ve ana veri bölümü (tüm belgelerimi, indirmeleri, projelerimi, kaynak kodumu vb. Depoladığım) dosya sistemi olarak NTFS'ye geri döndüm. Bölümlerimin yapısını ve iş akışımı (daha az Windows kullanmak için) tekrar düşünmekten vazgeçmiyorum ama şu anda NTFS'den vazgeçmek gerçekçi bir seçenek gibi görünmüyor.
Ivan

Verilerinizi Windows içinde de kullanmak zorundaysanız, NTFS tek seçenek olabilir. (Windows'unuzu linux içinde bir VM olarak kullanabiliyorsanız, birçok seçenek kullanılabilir)
Felix Yan

1
Bu sözde problemlerin NTFS'de ne olduğunun bir özeti faydalı olabilirdi.
underscore_d

2
Linux'taki NTFS, performans dışında hemen hemen kabul edilebilir. Sorunun özellikle dosya sistemi performansının iyileştirilmesi ile ilgili olduğu göz önüne alındığında, NTFS, gidecek ilk şey olmalıdır.
Mikko Rantalainen

btrfsSon zamanlarda tasarlanmış bir dosya sistemi olsa da , performansa ihtiyaç duyulursa bundan kaçınırdım. Aksi halde aynı sistemler btrfsve ext4dosya sistemleri kullanıyoruz ve ext4gerçek dünyada büyük bir marjla kazanıyoruz ( aynı performans seviyesinin btrfsyaklaşık 4x CPU zamanı gerektirdiği ext4ve tek bir mantıksal komut için daha fazla disk işlemi gerektirdiği görülüyor ). İş yüküne bağlı olarak, ben öneririm ext4, jfsya xfsherhangi bir performans talep eden iş için.
Mikko Rantalainen

8

Ileride okuyun:

32 bit sistemlerde:

blockdev --setra 8388607 /dev/sda

64 bit sistemlerde:

blockdev --setra 4294967295 /dev/sda

Önbelleğin arkasına yaz:

echo 100 > /proc/sys/vm/dirty_ratio

Bu, boş belleğinizin% 100'ünü yazma önbelleği olarak kullanır.

Veya dışarı çıkıp tmpfs kullanabilirsiniz. Bu, yalnızca yeterince RAM'iniz varsa geçerlidir. Bunu içine koy /etc/fstab. 100G'yi fiziksel RAM miktarıyla değiştirin.

tmpfs /mnt/tmpfs tmpfs size=100G,rw,nosuid,nodev 0 0

Sonra:

mkdir /mnt/tmpfs; mount -a

Sonra / mnt / tmpfs kullanın.


5
3GB veya 2TB okuma hızı? Gerçekten mi? Bu seçeneklerin ne yaptığını biliyor musun?
Cobra_Fast

1
@Cobra_Fast Ne anlama geldiğini biliyor musunuz? Gerçekten hiçbir fikrim yok ve şimdi ilgileniyorum.
syss

3
syss, okuma kafası ayarları, bayt veya bit olarak değil, bellek "blokları" olarak kaydedilir. Bir bloğun boyutu çekirdek derleme zamanında (okuma-bloklar bellek blokları olduğu için) veya bazı durumlarda dosya sistemi oluşturma süresinde belirlenir. Normalde, 1 blok 512 veya 4096 bayt içerir. Bkz. Linux.die.net/man/8/blockdev
Cobra_Fast 15:15

6

blockdev --setra sectors /dev/sda1512 bayt sektörlerde istediğiniz boyutta sektörlerin olduğu okumaya devam etme boyutunu ayarlayabilirsiniz .


2

Katil ayarım çok basit ve çok etkili:

echo "2000" > /proc/sys/vm/vfs_cache_pressure

Çekirdek dokümantasyonundan açıklama :

vfs_cache_pressure

Çekirdeğin, dizin ve inode nesnelerinin önbelleğe alınması için kullanılan belleği geri alma eğilimini kontrol eder.

Vfs_cache_pressure = 100'ün varsayılan değerinde çekirdek, pagecache ve swapcache geri kazanımı ile ilgili olarak, dişçi ve inodeları "adil" bir oranda geri almaya çalışacaktır. Vfs_cache_pressure değerini azaltmak, çekirdeğin dentry ve inode önbelleklerini tutmayı tercih etmesine neden olur. Vfs_cache_pressure = 0 olduğunda, çekirdek bellek basıncı nedeniyle dişçi ve inodeları asla geri kazanmaz ve bu durum bellek yetersizliğine neden olabilir. Vfs_cache_pressure'ın 100'ün üzerine çıkarılması çekirdeğin, dişçi ve inodları geri kazanmayı tercih etmesine neden olur.

vfs_cache_pressure 2000'de, bilgisayar işlemlerinin çoğunun RAM'de gerçekleşmesine ve çok geç disk yazmasına neden olur.


4
vfs_cache_pressureÇok yüksek ayarlamak ( çok yüksek olduğunu düşünürdüm 2000), önbellekte kolayca sığması gereken dizin listeleri gibi basit şeyler için bile gereksiz disk erişimine neden olur. Ne kadar RAM’iniz var ve sistemde neler yapıyorsunuz? Cevabımda yazdığım gibi, bu ayar için yüksek değer kullanmak, örneğin sınırlı RAM ile HD video düzenleme için anlamlıdır.
Mikko Rantalainen

2
Başvurulan belgelerin sürdüğünü unutmayın: " vfs_cache_pressure'ın 100'ün üzerinde önemli ölçüde arttırılması olumsuz performans etkisine neden olabilir. Reclaim kodunun, serbest dizini ve inode nesnelerini bulmak için çeşitli kilitler alması gerekir. Vfs_cache_pressure = 1000 ile, ondan daha serbest nesneler arayacaktır vardır."
Mikko Rantalainen

1

Önbelleğe alma ile ilgili değil, ancak yazılanlarla ilişkili:

  • Bir ext4 sistemi için günlük kaydını tamamen devre dışı bırakabilirsiniz.

    Bu, herhangi bir güncelleme için disk yazma sayısını azaltacaktır, ancak dosya sisteminin beklenmedik bir kapanmadan sonra fsck veya daha kötüsünü gerektiren beklenmedik bir kapanmadan sonra tutarsız bir durumda kalmasına neden olabilir.

Diski durdurmak için okunan disk yazmasını tetikleme:

  • İle monte Relatime veya noatime seçeneği

    Bir dosyayı okuduğunuzda, o dosyanın "son erişilen zaman" meta verileri genellikle güncellenir. noatimeSeçenek o davranışı devre dışı bırakacaktır. Bu gereksiz disk yazmalarını azaltır, ancak artık bu meta verilere sahip olmayacaksınız. Bazı dağıtımlar (örneğin Manjaro) bunu tüm bölümlerde varsayılan olarak benimsemiştir (muhtemelen önceki model SSD'lerin ömrünü artırmak için).

    relatimeatime kullanan uygulamaları desteklemeye yardımcı olan sezgisellere göre erişim süresini daha az günceller. Red Hat Enterprise Linux'ta varsayılandır.

Diğer seçenekler:

  • Yukarıdaki yorumlarda, Mikko nobarrier seçeneğiyle montaj olasılığını paylaştı . Fakat Ivailo , RedHat’a karşı dikkatli davrandı . Bu fazladan% 3'ü ne kadar istiyorsun?
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.