Neden Linux’ta önbellek bırakmalı?


84

Sunucularımızda gece yarısı önbellek bırakma alışkanlığımız var.

sync; echo 3 > /proc/sys/vm/drop_caches

Kodu çalıştırdığımda çok fazla RAM boşalmış gibi görünüyor, ancak gerçekten yapmam gerekiyor mu? Ücretsiz RAM boşa gitmiyor mu?


62
Bunu yapan kişiyi bul ve neden yaptığını sor. Doğru tahmin ettiğiniz gibi, bunun için açık bir sebep yok.
Michael Hampton

10
Çekirdeğin hata ayıklaması. Bu konuda. Bu aslında herhangi bir RAM'i boşaltmaz; adından da anlaşılacağı gibi önbellekleri bırakır ve böylece performansı azaltır.
Michael Hampton

28
@ iVcode O zaman, sorunu neden olan koşullardan kaçınmaya çalışmak yerine o sunucudaki sorunu bulmalı ve çözmelisiniz. Otomobilim her seferinde keskin bir sağa dönüş yaptığımda, sağa keskin dönüşlerden kaçınmak berbat bir çözüm.
David Schwartz

7
İlgili thedailywtf.com/Articles/Modern-Memory-Management.aspx Kesinlikle kötü bir fikir olduğunu savunarak.
Drunix

7
İlgili ve "sorunun" yararlı bir açıklaması: linuxatemyram.com
Bill Weiss

Yanıtlar:


86

% 100 haklısın. Öyle değil RAM boşaltmak için iyi bir uygulama. Bu muhtemelen bir kargo kült sistemi yönetimine bir örnektir.


9
Cargo Cult System Administration'dan bahsettiğin için +1. Bu terimi ve ne anlama geldiğini bilmeyen herhangi bir sysadmin kovulmalıdır.
Tonny

8
@Tonny: O zaman sysadmin departmanı olmadan
kalırdık

2
İnsanlığın çoğunda olduğu gibi, çok fazla onayı olan vahşice iddiaları severim, ama bir alıntı veya muhakeme süperego'nun + 1'lerini kazanır.
Aaron Hall

2
Sakıncası yoksa, kargo kültü idaresinin yanı sıra yukarıdakileri de açıklayın. Belki bir takip düzenlemesinde? Hala +
Aaron Hall

2
"Uygulamanız bu RAM'i kullanmasa da, ancak Linux hafızasına saldırgan bir şekilde önbelleğe giriyor olsa da ve uygulama belleği gerektirse de, bu önbelleğin bir kısmını serbest bırakmayacak ancak değişmeye başlayacaktır." Çok spesifik değil. Uygulamada, hafıza yönetimi mükemmel değildir ve bu kusurun ortaya çıkması durumunda dönecek bir topuzu olması iyi bir şeydir.
Dan Pritts,

62

Evet, önbelleği temizlemek RAM'i boşaltacaktır, ancak çekirdeğin önbellek yerine diskte dosya aramasına neden olur ve bu da performans sorunlarına neden olabilir.

Normalde, kullanılabilir RAM tükendiğinde çekirdek önbelleği temizler. Kirli içeriği pdflush kullanarak diske sık sık yazar.


20
Neden kötü bir fikir olduğunu açıklamak için + 1 .
Ogre Mezmurlar33

35

Bu tür önbellekleri düşürmenin nedeni disk performansını ölçmek içindir ve bunun tek nedeni budur.

Yoğun bir G / Ç kıyaslaması yaparken, denediğiniz çeşitli ayarların aslında disk G / Ç işlemi yaptığından emin olmak istersiniz; bu nedenle Linux, önyükleme yapmak yerine önbellekleri bırakmanıza izin verir.

Dan alıntı belgeler :

Bu dosya, çeşitli çekirdek önbelleklerinin büyümesini kontrol etmek için bir araç değildir (inode, diş macunu, pagecache vb.) Bu nesneler, sistemin başka bir yerinde belleğe ihtiyaç duyulduğunda, çekirdek tarafından otomatik olarak geri kazanılır.

Bu dosyanın kullanımı performans sorunlarına neden olabilir. Önbelleğe alınmış nesneleri attığı için, özellikle yoğun kullanımda olsalar, bırakılan nesneleri yeniden oluşturmak için önemli miktarda G / Ç ve CPU'ya mal olabilir. Bu nedenle, test etme veya hata ayıklama ortamı dışında kullanılması önerilmez.


