Na serwerach DL380p gen8 korzystających z XFS na LVM na szczycie RAID 1 + 0 z 6 dyskami identyczne obciążenie powoduje dziesięciokrotny wzrost zapisów na dyskach na RHEL 6 w porównaniu z RHEL 5, co sprawia, że ​​aplikacje nie nadają się do użytku.

Zauważ, że nie patrzę na optymalizację systemu co6 tak bardzo, jak to możliwe, ale na zrozumienie, dlaczego co6 zachowuje się tak zupełnie inaczej, i rozwiązanie tego.

vmstat / iostat

Mamy konfigurację replikacji MySQL, używając mysql 5.5. Mysql slave na serwerach gen8 używających RHEL 6, ponieważ system operacyjny działa źle, inspekcja za pomocą vmstat i iostat pokazuje, że te serwery wykonują dziesięciokrotnie przewijanie strony i dziesięciokrotnie więcej zapisów do podsystemu dyskowego. blktrace pokazuje, że te zapisy nie są inicjowane przez mysql, ale przez jądro.

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

A w Centos 6 dziesięciokrotny wzrost stronicowania i zapisu na dysku:

[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

Zawężenie

Serwery Gen 8 korzystające z RHEL 5 i serwery Gen 7 korzystające z RHEL 5 lub 6 nie wykazują tego problemu. Ponadto RHEL 6 z ext3 jako systemem plików zamiast naszego domyślnego systemu plików xfs nie pokazuje problemu. Problem wydaje się być gdzieś pomiędzy XFS, sprzętem gen8 i centos 6. RHEL 6 również pokazuje problem.

Edycja 29/04: dodaliśmy qlogic HBA do maszyny G8. Używanie XFS w pamięci Fibre Channel nie pokazuje problemu. Zdecydowanie jest to gdzieś w interakcji między XFS / HPSA / P420i.

XFS

Nowsze xfs w rhel 8 wydają się być w stanie wykryć leżącą poniżej szerokość paska, ale tylko na kontrolerach p420i korzystających ze sterownika hpsa, a nie na kontrolerach p410i korzystających z cciss.

Dane wyjściowe xfs_info:

[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 mają wartość 0 we wszystkich ustawieniach oznaczonych powyżej jako OK. Wydaje się, że nie jesteśmy w stanie tego zmienić ani w mkfs, ani w opcji noalign mount. Nie wiemy też, czy to jest przyczyna.

Hugepages

Inne osoby mające problemy z XFS na rhel 6 twierdzą, że wyłączenie hugpage, a szczególnie przezroczyste hugpage może być korzystne. Wyłączyliśmy oba, problem nie zniknął.

Próbowaliśmy i obserwowaliśmy już wiele rzeczy, żadne z poniższych nie pomogło:

• Używanie numactl do wpływania na przydziały pamięci. Zauważyliśmy, że g7 i g8 mają inny układ liczb, nie zauważono żadnego efektu
• Nowsze jądra (tak nowe jak 3.6) nie rozwiązały tego. Nie korzystałem też z fedory 17.
• iostat nie zgłasza dziesięciokrotnego wzrostu transakcji zapisu, a jedynie liczbę zapisanych bajtów
• Używanie różnych harmonogramów we / wy nie ma wpływu.
• Podłączenie odpowiedniego systemu plików noatime / nobarrier / nopdiratime nie pomogło
• Zmiana / proc / sys / vm / dirty_ratio nie przyniosła żadnego efektu
• Dzieje się tak zarówno w systemach opartych na procesorach 2640 i 2670
• hpsa-3.2.0 nie rozwiązuje problemu

XFS i EL6 popadły w brzydki stan ... Na razie porzuciłem XFS na systemach EL6 z powodu kilku wcześniejszych funkcji / zmian wpadających do jądra Red Hat ...

Ten był niespodzianką i wywołał panikę: Dlaczego moje systemy plików XFS nagle zużywają więcej miejsca i są pełne rzadkich plików?

Od listopada 2012 r. Wersja XFS jest dostarczana w jądrach nowszych niż 2.6.32-279.11.1.el6irytujące problemy z ładowaniem i wydajnością wynikające z Bugzilli 860787 firmy Red Hat . Od tego czasu miałem nieprzewidywalną wydajność i wyższe kolejki uruchamiania niż średnia.

W przypadku nowych systemów używam ZFS lub po prostu ext4. W przypadku starszych systemów zamrażam je 2.6.32-279.11.1.el6.

Spróbuj wrócić do tej wersji za pomocą:

yum install kernel-2.6.32-279.11.1.el6.x86_64

Oprócz powyższego, ze względu na typ kontrolera RAID, którego używasz, typowe optymalizacje są następujące:

Zamontuj systemy plików XFS noatime. Powinieneś również wykorzystać tuned framework dzięki:

tuned-adm profile enterprise-storage

ustawić readahead, nobarrier i windę I / O na dobrej linii bazowej.

Edytować:

Istnieje wiele zaleceń dotyczących optymalizacji systemu plików XFS. Korzystałem z systemu plików wyłącznie przez ostatnią dekadę i od czasu do czasu musiałem dostosowywać parametry, ponieważ wystąpiły podstawowe zmiany w systemie operacyjnym. Nie doświadczyłem dramatycznego spadku wydajności, takiego jak twój, ale nie używam również LVM.

Myślę, że nierozsądne jest oczekiwanie, że EL5 będzie działać tak samo jak EL6 , biorąc pod uwagę różne generowanie jądra, kompilowane ustawienia domyślne, harmonogramy, pakiety itp.

Co bym teraz zrobił?

• Zbadałbym parametry mkfs.xfs i jak budujesz systemy. Czy korzystasz z partycjonowania XFS podczas instalacji czy tworzysz partycje po fakcie? Tworzę system plików XFS po instalacji głównego systemu operacyjnego, ponieważ mam większą elastyczność w podanych parametrach.

• Moje parametry tworzenia mkfs.xfs są proste: mkfs.xfs -f -d agcount=32 -l size=128m,version=2 /dev/sdb1na przykład.

• Moje opcje montowania to: noatime,logbufs=8,logbsize=256k,nobarrierPozwoliłbym, aby dynamiczna prealokacja XFS działała natywnie i nie ograniczała jej tak, jak tutaj. Moja wydajność poprawiła się z tym.

• Więc nie używam LVM . Zwłaszcza na sprzętowej macierzy RAID ... Zwłaszcza na kontrolerach HP Smart Array, w których niektóre funkcje podobne do LVM są wbudowane w urządzenie. Jednak za pomocą LVM nie masz dostępu do fdisktworzenia partycji raw. Jedną rzeczą, która zmieniła się z EL5 na EL6, jest wyrównanie partycji w instalatorze i zmiana na fdisk, aby ustawić sektor początkowy na granicy cylindra.

• Upewnij się, że korzystasz z kontrolerów i dysków HP Smart Array na bieżącym poziomie wersji. W tym momencie sensowne jest zaktualizowanie całego serwera do aktualnego pakietu serwisowego HP dla wersji oprogramowania ProLiant . To bootowalna płyta DVD, która uaktualni wszystkie wykryte komponenty w systemie.

• Sprawdziłbym ustawienia kontrolera RAID. Wklej wyjściowy hpacucli ctrl all show config detail. To moje. Chcesz, aby stosunek pamięci podręcznej był ukierunkowany na zapisy i odczyty. 75:25 to norma. Domyślny rozmiar paska 256 K powinien być odpowiedni dla tej aplikacji.

• Potencjalnie spróbowałbym tego bez LVM.

• Jakie są twoje sysctl.confparametry?

Mieliśmy podobny problem i stwierdziliśmy, że jest to spowodowane zmianą wersji dziennika XFS. Dzienniki wersji 2 honorują zestaw szerokości pasków używany w mkfs.xfs. Jeśli wykonujesz dużo fsync, twoja karta rajdowa nie może już sfałszować tych logów. Możesz to przetestować, formatując partycję bez żadnego ustawienia swidth (nie robi to różnicy w przypadku RAID 1 + 0). Możesz to sprawdzić za pomocą blktrace / seekwatcher, aby sprawdzić, czy wymaga to dużej aktualizacji dziennika.