Linux incedit ad emendandum PostgreSQL faciendum. Ilya Kosmodemyansky

Transumptum 2015 relationis ab Ilya Kosmodemyansky "Linux tuning emendandi PostgreSQL effectus"

Disclaimer: noto hanc relationem datam esse Novembris 2015 - plus quam 4 anni elapsi sunt et multum temporis praeterierunt. Versio 9.4 in relatione tractata non diutius sustinetur. Praeteritis 4 annis, 5 novae emissiones PostgreSQL dimissae sunt, et 15 versiones nuclei Linux dimissae sunt. Si haec scribes, alio rumore finies. Sed hic consideramus fundamentalem Linux tuning pro PostgreSQL, quod hodieque pertinet.

Meum nomen est Ilya Kosmodemyansky. In PostgreSQL-Consulting laboro. Nunc aliquantulum dicam, quid cum Linux in relatione ad databases in communi et in PostgreSQL in particulari, quia principia satis similia sunt.

Quid ergo dicemus? Si communicas cum PostgreSQL, aliquatenus debes esse admin UNIX. Quid est hoc? Si Oraculum et PostgreSQL comparamus, in Oraculo debes esse 80% DBA database admin et 20% Linux admin.

Apud PostgreSQL est paulo magis complicata. Cum PostgreSQL debes multo melius intelligere quomodo opera Linux. Eodem autem tempore paulo post motivum secundum locum currite, quia nuper omnia satis belle renovata sunt. Ac nova nuclei eximuntur, et nova functionalitas apparet, effectus melioris, etc.

Cur de Linux loquimur? Minime quia apud Petrum colloquium Linux sumus, sed quia in hodiernis condicionibus una rationum operativarum iustissimarum utendi databases in genere et in particulari PostgreSQL est Linux. Quia FreeBSD, proh dolor, in aliqua directione valde mirum est. Et erunt questiones tam cum effectu quam cum aliis multis. Effectus PostgreSQL in Fenestra plerumque gravis exitus separatus est, ex eo quod Windows UniX memoriam communem non habet, cum PostgreSQL ad hoc ligatum est, quia multi-processus ratio est.

Et omnes puto minus interesse in exoticis sicut Solaris, sic abeamus.

Hodierna Linux distributio super 1 syctlos optiones habet, secundum quomodo nucleum aedificas. Simul, si diversas nuces spectemus, aliquid multipliciter accommodare possumus. Tabulae systematis parametri sunt in quo eas conscendant. Si quaestiones habes quomodo incipias: quid efficiat in BIOS, quomodo ferramenta configurare, etc.

Hoc volumen amplissimum est, quod per plures dies disputari potest, et non in uno brevi sermone, sed nunc res magnas intendere, quomodo illos rastros vitare, qui in tuto sunt, ne te bene uti in Linux database tuo, si vis. non corrigere. Eodem tempore magni momenti est quod plures parametri default in uncinis rectis datorum comprehenduntur. Hoc est, per defaltam male vel nullo modo laborabit.

Quid traditum scutorum in Linux sunt? Censeo quoniam omnes cum administratione Linux agimus, nihil maxime opus est exponere quae scuta sint.

Tune potes :

• CPUs.
• Memoria.
• Repono.
• Aliae. Loquemur de hoc in fine pro quaerunt. Etiam, exempli gratia, parametri, sicut industria salvifica, perficiendi in vagus admodum et non iucundissimo modo afficere possunt.

Quae sunt specialia PostgreSQL et datorum generatim? Problema est quod quemlibet nucem vellicare non potes et effectum nostrum insigniter emendasse videas.

Ita sunt tales gadgetes, sed res database complexus est. Penitus cum omnibus facultatibus quas ministrator habet et potius se refert ad plenissimam. Si spectes commendationem hodiernam Oraculi in hospite OS utatur, quasi iocus erit de cosmonauto illo Mongolico - canem pascere et nihil tangere. Datorum facultates omnes demus, ipsum datorum omnia disponet.

In principio, aliquatenus res se habet cum PostgreSQL. Discrimen est quod datorum nondum omnes facultates sibi sumere potest, i.e. alicubi in gradu Linux, quam necesse est omnes te ipsum exponere.

