Cur mea NVMe tardius SSD est?

In hoc articulo videbimus aliquas de nuances I/O subsystem et effectum incidamus.

Ante aliquot hebdomades ante quaesitum est cur NVMe in uno servo tardius esset quam SATA in altero. Intuiti speciem servo et intellexi hanc quaestionem captiosam fuisse: NVMe erat ex segmento usoris, et SSD e segmento servo erat.

Patet, non aequum est res ex diversis segmentis in diversis ambitibus comparare, sed hoc technicum responsum non est. Studeamus fundamenta, experimenta perducamus et ad quaestionem propositam respondeamus.

Quid est fsync et ubi usus est?

Accelerare laborem cum agitationibus, notitia quiddam est buffered, id est, in volatili memoria repositum, donec opportunitas opportuna se offert ad contenta obiectionis ad salvandum. Criteria pro "occasione" determinantur per systema operantem et characteres coegi. In casu alicuius potentiae deficiendi, omnia notitia in quiddam amittentur.

Plures operae sunt in quibus certo debes esse mutationes tabellae scribendae ad clavum et non ad medium quiddam. Haec certitudo obtineri potest utendo fsync ratione vocationis obsequentis POSIX. Vocans fsync cogit scribere a quiddam ad coegi.

Effectum quiddam demonstremus exemplo artificiali in forma brevi programmatis in 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;
}

Commentaria bene explicant ordinem actionum in programmatis. Textus "Responsio ad quaestionem principalem vitae, Universae et omnia" ab operante systemate opponetur, et si servo reset puga premendo per "calculationes", tabella vacua erit. In exemplo nostro, text damnum fluit non est, ergo fsync opus non est. Databases hanc spem non communicant.

Database programmata implicata sunt quae simul cum multis fasciculis laborant, ideo volunt fideles esse notitias quas scribunt in activitate servabuntur, quia constantia notitiarum intra datorum hoc pendet. Database ordinantur ad res omnes peractas recordandas et ad virtutem aliquando amittendam parati sint. Haec agendi ratio usum fsync assidue in magna quantitate requirit.

Quid facit frequens usus fsync?

Durante normali I/O, ratio operativa communicationem cum disco optimize nititur, quia externae agentes tardiores sunt in hierarchia memoria. Ideo ratio operativa quam plurimum in uno accessu ad coegi scribere conatur.

Demonstremus ictum usus fsync cum specifico exemplo. Sequentes SSDs sicut test habemus agitet:

Intel® DC SSD S4500 480 GB, connexum per SATA 3.2, 6 Gbit/s;
Samsung 970 EVO Plus 500GB, connexum per Plu 3.0 x4, ~31 Gbit/s.

Experimenta in systemate operativo Intel® Xeon® W-2255 peraguntur. Ubuntu Die XX mensis Aprilis. Sysbench 1.0.18 ad probationem discorum adhibitum est. Partitio singularis, formata ut ext4, in disco creata est. Praeparatio ad probationem creationem fasciculorum 100 GB complectitur:

sysbench --test=fileio --file-total-size=100G prepare

Cursus probat:

# Без 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 run

Proventus testium sistuntur in schemate.

test
Intel® S4500
Samsung 970 EVO+

Legendum sine fsync, MiB/s
5734.89
9028.86

Memoria sine fsync, MiB/s
3823.26
6019.24

Reading with fsync, MiB/s
37.76
3.27

Recordatio cum fsync, MiB/s
25.17
2.18

Facile perspicitur NVMe ex segmento clientis confidenter in plumbo esse, cum ipsa ratio operativa decernit cum orbes laborare, et amittere cum fsync adhibetur. Hic movet duas quaestiones:

Cur celeritas lectionis in test sine fsync ad latitudinem corporis canalis excedit?
Cur portio serviens SSD melius est cum numerosis petitionibus fsync tractandis?

Responsio primae quaestionis simplex est: sysbench generat scaphas cyphras repletas. Ita probatio per 100 gigabytarum cyphrarum peracta est. Cum notitia valde uniformis et praedictio est, variae OS optimizationes exoriri et signanter exsecutionem accelerare.

Si omnia sysbench eventa interroges, fio uti potes.

# Без 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/sdb

test
Intel® S4500
Samsung 970 EVO+

Legendum sine fsync, MiB/s
45.5
178

Memoria sine fsync, MiB/s
30.4
119

Reading with fsync, MiB/s
32.6
20.9

Recordatio cum fsync, MiB/s
21.7
13.9

Proclivitas ad NVMe degradandi cum usura fsync clare apparet. Ad secundam quaestionem respondendo procedere potes.

Optimization vel harundineo

Antea diximus datam esse in quiddam repositum, sed non definivimus quod unum, quia hoc non erat momenti. Etiam nunc non intromittemus ambages systematum operandi et duo genera genera buffers illustrabimus:

Program;
odio.

Software quiddam refertur ad buffers qui in systemate operante existunt, et quiddam ferramentum ad memoriam volatilis orbis moderatoris refertur. Systema fsync vocationis mandatum mittit ut notitias scribendas ex opificiis ad principale repositione scribas, sed nullum habet modum comprobandi mandatum quod recte fiat.

Cum SSD optimos eventus ostendit, duo suppositiones fieri possunt;

orbis ad simile onus destinatur;
orbis "bluffs" et imperium ignorat.

Improbus mores de repellere possunt notari, si potestatem damnum geris probandi. Hoc potes inspicere cum scripto diskchecker.pl, ille erat creatum 2005 per annos singulos.

Hoc scriptum requirit duas machinas physicas - "servatorem" et "clientem". Cliens scribit parvas notitias orbis sub experimento, vocat fsync, et nuntios mittit servo de iis quae scripta sunt.

# Запускается на сервере
./diskchecker.pl -l [port]

# Запускается на клиенте
./diskchecker.pl -s <server[:port]> create <file> <size_in_MB>

Post currendo scriptionem averte oportet potestatem ad "clientem" et potestatem aliquot momentis non redde. Gravis est hominem ab electricitate temptatum disiungere, et non solum difficilem shutdown facere. Post aliquod tempus, server OS coniungi et onerari potest. Plenique OS vos postulo ut satus illud diskchecker.plsed cum ratione quin.

./diskchecker.pl -s <server[:port]> verify <file>

In fine perscriptio errorum numerum videbis. Si 0 sunt, orbis reprobi transiit. Ad excludendum felicis discri congruentiam, pluries iterari experimentum potest.

Noster S4500 errores non ostendit cum potentia amissa est, id est parata ad labores cum multa fsync vocat.

conclusio,

Cum orbes eligens vel configurationes integras paratas confectas, memineris specialium quaestionum quae solvendae sunt. Primo aspectu, videtur evidens NVMe, id est, SSD cum interfacie, velociorem esse quam "classicum" SATA SSD. Sed, sicut hodie didicimus, in certis condicionibus et quibusdam operibus hoc non potest contingere.

Quomodo tu probas servers componentes cum conductione ab an IaaS provisore?
Te exspectamus in comment.

Source: www.habr.com