🥇Kernel-Astellung Linux fir GlusterFS

D'Iwwersetzung vum Artikel gouf um Virowend vum Start vum Cours virbereet Administrateur LinuxProfessionell».

Vun Zäit zu Zäit stelle sech hei an do Froen iwwer dem Gluster seng Empfehlungen betreffend Kernelpersonaliséierung an ob et néideg ass.

Dëse Besoin trëtt selten op. Ënner de meeschte Workloads funktionéiert de Kär ganz gutt. Et gëtt awer en Nodeel. Historesch gesinn, de Kär Linux verbraucht fräiwëlleg vill Späicherplatz, wann d'Méiglechkeet kritt gëtt, dorënner och fir Caching als Haaptwee fir d'Performance ze verbesseren.

Am meeschte Fäll funktionnéiert dëst super, awer ënner schwéierer Belaaschtung kann et Problemer verursaachen.

Mir hunn extensiv Erfahrung mat Systemer ze schaffen déi vill Erënnerung verbrauchen, wéi CAD, EDA an dergläiche, déi ugefaang hunn ënner héijer Belaaschtung ze luesen. An heiansdo hu mer zu Gluster Problemer gestouss. No virsiichteg Iwwerwachung vun der benotzt Erënnerung an Disk Waardezäit fir méi wéi een Dag, hu mir Disk Iwwerlaascht, enorm iowait, Kernel Feeler (Kernel Oops), Afréiere, etc.

Dësen Artikel ass d'Resultat vu ville Parametertuning Experimenter a verschiddene Situatiounen. Dank dëse Parameteren ass net nëmmen d'Reaktiounsfäegkeet allgemeng verbessert, awer och d'Operatioun vum Cluster war wesentlech stabiliséiert.

Wann et drëm geet Erënnerung ze konfiguréieren, ass déi éischt Plaz fir ze kucken de virtuelle Memory-Subsystem (VM), deen eng grouss Zuel vun Optiounen huet, déi Iech duerchernee kënnen.

vm.swappiness

Parameter vm.swappiness bestëmmt wéi vill de Kärel benotzt Swap am Verglach zum RAM. Et ass och am Quellcode definéiert als "Tendenz fir kartéiert Erënnerung ze klauen." En héije Swappiness Wäert bedeit datt de Kernel méi ufälleg ass fir kartéiert Säiten auszetauschen. E nidderegen Swappinesswäert bedeit de Géigendeel: de Kärel wäert manner Säiten aus der Erënnerung tauschen. An anere Wierder, wat méi héich ass de Wäert vm.swappiness, wat méi de System Swap benotzt.

Extensiv Notzung vum Tauscht ass onerwënscht, well enorm Blöcke vun Date gelueden an an de RAM entluet ginn. Vill Leit plädéieren datt de Swapinesswäert héich sollt sinn, awer a menger Erfahrung, wann et op "0" gesat gëtt, gëtt eng besser Leeschtung.

Dir kënnt méi hei liesen - lwn.net/Articles/100978

Awer erëm, dës Astellunge solle mat Vorsicht benotzt ginn an nëmmen nodeems Dir déi spezifesch Applikatioun getest huet. Fir héich gelueden Streaming Uwendungen, soll dëse Parameter op "0" gesat ginn. Wann op "0" geännert gëtt, verbessert d'Systemreaktiounsfäegkeet.

vm.vfs_cache_pressure

Dës Astellung kontrolléiert d'Erënnerung, déi vum Kernel verbraucht gëtt fir Verzeechnesobjekter an Inoden (Dentry an Inode) ze cachen.