Praecipua notio non est unum scopum eligere et illud incidere, exempli gratia, memoriam, CPU vel aliquid huiusmodi, sed inposuit analysi et perput quam maxime emendare conetur ut onus quod boni programmatores illud creaverunt. pro nobis, etiam usoribus nostris.

Hic imago est, quid sit explicandum. Est quiddam Linux OS et memoria communicatur et sunt quiddam PostgreSQL communes. PostgreSQL, dissimilis Oraculum, directe tantum per quiddam acinum operatur, i.e., ut pagina ex orbe in memoriam suam communicat, per nucleum quiddam et dorsum procedere debet, eadem prorsus condicione.

Disci sub hac ratione vivunt. Hoc ut orbes traxi. Nam sit incursio moderatoris, etc.

Et hoc input-output uno modo vel alio fit per hanc materiam.

PostgreSQL database classicum est. Pagina intus est. Et omnia input et output fiunt utens paginis. In memoriam cum paginis caudices suscitamus. Et si nihil factum est, ea tantum legebamus, paulatim ex hoc cella evanescunt, a communibus buffers et retro in disco demum.

Si alicubi aliquid restituimus, pagina tota sordida designata est. Eas hic caeruleis notavi. Idque significat hanc paginam cum repositione trunco ​​congruere debere. Hoc est, cum eam sordidam fecimus, ingressum in WAL. Et aliquo momento in tempore mirabile, phaenomenon vocatur LAPIS. Et in hac tabula pervenisse nuntiabatur. Idque significat omnes paginas sordidas, quae eo momento in his buffers communes erant, congruere cum disco repositoria per quiddam nuclei usura fsync.

Cur hoc agitur? Si intentione amisimus, res omnes notitias non perdidimus. Memoria assidua, quam omnes de nobis narraverunt, tantum abest in theoria database - haec clara futura est, quam nos quidem contendimus et placet, sed nunc minus XX annis vivunt. Et haec quidem omnia viverra debent.

Negotium autem maximi momenti est ad omnes istos gradus subtiliter modulandi, ut omnia cito vadat et recedat. Memoria communis est basically pagina cache. In PostgreSQL inquisitionem selectam misimus vel aliquid, haec notitia ex disco restituit. Finiunt buffers in communi. Unde ad hoc operandum melius multum debet esse memoria.

Ut haec omnia bene et celeriter operantur, necesse est ut ratio operativa in omnibus gradibus recte conformetur. Et elige libratum ferramentum, quia si habes in aliquo loco disparitatem, tunc multum potes facere memoriam, sed non erit sufficiens velocitas.

Et per singula puncta transeamus.

Ad has paginas citroque commeare, sequentia consequi debes:

• Uno modo, debes efficacius operari cum memoria.
• Secundo, hic transitus, cum paginae a memoria eunt ad orbem, efficacior esse debet.
• Et tertio, oportet quod sint bonae orbis.

Si 512 GB de RAM in servo habes et omnes eius in sata ferreo coegi sine cella desinunt, tota datorum ministrator non solum cucurbitam vertit, sed cucurbita cum instrumento sata. In illud protinus incurris. et nihil te salvam faciet.

Circa primum tria sunt quae difficillime possunt facere vitam.

Earum prima est NUMA. NUMA est res quae ad emendam fit. Secundum quod inposuit, diversae res optimized possunt. Et in nova forma hodierna, non valde prodest applicationibus sicut databases qui intensive pagina utuntur cache buffers communicata.

In nuce. Quomodo scias si quid cum NUMA mali est? Habes quaedam ingratus pulso, subito aliquo CPU cumulatur. Simul, interrogationes in PostgreSQL resolves et vide nihil esse ibi simile. Hae interrogationes non debent esse intensive CPU. Hoc diu capere potes. Facilius est recta commendatione ab initio uti, quam NUMA pro PostgreSQL configurare.

Quid vere agatur? NUMA stands for Memoriae Non-Uniformes. Quis 'punctum? Habesne CPU, iuxta eam loci memoria est. Et haec memoria coniungit memoriam ex aliis CPUs evellere.

