Magas disk latency mitől?

Linux-kezdő

Sziasztok,

Adott egy szerverem, aminek kb 1 hónapja a disk latencyje az egekben van közel 100%-on.
Sajnos eddig nem fordítottam rá kellő időt (időhiány), de most már muszáj vele foglalkoznom.
Előtte átlag 30-40%-on volt a munin stat szerint az utilization grafikon.

Kérlek javasoljatok nekem valamit, hogy mivel tudnám kideríteni, hogy mi okozza ezt?
Sejtésem szerint valami process pörgeti nagyon a winyókat, de a load nem vészesen magas (1.5) és top sem mutat számomra használható dolgot.

Köszi!

  • 1985 megtekintés

( bucko | 2017. 02. 19., v – 18:19 )

A disk latency mértékegysége ms.
Fussunk neki mégegyszer!

( seferbt v | 2017. 02. 19., v – 18:39 )

Kevered a fogalmakat, a utilization és a latency két külön dolog. iostat-ot és iotop-ot néznék elsőre, ha nincs otklet, hogy mi hajtja szét a diszket. Ez sok mindentől lehet.

Igen, ezt vágom, hogy más dolog, nyilván rosszul futottam neki a témának, de azért köszi, hogy próbáltok segíteni. :)
Amúgy tegnap és ma pl volt némi hullámzás a terhelésben (épp most nincs 100%-on), de előtte jópár hétig kb 100%-n pörögtek a winyók.
http://i68.tinypic.com/5ug38l.png

Debian szerver, 6 disk RAID 5-ben van.

iostat adat:
Linux 3.16.0-4-amd64 (metisz) 02/19/17 _x86_64_ (8 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
7.64 0.15 2.27 9.40 0.00 80.53

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
cciss/c0d0 151.56 4344.59 1294.92 48267790235 14386387481

Köszi, ahogy elnézem az iotop a legjobb.

A txg_sync nevű process van a legtöbbször az első sorban, és 100%-os IO -t mutat.

Ahogy látom ez a ZFS-nek valami folyamata.
Még egy előző rendszergazdám szoftveres ZFS-t tett a rendszerre, amiről sajnos semmit sem tudok, úgyhogy most nyomozhatok, hogy mi ez és hogy kezeljem a problémát.

Hmm. ZFS. jó cucc, én szeretem, de linux alatt sose használtam. A ZFS egy elég komplex fs, elég sokat "tud", a komplexitása miatt oda kell figyelni pár dologra, mikor összerakod. Mondjuk azt nem vágom, hogy ha egy HP HW RAID kártya van a gépben, akkor miért lett a ZFS, de ez egy másik kérdés.
A kontrollertől is érdemes megkérdezni ezt-azt az eszközök, tömbök állapotáról.
Lehet, hogy a zfs-en belül is kellene performanciát nézni, meg a pool(ok) állapotát lekérdezni, ilyesmi. Első körben egy 

zpool list

lesz a barátod, hogy megtudd milyen pooljaid vannak egyáltalán. Utána le kell kérdezni a pool-ok állapotát 

zpool status -v [poolname]

, hogy nincs-e DEGRADED státuszú. Van a 

zpool iostat

, ami szintén elárul pár dolgot, hogy merre érdemes keresgélni. Illetve még egy 

df -h

is hasznodra lehet. A ZFS - legalábbis FreeBSD-n - komoly performancia vesztést tud produkálni, ha a diszktelítettség 80% főlé megy.
Ha ezekből komolyabb, és egyértelmű hiba nem derül ki (mondjuk döglött diszk, ami cserélni kéne), akkor attól függően, hogy üzletileg mennyire kritikus a rendszer, érdemes lenne elgondolkozni egy ZFS-t ismerő, tapasztalt másik rendszergazda bevonásán. Persze, ha a rendszer elbírja, és téged érdekel a téma, akkor nekiállhatsz magad megoldani a problémát. Utóbbi esetben érdemes ZFS témában Oracle és FreeBSD dokumentációkat olvasni. Az alap dolgokat viszonylag gyorsan össze lehet szedni belőlük.

Köszi a tippeket!

Lefuttattam amiket írtál, úgy tűnik, hogy minden ok.


:~# zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 666G 119G 547G - 42% 17% 1.00x ONLINE -

:~# zpool status -v tank
pool: tank
state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not support
the features. See zpool-features(5) for details.
scan: scrub repaired 0 in 8h32m with 0 errors on Sun Feb 19 15:20:16 2017
config:

NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
c0d0p5 ONLINE 0 0 0
c0d0p7 ONLINE 0 0 0

errors: No known data errors

:~# zpool iostat
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
tank 119G 547G 72 69 4.14M 1.21M

:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/cciss/c0d0p1 1.9G 1.2G 599M 66% /
udev 10M 0 10M 0% /dev
tmpfs 2.4G 249M 2.2G 11% /run
/dev/cciss/c0d0p2 3.2G 2.2G 856M 72% /usr
tmpfs 5.9G 0 5.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 5.9G 0 5.9G 0% /sys/fs/cgroup
tank/home 613G 87G 526G 15% /home
/dev/cciss/c0d0p3 4.5G 2.4G 2.0G 55% /var
tmpfs 1.2G 0 1.2G 0% /run/user/0

Ha nagyon nem boldogulok, akkor az egész rendszert újra fogom rakni egy új szerverre, mert amúgy is érik a vas cseréje.

( E-Medve v | 2017. 02. 19., v – 18:40 )

Nézz egy iowait-et, illetve ha szerver: a RAID-ről mit tudunk?

( szilas | 2017. 02. 19., v – 19:35 )

Na igen. Ismét egy "linux-haladó" kategóriás felvetés.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

( klixnetwork | 2017. 02. 24., p – 14:33 )

hw raid (ráadásul raid-5) + zfs ... ennek mi értelme? egyébként van azon a kártyán bbu illetve cache memória?! esetleg nem valamelyik hdd pusztult meg?!

De vicces. :)
Nyilván nem tudom mindenre a választ és igen, a google nekem sokat segített már, nektek biztosan nem volt még rá szükség.

Amúgy szimplán azért nem válaszoltam, mert kb semmi időm nincs, tele vagyok munkával. Mindenesetre hálásan köszönök minden javaslatot, nem ignorálom, csak időbe telik mire rá tudok szánni 1-2 órát hogy körbejárjam a dolgokat. Peace!

( Dyl4n | 2017. 02. 26., v – 17:24 )

Köszi a tippet, úgy néz ki, hogy a bbu-val van a gond:
smh megírta: Battery Status: Failed, Replace Battery 1

Szerintem nem ez okozza a magas lemezterhelést. Ez csak egy újabb csontváz az örökölt rendszer szekrényében.
Az biztos hogy mire mindent rendberaksz, qrvára fogsz érteni ehhez a rendszerhez. Jó kis tanuló project.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.