Mat dem Standardwäert vun 100 wäert de Kernel probéieren d'Zänn an d'Inode-Cache op eng fair Manéier op de Pagecache an Swapcache ze befreien. Ofsenkung vun vfs_cache_pressure verursaacht datt de Kärel Zänn an Inode Cache bewahrt. Wann de Wäert "0" ass, wäert de Kär ni den Zänn an den Inode-Cache spülen wéinst dem Gedächtnisdrock, an dëst kann einfach zu engem Out-of-Memory Feeler féieren. D'Erhéijung vun vfs_cache_pressure iwwer 100 verursaacht datt de Kernel Prioritéit fir Zänn an Inode Pageouts gëtt.

Wann Dir GlusterFS benotzt, kënne vill Benotzer mat groussen Quantitéiten un Daten a vill kleng Dateien einfach e wesentleche Betrag u RAM um Server benotzen wéinst Inode / Dentry Caching, wat zu enger schlechter Leeschtung féiere kann well de Kernel Datestrukturen op engem System muss handhaben mat 40 GB Erënnerung. Dëse Parameter op méi wéi 100 ze setzen huet vill Benotzer gehollef e méi faire Caching a verbesserte Kärreaktiounsfäegkeet z'erreechen.

vm.dirty_background_ratio an vm.dirty_ratio

Éischte Parameter (vm.dirty_background_ratio) bestëmmt de Prozentsaz vun der Erënnerung mat dreckeg Säiten, wann et erreecht gëtt, ass et noutwendeg fir d'Spullung vun dreckeg Säiten op den Disk ze starten. Bis dëse Prozentsaz erreecht ass, ginn Säiten net op Disk gespullt. A wann de Reset ufänkt, leeft se am Hannergrond ouni Lafen Prozesser ze ënnerbriechen.

Zweete Parameter (vm.dirty_ratio) bestëmmt de Prozentsaz vun der Erënnerung, déi duerch dreckeg Säiten besat ka ginn, ier e gezwongenen Flash ufänkt. Wann dës Schwell erreecht ass, ginn all Prozesser synchron (blockéiert) a kënnen net weider lafen bis d'I/O Operatioun déi se gefrot hunn tatsächlech fäerdeg ass an d'Donnéeën op der Disk sinn. Mat héijer I/O Belaaschtung verursaacht dëst e Problem well et keen Datekaching gëtt an all Prozesser déi I/O maachen sinn blockéiert fir op I/O ze waarden. Dëst resultéiert an enger grousser Zuel vun hängkt Prozesser, héich Laascht, System Onstabilitéit a schlecht Leeschtung.

D'Ofsenkung vun de Wäerter vun dëse Parameteren verursaacht datt d'Donnéeën méi dacks op den Disk gespullt ginn an net am RAM gespäichert ginn. Dëst kann Gedächtnis-schwéier Systemer hëllefen, wou et normal ass 45-90GB Säitcaches op Disk ze spülen, wat zu enger enormer Latenz fir Front-End Uwendungen resultéiert, déi allgemeng Reaktiounsfäegkeet an Interaktivitéit reduzéiert.

"1"> /proc/sys/vm/pagecache

Page Cache ass e Cache deen Daten aus Dateien an ausführbare Programmer späichert, dat heescht, dëst sinn Säiten mat dem aktuellen Inhalt vu Dateien oder Blockapparaten. Dëse Cache gëtt benotzt fir d'Zuel vun den Disk Liesungen ze reduzéieren. E Wäert vun "1" bedeit datt de Cache 1% vum RAM benotzt an et gëtt méi Liesunge vun der Disk wéi vum RAM. Et ass net néideg dës Astellung z'änneren, awer wann Dir paranoid sidd iwwer d'Kontroll vun der Säit Cache, kënnt Dir et benotzen.

"Deadline"> /sys/block/sdc/queue/scheduler