Si curris numactl --hardwaretunc habebis tam grandem schedam. Inter cetera campi distantia erunt. Erunt numeri - 10-20 aliquid tale. Hi numeri nihil aliud sunt quam numerus adsultim ad hanc remotam memoriam colligendam et localiter utendam. In principio, idea bona. Hoc accelerat effectum bene sub diversis laboribus.

Nunc finge te unum CPU habere primum memoria locali eius uti conatur, deinde aliam memoriam per interiungo rei evellere conatur. Et hoc CPU totum tuum PostgreSQL paginam cache accipit - quod est, quidam gigabytes. Semper pessimum est, quod in CPU memoria in ipso modulo solet esse. Et omnis memoria quae ministratur per has connexiones vadit. Tarda et tristis evenit. Et processus vestri qui officia hac nodi perpetuo cumulantur. Et accessus temporis huius memoriae est malus, tardus. Haec condicio non vis si hoc pro database uteris.

Ideo rectior optio datorum est pro Linux operante ad nesciendum quid omnino ibi agatur. Ut memoria accesserit ut facit.

Cur est? Videtur quod debeat esse e converso. Hoc propter unam simplicem rationem accidit: multa memoria opus est pro pagina cache-tensa, centena gigabytarum.

Et si haec omnia collocaverimus et notitias nostras ibi condiverimus, tunc quaestus ex usu latibulo signanter maior erit quaestus ex tam insidiosa accessu ad memoriam. Et sic incomparabiliter ad hoc proficiemus, quod efficacius memoriam NUMA adhibebimus.

Duae igitur accessus hic sunt in momento, donec clarum futurum advenit, et ipsum database figurare non potest quem CPUs currit et ubi aliquid ex se trahere debet.

Recta igitur accessio est ut NUMA omnino inactivandiputa cum rebooting. In pluribus, lucrationes tales sunt ordines magnitudinis, ut quaestio de qua melior est, omnino non oriatur.

Est alia optio. Saepius eo utimur quam primo, quia cum clientulus ad nos venit in subsidium, servo reboando multum pro eo est. Negotium habet ibi. Et difficultates experiuntur propter NUMA. Propterea conamur eam in minus incursionis quam reboot ut disable, sed diligenter reprehendo quod debilitatum est. Quia, ut experientia docet, bonum est quod NUMA in parente PostgreSQL processu disable, sed minime necessarium est ut operetur. Nos postulo ut reprimamus et videamus eam vere switched off.

Est bonus stipes per Robertum Haas. Hoc unum e comitibus PostgreSQL est. Aliquam sit amet tincidunt ex, scelerisque iaculis massa. Et si nexus ex hac statione sequeris, varias varias fabulas describunt quomodo NUMA vitam hominibus difficilem fecit. Vide, investigare systema machinula administratoris eorum quae in calculonis configurari debent ut ad bene operandum datorum nostrorum. Hae uncinis scribendae et deprimendae sunt necesse est, quia aliter non valde bona est.

Quaeso notas hoc ad omnes locutiones, quas ego loquar. Sed plerumque databases colliguntur in domino-servo pro modo culpae tolerantiae. Noli oblivisci ut haec servo constituas quia unus dies casus habebis et servum mutabis et dominus fiet.

In casu necessitatis, cum omnia pessima sint, telephonum assidue sonant et bulla tua cum magno baculo currit, tempus cogitandi de reprimendo non habebis. Eventus et funestus admodum esse potest.

Sequitur punctum paginae ingentis. Paginae ingentes difficiles sunt seorsim examinare, nec punctum in facere, quamvis probationes sint quae hoc facere possunt. Google facilia sunt.

Quis 'punctum? Servitorem non valde pretiosam habes cum multum RAMO, exempli gratia, plusquam 30 GB. Ingentibus paginis non uteris. Hoc significat, ut supra caput in memoria usurpationis certo habeas. Et hoc supra caput longe est ab amoenissimis.

Cur est? Quid igitur agitur? Ratio operativa memoriam in frusta disponit. Ita opportunum est, quomodo historice factum est. Et si singulatim ingrediamur, OS inscriptiones virtuales in physicas transferre debent. Et hic processus non est simplicissimus, ergo OS cachet exitum huius operationis in Translatione Lookaside Buffer (TLB).

