Tek iş parçacıklı ve çok iş parçacıklı veritabanı performansı hakkında

H2, performans konusunda iyi bir üne sahip tek dişli bir veritabanıdır. Diğer veritabanları çok iş parçacıklıdır.

Sorum şu: Çok iş parçacıklı bir veritabanı ne zaman bir iş parçacığı veritabanından daha ilginç hale gelir? Kaç kullanıcı Kaç süreç Tetik nedir? Herkes paylaşacak deneyime sahip mi?

özet

• Genel darboğaz disk erişim
• SSD'ler hızlı, ancak kırılgan (başarısızlık prosedürü bir zorunluluktur)
• Tek bir iş parçacığı sistemi üzerinde uzun bir sorgu diğerlerini engelleyecektir
• Çok iş parçacıklı sistemin yapılandırılması zor olabilir
• Çok iş parçacıklı veritabanları, tek çekirdekli sistemlerde bile faydalıdır

İşte benim görüşüm:

Genellikle bir DB sisteminin tıkanması (veya en yavaş kısmı) disktir. CPU sadece aritmetik işlemler, işleme veya CPU'nun yaptığı diğer işler sırasında hızlanır. Uygun mimariyle, çoklu okuma yavaş diski okumak / yazmak yerine bir sorgunun yükünü CPU üzerine dengelemeye yardımcı olabilir. Hesaplanan bir sütun (daha önce diske kaydedilmiş) oluşturmak ve bu sütunu diskten okumak yerine CPU döngülerini kullanarak bir değeri hesaplamanın daha hızlı olduğu durumlar vardır.

Bazı RDBMS'lerde, bu örnekteki tüm DB'ler tarafından sıralama, karma, geçici değişkenler vb. İçin kullanılan geçici bir DB (tempdb) vardır. böylece genel sunucu performansını iyileştirir.

Çoklu okuma (paralellik) kullanarak, bir sorgunun sonuç kümesi, yalnızca bir çekirdeği kullanmak yerine, sunucunun farklı çekirdeklerinde işlenecek şekilde bölünebilir. Bu özellik performansı her zaman iyileştirmez, ancak olduğu durumlar da vardır ve bu nedenle bu özellik kullanılabilir durumdadır.

DB için mevcut olan iş parçacıkları birçok amaç için kullanılır: diske okuma / yazma, kullanıcı bağlantıları, arka plan işleri, kilitleme / kilitleme, ağ IO, vb ... İşletim sistemi mimarisine bağlı olarak, iş parçacıkları önleyici olarak CPU'ya beslenir ve bekleme ve kuyrukları kullanarak başardı. Eğer CPU bu ipleri çok hızlı bir şekilde kırabilirse, bekleme süresi düşük olacaktır. Çok iş parçacıklı bir DB, tek iş parçacıklı bir DB'den daha hızlı olacaktır, çünkü tek iş parçacıklı bir DB'de, diğer eleklere kolayca ulaşılabilir olmak yerine sadece bir iş parçacığının geri dönüşümü ek yükü olacaktır.

Ölçeklenebilirlik de bir sorun haline gelir, çünkü ölçeklendirilmiş DB sistemini yönetmek ve yürütmek için daha fazla iş parçacığı gerekir.

MySQL hakkında söyleyebileceğim bir şey varsa, işlemsel (ACID uyumlu) depolama motoru olan InnoDB gerçekten de okuyucusudur. Ancak, SİZİN YAPILANDIRMAK kadar çok iş parçacıklı !!! "Kutudan çıkar çıkmaz" bile, InnoDB, varsayılan ayarları göz önüne alındığında tek bir CPU ortamında mükemmel performans sergiliyor. InnoDB çoklu okuma özelliklerinden yararlanmak için birçok seçeneği etkinleştirmeyi unutmayın.