Den I/O-Scheduler ass eng Kernelkomponent. Linux, déi Lies- a Schreifwartschlaangen handhabt. Theoretesch ass et fir e Smart RAID Controller besser "noop" ze benotzen, well Linux De Scheduler weess näischt iwwer déi physikalesch Geometrie vun der Festplack, dofir ass et méi effizient, de Controller, deen d'Geometrie vun der Festplack gutt kennt, d'Ufro sou séier wéi méiglech veraarbechte ze loossen. D'"Deadline" schéngt awer d'Performance ze verbesseren. Méi Informatiounen iwwer Scheduler fannt Dir an der Kernel-Quelldokumentatioun. Linux: linux/Documentation/block/*osched.txt. An ech hunn och eng Erhéijung vum Liesduerchgang während gemëschten Operatiounen observéiert (vill Schreiwen).

"256"> /sys/block/sdc/queue/nr_requests

D'Zuel vun den I/O Ufroen am Puffer ier se un de Scheduler geschéckt ginn. E puer Controller intern Schlaanggréisst (queue_depth) ass méi grouss wéi den I / O Scheduler d'nr_requests, sou datt den I / O Scheduler wéineg Chance huet fir Ufroen korrekt ze prioritéieren an ze fusionéieren. Fir Frist an CFQ Scheduler ass et besser wann nr_requests 2 Mol méi grouss ass wéi déi intern Schlaang vum Controller. Fusioun an nei Ufroen Ufroen hëlleft dem Scheduler méi reaktiounsfäeger ënner schwéierer Belaaschtung.

echo "16"> /proc/sys/vm/page-cluster

De Page-Cluster-Parameter kontrolléiert d'Zuel vun de Säiten, déi gläichzäiteg op den Swap geschriwwe ginn. Am Beispill hei uewen ass de Wäert op "16" gesat fir mat der RAID Sträifgréisst vu 64 KB ze passen. Dëst mécht kee Sënn wann swappiness = 0, mee wann Dir swappiness op 10 oder 20 setzen, dann benotzt dëse Wäert hëlleft Iech wann d'RAID Sträif Gréisst 64 KB ass.

blockdev --setra 4096 /dev/`<`devnumm`>` (-sdb, hdc oder dev_mapper)

D'Standardblock-Apparat Astellunge fir vill RAID Controller resultéieren dacks zu schrecklecher Leeschtung. Déi uewe genannte Optioun bäizefügen konfiguréiert Read-Ahead fir 4096 * 512 Byte Sektoren. Op d'mannst fir Streaming Operatiounen gëtt d'Geschwindegkeet erhéicht andeems den On-Chip Disk Cache iwwer Read-Ahead fëllt wärend der Period déi de Kernel benotzt fir I/O virzebereeden. De Cache kann Daten halen, déi während der nächster Liesung gefrot ginn. Ze vill Virliesung kann zoufälleg I/O fir grouss Dateien ëmbréngen wann et potenziell nëtzlech Disk Zäit benotzt oder Daten ausserhalb vum Cache lued.

Drënner sinn e puer méi Empfehlungen um Dateisystemniveau. Awer si sinn nach net getest ginn. Vergewëssert Iech datt Äre Dateiesystem d'Sträifgréisst an d'Zuel vun den Disken an der Array kennt. Zum Beispill, datt dëst eng raid5-Array ass mat enger Sträifgréisst vu 64K vu sechs Scheiwen (eigentlech fënnef, well eng Scheif fir Paritéit benotzt gëtt). Dës Empfehlungen baséieren op theoreteschen Viraussetzungen a gesammelt aus verschiddene Blogs / Artikele vun RAID Experten.

-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

Fir gréisser Dateien, kënnt Dir berécksiichtegen déi uewe genannte Sträifengréissten ze erhéijen.

AENTWERT! Alles uewen beschriwwen ass extrem subjektiv fir verschidden Aarte vun Uwendungen. Dësen Artikel garantéiert keng Verbesserungen ouni éischt déi jeeweileg Uwendungen vum Benotzer ze testen. Et sollt nëmme benotzt ginn wann et e Besoin ass fir d'allgemeng Systemreaktiounsfäegkeet ze verbesseren oder wann et aktuell Probleemer léist.