Cum autem TLB cella sit, omnes difficultates in hoc situ cella oriuntur. Primo, si multum RAM habes et in minimas res partita est, tum hoc quiddam praegrande fit. Et si latibulum magnum est, perscrutando tardius est. Sanum caput est, et ipsum occupat spatium, i.e., RAM aliquo vitio consumitur. Hoc tempore.

Duo - quo plus latibulum in tali re crescit, eo verisimilius est quod misses latibulum habebis. Et efficientia cachectica huius celerius decrescit sicut eius magnitudo augetur. Ergo cum simplici accessu operandi ratio accessit. In Linux diu usus est. FreeBSD non ita pridem apparebat. Sed de Linux loquimur. Hae paginae ingentes sunt.

Et hic notandum est quod ingentes paginae, ut ideae, a communitatibus initio impulsae sunt, quae Oraculum et IBM comprehenderunt, artifices datorum i.e., vehementer existimaverunt hoc tam databases utile fore.

Quonam pacto hoc amici cum PostgreSQL fieri potest ? Uno modo, ingentes paginae in Linux nucleo dandae sunt.

Secundo, oportet per modulum sysctl explicite specificari — quot sunt. Numeri hic sunt ab aliquo antiquo servo. Numerare potes quam multae buffers communes habeas ut ingentes paginae ibi accommodare possint.

Et si totum tuum servulum PostgreSQL dicatum est, bonum principium est vel 25% RAM ad buffers communes collocare, vel 75% si certus es tuum database in hoc 75% certum fore. Satus unus. Et vide, si 256 GB RAMI habebis, ergo habebis 64 GB magnarum buffers. Conputat proxime cum margine aliquo - quaenam haec figura apponatur.

Ante versionem 9.2 (si fallor, ex quo versio 8.2), potuit coniungere PostgreSQL cum ingentibus paginis utentem bibliothecam tertiam partem. Et hoc semper debet fieri. Primum, nucleo opus est ut ingentes paginas recte collocare possit. Secundo ut applicatio quae operatur in eis uti possit. Non modo utendum est. Cum PostgreSQL memoriam in systemate stili 5 collocavit, hoc fieri posse utens libhugetlbfs — hoc plenum bibliothecae nomen est.

In 9.3, PostgreSQL effectus emendavit cum memoria operando et ratio 5 memoriae destinatio methodi relicta est. Omnes valde gavisi sunt, quod alias duas instantias PostgreSQL in una machina currere conaris, et dicit me memoriam non satis communicatam habere. Et dicit quod sysctl corrigi debet. Et talis est sysctl quod adhuc opus est reboot, etc. Fere omnes felix fuit. Sed mmap prouinciis memoria ingentium paginarum usum fregit. Plerique clientes nostri magnis buffers communibus utuntur. Et valde commendamus nos non mutandum ad 9.3, quia supra caput coepit esse in recipis bonam rationem.

Sed communitas huic problemati attendebat et in 9.4 valde bene laboraverunt. Et in 9.4 parameter apparuit in postgresql.conf in quo potes experiri, vel off.

Experiri tutissimum est optio. Cum PostgreSQL incipit, cum memoriam communicat, hanc memoriam ab ingentibus paginis capere conatur. Et si non operatur, ad electionem normalem revertitur. Et si FreeBSD vel Solaris habes, tunc experiri potes, semper tuta est.

Si in, simpliciter non incipit si ex ingentibus paginis eligere non potuit. Hic iam de quis et quid mitior est. Sed si experiri potes, tunc reprehendo te vere habere quod debes illustrari, quia multum errori locus est. In statu haec functionis solum in Linux laborat.

Unius notulae minoris antequam ulterius progrediamur. Paginae ingentes perspicuae non sunt de PostgreSQL sed. Solet uti non potest. Et cum magnae paginae perlucidae pro tali inposuit inposito, cum magna communicatae memoriae pars necessaria est, beneficia tantum cum amplissimis voluminibus veniunt. Si terabytes memoriae habes, tunc hoc oriatur. Si loquimur de pluribus applicationibus quotidianis, cum in machina tua memoria 32 64, 128, 256 GB habebis, consueta paginae ingentis Ok est, et nos simpliciter disable Transparent.

