A szokásos délelőtti szerversimogatás során azt vettem észre, hogy a szerver lassabban reagál, a válaszidők is lassultak a netdiag szerint:
A Munin grafikonok ugyanezt támasztották alá, a ZFS cache intenzív használata látszott, illetve a bpool írás/olvasás sávszélessége is megugrott, az ehhez pedig CPU ugrások is társultak:
A jelenség oka leszűkült a bpool ZFS pool problémájára, a `zpool status` nem mutatott rendellenességet, a `zfs list` viszont igen:
[root@freebsd:/dpool/jails/v8.1.0/logserver/data/192.168.2.6-2010-12]$ zfs list NAME USED AVAIL REFER MOUNTPOINT bpool 7,61G 203M 22K /bpool bpool/jails 4,93G 203M 22K /bpool/jails bpool/jails/data 3,11G 203M 22K /bpool/jails/data bpool/jails/data/dns 41,5K 203M 41,5K /bpool/jails/v7.1.0/dns/var/named/etc/namedb bpool/jails/data/httpd 519M 203M 519M /bpool/jails/v7.1.0/httpd/data/ bpool/jails/data/mailman 231M 203M 231M /bpool/jails/v7.1.0/mailman/data/ bpool/jails/data/mailscanner 2,17G 203M 2,17G /bpool/jails/v7.1.0/mailscanner/data/ \[...\]
Fogytán a hely, ami a ZFS pool halála tud lenni, a Copy-on-Write miatt hülyére dolgozza magát, amikor írás történik, hiszen a módosított adatoknak helyet kell keresnie. A 2,17G méretű mailscanner adatmennyiség soknak tűnt, elkezdtem keresni az okát a méretnövekedésnek:
total 2207915 -rw------- 1 110 110 5,0M dec 8 10:28 auto-whitelist -rw------- 1 110 110 74B dec 8 10:43 bayes.lock -rw------- 1 110 110 77K dec 8 10:28 bayes_journal -rw------- 1 110 110 10M dec 8 10:43 bayes_seen -rw------- 1 110 110 5,3M dec 8 10:43 bayes_toks -rw------- 1 110 110 128T dec 8 08:50 bayes_toks.expire20494 -rw------- 1 110 110 128T dec 8 07:34 bayes_toks.expire28650 -rw------- 1 110 110 128T dec 8 07:57 bayes_toks.expire35681 -rw------- 1 110 110 128T dec 8 07:13 bayes_toks.expire50364 -rw------- 1 110 110 2,0T dec 8 10:43 bayes_toks.expire59908
Igen, jól látod: 128TBájt méretű fájlok, és éppen egy 2T méretű fájl keletkezik, mintha megőrült volna a SpamAssassin. De hogy keletkezhet ekkora fájl egy összesen 8G méretű pool-ban? Tömörített fájlrendszer:
bpool/jails/data/mailscanner compression gzip-9 local
Leállítottam az adott jail-t, kitöröltem a felesleges fájlokat, majd elindítottam a jail-t, egyelőre megjavult, a hiba okát még nem találtam meg.
5 Comments
Unknown User (zoltan@istvanovszki.hu)
Na ezért nem használok SpamAssassin-t.
Amúgy ebben a ZFS verzióban amit használsz már benne van a deduplikáció?
Auth Gábor AUTHOR
Csinált már neked is ilyet, vagy csak valami ellenszenv.
A ZFS tudja, a pool-t még nem frissítettem.
Unknown User (zoltan@istvanovszki.hu)
Nem csinált, de alapból rühellem a SA-t. Nehezen kezelhető. Lassú. Meg olyan furcsa. Nem szeretem. :))
Hmmm Pedig a dedupra már nagyon kíváncsi vagyok. :) Ha minden igaz most kipróbálok egy igen jó kis vasat 24TB RAW kapacitással. Azon érdekes lenne a deduplikáció, de ha jól láttam az még csak az Solaris Express-ben van és a Solaris 10-ben még nem. Hmmm
Nem merek felrakni éles környezetre ilyet.
Auth Gábor AUTHOR
SpamAssassin Amavisd-vel együtt nagyon kényelmes... nincs akkora levélforgalmam, hogy gond lenne belőle... mi az alternatíva?
Most néztem a FreeBSD-s ZFS tudást, version 15 van még csak, nem tudja a dedupot, szóval nem tudok még erről nyilatkozni... de a pool verziója még 6-os, ezt tudta a 7.0-s FreeBSD, azóta nem csináltam upgrade-et.
"Nem merek felrakni éles környezetre ilyet."
Oralis-t?
Anonymous
Kedvenc blogkommentelod is ezzel szopta be. :)
http://gabucino.be/files/spamassassin-sucks.html
Nem tudom, hogy mi ertelme van ilyen kontent-alapu szoporollert porgetni. :)