Tabii ki, ne yapmaya çalıştığınıza bağlı olarak, tam bir yeniden başlatma bile disk önbelleğini yeterince temizlemeyebilir.
bir CVn

1
Tasarım amacı "Bu nesneler bellek gerektiğinde otomatik olarak çekirdek tarafından geri kazanılır" ancak tasarım her zaman gerçek davranış olmayabilir.
Dan Pritts,

@DanPritts Tam olarak öyle olmadığını düşündüren nedir?
Joe

2
Açık olan durum, daha fazla (saydam olmayan) hugepage yerleştirilmesine izin vermek için RAM’i silmek istediğinizde; Başka bir durum ise şeffaf hugepage çöp toplama duraklama böcekleridir (bu sorudaki cevaplarıma / yorumlarıma bakınız). Ancak benim yorumum genel dava için düşünülmüştü. Bazen sistemi işleten insanlar, onu tasarlayan / uygulayan insanlardan daha iyi bilirler. Genelde, hayır - yorumlarının buna karşı koruma sağlamaya çalıştığı şey budur. Sadece sevindim
Dan Pritts

26

Buradaki temel fikir muhtemelen o kadar da kötü değil (sadece çok saf ve yanıltıcı): Önbelleğe alınmış, yakın bir gelecekte erişilebilecek gibi görünmeyen dosyalar olabilir, örneğin günlük dosyaları. Bu “yemek” koçu, daha sonra işletim sistemi tarafından gerektiğinde bir şekilde veya başka bir şekilde serbest bırakılması gerekecek.

Değişim ayarlarınıza, dosya erişim düzeninize, bellek ayırma düzeninize ve daha pek çok tahmin edilemeyeceğiniz şeylere bağlı olarak, bu önbellekleri serbest bırakmadığınızda, daha sonra tekrar kullanılmaya zorlanacakları anlaşılabilir. kullanılmayan hafıza havuzundan hafıza ayırma. En kötü durumda, linux'un takas ayarları program belleğinin değiştirilmesine neden olacaktır, çünkü linux bu dosyaların program belleğinden daha yakın bir zamanda kullanılabileceğini düşünüyor.

Benim çevremde, linux oldukça sık yanlış tahmin ediyor ve çoğu Avrupa borsalarının başında (yaklaşık 0900 yerel saate kadar) sunucular, günde yalnızca bir kez yaptıkları şeyleri yapmaya başlayacaklar; kütük dosyaları, bunları sıkıştırmak, kopyalamak vb. şeylerin değiştirilmesi gereken noktaya önbellek dolduruyordu.

Ancak bırakma, bu sorunun çözümünü önlüyor mu? kesinlikle değil. Buradaki çözüm, linux'a bilmediklerini söylemektir: bu dosyaların artık kullanılmayacağını. Bu, yazma gibi posix_fadvise()bir şey kullanarak veya bir cmd satırı aracı kullanarak vmtouch(önbellek dosyalarının yanı sıra nesnelere bakmak için de kullanılabilir) kullanılarak yazma uygulaması ile yapılabilir .

Bu şekilde, artık gerekmeyen verileri önbellekten kaldırabilir ve önbelleğe alınması gerekenleri saklayabilirsiniz, çünkü tüm önbellekleri bıraktığınızda, diskten çok fazla şey okunması gerekir. Ve bu mümkün olan en kötü anda: gerektiğinde; Uygulamanızda fark edilir ve genellikle kabul edilemez olan gecikmelere neden olabilir.

Yapmanız gereken şey, bellek kullanım düzenlerinizi izleyen (örneğin, bir şey değişiyorsa) ve ardından buna göre analiz eden ve buna göre davranan bir sistemdir. Çözüm, vtouch kullanarak günün sonunda bazı büyük dosyaları çıkarmak olabilir; Sunucunun günlük yoğun kullanımı tam da bu olduğundan daha fazla ram eklemek de olabilir.


Sunucumdaki tüm uygulamalar nohup'ta çalışıyor. Belki de nohup.out önbellekte saklanıyor ve hafızayı yiyor?
ivcode

@ivcode: Bu bir neden olabilir, nohup.out'un ne kadar büyük olduğunu kontrol edin. Belki ne kadarının önbellekte saklandığını bulmak için vmtouch kullanın.
PlasmaHH