Et quod ultimum de memoria non directe ad fruitut refertur, vere potest vitam perdere. Omnes throughput valde afficientur quod servo perpetuo permutando.

Idque multis modis valde ingratum erit. Et principale problema est quod moderni nuclei paulo aliter se habent a nucleis Linux vetustis. Et hoc satis ingratum est, quia cum de aliquo opere permuto loquimur, intempestivum adventus OOM interfectoris desinit. et OOM-homicida, qui tempestive non pervenit et omisit PostgreSQL, injucundus est. Hoc omnes, hoc est, usque ad ultimum usum cognoscent.

Quid fit? Multum ibi RAM habes, omnia bene operatur. Sed servo propter aliquam causam in permundo dependet et ob hoc retardat. Videtur quod multa sit memoria, sed hoc fiat.

Antea monuimus vm.swappiness ad nihilum constituere, i.e. inactivare RES. Antea, visum est 32 GB of RAM et respondeo buffers communibus quantitatem ingens fuisse. Praecipuum propositum PERMUTATIO est locum habere, si decidat crustam. Nec iam magnopere impletum est. Quid ergo cum hac crusta acturus es? Hoc negotium est ubi non satis liquet quare permuto opus sit, praesertim tantae molis.

Sed in recentioribus, i.e., tertia versionibus nucleis, mores mutavit. Et si RES ad nihilum posueris, i.e. avertas, tunc citius vel serius, etiam si aliqua RAM relictus sit, OOM homicida ad te veniet ad occidendum acerrimum consumerent. Quia considerabit quod in tali inposuit quod superest exigua adhuc habemus et prosiliemus, i.e., non ad processum systematis configere, sed demittere aliquid minus momenti. Haec minus momenti erit intensivus consumptor memoriae communis, nempe postmaster. Et post hoc bonum erit, si turpe non fuerit, restitui.

Nunc ergo defectus, quantum memini, pleraeque distributiones alicubi sunt circa VI, i.e., quo in loco incipias uti permutet secundum quantum memoria superest. Nunc commendamus occasum vm.swappiness=1, quia hoc fere vertit illud, sed non dat idem effectus ac cum OOM-interfectore qui inopinato advenit et totam rem occidit.

Quid suus 'postero? Cum de observantia databases loquimur et sensim ad orbes tendunt, quisque capita sua arripere incipit. Quia verum quod orbis tardum est et memoria tenemus, nota est omnibus ab infantia. Et omnes sciunt quod difficultates orbis database habebunt.

Praecipua PostgreSQL quaestio perficiendi cum spicis checks coniungitur non quia orbis tardus est. Hoc maxime probabile est ex eo quod scientia et latitudo disci non sequatur. Sed non licet diversis locis aequari. PostgreSQL non configuratur, OS non configuratur, ferramentum configuratur et ferramentum non est falsum. Et hoc problema non fit nisi si omnia fiunt prout oportet, i.e., vel nulla est onus, vel occasus et ferramenta bene scribuntur.

Quid est et quid simile? Solent homines qui cum PostgreSQL laborant in hanc rem plus quam semel ingressi sunt. expediam. Ut dixi, PostgreSQL periodice facit puncta ad TUBER paginas sordidas in memoria communi in disco. Si magnum pondus memoriae communicatae habemus, tunc LAPIS intensiva in disco ictum habere incipit, quia has paginas cum fsync volat. In quiddam nuclei advenit et ad orbes fsync usus scriptum est. Et si volumen huius negotii magnum sit, notare possumus ingratum effectum, nempe amplissimum usum orbis.

Hic habeo duas imagines. Nunc dicam quid sit. Haec duo graphi temporis connectuntur. Prima lacinia purus utendo est orbis. Hic fere 90% attingit hoc loco in tempore. Si defectum database cum physicis orbis habes, utendo moderatrix INCURSIO ad 90%, malum hoc nuntium est. Hoc significat paulo plus et 100 perveniet et I/O cessabit.

