6 diskli baskın 1 + 0 üstünde LVM üstünde XFS kullanan DL380p gen8 sunucularında, aynı iş yükü RHEL 5'e kıyasla RHEL 6'ya göre disk yazmalarında on kat artış sağlayarak uygulamaları kullanılamaz hale getirir.

Co6 sistemini mümkün olduğunca optimize etmeye değil, co6'nın neden bu kadar çılgınca davrandığını anlamaya ve bunu çözmeye baktığımı unutmayın.

vmstat / iostat

MySQL çoğaltma kurulum var, mysql 5.5 kullanarak. OS olarak RHEL 6 kullanan gen8 sunucularındaki Mysql köleleri kötü performans gösteriyor, vmstat ve iostat ile yapılan inceleme, bu sunucuların sayfa çıkış etkinliğinin on katı ve disk alt sistemine yazma sayısının on katı olduğunu gösteriyor. blktrace bu yazımların mysql tarafından değil çekirdek tarafından başlatıldığını göstermektedir.

Centos 5:

[dkaarsemaker@co5 ~]$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0     12 252668 102684 10816864    0    0     8   124    0    0  9  1 90  0  0
 1  0     12 251580 102692 10817116    0    0    48  2495 3619 5268  6  1 93  0  0
 3  0     12 252168 102692 10817848    0    0    32  2103 4323 5956  6  1 94  0  0
 3  0     12 252260 102700 10818672    0    0   128  5212 5365 8142 10  1 89  0  0

[dkaarsemaker@co5 ~]$ iostat 1
Linux 2.6.18-308.el5 (bc290bprdb-01.lhr4.prod.booking.com)  02/28/2013

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.74    0.00    0.81    0.25    0.00   90.21

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      277.76       399.60      5952.53 2890574849 43058478233
cciss/c0d0p1      0.01         0.25         0.01    1802147      61862
cciss/c0d0p2      0.00         0.01         0.00     101334      32552
cciss/c0d0p3    277.75       399.34      5952.52 2888669185 43058383819
dm-0             32.50        15.00       256.41  108511602 1854809120
dm-1            270.24       322.97      5693.34 2336270565 41183532042

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7.49    0.00    0.79    0.08    0.00   91.64

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      300.00        32.00      4026.00         32       4026
cciss/c0d0p1      0.00         0.00         0.00          0          0
cciss/c0d0p2      0.00         0.00         0.00          0          0
cciss/c0d0p3    300.00        32.00      4026.00         32       4026
dm-0              0.00         0.00         0.00          0          0
dm-1            300.00        32.00      4026.00         32       4026

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.25    0.00    0.46    0.21    0.00   95.09

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      507.00       160.00     10370.00        160      10370
cciss/c0d0p1      0.00         0.00         0.00          0          0
cciss/c0d0p2      0.00         0.00         0.00          0          0
cciss/c0d0p3    507.00       160.00     10370.00        160      10370
dm-0              0.00         0.00         0.00          0          0
dm-1            507.00       160.00     10370.00        160      10370

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.33    0.00    0.50    0.08    0.00   94.09

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      318.00        64.00      4559.00         64       4559
cciss/c0d0p1      0.00         0.00         0.00          0          0
cciss/c0d0p2      0.00         0.00         0.00          0          0
cciss/c0d0p3    319.00        64.00      4561.00         64       4561
dm-0              0.00         0.00         0.00          0          0
dm-1            319.00        64.00      4561.00         64       4561

Ve Centos 6'da disk belleği ve diskte on kat artış var:

[root@co6 ~]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 361044  52340 81965728    0    0    19  1804   36  110  1  1 98  0  0  
 0  0      0 358996  52340 81965808    0    0   272 57584 1211 3619  0  0 99  0  0  
 2  0      0 356176  52348 81966800    0    0   240 34128 2121 14017  1  0 98  0  0 
 0  1      0 351844  52364 81968848    0    0  1616 29128 3648 3985  1  1 97  1  0  
 0  0      0 353000  52364 81969296    0    0   480 44872 1441 3480  1  0 99  0  0  