cat /dev/null > path/nohup.outNohup.out hızla büyüdükçe her 15 dakikada bir cron işim var . Belki linux temizlememe rağmen nohup.out'u önbelleğe alıyordur
ivcode

5
@ivcode Sizden çıktıya ihtiyacınız nohupyoksa, yeniden yönlendirmeniz gerekir /dev/null. Bir noktada sistemlerinizde çalışan çok deneyimsiz bazı sistem yöneticileriniz var gibi gözüküyor. Bkz stackoverflow.com/questions/10408816/... yönlendirmek için nasıl nohup'ın çıkış için/dev/null
David Wilkins

nohup.out 15 dakikalık aralıklarla silinmesine rağmen, uygulamaların bir nedenden dolayı öldürülmesi durumunda, nohup.out başka bir komut dosyasından otomatik olarak yedeklenecektir. Vmtouch'u denedim. Gerçekten de çok iyi bir araç
ivcode

16

Bir sürü sanal makineyi başlatırken yararlı olacak önbellekleri gördüm. Veya bazı veritabanı sunucuları gibi Büyük Sayfaları kullanan herhangi bir şey.

Linux'taki Büyük Sayfalar, bir sayfaya koymak için 2 MB bitişik fiziksel RAM bulmak için RAM'i birleştirmek zorundadır. Tüm dosya önbelleğini boşaltmak bu işlemi çok kolaylaştırır.

Ancak diğer cevapların çoğuna katılıyorum, çünkü her gece dosya önbelleğini bırakmak için genellikle iyi bir neden yoktur.


1
İkinci dereceden önyargının, önbelleklere verilen tepkiler olduğunu belirtti.
Noah Spurrier

1
Ayrıca, yüksek bellek düğümlerindeki (1Tb) HPC uygulamalarında, birkaç büyük dosyayı okumak, büyük miktarda belleğin önbelleğe alınmasına neden olur. Birçok HPC uygulaması, yüzlerce GB malloc'ları gerçekleştirdiğinden, sistem önbelleğe alınmış bellek "sınırına" ulaştıktan sonra, geçiş işlemleri NUMA düğümleri boyunca meyvesiz olarak küçük parçalanmış bellek parçalarını hareket ettirdikçe sistem saatlerce durur. Daha da kötüsü, kullanıcılara yapabileceğiniz önbellekleri boşaltmak için yapabileceğiniz hiçbir şey, sistemi bir kerede serbest bırakıp, dolaştırılan birleştirme ve uygulamaların normal şekilde çalışmasına izin vererek tüm küçük 2 MB'lık blokları tahsis etmelerini sağlamaktır.
user1649948

+1 Büyük sayfalar oluşturma ( sysctl -w vm.nr_hugepages=...) komutu, ilk önbellekleri bırakmadığım sürece bile çalışmayı reddediyor (Arch linux).
Aleksandr Dubinsky,

8

Bunun sorunu çözecek beceri veya deneyime sahip hiç kimsenin olmadığı durumlarda sistemi dengelemenin bir yolu olarak kullanılması mümkündür.

Kaynakları serbest bırakma

Bırakma önbellekleri temel olarak bazı kaynakları serbest bırakacaktır, ancak bunun, sistemin gerçekten yapmaya çalıştığı şeyi yapmak için daha çok çalışmasını sağlama yan etkisi var. Sistem değişiyorsa (disk takma bölümünden gerçekten daha hızlı bir şekilde okumaya ve yazmaya çalışarak), önbellekleri düzenli aralıklarla bırakmak, semptomları hafifletebilir , ancak nedeni düzeltmek için hiçbir şey yapmaz .

Hafızadan ne yiyor?

Düşen önbelleklerin işe yaradığını gösteren çok fazla hafıza tüketimine neyin neden olduğunu belirlemelisiniz. Bu, kötü yapılandırılmış herhangi bir sayıda veya yanlış kullanılan sunucu işlemlerinden kaynaklanabilir. Örneğin, bir sunucuda bir Magento web sitesi 15 dakikalık bir süre içinde belirli sayıda ziyaretçiye ulaştığında en fazla bellek kullanımına tanık oldum. Bu, Apache'nin aynı anda çok fazla işlemin çalışmasına izin verecek şekilde yapılandırılmasından kaynaklandı. Çok fazla bellek kullanarak çok fazla işlem (Magento bazen bir canavardır) = değiş tokuş.