Si disco aciem habes, fabula paulo diversa est. Qualiter dependet configuratur, qualis est ornatus, etc.

Et in parallela grapha ex visu interna postgres configuratur hic, qui narrat quomodo punctum fiat. Color viridis et hic ostendit quot buffers, hae sordidae paginae, eo momento ad hunc lapidum synchronizationem pervenerunt. Et hoc maximum est, quod hic scire debes. Videmus nos multas paginas hic habere et in aliquo puncto tabulam ferire, id est, scripsimus et scripsisse, hic systema orbis clare valde occupatus. Et nostrum LAPIS valde fortis ictum in orbe habet. Specimen, res magis placet, i.e., minus hic notando habuimus. Idque figere possumus cum uncinis ut sic perseveret. Hoc est, redivivus parvus est, alicubi autem aliquid hic scribimus.

Quid agendum est ut hanc quaestionem superemus? Si IO sub datorum destiterint, hoc significat omnes utentes qui venerunt ad suas petitiones adimplendas exspectant.

Si ex parte Linux spectes, si bene ferramenta cepisti, illud recte configuratum, PostgreSQL regulariter figuratum, ut has checks rarius reddit, eas inter se per tempus diffundit, tunc in parametri Debian defaltam ingrediaris. Ut plurimas distributiones Linux, haec est pictura: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Quid est hoc? Unus daemon rutilans ex nucleo 2.6 apparuit. Pdglush, fretus qui utitur quo, qui in background deponendis paginis sordidis a nucleo quiddam et abiecta est, cum necesse est utcumque paginas sordidas abiicias, cum backgrouind abiecta non adiuvat.

Quando background venit? Cum 10% totius RAM in calculonis servi praesto sint, sordidis paginis in nucleo quiddam occupatum, speciale munus scribe-off in curriculo vocatur. Quid est hoc background? Pro modulo, quot paginas scribendas ratio habet. Et dicamus, N paginas scribit. Et hæc quidem res ad tempus dormit. Et illa iterum venit et nonnulla exemplaria aliquot paginas.

Haec est fabula perquam simplex. Difficultas hic similis est cum piscina, quae in unam fistulam influit, in alteram influit. LAPIS noster advenit et si paucas paginas sordidas abiectas misit, paulatim res tota e nucleo quiddam pgflush pulchre resolvetur.

Si hae sordidae paginae cumulare pergunt, usque ad 20% accumulant, post quam OS prioritas totam rem in disco scribet, quia potentia deficiet et omnia nobis mala erunt. Notitiam hanc amittemus, exempli gratia.

Quid est dolum? Dolum est quod hi parametri in mundo huius temporis sunt 20 et 10% totius RAM quae in machina est, omnino portentosa sunt secundum perputationem cuiuslibet orbis systematis quam habes.

Finge tibi 128 GB of RAM. 12,8 GB ipsius orbis ratio advenit. Et quecumque ibi habes cella, quecumque ibi es ordinata, non diu durabunt.

Ideo commendamus ut hos numeros statim componas secundum possibilitates moderatoris tui incursio. Statim commendationem hic feci pro moderatoris qui habet 512 MB cella.

Omnia simplicissima considerantur. Potes vm.dirty_background in bytes ponere. Et hae occasus duos priores destruunt. Aut proportio est defalta, aut agitantur cum bytes, tunc operabuntur illi cum bytes. Sed quia DBA consultus sum et cum diversis clientibus laboro, stipulas trahere conor et ideo, si in bytes, tunc in bytes. Nemo quidquam fideiussit quod bona admin non plus memoriae servo adderet, eam retraheret, et eadem figura maneret. Hos numeros modo numera, ut omnia inibi cauta cohaereant.

Quid si non refert? Scriptum est quodvis rutilant efficaciter sistitur, sed est figura locutionis. Ratio operativa magnam quaestionem habet - paginas sordidas multum habet, ideo IO ut clientes tui generare efficaciter cessant, i.e. application venit ut sql interrogationem datorum mittat, exspectat. Quodvis input/outputium est infimae prioritatis, quia datorum LAPIS occupatum est. Quae cum perficiet omnino incertum est. Et cum rutilant non-background consecuti, significat omnia vestra IO ab eo occupata esse. Et donec finiat, nihil facietis.

