Yn dit artikel sille wy sjogge nei guon fan 'e nuânses fan it I / O-subsysteem en har ynfloed op prestaasjes.
In pear wike lyn waard ik konfrontearre mei de fraach wêrom't NVMe op ien server trager wie dan SATA op in oare. Ik seach nei de serverspesifikaasjes en realisearre dat dit in lestige fraach wie: NVMe wie fan it brûkerssegment, en SSD wie fan it serversegment.
Fansels is it net earlik om produkten út ferskate segminten yn ferskate omjouwings te fergelykjen, mar dit is net in folslein technysk antwurd. Litte wy de basis studearje, eksperiminten útfiere en antwurd jaan op 'e stelde fraach.
Wat is fsync en wêr wurdt it brûkt?
Om it wurk mei driuwfearren te fersnellen, wurde gegevens buffered, dat wol sizze, opslein yn flechtich ûnthâld oant in handige kâns him foarkomt om de ynhâld fan 'e buffer op it stasjon te bewarjen. De kritearia foar in "kâns" wurde bepaald troch it bestjoeringssysteem en de skaaimerken fan it stasjon. Yn it gefal fan in stroomûnderbrekking sille alle gegevens yn 'e buffer ferlern gean.
D'r binne in oantal taken wêryn jo der wis fan wêze moatte dat wizigingen yn in bestân wurde skreaun nei it stasjon en net yn in tuskenbuffer. Dizze garânsje kin wurde krigen troch de POSIX-kompatibele fsync-systeemoprop te brûken. Calling fsync twingt in skriuwe út de buffer nei it stasjon.
Litte wy it effekt fan buffers sjen litte mei in keunstmjittich foarbyld yn 'e foarm fan in koart programma yn C.
#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>
int main(void) {
/* Открываем файл answer.txt на запись, если его нет -- создаём */
int fd = open("answer.txt", O_WRONLY | O_CREAT);
/* Записываем первый набор данных */
write(fd, "Answer to the Ultimate Question of Life, The Universe, and Everything: ", 71);
/* Делаем вид, что проводим вычисления в течение 10 секунд */
sleep(10);
/* Записываем результат вычислений */
write(fd, "42n", 3);
return 0;
}De opmerkings ferklearje goed de folchoarder fan aksjes yn it programma. De tekst "it antwurd op 'e wichtichste fraach fan it libben, it universum en al dat" wurdt buffered troch it bestjoeringssysteem, en as jo opnij starte de tsjinner troch te drukken op de Reset knop tidens "berekkeningen", it bestân sil leech wêze. Yn ús foarbyld is tekstferlies gjin probleem, dus fsync is net nedich. Databanken diele dit optimisme net.
Databases binne komplekse programma's dy't tagelyk wurkje mei in protte bestannen, dus se wolle der wis fan wêze dat de gegevens dy't se skriuwe sille wurde opslein op it stasjon, om't de konsistinsje fan 'e gegevens yn' e databank hjirfan hinget. Databanken binne ûntworpen om alle foltôge transaksjes op te nimmen en op elk momint ree te wêzen om macht te ferliezen. Dit gedrach fereasket it gebrûk fan fsync konstant yn grutte hoemannichten.
Wat is it effekt fan faak gebrûk fan fsync?
Under normale I / O besiket it bestjoeringssysteem kommunikaasje mei skiven te optimalisearjen, om't eksterne skiven de stadichste binne yn 'e ûnthâldhierarchy. Dêrom besiket it bestjoeringssysteem safolle mooglik gegevens te skriuwen yn ien tagong ta it stasjon.
Litte wy de ynfloed fan it brûken fan fsync demonstrearje mei in spesifyk foarbyld. Wy hawwe de folgjende SSD's as testdriven:
- Intel® DC SSD S4500 480 GB, ferbûn fia SATA 3.2, 6 Gbit / s;
- Samsung 970 EVO Plus 500GB, ferbûn fia PCIe 3.0 x4, ~31 Gbit / s.
Tests wurde útfierd op in Intel® Xeon® W-2255 mei Ubuntu 20.04. Sysbench 1.0.18 wurdt brûkt om skiven te testen. Ien partition is makke op 'e skiven, opmakke as ext4. Tarieding op de test omfettet it meitsjen fan 100 GB-bestannen:
sysbench --test=fileio --file-total-size=100G prepareRunning tests:
# Без fsync
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=0 run
# С fsync после каждой записи
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=1 runDe testresultaten wurde presintearre yn 'e tabel.
Test
Intel® S4500
Samsung 970 EVO+
Lêzen sûnder fsync, MiB/s
5734.89
9028.86
Opname sûnder fsync, MiB/s
3823.26
6019.24
Lêze mei fsync, MiB/s
37.76
3.27
Opname mei fsync, MiB/s
25.17
2.18
It is maklik om te sjen dat NVMe fan 'e kliïntsegment mei fertrouwen yn' e lieding is as it bestjoeringssysteem sels beslút hoe't jo wurkje mei skiven, en ferliest as fsync wurdt brûkt. Dit ropt twa fragen op:
- Wêrom komt de lêssnelheid yn 'e test sûnder fsync boppe de fysike bânbreedte fan it kanaal?
- Wêrom is in serversegment SSD better by it behanneljen fan grutte oantallen fsync-oanfragen?
It antwurd op 'e earste fraach is ienfâldich: sysbench genereart bestannen fol mei nullen. Sa waard de test útfierd oer 100 gigabytes fan nullen. Sûnt de gegevens binne heul unifoarm en foarsisber, komme ferskate OS-optimisaasjes yn spiel en fersnelle de útfiering signifikant.
As jo alle sysbench-resultaten freegje, kinne jo fio brûke.
# Без fsync
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=0 --filename=/dev/sdb
# С fsync после каждой записи
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=1 --filename=/dev/sdbTest
Intel® S4500
Samsung 970 EVO+
Lêzen sûnder fsync, MiB/s
45.5
178
Opname sûnder fsync, MiB/s
30.4
119
Lêze mei fsync, MiB/s
32.6
20.9
Opname mei fsync, MiB/s
21.7
13.9
De oanstriid foar NVMe-prestaasjes om te degradearjen by it brûken fan fsync is dúdlik sichtber. Jo kinne trochgean mei it beäntwurdzjen fan 'e twadde fraach.
Optimalisaasje of bluff
Earder seine wy dat de gegevens yn in buffer wurde opslein, mar wy hawwe net oanjûn hokker, om't dit net wichtich wie. Sels no sille wy net ferdjipje yn 'e intricacies fan bestjoeringssystemen en sille twa algemiene soarten buffers markearje:
- programma;
- hardware.
De software buffer ferwiist nei de buffers dy't bestean yn it bestjoeringssysteem, en de hardware buffer ferwiist nei it flechtich ûnthâld fan de skiif controller. De fsync-systeemoprop stjoert in kommando nei it stasjon om gegevens fan syn buffer nei de haadopslach te skriuwen, mar hat gjin manier om te kontrolearjen dat it kommando goed wurdt útfierd.
Sûnt de SSD de bêste resultaten toant, kinne twa oannames makke wurde:
- de skiif is ûntwurpen foar in ferlykbere lading;
- de skiif "bluffs" en negearret it kommando.
It ûnearlik gedrach fan 'e stasjon kin wurde opmurken as jo in test foar krêftferlies útfiere. Jo kinne dit kontrolearje mei in skript , hokker wie yn 2005 jier.
Dit skript fereasket twa fysike masines - in "tsjinner" en in "kliïnt". De kliïnt skriuwt in lyts bedrach fan gegevens nei de skiif ûnder test, ropt fsync, en stjoert ynformaasje nei de tsjinner oer wat is skreaun.
# Запускается на сервере
./diskchecker.pl -l [port]
# Запускается на клиенте
./diskchecker.pl -s <server[:port]> create <file> <size_in_MB>Nei it útfieren fan it skript moatte jo de krêft útsette nei de "kliïnt" en de krêft net foar ferskate minuten werombringe. It is wichtich om de persoan dy't wurdt hifke fan elektrisiteit los te meitsjen, en net allinich in hurde shutdown út te fieren. Nei in skoft kin de tsjinner wurde ferbûn en laden yn it OS. Nei it laden fan it OS moatte jo it opnij starte diskchecker.pl, mar mei in argumint ferifiearje.
./diskchecker.pl -s <server[:port]> verify <file>Oan 'e ein fan' e kontrôle sille jo it oantal flaters sjen. As der 0 binne, dan hat de skiif de test trochjûn. Om in lokkich tafal foar de skiif út te sluten, kin it eksperimint ferskate kearen werhelle wurde.
Us S4500 liet gjin flaters sjen doe't macht ferlern gie, wat betsjuttet dat it klear is foar workloads mei in protte fsync-oproppen.
konklúzje
By it kiezen fan skiven of folsleine klearebare konfiguraasjes, moatte jo de spesifikaasjes fan 'e problemen betinke dy't moatte wurde oplost. Op it earste each liket it fanselssprekkend dat NVMe, dat is in SSD mei in PCIe-ynterface, rapper is as de "klassike" SATA SSD. Lykwols, sa't wy hjoed leard hawwe, kin dit yn spesifike omstannichheden en mei bepaalde taken miskien net it gefal wêze.
Hoe testen jo serverkomponinten as jo hiere fan in IaaS-provider?
Wy wachtsje op jo yn 'e kommentaren.
Boarne: www.habr.com