Alt çizgi

Sadece gerekli bir şey olduğunu varsaymayın. Neden orada olduğunu bulma konusunda proaktif olun, diğerleri yanlış olduğunu söylerse onu etkisiz hale getirme cesaretini alın ve sistemi gözlemleyin - asıl sorunun ne olduğunu öğrenin ve düzeltin.


4

Linux / m68k aslında kswapd'ın çılgına dönmesine ve% 100 CPU (% 100 başka CPU işlemine bağlı bir işlem varsa,% 50 gibi), Debian ikili paket autobuilder - vulgo buildd - çalışıyor gibi) çağırabilen bir çekirdek böceğine sahiptir (çoğu zaman zaman; her zaman değil) bu komutu çalıştırarak her birkaç saatte bir azaltılabilir.

Söyleniyor… sunucunuz bir m68k değil (Atari, Amiga, Klasik Macintosh, VME, Q40 / Q60, Sun3) sistemi ;-)

Bu durumda, satırları sıraya koyan kişi ya biraz sorgulanabilir ya da en iyi ihtimalle modası geçmiş bir tavsiyede bulundu ya da RAM'in nasıl yanlış kullanılması gerektiği konusunda fikir sahibi oldu (modern düşünce gerçekten de “serbest RAM RAM israfı” diyor ve önbelleklemeyi öneriyor) , veya “başka bir problemin başka bir sorunu“ çözdüğünü ”(“ uygun bir çözüm bulmak için çok tembeldi ”) keşfetti.


"kswapd'ın delirmesine neden olan bir çekirdek hatası" - Hangi hata bu?
Ben

@Ben bu konuyu gör (bu mesaj ve bunlardan biri nereden gelebileceğini bir tahmin içeren bir kaç takip, birkaç kişi)
mirabilos

1
Benzer bir sorun yaşıyorum (her ne kadar x86_64 olsa da) ve şu andaki tek çözüm önbellekleri düşürmek için serverfault.com/questions/740790/…
Fernando

2
@Fernando Ben de m68k kutusunda bir "damla önbellek" cronjob var ☹
mirabilos

3

Bunun bir nedeni, site, serbest ram miktarını kontrol eden ve serbest ram belirli bir yüzdesinin altına düştüğünde yöneticilere bir uyarı gönderen bir tür izleme çalıştırması olabilir. Bu izleme aracı serbest ram hesaplamasına önbellek eklenmeyecek kadar aptalsa, yanlış uyarılar gönderebilir; Önbelleğin düzenli olarak boşaltılması bu uyarıları bastırabilirken, aynı zamanda aletin "gerçek" tokmak ne zaman azaldığını fark etmesini sağlar.

Tabii ki, bu tür durumlarda, gerçek çözüm izleme aracını serbest ram hesaplamasına önbellek içerecek şekilde değiştirmek; önbelleğin temizlenmesi yalnızca bir geçici çözüm ve aynı zamanda kötü bir durumdur, çünkü işlemler diske eriştiğinde önbellek hızla dolar.

Bu yüzden benim varsayım doğruysa bile, önbellek temizliği mantıklı bir şey değil, daha çok birincil sorunu çözecek kadar yetkin olmayan bir kişi için geçici bir çözüm.


3

Her gece bir cron işinde bunu yapmak için makul bir neden düşünebilirim.

Büyük bir sistemde, düzenli aralıklarla önbellekleri düşürmek yararlı olabilir, böylece bellek parçalanmasını kaldırabilirsiniz.

Çekirdek saydam hugepage desteği, küçük sayfaları hugping'lerde birleştirmek için düzenli aralıklarla bellek taraması yapar. Dejenere koşullar altında bu, bir iki dakika kadar sistem duraklamalarına neden olabilir (bununla ilgili deneyimim RHEL6'daydı; umarım geliştirilmiştir). Bırakma önbellekleri, sarmal sayfası süpürücüsünün çalışacak bazı odalarının olmasına izin verebilir.

Bunun, şeffaf sargıları devre dışı bırakmak için iyi bir neden olduğunu iddia edebilirsiniz; OTOH, şeffaf sarf malzemelerinin genel performans geliştirmesinin, önbelleklerinizi günde bir kez kaybetmenin bedelini ödemeye ve değer vermeye değer olduğuna inanabilirsiniz.