Duo hic principaliora sunt quae extra ambitum huius relationis sunt. Hae occasus debent aequare occasus in postgresql.conf, i.e. checkpoints occasus. Et ratio orbis tui sufficienter configurari debet. Si cella in EXCURSUS habes, pilam habere debet. Incursio populi cum bono cache sine pugna emunt. Si SSDs in INCURSIO habeatis, servientes esse debent, capacitores ibi esse debent. Singula hic maculosa est. Haec pagina meam relationem continet in quo ad disci perficiendum in PostgreSQL configurandum. Sunt haec omnia ibi.

Quid est aliud difficile facere vitam? Haec duo parametri sunt. Nova relative sunt. Defalta, diversis applicationibus comprehendi possunt. Et tam difficilem vitam facere possunt si ad male vertantur.

Duo sunt relative nova. Iam in tertio choros. Haec sched_migration_cost in nanoseconds et scheda autogroup_enabled, quae una per defaltam est.

Et quomodo perdunt vitam tuam? Quid est sched_migration_cost? In Linux, processus ab uno CPU in alterum migrare potest schedula. Et pro PostgreSQL, quod queries exequitur, in aliud CPU migrans omnino lateat. Ex ratio operativa parte, cum fenestras inter openofficium et terminales commutaveris, hoc bonum esse potest, sed database hoc est pessimum. Ideo consilium rationabile est ut migratio_suspendii magno aliquo pretio, saltem aliquot milia nanoseconda poneret.

Quid hoc vult pro schedula? Videbitur etiam in hoc tempore processum calidum adhuc esse. Hoc est, si diuturnum negotium habueris quod diu aliquid egerat, cedula hoc intelliget. Ponet quod usque ad hoc tempus transit, non opus est quoquam migrare. Si simul processus aliquid agit, non quoquam migrabitur, quiete operabitur in CPU quod ei partita est. Consequens est et egregius.

Secundum punctum est autogroup. Est bona idea pro certis laboribus quae modernis databases non referuntur - hoc est processuum coetuum per virtualem terminalem, e quo emittuntur. Hoc ad aliqua officia convenit. In praxi, PostgreSQL systema multi-processus cum preforco qui ex uno termino decurrit. Habes scriptorem clavem, LAPIS, et omnes petitiones clientium tuorum in unum schedularum, per CPU distribuentur. Et ibi concordes exspectant eum esse liberum, ut se mutuo impediat et eum diutius occupatum custodiat. Narratio haec in tali onere omnino supervacanea est et ideo necesse est inverti.

Collegium meum Alexey Lesovsky probavit cum simplici pgbench, ubi migrationem_cost auxit magnitudine et autogroupe avertit. Differentia fere X% in hardware malum. Disceptatio de indice tabellariorum postgresium ubi homines eventus praebet similis mutationis ad celeritatem interrogationis motus L%. Tales fabulae satis multae sunt.

Postremo, de virtute consilii salutaris. Bonum est quod Linux nunc in laptop adhiberi potest. Et pilae bene usus erit. Subito autem evenit ut hoc etiam servo evenire possit.

Praeterea, si ministros ab aliquo hospite emiseris, tunc "bonum" hospites non curant ut meliores effectus habeas. Eorum munus est curare ut ferrum eorum quam maxime efficaciter adhibeatur. Ergo per defaltam possunt laptop potestatem efficere modum salutis in operante.

Si hac materia in servo cum datorum sub gravi onere uteris, tunc optio tua acpi_cpufreq + permormance est. Etiam ondemand magna sit amet volutpat.

Intel_pstate paulo aliter agitator est. Et nunc praeponitur huic, quod posterius est, et melius operatur.

Ac per hoc, Praefectus est tantum effectus. Ondemand, powersave, et omnia alia de te non sunt.

Eventus explicandi analysim PostgreSQL ab pluribus ordinibus magnitudinis differre possunt, si vires viresve sinis, quia propemodum CPU sub tuo datorum modo inaestimabili modo curritur.