[root@co6 ~]# iostat 1
Linux 2.6.32-279.22.1.el6.x86_64 (bc291bprdb-01.lhr4.prod.booking.com)  02/28/2013  _x86_64_    (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.08    0.00    0.67    0.27    0.00   97.98

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             373.48      1203.02    115203.05   11343270 1086250748
dm-0             63.63        74.92       493.63     706418    4654464
dm-1            356.48      1126.72    114709.47   10623848 1081596740

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.25    0.00    0.19    0.06    0.00   99.50

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             330.00        80.00     77976.00         80      77976
dm-0              0.00         0.00         0.00          0          0
dm-1            328.00        64.00     77456.00         64      77456

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.38    0.00    0.19    0.63    0.00   98.81

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             570.00      1664.00    128120.00       1664     128120
dm-0              0.00         0.00         0.00          0          0
dm-1            570.00      1664.00    128120.00       1664     128120

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.66    0.00    0.47    0.03    0.00   98.84

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             317.00       448.00     73048.00        448      73048
dm-0             34.00         0.00       272.00          0        272
dm-1            309.00       448.00     72776.00        448      72776

Daraltmak

RHEL 5 kullanan Gen 8 sunucuları ve RHEL 5 veya 6 kullanan gen 7 sunucuları bu sorunu göstermez. Ayrıca, varsayılan xfs yerine ext3 ile RHEL 6 dosya sistemi olarak sorunu göstermez. Sorun gerçekten XFS, gen8 donanımı ve centos 6 arasında bir yerde görünüyor. RHEL 6 da sorunu gösteriyor.

Edit 29/04: Glogic makinesinde qlogic HBA'ları ekledik. Fiber kanal depolamasında XFS kullanmak sorunu göstermez. Yani kesinlikle xfs / hpsa / p420i arasındaki etkileşimde bir yer.

XFS'in

Rhel 8'deki daha yeni xfs, altta yatan şerit genişliğini algılayabiliyor gibi görünüyor, ancak cciss kullanan p410i denetleyicilerinde değil, yalnızca hpsa sürücüsünü kullanan p420i denetleyicilerinde.

xfs_info çıktısı:

[root@co6 ~]# xfs_info /mysql/bp/
meta-data=/dev/mapper/sysvm-mysqlVol isize=256    agcount=16, agsize=4915136 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=78642176, imaxpct=25
         =                       sunit=64     swidth=192 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=38400, version=2
         =                       sectsz=512   sunit=64 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

sunit / swidth, yukarıdaki Tamam olarak işaretlenmiş tüm kurulumlarda 0'dır. Bunu mkfs'de veya noalign mount seçeneğiyle değiştiremiyoruz. Bunun nedeni olup olmadığını da bilmiyoruz.

Hugepages

Rhel 6'da XFS sorunları olan diğer insanlar, büyük sayfaların ve özellikle şeffaf büyük sayfaların devre dışı bırakılmasının yararlı olabileceğini söylüyor. İkisini de devre dışı bıraktık, sorun gitmedi.

Birçok şeyi denedik ve gözlemledik, aşağıdakilerin hiçbiri yardımcı olmadı:

• Bellek ayırmalarını etkilemek için numactl kullanma. G7 ve g8'in farklı bir numa düzenine sahip olduğunu fark ettik, hiçbir etki görülmedi
• Daha yeni çekirdekler (3.6 kadar yeni) bunu çözmedi. Hiçbiri fedora 17'yi kullanmadı.
• iostat yazma işlemlerinde on kat artış bildirmez, sadece yazılan bayt sayısında
• Farklı G / Ç zamanlayıcılarının kullanılmasının bir etkisi yoktur.
• İlgili dosya sistemi noatime / nobarrier / nopdiratime'ın montajı yardımcı olmadı
• / Proc / sys / vm / dirty_ratio değiştirmenin hiçbir etkisi olmadı
• Bu hem 2640 hem de 2670 CPU'lara dayanan sistemlerde olur
• hpsa-3.2.0 sorunu çözmüyor

XFS ve EL6 çirkin bir duruma düştü ... Red6 çekirdeğine giren birkaç yukarı yönlü özellik / değişiklik nedeniyle ELFS sistemlerinde XFS'den vazgeçtim ...

Bu bir sürprizdi ve biraz paniğe neden oldu: XFS dosya sistemlerim neden birdenbire daha fazla alan ve seyrek dosyalarla dolu?

Kasım 2012'den bu yana 2.6.32-279.11.1.el6, Red Hat Bugzilla 860787'den kaynaklanan can sıkıcı bir yük ve performans sorunundan daha yeni çekirdeklerde nakliye yapan XFS sürümü . O zamandan beri, tahmin edilemeyen performansım ve ortalamadan daha yüksek çalışma kuyruklarım vardı.

Yeni sistemler için ZFS veya sadece ext4 kullanıyorum. Eski sistemler için onları donduruyorum 2.6.32-279.11.1.el6.

Şu sürüme geri dönmeyi deneyin:

yum install kernel-2.6.32-279.11.1.el6.x86_64

Yukarıdakilere ek olarak, kullandığınız RAID denetleyicisi türü nedeniyle, tipik iyileştirmeler sırayla yapılır:

XFS dosya sistemlerinizi bağlayın noatime. Ayarlanmış çerçeveyi aşağıdakilerle de kullanmalısınız :

tuned-adm profile enterprise-storage

readahead, nobarrier ve I / O asansörünü iyi bir taban çizgisine ayarlamak için.

Düzenle:

XFS dosya sistemi optimizasyonunu çevreleyen birçok öneri var. Dosya sistemini yalnızca son on yıldır kullandım ve işletim sisteminde altta yatan değişiklikler meydana geldiğinden parametreleri zaman zaman ayarlamak zorunda kaldım. Sizinki gibi dramatik bir performans düşüşü yaşamadım, ancak LVM kullanmıyorum.

Farklı çekirdek üretimi, derlenmiş varsayılanlar, zamanlayıcılar, paketler vb.İle EL5'in EL6 ile aynı şekilde hareket etmesini beklemenin mantıksız olduğunu düşünüyorum .

Ne olurdu ben bu noktada yapmak ??

• Mkfs.xfs parametrelerini ve sistemleri nasıl oluşturduğunuzu inceleyeceğim. Yükleme sırasında XFS bölümleme mi kullanıyorsunuz yoksa gerçekte bölümler mi oluşturuyorsunuz? Verilen parametrelerde daha fazla esnekliğe sahip olduğum için ana işletim sistemi kurulumunu takiben XFS dosya sistemi oluşturma işlemini gerçekleştiriyorum.

• Mkfs.xfs oluşturma parametrelerim basit: mkfs.xfs -f -d agcount=32 -l size=128m,version=2 /dev/sdb1örneğin.

• Bağlama seçeneklerim: XFS dinamik ön konumunun yerel olarak çalışmasına noatime,logbufs=8,logbsize=256k,nobarrierizin veriyorum ve burada olduğu gibi kısıtlamıyor. Performansım bununla birlikte gelişti.

• Bu yüzden LVM kullanmıyorum . Özellikle donanım RAID'inin üstünde ... Özellikle aygıta özgü bazı LVM benzeri işlevlerin bulunduğu HP Smart Array denetleyicilerinde. Ancak, LVM kullanarak fdiskham bölüm oluşturma için erişiminiz yoktur . EL5'ten EL6'ya değişen bir şey, yükleyicideki bölüm hizalaması ve başlangıç ​​sektörünü bir silindir sınırına ayarlamak için fdisk olarak değiştirilmesidir.

• HP Akıllı Dizi denetleyicilerinizi ve sürücülerinizi geçerli düzeltme düzeyinde çalıştırdığınızdan emin olun. Bu noktada, sunucunun tamamını ProLiant ürün yazılımı revizyonu için geçerli HP Servis Paketi ile güncellemek mantıklıdır . Bu, sistemdeki tüm algılanan bileşenleri yükselten önyüklenebilir bir DVD'dir.

• RAID denetleyici ayarlarını kontrol ederdim. Çıktısını yapıştırın hpacucli ctrl all show config detail. Benimki burada. Yazmaya karşı okumalara karşı önyargılı bir önbellek oranı istiyorsunuz. 75:25 normdur. Bu uygulama için varsayılan şerit boyutu 256K olmalıdır.

• Bunu potansiyel olarak LVM olmadan deneyebilirim.

• sysctl.confParametreleriniz neler ?

Benzer sorunu yaşadık ve bunun XFS günlük sürümü değişikliğinden kaynaklandığını öğrendik. Sürüm 2 günlükleri mkfs.xfs ile kullanılan şerit genişliği kümesini dikkate alır. Çok fazla fsync yaparsanız, raid kartınız artık bu günlükleri taklit edemez. Bölümü herhangi bir genişlik ayarı olmadan biçimlendirerek test edebilirsiniz (RAID 1 + 0 ile herhangi bir fark yaratmaz). Çok fazla günlük güncellemesi içerip içermediğini görmek için blktrace / seekwatcher ile doğrulayabilirsiniz.