Bir cron işinde olmasa da, yapmak istemeniz için başka bir neden düşündüm. Sanallaştırma sistemi bir VM'yi yeni donanıma geçirmeden hemen önce bunun için çok iyi bir zaman olurdu. Yeni ana bilgisayara kopyalamak için daha az bellek içeriği. Sonunda tabii ki, depodan okumak zorunda kalacaksınız, ama muhtemelen bu tradeoffu alırdım.

Gerçekten herhangi bir yazılımın bunu gerçekten yapıp yapmadığını bilmiyorum.


1
Bunun için herhangi bir kaynağınız var mı? Bu, eğer böyle bir sorun olursa, çekirdekte sabitlenmesi gereken bir şeye benziyor.
Ocak'ta

3
Şeffaf hugepages durakları ile kişisel deneyimim var. RHEL6, Dell R810, 4CPU'lar, 64 GB RAM. Şeffaf sargıları devre dışı bırakmak (bunu yapmak için bir / proc dosyası vardır) duraklamaları hemen düzeltti. O zaman önbellek bırakma tekniğini denemedim; bunun yerine java uygulamalarımızı şeffaf olmayan hugpe'ları kullanacak şekilde yeniden yapılandırdım ve şeffaf hugepage'leri devre dışı bıraktım. IIRC, etkilenen tek insan olmadığımızı ve Red Hat'ın sorunu bildiğini anlamaya yetecek duruma baktık.
Dan Pritts,