Haec items per defaltam includi potest. Diligenter vide an per defaltam verterint. Hoc problema magnum esse potest.

Et in fine, gratias agere volui vobis de nostris PosgreSQL-Consulentibus DBA quadrigis, scilicet Max Boguk et Alexey Lesovsky, qui quotidie in hac re proficere volebam. Et conamur optimum quod possumus nostris clientibus facere ut omnia pro eis operetur. Cum instructionibus aeroplanis simile est. Omnia hie scripta sanguine. Quaelibet harum nucum in aliqua quaestionis processu invenitur. Laetus sum tecum communicare.

quaestiones:

Gratias tibi! Si, exempli gratia, societas pecuniam servare vult et rationem datorum et applicationis in uno servo collocare, vel si societas architecturae microserviae modum sequitur, in quo PostgreSQL in vase decurrit. Quid est dolum? Sysctl totum nucleum globally accidet. De sysctls quodammodo virtualis non audivi ut separatim in vase operantur. Est solum globus et est tantum pars ditionis ibi. Quomodo cum hoc vivere potes? Aut si vis effectus, postgreSQL currere in separato ferramento server et tune illud?

Interrogasti nos de tribus modis. Si non loquimur de servo ferrario quod inungi potest, etc., tunc relaxetur, omnia denique sine his uncinis operabuntur. Si tale onus habebis ut has occasus facere debes, tunc ad ferrariam servo maturius quam ad hos uncinis venies.

Quid est problema? Si haec machina virtualis est, tunc fere plures difficultates habebis, verbi gratia, quod in plerisque machinis virtualis latentia orbis omnino repugnat. Etiamsi orbis throughput bonus est, tunc unus I/O negotium quod medium perputum non valde afficit quod factum est in tempore LAPIS vel in tempore scribendi ad WAL, tunc multum ex hoc patietur datorum. Et hoc videbis antequam in has difficultates incurras.

Si NGINX in eodem servo, idem quoque problema habebis. Pugnabit pro communi memoria. Et quaestiones hic descriptas non habebis.

Sed ex altera parte aliqua ex his parametris adhuc ad te pertinebunt. Exempli gratia, pone dirty_ratio cum sysctl ita ut non ita delirus sit - certe hoc adiuvabit. Uno modo vel alio, commercium habebis cum orbe. Et erit secundum iniquitatem exemplaris. Hoc fere defaltam parametri demonstravi. Et utique melius est eos mutare.

Sed cum NUMA problemata esse possunt. VmWare, exempli gratia, bene NUMA cum fundis prorsus oppositis operatur. Et hic eligendum est tibi servom ferreum vel non ferreum.

I have question related to Amazon AWS. Imagines habent pre-figuratas. Una earum vocatur Amazon RDS. Ulla consuetudo loca operandi ratio?

Occasus ibi sunt, sed diversae sunt occasus. Hic ratio operativam configuramus per modum quo datorum hac re utetur. Sunt autem parametri, qui constituunt quo nunc eamus, ut effingamus. Hoc est, tot opibus indigemus, eas nunc devorabimus. Post hoc, Amazon RDS has facultates constringit, et effectus ibi guttae sunt. Singulae fabulae sunt quomodo homines ad pulmentum cum hac re incipiant. Interdum etiam satis feliciter. Sed hoc nihil ad OS occasus pertinet. Nubes caesim similis est. Haec alia fabula est.

Cur paginae ingentes perspicuae nullum effectum habent cum ingenti TLB comparati?

Noli dare. Quod multipliciter potest exponi. At enim simpliciter illi non dant. Quid est historia PostgreSQL? In startup, magnam partem memoriae communis communicat. Sive sint diaphana sive non, nihil refert. Quod in initio exstent, omnia explicat. Et si multum in memoria est et segmentum communicatum reficere debes, tunc paginae ingentis perspicuae pertinebunt. In PostgreSQL, simpliciter collocatur in ingenti FRUSTUM initio et hoc est, et tunc nihil speciale ibi accidit. Utique potes ea uti, sed facultas est adeundi corruptionem communis_memoriae, cum aliquid re- fert. PostgreSQL hoc nescit.

Source: www.habr.com