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
mkfs.xfs
imount
opcje. EL6 obsługuje wyrównanie partycji. HPSA byłby używany dla obu typów kontrolerów Smart Array pod EL6, ale EL5 używałby CCISS.Odpowiedzi:
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.el6
irytują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ą:
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: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/sdb1
na przykład.Moje opcje montowania to:
noatime,logbufs=8,logbsize=256k,nobarrier
Pozwolił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
fdisk
tworzenia 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.conf
parametry?źródło
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.
źródło
mkfs.xfs
ciąg poleceń?