innodb_thread_concurrency , InnoDB'nin açık tutabileceği eşzamanlı konu sayısına bağlı olarak üst sınırı ayarlar. Bunun için belirlenecek en iyi tur sayısı (2 X CPU Sayısı) + Disk Sayısı. GÜNCELLEME : Percona NYC Konferansı'ndan ilk elden öğrendiğim gibi, InnoDB Storage Engine'i içinde bulunduğu ortam için en iyi sayıda iş parçacığı bulmak üzere uyarmak için bunu 0 olarak ayarlamanız gerekir.

innodb_concurrency_tickets , eşzamanlılık kontrolünü cezasızlıkla atlayabilecek iş parçacıklarının sayısını ayarlar. Bu sınıra ulaşıldıktan sonra, iş parçacığı eşzamanlılık denetimi tekrar norm haline gelir.

innodb_commit_concurrency , gerçekleştirilebilecek eş zamanlı işlem sayısını belirler. Varsayılan değer 0 olduğundan, bu ayarı yapmamak, herhangi bir sayıda işlemin aynı anda işlem yapmasına izin verir.

innodb_thread_sleep_delay , InnoDB kuyruğuna yeniden girmeden önce bir InnoDB iş parçacığının uykuda kalabileceği milisaniye sayısını ayarlar. Varsayılan değer 10000 (10 sn).

