Java uygulaması performans ayarlama uygulaması
Java uygulamalarının daha hızlı çalışmasını sağlayın: performans ayarlama araçları ve uygulamaları
Java uygulama performans optimizasyonu yaygın bir konudur.Tipik performans sorunları arasında yavaş sayfa yanıtı, arayüz zaman aşımı, yüksek sunucu yükü, düşük eşzamanlılık ve sık veritabanı kilitlenmeleri bulunur. Özellikle günümüzün "kaba, hızlı ve şiddetli" İnternet geliştirme modelinde, artan sistem ziyaretleri ve şişirilmiş kodlarla birlikte çeşitli performans sorunları ortaya çıkmaya başlamıştır. Java uygulama performansında disk, bellek, ağ G / Ç, Java uygulama kodu, JVM GC, veritabanı, önbellek vb. Gibi sistem faktörleri gibi birçok darboğaz vardır. Yazar, kişisel deneyime dayanarak, Java performans optimizasyonunu 4 seviyeye ayırır: Şekil 1'de gösterildiği gibi uygulama katmanı, veritabanı katmanı, çerçeve katmanı ve JVM katmanı.
Şekil 1. Java performans optimizasyonu katmanlı model
Her bir optimizasyon seviyesinin zorluğu adım adım artar ve ilgili bilgi ve çözülecek problemler farklı olacaktır. Örneğin, uygulama katmanının kod mantığını anlaması ve Java iş parçacığı yığını aracılığıyla sorunlu kod satırlarını bulması gerekir; veritabanı katmanının SQL'i analiz etmesi ve kilitlenmeleri bulması gerekir; çerçeve katmanının kaynak kodunu ve çerçeve mekanizmasını anlaması gerekir; JVM katmanının GC'nin türünü ve çalışmasını anlaması gerekir Mekanizma derinlemesine bir anlayışa sahiptir ve çeşitli JVM parametrelerinin etkisi açıktır.
Java performans optimizasyonu etrafında iki temel analiz yöntemi vardır: yerinde analiz ve analiz sonrası. Yerinde analiz yöntemi, siteyi korumak ve ardından konumu analiz etmek için teşhis araçlarını kullanmaktır. Yerinde analizin çevrimiçi üzerinde daha büyük bir etkisi vardır ve bazı senaryolar (özellikle kullanıcıların önemli çevrimiçi işleri dahil olduğunda) uygun değildir. Analiz sonrası yöntem, mümkün olduğunca fazla alan verisi toplamalı ve ardından post mortem analizi ve toplanan saha verilerinin yeniden üretimini gerçekleştirirken hemen hizmete devam etmelidir. Performans teşhis aracından başlayalım ve Sogou'nun ticari platformunun bazı vakalarını ve uygulamalarını paylaşalım.
Performans teşhis aracı
Performans teşhisinin bir türü, performans sorunları olduğu belirlenen sistemleri ve kodları teşhis etmek, diğeri ise performansın lansmanın gereksinimlerini karşılayıp karşılamadığını belirlemek için başlatma öncesi sistemin erken performans testini yapmaktır. Bu makale birincisine odaklanır, ikincisi bu makalenin kapsamı dışında kalan çeşitli performans stres ölçüm araçlarıyla (JMeter gibi) test edilebilir. Java uygulamaları için, performans teşhis araçları esas olarak iki katmana ayrılır: İşletim sistemi seviyesi ve Java uygulama seviyesi (uygulama kodu teşhisi ve GC teşhisi dahil).
İşletim sistemi teşhisi
İşletim sistemi teşhisi temel olarak CPU, Bellek ve G / Ç'nin üç yönüne odaklanır.
CPU teşhisi
CPU için ana sorun, Ortalama Yük, CPU kullanımı ve bağlam anahtarlarının sayısıdır (Bağlam Anahtarı).
Sistemin ortalama yükünü ve CPU kullanımını üst komut aracılığıyla görüntüleyebilirsiniz Şekil 2, üst komut aracılığıyla bir sistemin durumunu gösterir.
Şekil 2. top komutu örneği
Ortalama yükün üç sayısı vardır: 63.66, 58.39, 57.18, makinenin sırasıyla son 1 dakika, 5 dakika ve 15 dakika içindeki yükünü temsil eder. Deneyimlere göre, değer 0.7 * CPU sayısından küçükse, sistem normal çalışır; bu değeri, hatta CPU çekirdek sayısının dört veya beş katını aşarsa, sistem yükü önemli ölçüde daha yüksek olacaktır. Şekil 2'de 15 dakikalık yük 57.18'e ulaşmıştır ve 1 dakikalık yük 63.66'dır (sistemde 16 çekirdek vardır), bu da sistemin bir yük sorunu olduğunu ve daha da yükselen bir eğilim olduğunu gösterir.Özel sebebin bulunması gerekmektedir.
Şekil 3'te gösterildiği gibi, vmstat komutu aracılığıyla CPU'nun bağlam anahtarlarının sayısını görüntüleyebilirsiniz:
Şekil 3. vmstat komutu örneği
Bağlam anahtarlarının sayısının meydana geldiği senaryolar esas olarak aşağıdaki gibidir: 1) Zaman dilimi kullanılır ve CPU normal olarak sonraki görevi planlar; 2) Daha yüksek önceliğe sahip diğer görevler tarafından önceliklendirilir; 3) Yürütme görevi, G / Ç engellemeyle karşılaşır ve kilitlenir. Mevcut görevi başlatın ve bir sonraki göreve geçin; 4) Kullanıcı kodu, CPU'dan vazgeçmek için mevcut görevi aktif olarak askıya alır; 5) Çok görevli, yakalanmadıkları için askıya alınan kaynakları önceden kullanır; 6) Donanım kesintileri. Java iş parçacığı bağlamı değiştirme, esas olarak paylaşılan kaynaklar için rekabetten gelir. Genel olarak, tek bir nesne kilidi, kilit ayrıntı düzeyi çok büyük olmadığı sürece nadiren bir sistem darboğazı haline gelir. Bununla birlikte, sıklıkla erişilen ve birden çok nesneyi sürekli olarak kilitleyen bir kod bloğunda çok sayıda bağlam anahtarı oluşabilir ve bu da bir sistem darboğazı haline gelir. Örneğin, sistemimizde log4j 1.x, büyük eşzamanlılık, sık bağlam değiştirme, çok sayıda iş parçacığı engelleme altında çok sayıda günlük yazdırdı, bu da sistem veriminde önemli bir düşüşe neden oldu, ilgili kod Liste 1'de gösteriliyor, Log4j 2.x bu sorunu yalnızca çözdü.
Liste 1. Log4j 1.x senkronizasyon kodu pasajı
for (Kategori c = this; c! = null; c = c.parent) {
// addAppender, removeAppender, ... için eşzamanlı çağrıya karşı korumalı
senkronize (c) {
eğer (c.aai! = null) {
+ = c.aai.appendLoopAppenders (olay) yazın;
}
}
}
Hafıza
İşletim sistemi perspektifinden, bellek, uygulama işleminin yeterli olup olmadığı ile ilgilenir Bellek kullanımını görüntülemek için free -m komutunu kullanabilirsiniz. Top komutu, işlem tarafından kullanılan sanal bellek VIRT ve fiziksel bellek RES'i görüntülemek için kullanılabilir.VIRT = SWAP + RES formülüne göre, belirli uygulama tarafından kullanılan takas bölümü (Takas) hesaplanabilir. Takas bölümünün aşırı kullanımı Java uygulamalarının performansını etkileyecek ve takas özelliğini azaltabilir Değeri olabildiğince küçük ayarlayın. Çünkü Java uygulamaları için çok fazla takas bölümü kullanmak performansı etkileyebilir, sonuçta disk performansı bellekten çok daha yavaştır.
G / Ç
G / Ç, disk G / Ç ve ağ G / Ç'yi içerir. Genellikle, diskler G / Ç darboğazlarına daha yatkındır. İostat aracılığıyla disk okuma ve yazma durumunu görüntüleyebilir ve CPU G / Ç beklemesi aracılığıyla disk G / Ç'sinin normal olup olmadığını görebilirsiniz. Disk G / Ç'si her zaman yüksek durumda ise bu, diskin çok yavaş veya arızalı olduğu, bu da bir performans darboğazına dönüştüğü ve uygulama optimizasyonu veya disk değişiminin gerekli olduğu anlamına gelir.
Yaygın olarak kullanılan top, ps, vmstat, iostat ve diğer komutlara ek olarak, mpstat, tcpdump, netstat, pidstat, sar, vb. Gibi sistem sorunlarını teşhis edebilen başka Linux araçları da vardır. Brendan, referans için Şekil 4'te gösterildiği gibi, farklı Linux cihaz türleri için performans teşhis araçlarını özetledi ve listeledi.
Şekil 4. Linux performans gözlem aracı
Java uygulaması teşhis aracı
Uygulama kodu teşhisi
Uygulama kodu performans sorunları, çözülmesi görece kolay olan bir tür performans sorunlarıdır. Bazı uygulama düzeyinde izleme alarmları aracılığıyla, sorunlu işlevi ve kodu belirlerseniz, doğrudan kod aracılığıyla veya top + jstack aracılığıyla, sorunlu iş parçacığı yığınını, sorunlu iş parçacığının kodunu ve sorunu da bulabilirsiniz. Daha karmaşık ve mantıksal kod bölümleri için, Kronometre aracılığıyla performans günlüklerini yazdırmak çoğu zaman uygulama kodu performans sorunlarının çoğunu bulabilir.
Yaygın olarak kullanılan Java uygulaması teşhisi, iş parçacığı, yığın, GC vb. Tanılamayı içerir.
jstack
Jstack komutu genellikle top ile bağlantılı olarak kullanılır.Java süreçlerini ve iş parçacıkları bulmak için top -H -p pid kullanır ve ardından iş parçacığı yığınını dışa aktarmak için jstack -l pid kullanır. İş parçacığı yığını geçici olduğundan, birden çok döküm gerektirir, genellikle 3 döküm, genellikle her 5 saniyede bir. Java iş parçacığı yığınındaki nid'i elde etmek için üstte bulunan Java iş parçacığı pidini onaltılıya dönüştürün ve karşılık gelen sorunlu iş parçacığı yığınını bulabilirsiniz.
Şekil 5. Üst -H -p aracılığıyla daha uzun çalışan Java iş parçacıklarını görüntüleyin
Şekil 5'te gösterildiği gibi, 24985 iş parçacığı uzun bir çalışma süresine sahiptir ve sorunları olabilir Onaltılık düzeye dönüştürdükten sonra, Şekil 6'da gösterildiği gibi sorunu bulmak için Java iş parçacığı yığınında karşılık gelen 0x6199 iş parçacığının yığınını aşağıdaki gibi bulun.
Şekil 6. jstack görünümü iplik yığını
JProfiler
JProfiler, CPU, yığın ve belleği analiz edebilir ve Şekil 7'de gösterildiği gibi güçlüdür. Aynı zamanda, stres testi araçlarıyla birlikte, zaman alan kod örnekleme istatistiklerini toplayabilirsiniz.
Şekil 7. JProfiler ile bellek analizi
GC teşhisi
Java GC, programcıların belleği yönetme riskini çözer, ancak GC'nin neden olduğu uygulama askıya alma, çözülmesi gereken başka bir sorun haline gelir. JDK, GC sorunlarını bulmak için bir dizi araç sağlar. Daha yaygın olarak kullanılanlar jstat, jmap ve üçüncü taraf araçları MAT'dir.
jstat
Jstat komutu, GC ayrıntılı bilgilerini, Genç GC ve Tam GC sürelerini, yığın bilgilerini vb. Yazdırabilir. Komut formatı
jstat gcxxx -t pid < Aralık > < Miktar > , Şekil 8'de gösterildiği gibi.
Şekil 8. jstat komutu örneği
jmap
jmap, jmap -heap pid Java işleminin yığın bilgisini yazdırır. Jmap -dump: file = xxx pid aracılığıyla, yığını bir dosyaya aktarın ve ardından yığın kullanımını daha ayrıntılı analiz etmek için diğer araçları kullanın
MAT
MAT, Java yığınlarını analiz etmek için bir araçtır ve sezgisel tanı raporları sağlar.Dahili OQL, yığın üzerinde SQL benzeri sorgulara izin verir ve güçlüdür.Giden referans ve gelen referans, nesne referanslarının kaynağını izleyebilir.
Şekil 9. MAT örneği
Şekil 9, MAT kullanımına bir örnektir.MAT, nesnenin boyutunu, Sığ boyut ve Tutulan boyutu görüntülemek için iki sütuna sahiptir. İlki, nesnenin kendisinin kapladığı belleğin boyutunu temsil eder ve başvurduğu nesneyi içermez ve ikincisi, nesnenin kendisi ve doğrudan veya dolaylı referanslarıdır. Nesnenin Sığ boyutunun toplamı, yani nesne geri dönüştürüldükten sonra GC tarafından serbest bırakılan belleğin boyutu Genel olarak konuşursak, ikinci boyuta odaklanabilirsiniz. Büyük yığınlara (onlarca G) sahip bazı Java uygulamaları için MAT'ı açmak için büyük miktarda bellek gerekir. Genellikle yerel geliştirme makinesinin hafızası onu açamayacak kadar küçüktür.Grafik ortamını ve MAT'ı çevrimdışı sunucuya kurmanız ve uzaktan açmanız önerilir. Ya da bir yığın indeksi oluşturmak ve indeksi yerel olana kopyalamak için mat komutunu çalıştırın, ancak bu şekilde görülen yığın bilgisi sınırlıdır.
GC sorunlarını teşhis etmek için, JVM parametresine -XX: + PrintGCDateStamps eklemeniz önerilir. Yaygın olarak kullanılan GC parametreleri Şekil 10'da gösterilmektedir.
Şekil 10. Ortak GC parametreleri
Büyük resmi görmek için tıklayın
Java uygulamaları için, çoğu uygulama ve bellek sorunu, önemli bir araç olan top + jstack + jmap + MAT aracılığıyla bulunabilir. Bazen, Java uygulama tanısının işletim sistemi ile ilgili bilgilere başvurması gerekir ve Zabbix (entegre işletim sistemi ve JVM izleme) gibi bazı daha kapsamlı teşhis araçları kullanılabilir. Dağıtık bir ortamda, dağıtılmış izleme sistemleri gibi altyapı da uygulama performansı teşhisi için güçlü destek sağlar.
Performans optimizasyonu uygulaması
Yaygın olarak kullanılan bazı performans teşhis araçlarını tanıttıktan sonra, aşağıda JVM katmanından, uygulama kod katmanından ve veritabanı katmanından gelen vakaları paylaşmak için Java uygulama ayarlamasındaki bazı uygulamalarımız birleştirilecektir.
JVM ayarı: GC'nin acısı
Sogou ticari platformundaki bir sistem yeniden kurulduğunda, dahili uzaktan çağrı protokolü olarak RMI seçildi.Sistem çevrimiçi olduktan sonra, periyodik hizmet durdurma yanıtı başladı ve duraklama süresi birkaç saniye ile onlarca saniye arasında değişiyordu. GC günlüğünü gözlemleyerek, hizmet başlatıldıktan sonra her saat bir Tam GC görüneceği bulunmuştur. Büyük sistem yığın ayarı nedeniyle, Full GC'nin uygulamayı tek seferde duraklatması uzun zaman alır ve bu da çevrimiçi gerçek zamanlı hizmetler üzerinde daha büyük bir etkiye sahiptir. Analizden sonra, sistem yeniden yapılanmadan önce periyodik Tam GC'ye sahip değildi, bu nedenle RMI çerçeve seviyesinde bir sorun olduğundan şüpheleniliyor. Kamuya açık bilgiler aracılığıyla, RMI'nin GDC'sinin (Dağıtılmış Çöp Toplama) uzak nesneleri geri almak için Tam GC'yi periyodik olarak yürütmek için bir arka plan programı iş parçacığı başlatacağı bulunmuştur.Liste 2, arka plan iş parçacığı kodunu gösterir.
Liste 2. DGC arka plan iş parçacığı kaynak kodu
private static class Daemon Thread'ı genişletir {
public void run () {
için (;;) {
// ...
uzun d = maxObjectInspectionAge ();
eğer (d > = l) {
System.gc ();
d = 0;
}
// ...
}
}
}
Sorunu bulduktan sonra çözmek daha kolaydır. Birincisi, -XX: + DisableExplicitGC parametresini ekleyerek sistem GC'sinin görüntülü çağrısını doğrudan devre dışı bırakmaktır, ancak NIO kullanan sistemler için yığın dışı bellek taşması riski vardır. Diğer bir yol da -Dsun.rmi.dgc.server.gcInterval ve -Dsun.rmi.dgc.client.gcInterval parametrelerini artırarak Tam GC aralığını artırmak ve tamamen Durduracak olan -XX: + ExplicitGCInvokesConcurrent parametresini artırmaktır. The-World'ün Tam GC'si, uygulamanın duraklatma süresini azaltan ve NIO uygulamalarını etkilemeyen eşzamanlı bir GC döngüsüne ayarlanır. Şekil 11'de, düzenlemenin ardından Tam GC sayısının Mart'tan sonra önemli ölçüde azaldığı görülebilir.
Şekil 11. Tam GC izleme istatistikleri
GC ayarı, yüksek eşzamanlılık ve büyük verili etkileşimli uygulamalar için hala gereklidir, özellikle varsayılan JVM parametreleri genellikle iş gereksinimlerini karşılamaz ve özel ayar gerektirir. GC günlüklerinin yorumlanmasıyla ilgili pek çok kamuya açık bilgi var, bu yüzden bunları bu makalede tekrar etmeyeceğim. GC ayarlama hedefleri için temel olarak üç fikir vardır: gereksiz nesne üretimini azaltmak için yığın alanını artırarak GC sıklığını azaltın; yığın alanını azaltarak ve CMS GC algoritmasını kullanarak GC duraklatma süresini kısaltabilir; Tam GC'den kaçınarak ve CMS tetikleyicisini ayarlayarak Oran, Promosyon Başarısızlığından ve Eşzamanlı mod arızasından kaçının (yaşlılıkta daha fazla alan ayırın, kurtarma hızını hızlandırmak için GC iş parçacığı sayısını artırın), büyük nesnelerin oluşumunu azaltın, vb.
Uygulama katmanı ayarı: kodun kötü kokusunu koklayın
Uygulama katmanı kod ayarlamasından başlayarak, kod verimliliğindeki düşüşün temel nedenini analiz etmek şüphesiz Java uygulamalarının performansını iyileştirmenin iyi yollarından biridir.
Belirli bir ticari reklamcılık sistemi (yük dengeleme için Nginx kullanan) belirli bir gün boyunca çevrimiçi olduktan sonra, makinelerinin birçoğunun yükü keskin bir şekilde arttı ve CPU kullanım oranı hızla doldu. Hatta bir acil durum geri dönüşü yaptık ve sunuculardan birinin sitesini jmap ve jstack aracılığıyla kurtardık.
Şekil 12. MAT ile yığın sahnesinin analizi
Yığın sahnesi Şekil 12'de gösterilmiştir. MAT ile döküm verilerinin analizine göre bellek nesnelerinin çoğunun byte ve java.util.HashMap $ Entry olduğu ve java.util.HashMap $ Entry nesnelerinde dairesel referansların olduğu bulunmuştur. HashMap'in put işleminde sonsuz bir döngü olabileceği önceden konumlandırılmıştır (şekildeki java.util.HashMap $ Entry 0x2add6d992cb8 ve 0x2add6d992ce8'in bir sonraki referansı bir döngü oluşturur). Bunun tipik bir eşzamanlı kullanım senaryosu hatası olduğunu bulmak için ilgili belgelere bakın ( Kısacası, HashMap çok iş parçacıklı eşzamanlılık özelliklerine sahip değildir. İşlemleri aynı anda koyan birden fazla iş parçacığı olması durumunda, dahili dizinin genişletilmesi HashMap'in dahili bağlantılı listesinin bir halka yapısı oluşturmasına neden olarak sonsuz bir döngü ile sonuçlanacaktır.
Bu lansman için en büyük değişiklik, Liste 3'te gösterildiği gibi web sitesi verilerini bellekte önbelleğe alarak ve geç yükleme mekanizması kullanarak sistem performansını iyileştirmektir.
Liste 3. Web sitesi verileri geç yükleme kodu
özel statik Harita < Long, UnionDomain > domainMap = yeni HashMap < Long, UnionDomain > ();
özel boole isResetDomains () {
if (CollectionUtils.isEmpty (domainMap)) {
// Uzak http arayüzünden web sitesi ayrıntılarını alın
Liste < UnionDomain > newDomains = unionDomainHttpClient
.queryAllUnionDomain ();
if (CollectionUtils.isEmpty (domainMap)) {
domainMap = yeni HashMap < Long, UnionDomain > ();
for (UnionDomain etki alanı: newDomains) {
if (alan! = null) {
domainMap.put (domain.getSubdomainId (), alan);
}
}
}
doğruya dön;
}
yanlış dönüş;
}
Burada domainMap'in HashMap tipinde statik bir paylaşımlı kaynak olduğu görülebilmektedir.Çoklu iş parçacıklı olması durumunda, dahili bağlantılı listesinin bir halka yapısı oluşturmasına ve bunun sonucunda sonsuz bir döngü oluşturmasına neden olacaktır.
Ön uç Nginx'in bağlantı ve erişim günlüğü aracılığıyla, sistem yeniden başlatıldıktan sonra Nginx'in çok sayıda kullanıcı isteği biriktirdiği görülebilir.Reçine kabı başlatıldığında, çok sayıda kullanıcı isteği uygulama sistemine aktı ve birden çok kullanıcı aynı anda web sitesi verilerini istedi ve başlattı HashMap'te eşzamanlılık sorunlarına neden olan çalışın. Arızanın nedenini bulduktan sonra çözüm nispeten basittir. Ana çözümler şunlardır:
(1) Yukarıdaki eşzamanlılık sorununu çözmek için ConcurrentHashMap veya senkronize blok kullanın;
(2) Sistem başlamadan önce web sitesi önbellek yüklemesini tamamlayın, geç yüklemeyi kaldırın, vb .;
(3) Yerel önbelleği vb. Değiştirmek için dağıtılmış önbellek kullanın.
Kötü kodun konumu için, geleneksel anlamda kod incelemesine ek olarak, MAT gibi araçlar, sistem performans darboğazlarını belirli bir dereceye kadar hızlı bir şekilde bulmak için de kullanılabilir. Ancak, belirli senaryolara veya iş verilerine bağlı bazı durumlarda, performans sorunlarının kaynağını nihayet doğrulamak için yardımcı kodlar, performans test araçları, veri simülasyonları ve hatta çevrimiçi drenaj gereklidir. Aşağıda, referansınız için özetlediğimiz bazı kötü kodların olası özelliklerinden bazıları verilmiştir:
(1) Zayıf kod okunabilirliği ve temel programlama özellikleri yok;
(2) Çok fazla nesne üretiliyor veya büyük nesneler üretiliyor, bellek sızıntıları vb.
(3) Çok fazla GÇ akışı işlemi veya kapatmayı unutmak;
(4) Çok fazla veritabanı işlemi var ve işlem çok uzun;
(5) Eşzamanlı kullanım sahnesi yanlış;
(6) Zaman alan döngü yineleme işlemi.
Veritabanı katmanı ayarı: kilitlenme kabusu
Çoğu Java uygulaması için, özellikle yüksek veri tutarlılığı gerektiren OLTP gibi uygulamalar için veritabanı ile etkileşim senaryosu çok yaygındır Veritabanının performansı tüm uygulamanın performansını doğrudan etkileyecektir. Sogou'nun reklam verenler için bir reklam platformu olan ticari platform sistemi, materyallerinin gerçek zamanlı ve tutarlılığı için son derece yüksek gereksinimlere sahiptir.Ayrıca, ilişkisel veritabanı optimizasyonunda belirli deneyimler edindik.
Reklam materyali kitaplığı için, daha yüksek operasyon sıklığı (özellikle toplu materyal aracı operasyonu yoluyla), veritabanının kilitlenmesine neden olmak çok kolaydır.Daha tipik senaryolardan biri, reklam materyallerinin fiyat ayarlamasıdır. Müşteriler genellikle malzeme tekliflerini sık sık ayarlar, bu da dolaylı olarak veritabanı sisteminde daha fazla yük baskısına neden olur ve kilitlenme olasılığını artırır. Aşağıda, Sogou ticari platformundaki bir reklam sisteminde reklam malzemelerinin fiyatının ayarlanması durumu verilmiştir.
Belirli bir ticari reklamcılık sistemi, belirli bir günde ani bir trafik artışına sahiptir, bu da artan sistem yüküne ve sık veritabanı kilitlenmelerine neden olur. Deadlock ifadesi Şekil 13'te gösterilmiştir.
Şekil 13. Kilitlenme bildirimi
Bunlar arasında, groupdomain tablosundaki indeks, Mysql innodb motorunu kullanan idx_groupdomain_accountid (accountid), idx_groupdomain_groupid (groupid), primer (groupdomainid) üç tek indeks yapısıdır.
Bu senaryo, grup teklifi güncellendiğinde ortaya çıkar.Senaryoda gruplar, grup endüstrileri (groupindus tablosu) ve grup web siteleri (grup etki alanı tablosu) vardır. Grup teklifini güncellerken, grup sektör teklifi grup teklifini kullanıyorsa (tek grup fiyatı ile işaretlenir, 1 ise grup teklifi kullanılır). Aynı zamanda, grup web sitesi teklifi grup sektör teklifini kullanıyorsa (isuseindusprice ile işaretlenir, 1 ise grup sektör teklifi kullanılır), grup web sitesi teklifi de aynı anda güncellenmelidir. Her grup altında maksimum 3000 web sitesi olabileceğinden, grup teklifleri güncellenirken ilgili kayıtlar uzun süre kilitlenecektir. Yukarıdaki kilitlenme probleminden, hem işlem 1 hem de işlem 2'nin tek sütunlu bir idx_groupdomain_accountid dizini seçtiğini görebiliriz. Mysql innodb motorunun kilitleme özelliklerine göre, bir işlemde kullanılmak üzere yalnızca bir dizin seçilir ve ikincil dizin kilitleme için kullanıldığında, birincil anahtar dizinini kilitlemeye çalışır. Daha fazla analiz, işlem 1'in işlem 2 tarafından tutulan "idx_groupdomain_accountid" ikincil dizinini kilitlediğini (kilitleme aralığı "alan kimliği 5726 sayfa no 8658 n bit 824 endeksi"), ancak işlem 2'nin ikincil dizini ("boşluk id 5726 sayfa no 8658 n bit 824 indeksi ), birincil anahtar indeksinin PRIMARY indeksindeki kilidi kilitleme talebini bekliyor. İşlem 2, yürütmek için çok uzun süre beklediğinden veya kilidi uzun süre serbest bırakmadığından, işlem 1 sonunda geri döner.
Günün erişim günlüğünü izleyerek, o gün müşterilerin promosyon grubu teklifini komut dosyaları aracılığıyla değiştirmek için çok sayıda işlem başlattığını ve bunun bir önceki işlemin kilitli birincil anahtar PRIMARY endeksini serbest bırakmasını bekleyen çok sayıda işlemle sonuçlandığını görebiliriz. Sorunun kökü aslında Mysql innodb motoru tarafından endekslerin sınırlı kullanımıdır ve bu sorun Oracle veritabanında belirgin değildir. Çözüm, doğal olarak, tek bir işlemle kilitlenen kayıtların sayısının olabildiğince az olmasını ve böylece kilitlenme olasılığının büyük ölçüde azaltılmasını ummaktır. Son olarak, tek bir işlemle kilitlenen kayıtların sayısını azaltan ve aynı zamanda farklı planlar altında promosyon grubu veri kayıtlarının izolasyonunu gerçekleştiren ve böylelikle bu tür kilitlenme olasılığını azaltan bir bileşik (accountid, groupid) indeksi kullanılır.
Genel olarak, veritabanı katmanını ayarlamak için temel olarak aşağıdaki yönlerden başlıyoruz:
(1) SQL ifadesi düzeyinde optimizasyon yapın: yavaş SQL analizi, dizin analizi ve ayarlama, işlem bölme, vb .;
(2) Veritabanı yapılandırma düzeyinde optimizasyon yapın: örneğin alan tasarımı, önbellek boyutunun ayarlanması, disk G / Ç ve diğer veritabanı parametre optimizasyonu, veri birleştirme, vb .;
(3) Veritabanı yapı seviyesinden optimizasyon yapın: veritabanının dikey ve yatay bölünmesini göz önünde bulundurun;
(4) NoSQL'in tanıtılması gibi farklı senaryolara uyum sağlamak için uygun veritabanı motorunu veya türünü seçin.
Özet ve öneriler
Performans ayarlaması ayrıca 2-8 ilkesini de izler, performans sorunlarının% 80'i kodun% 20'sinden kaynaklanır, bu nedenle anahtar kodunu optimize etmek, çabanın yarısı ile sonucun iki katıdır. Aynı zamanda, performansın optimizasyonu talep üzerine optimize edilmelidir ve aşırı optimizasyon daha fazla soruna neden olabilir. Java performans optimizasyonu için sadece sistem mimarisini ve uygulama kodunu anlamak değil, aynı zamanda JVM katmanına ve hatta işletim sisteminin alt katmanına da dikkat etmek gerekir. Özet olarak, aşağıdaki noktalar dikkate alınabilir:
1) Temel performansın ayarlanması
Buradaki temel performans, ağ ayarı, işletim sistemi sürümü yükseltmesi ve donanım cihaz optimizasyonu gibi donanım seviyesinin veya işletim sistemi seviyesinin yükseltilmesi ve optimizasyonu anlamına gelir. Örneğin, NIO'da Linux'un yeni sürümünün yükseltilmesi de dahil olmak üzere, F5 kullanımı ve SDD sabit disklerin tanıtılması, uygulamaların performansını büyük ölçüde artırabilir;
2) Veritabanı performans optimizasyonu
Ortak işlem bölme, dizin ayarlama, SQL optimizasyonu, NoSQL tanıtımı, vb. Dahil, işlem bölme sırasında eşzamansız işlemenin tanıtımı ve son olarak, belirli senaryolar için tanıtılan çeşitli NoSQL veritabanları dahil olmak üzere tutarlılığın tanıtımı, Yüksek eşzamanlılık altında geleneksel veri tabanlarının eksikliklerini büyük ölçüde azaltabilir;
3) Uygulama mimarisi optimizasyonu
Bazı yeni bilgi işlem veya depolama çerçevelerini tanıtın, orijinal küme hesaplama performans darboğazlarını vb. Çözmek için yeni özellikleri kullanın; veya zamana göre tipik alan uygulamalarını kullanarak önceden hesaplama vb. Dahil olmak üzere düzey hesaplama ve depolamaya dağıtılmış bir strateji uygulayın. Vb .; sistem yükünü belli ölçüde azaltabilir;
4) İşletme düzeyinde optimizasyon
Sistem performansını iyileştirmenin tek yolu teknoloji değildir.Performans sorunlarının ortaya çıktığı birçok senaryoda, bunun büyük bir kısmının özel iş senaryolarından kaynaklandığı görülebilir. İşletmeyi engelleyebilir veya ayarlayabilirseniz, genellikle en çok Etkili.
