Sziasztok!
Van egy CentOS 7 rendszerünk az alábbi paraméterekkel:
Dual Xeon, 128GB ECC, 4x300GB SAS - RAID 5, PERC H700
Az a probléma, hogy 5-10 másodpercenként az iowait legalább 10-20%-os magasságba ugrik, ami érezhető a gépen, ilyenkor még a mappa váltás is megakad mc-ben.
A gépen elég sok java folyamat fut. Van egy ugyanilyen gépünk hasonló mennyiségű java folyamatokkal, azon nyoma sincs a problémának. Rengeteg oldalt felbújtam már az iowait témakörben, még annál is több toolt, scriptet, keresgélést végrehajtottam ( hátha valamelyik java a ludas ) de nem találtam semmi említésreméltót. A keresgélés végeredménye kb az, hogy a jbd2 / kworker okozza a waitet. Merre induljak el a probléma megoldása gyanánt? noatime és nodiratime hozzáadva a mount paraméterekhez.
TASK PID TOTAL READ WRITE DIRTY DEVICES
kworker/u65:1 219 6465 0 6465 0 sda2, sda3
jbd2/sda2-8 731 2474 0 2474 0 sda2
jbd2/sda3-8 482 290 0 290 0 sda3
java 6799 272 0 272 0 sda2
java 19158 203 195 8 0 sda2
java 9921 79 0 79 0 sda2
java 8217 28 0 28 0 sda2
java 24785 20 0 20 0 sda2
java 18124 16 0 16 0 sda2
java 12314 14 0 14 0 sda2
java 25422 10 0 10 0 sda2
java 29144 9 0 9 0 sda2
java 19710 9 0 9 0 sda2
java 19188 8 0 8 0 sda2
java 26795 8 0 8 0 sda2
perl 8230 8 8 0 0 sda3
java 27922 7 0 7 0 sda2
java 28964 7 0 7 0 sda2
java 7415 6 0 6 0 sda2
java 25857 6 0 6 0 sda2
java 25439 6 0 6 0 sda2
wget 8227 6 6 0 0 sda3
java 20208 5 0 5 0 sda2
Ha a code tag miatt rosszul látható akkor itt egy kép is: https://gyazo.com/9781227885e89cbe2f51e5d4bf37eefc
Hozzászólások
mount opciók? fs?
Azt lehet tudni, hogy kb. milyen i/o patternt használnak azok a java-k?
ext4 defaults,usrquota,noatime,nodiratime 1 2
Sajnos nem tudom mit használnak, különböző pluginokkal vannak bővítve.
---
http://www.vultr.com/?ref=6814182
A default ext4 commit interval 5s, valszeg ezt érzed. Azért a jbd2/kworker processzhez akkumulálódik az IO mert az flush-olja az adatot amit az alkalmazás bepiszkít (writeback cache). Ha gondolod, megnézheted hogy mi mocskolja a lapokat, de biztos hogy az alkalmazás lesz az;
Mennyi IOPS van ezeknél a csúcsoknál (iostat)?
Az alkalmazás milyen IO workloadot generál, mit irogat?
Valóban a java processzek hányják tele az egészet.
Lefuttattam egy "iostat -d 1 30" -at, remélem erre gondolsz: http://pastebin.com/9e1S2jhS
---
http://www.vultr.com/?ref=6814182
A RAID5 nem optimális erre a random write-ra, RAID10 kéne.
Ha az alkalmazáson nem tudsz változtatni és nem tudjuk hogy pontosan hogy dolgozik, akkor a következővel próbálkozhatsz:
a.
b.
A data=writeback a commit közben fellépő write lockot mérsékli. A sűrű commit interval azért lehet jó, mert időben jobban eloszlik az írás, a ritkább pedig azért, mert ugyan nagyobb lesz a tüske, de nem 12x akkora ha az írásokat össze lehet vonni (ha pl a workload append sok fájl végére néhány másodpercenként).
Köszönöm, mindenképpen megpróbálom! :)
---
http://www.vultr.com/?ref=6814182
ezzel a komboval (commit=60) egy powerloss eseten azert osszekuszalodhatnak az adatai, nem?
A commit=60 miatt az uccsó 60s adata elveszhet (defaultban ez 5s).
A data=writeback miatt a metadata commit nem triggerel file data flush-t, emiatt a fájlok végéhez írt adat helyén null bájtok lehetnek. Viszont más fájlrendszerek mint pl az XFS by default így működnek, szóval ez is hozzáállás kérdése.
A metaadat semmiképp nem sérülhet.