innodb_read_io_threads ve innodb_write_io_threads (her ikisi de MySQL 5.1.38'den beri) okuma ve yazma için belirtilen sayıda konu tahsis eder. Varsayılan 4 ve maksimum 64'tür.

innodb_replication_delay , bir köledeki iplik gecikmesini empoze eder, innodb_thread_concurrency değerine ulaşılır.

innodb_read_ahead_threshold , eşzamansız okumaya geçmeden önce ayarlanan sayıdaki (64 sayfa [sayfa = 16K]) doğrusal okumalara izin verir.

Daha fazla seçenek söylesem zaman zaman benden kaçardı. Onlar hakkında MySQL'in Dokümantasyonunda okuyabilirsiniz .

Çoğu kişi bu özelliklerin farkında değildir ve InnoDB'den yalnızca ACID uyumlu işlemler yapmaktan oldukça memnun. Bu seçeneklerden herhangi birini ince ayarladıysanız, kendi sorumluluğunuzdadır.

MySQL 5.5 Çoklu Tampon Havuz Örnekleri ile oynadım (9 tampon havuz örneğinde 162 GB) ve verilerin bu şekilde bellekte otomatik olarak bölünmesine çalıştım. Bazı uzmanlar bunun% 50 performans artışı vermesi gerektiğini söylüyor. Elimde InnoDB taramasını yapan bir ton iplik kilitleme vardı. 1 tampona (162GB) geçtim ve dünyada yine her şey yolunda gitti. Bunu ayarlamak için emrinde Percona uzmanlarına ihtiyacın var sanırım. Yarın New York'taki Percona MySQL Konferansında olacağım ve fırsatın yeterliliği varsa bunu soracağım.

Sonuç olarak, InnoDB çok iş parçacıklı işlemler için varsayılan ayarları göz önüne alındığında çok işlemcili bir sunucuda şimdi iyi davranıyor. Tweaking, büyük özen, sabır, mükemmel belgeler ve mükemmel kahve (veya Red Bull, Jolt, vb.) Alır.

Günaydın, iyi akşamlar ve iyi geceler !!!

GÜNCELLEME 2011-05-27 20:11

Perşembe günü New York'ta düzenlenen Percona MySQL Konferansından geri döndüm . Ne konferans. Çok şey öğrendim, ancak InnoDB ile ilgili olarak bakacağım bir cevap aldım. Ronald Bradford tarafından innodb_thread_concurrency değerinin 0 olarak ayarlanmasının InnoDB'nin iplik eşzamanlılığı ile şirket içinde en iyi hareket tarzına karar vermesine izin vereceği konusunda bilgilendirildim . Bunu daha fazla MySQL 5.5'te deneyeceğim.

GÜNCELLEME 2011-06-01 11:20

Bir uzun sorgu devam ettiği sürece, InnoDB ACID uyumludur ve MultiVersion Eşzamanlılık Kontrolü ile çok iyi çalışır . İşlemler, başkalarının verilere erişmesini engelleyen yalıtım düzeylerini (varsayılan olarak tekrarlanabilir okumalar) taşıyabilmelidir.

Çok çekirdekli sistemlere gelince, InnoDB uzun bir yol kat etti. Geçmişte, InnoDB çok çekirdekli bir ortamda iyi performans gösterememiştir. Birden fazla mysqld işlemini CPU'lara dağıtmak için birden fazla çekirdeği almak için tek bir sunucuda birden fazla mysql örneği çalıştırmak zorunda olduğumu hatırlıyorum. Percona ve daha sonra MySQL (eh, Oracle, beni hala kıkırdattığını söylüyorlar) sayesinde artık gerekli değil, çünkü InnoDB'yi çekirdeklere çok fazla ayarlama yapmadan basitlikle erişebilen daha olgun bir depolama motorunda geliştirdiler. Bugün InnoDB'nin mevcut örneği, tek bir çekirdekli sunucuda iyi çalışabilir.

Birden fazla eşzamanlı kullanıcı veya işleminiz olduğunda veya çok iş parçacıklı veritabanı erişimi olan tek bir işlem olması durumunda, iş parçacığını destekleyen bir veritabanına sahip olmak potansiyel olarak ilginç hale gelecektir.

H2 iş parçacığı güvenlidir, ancak tüm istekleri veritabanına seriler; bu da ağır yük senaryosunda potansiyel bir performans sorunu olabilir. Bunun gerçekte belirli bir proje için geçerli olup olmadığı, performans gereksinimlerinizin bir kombinasyonuna, veritabanına erişen iş parçacığı / kullanıcı / işlem sayısına, bu iş parçacıkları tarafından yürütülen sorgulama sıklığına ve sizin iş ortağınızın ortalama ve en kötü durum performansına bağlıdır. sorguları.

Örneğin, performans gereksinimleriniz bir saniye içinde yanıt verecekse, yürütülmesi 0.05 saniye süren tek bir sorgu yürüten 10'dan fazla eşzamanlı kullanıcınız olmazsa, tek iş parçacıklı bir veritabanı yine de bu hedeflere ulaşmanıza izin verir (çok iş parçacıklı olmasına rağmen) Muhtemelen zaten gözle görülür bir performans artışı verecekti). Aynı senaryo göz önüne alındığında, yarım saniyelik en kötü durum performansına sahip tek bir potansiyel sorgu ile göz önüne alındığında, veritabanı erişiminizi serileştirmek artık performans hedeflerinize ulaşmanıza izin vermeyecektir.

Şu anda projenizde H2 kullanıyorsanız, bir yükleme senaryosunda kod üssünüze karşı bir profilleyici çalıştırmanızı tavsiye ederim (yalnızca bazı tipik kullanım alanlarını kullanarak aynı anda kodunuzu vuran bir x sayı dizisini atmanız yeterli). Bu size sadece teorik yapmak yerine kod tabanınızdaki performans ve darboğazlarla ilgili gerçek ölçümler verecektir. Bu, isteklerinizin yalnızca veritabanına erişmeyi bekleyen zamanlarının büyük bir kısmını harcadığını gösteriyorsa, iş parçacığı veritabanına geçmenin zamanı gelmiştir.

Söyleyebileceğim kadarıyla, "tek iş parçacıklı" H2 için bir yanlış isim biraz. Mesele şu ki , tüm işlemleri seri hale getiriyor (yani bir seferde bir işlem yapıyor).

Başvurunuz için "tamam" olup olmadığına ilişkin önemli soru "Kaç kullanıcı var?" Değil. hatta "Kaç işlem?", "İşlemlerim ne kadar sürecek?"

Tüm işlemleriniz ikinci saniyedeyse, bu iyi olabilir, bazı işlemlerin tamamlanması birkaç saat sürerse, diğer bekleyen işlemlerin tamamlanmasını bekleyeceği için bu iyi olmayabilir. Bunun “iyi” olup olmadığına dair karar kendi performans gereksinimlerinize bağlı olacaktır - yani, kullanıcılarımın veritabanına işlemlerle ulaşması için ne kadar beklediğiniz beklenir.

--DÜZENLE

Görünüşe göre H2 gerçekten işlemleri seri hale getirmiyor - sadece DML. Başka bir deyişle, uzun bir işlem içindeki birçok kısa güncelleme diğer güncellemeleri engellemeyecektir . Ancak deneysel MVCC özelliğini kullanmadığınız sürece , masa kilitleme, bunun pratikte benzer bir etkiye sahip olduğu anlamına gelir. Deneysel bir "multi_threaded" özelliği de vardır, ancak MVCC ile aynı anda kullanılamaz.

PostgreSQL sitesinden bit ve parça alıntı yapmak ... Lütfen bu argümanların yararları hakkında hiçbir fikrim olmadığını - sadece bir yorumda bulunmadıklarını unutmayın.

Geliştirici SSS’sinden ("Neden iş parçacığı kullanılmıyor ..."):

http://wiki.postgresql.org/wiki/Developer_FAQ#Why_don.27t_you_use_threads.2C_raw_devices.2C_async-I.2FO.2C_.3Cinsert_your_favorite_wizz-bang_feature_here.3E.3F

Konular şu anda arka uçlar için birden çok işlem yerine kullanılmıyor, çünkü: (...)

• Bir arka uçtaki bir hata, tek bir işlem içindeki iş parçacığı varsa diğer arka uçları bozabilir
• İplikler kullanılarak yapılan hız iyileştirmeleri, kalan arka uç başlangıç ​​zamanına göre küçüktür.
• Salt okunur yürütülebilir eşlemelerin paylaşılması ve paylaşılan dosyaların kullanılması, iş parçacığı gibi işlemler çok bellek etkin demektir
• İşlemlerin düzenli olarak oluşturulması ve imha edilmesi, uzun süreli işlemlerde yönetimi zor olabilen bellek parçalanmasına karşı korunmaya yardımcı olur

Yapılacaklar listesinden ("İstemediğimiz özellikler"):

http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want

Tek bir süreçte iş parçacığı olarak çalışan tüm arka uçlar (istenmiyor)

Bu, mevcut kurulumdan aldığımız işlem korumasını ortadan kaldırır. İş parçacığı oluşturma genellikle modern sistemlerde işlem oluşturma ile aynıdır, bu nedenle saf bir dişli model kullanmak pek akıllıca değildir ve MySQL ve DB2, iş parçacıklarının çözdükleri kadar çok konu sunduğunu göstermiştir. (...)

Yani, yine ... Yukarıdakilerin esası hakkında hiçbir fikrim yok. Yoruma uyması çok uzun sürdü.

Çok iş parçacıklı bir veritabanı, yalnızca veritabanına giden 1'den fazla paralel sorgunuz olduğunda size yarar sağlar. Bu sahip olduğunuz kullanıcı sayısına bağlıdır. Uygulamada aynı anda çalışan ondan fazla kullanıcınız varsa, aynı anda veritabanında birden fazla sorgu üreteceklerdir.

Ayrıca, çok iş parçacıklı bir veritabanı yalnızca CPU'da çok çekirdekli olduğunda faydalanabilir. Tek çekirdekli varsa, çok iş parçacıklı veritabanı işi sıraya koymak ve bunları tek çekirdekte sırayla çalıştırmak zorundadır. Çok çekirdekli olduğunda, her çekirdek paralel olarak bir iplik geçirebilir. Böylece daha iyi performans.

Bu, sorgunuzu yanıtlıyor mu?