Merhaba Dan, sunucumda aynı davranışı yapıyorum. Çok fazla miktarda veriyle çalışıyorum ve aynı python programının 10+ hesaplamasından sonra (ilk hesaplama süresinin x2-3'ü) şiddetli bir performans düşüyor. Bakarsam, bellek önbellek büyüklüğü 100 + GB'dir. Bu bellek önbelleğini temizler ve programımı yeniden çalıştırırsam, ilk hesaplama zamanımı geri alırım. Bu fenomen hakkında paylaşmak için herhangi bir belge veya bilginiz var mı? Teşekkür ederim.
Axel Borja

1
access.redhat.com/solutions/46111 bunu açıklar. Bu durumda sorun olup olmadığını görmek için şeffaf sarmalları devre dışı bırakabilirsiniz.
Dan Pritts

2

Sadece iki kuruş eklemek için: Sistem bu hafıza sayfalarının önbellek olduğunu çok iyi biliyor ve bir uygulama hafıza istediğinde istediği kadar düşecek.

/proc/sys/vm/swappinessYeni bir bellek tahsisi sırasında çekirdeğe bellek önbelleklerini bırakmayı veya "boşta" ayrılmış bellek sayfalarını değiştirmeyi tercih etmelerini söyleyen ilgili bir ayardır .


1

Soru 2014'ten itibaren, ancak sorun şu ana kadar bazı gizli centos 6.8 arka uçlarında mevcut olduğu için, yine de birisi için yararlı olabilir.

https://github.com/zfsonlinux/zfs/issues/1548 , zfs ile ilgili bir sorunu anlatıyor. Orada, disk alanı silinmiş dosyalar için boş bırakılmaz, çünkü eğer nfs kullanılırsa, dosyanın inode'ları çekirdeğin inode önbelleğinden çıkarılmaz.

Böcek parçasından alıntı yapmak için, 6 Ocak 2015 behlendorf yazdı:

Mevcut spekülasyon, bir nedenden dolayı NFS sunucusunun dosya tanıtıcısının önbelleğe alınmış bir versiyonunu tutuyor olmasıdır. NFS sunucusu bu dosyadan çıkana kadar ZFS bu dosyanın bağlantısını kaldıramaz. Bazı ışık testleri, sunucudaki bırakma önbelleklerinin, bu referansın, alanın doğru bir şekilde serbest bırakıldığı noktada bırakılmasına (NFS dosya tanıtıcısı gibi) neden olacağını göstermiştir. Bellek basıncı da düşmesine neden olabilir.

yani, her gece yankı 3> / proc / sys / vm / drop_caches, zfs'nizi yeniden yapılandırmak için bir zamanınız kalmasını istemiyorsanız, bu hata için en kolay çözümdür.

Bu yüzden belki kargo kültü idare etmiyor olabilir, ancak bazı iyi hata ayıklama sebepleriydi.


0

Bu, tipik olarak her bir CPU'nun (soketin) tüm belleğe şeffaf bir şekilde erişebildiği, ancak kendi belleğine, paralel HPC uygulamalarıyla bağlantılı olarak diğer soketin belleğinden daha hızlı bir şekilde erişilebildiği NUMA (düzgün olmayan bellek erişimi) sistemlerinde anlamlı olabilir.

Birçok basit paralel uygulama, tek bir işlemden dosya G / Ç yapma eğilimindedir, bu nedenle çıkışta disk önbelleğine ayrılan tek bir NUMA düğümü üzerinde büyük bir bellek bölümü bırakılırken, diğer NUMA düğümü üzerinde bellek çoğunlukla serbest olabilir. Bu durumlarda, bildiğim kadarıyla, Linux çekirdeğindeki önbellek geri alma işlemi hala NUMA farkında olmadığından, önbellek için ayrılmış belleği olan NUMA düğümünde çalışan işlemler diğer NUMA düğümüne bellek ayırmak zorunda kalır. diğer düğümde boş RAM olduğu sürece, performansları öldürür.

Ancak, bir HPC sisteminde, cron ile belirli bir zamanda değil, yeni bir kullanıcı işine başlamadan önce önbelleği temizlemek daha akıllıca olacaktır.

Paralel olmayan uygulamalar için bu sorunun ortaya çıkması muhtemel değildir.


0

Sayfa önbelleğiniz oldukça büyük olduğunda (geçerli takas kullanımınızdan çok daha büyük) ve takas ve takas işlemleri sırayla gerçekleşir, bu, önbellekleri bırakmanız gereken zamandır. Ubuntu 16.04LTS çalıştıran MariaDB veritabanı sunucularımdan birinde bellek kullanımının arttığı, Linux ise kullanılmayan sayfa önbelleklerini kaldırmak yerine takas kullanımını arttırmayı seçti. TokuDB devre dışı bırakılmasını gerektirdiği için şeffaf sarmallar sistemimde zaten devre dışı bırakıldı. Her neyse, belki bir hata değil, ama linux hala bu davranışı yapmak benim için oldukça kafa karıştırıcı. Çeşitli kaynaklar, Linux'un uygulama istediğinde sayfa önbelleğini kaldıracağını belirtti:

Ancak gerçek bu kadar basit değil. Geçici çözüm ya:

  1. Bırakma önbelleğini düzenli aralıklarla yürütün
  2. Gerektiğinde bırakma önbelleğini yürütün (etkinlikleri değiştirmek için vmstat 1 kullanarak izleyin)
  3. Dd veya python-fadvise gibi yardımcı programları kullanarak belirli dosyaları önbellekten (apache günlük dosyaları gibi) kaldırmak için linux'a danışın. Bkz. Https://unix.stackexchange.com/questions/36907/drop-a-specific-file-from-the-linux-filesystem-cache

Örnek dd çalışması:

dd if=/var/log/apache2/access_log.1 iflag=nocache count=0

Örnek python-fadvise:

pyadvise -d /var/log/apache2/access_log.1


-5

PAE çekirdeğinde 16GB RAM çalışan bir masaüstü makinem var. Bir ya da iki saat sonra disk performansı, önbellekleri bırakana kadar çarpıcı bir şekilde düşer, bu yüzden basitçe cron'a koyarım. Bunun PAE çekirdeği ile mi yoksa önbellek uygulamasının çok fazla bellek varsa yavaş kalmasıyla ilgili bir sorun mu olduğunu bilmiyorum.


9
Bu, "kargo kültü" sistem yönetiminin en önemli örneği: sorunu bulmak ve çözmek yerine, basitçe maskeliyorsunuz.
Michael Hampton

2
Bazen uygun çözüm doğru olanıdır. Sadece asıl sorunun çözülmesini önlüyor olabilir ya da bu şartlarda gerektiği kadar çözüm olabilir. Kötü bir uygulama olsa bile, hala "kargo kültü" değil. Gösterilmiş bir sebep ve sonuç var: bırakma önbellekleri ve disk performansı iyileşir.
Dan Pritts,

1
CCSA'nın orijinal tanımının bir kısmı nedensellik için korelasyonu yanlışlama eğilimindeydi ve işte buradayız. İlişkili olan ancak nedensel olmayan bir varlığa değinerek bir problemi maskeleme, en alt düzeyde problem çözmedir; bu, CCSA kavramını neye karşı uyarmaya çalıştığıdır.
underscore_d
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.