Ahoj,

tak to by mne docela zajimalo, myslim, ze problem bude nekde jinde :)

Anekdoticky podobne relevantni tvrzeni: ja pozoruju jenom zrychleni, ale nikde na nic zrovna konkretne sqlite nepotrebuju :D zrovna pri tech aktualizacich si toho zrychleni vsimnu nejvic :) Pro drtivou vetsinu bezicich virtualu jeste presun na vpsAdminOS znamenal presun z rotacaku na SSDcka.

Ze bude spatne napsana aplikace mit se ZFS horsi vykon, mne vcelku neprekvapuje taktez - obzvlast, kdyz nepocita s potrebou predchazeni read-modify-write, jak pise Glux - cehoz je sqlite zrovna asi jeden z nejlepsich prikladu, co vubec jde najit :D

Jeste, kdyz se to pri kazdem tom RMW cyklu znova dekomprimuje a komprimuje... konstruktivne muzu poradit akorat udelat tomu sqlite separatni dataset, kteremu se vypne komprese a nastavi se velikost recordsize tak, sedela s page_size u sqlite (v nasem setupu bych videl jako optimalni sweet spot neco mezi 16 a 64 kB). Tohle plati pro jakoukoliv databazoidni aplikaci, od ktere je potreba vykon - hodit na zvlastni dataset, vypnout kompresi a naladit velikost bloku proti sobe spravne.

Jinak ma totiz ZFS dynamickou velikost bloku a pokud se zapise tech dat najednou vic, tak skonci az 128 kB v jednom bloku spolu a tohle se pak bude vzdycky prepisovat cele, i kdyz se v tom zmeni jeden jediny bajt.

Pro obecny use-case dava v nasem pripade smysl mit defaulty takto, benefity checksumu, komprese a dynamicke veikosti bloku hodne prevysuji vyhody storage natuneneho na perfektni latenci pri jednom threadu, ktery dela neoptimalni IO pattern. Zmenit/ovlivnit si to pro svoje data muze kazdy, tyhle properties jsou vystavene pres vpsAdmin. Doporucuju pro takova specificka data udelat separatni dataset, at muze mit ta nastaveni jenom on. Jedine, co nejde u ZFS vypnout, jsou checksumy a copy on write (ale presne kvuli tomu ZFS pouzivame :D)

/snajpa

On 2023-03-03 18:00, Petr Vanek wrote:

Caues. Já mám dost mizerný write od migrace na nový AdminOS nebo jak se to jmenuje. Ale ještě jsem nenašel čas na analýzu.

Objevil jsem to při manuálních aktualizacích.

Petr

Mar 3, 2023 17:53:25 Josef Moudrik j.moudrik@gmail.com:

...

Ahoj,

ladim spatny vykon zapisu do sqlite databaze v produkci (jak je to dobre rozhodnuti nechme na jinou debatu :-D ); zapisy se deji v jednom threadu. Problem je v tom, ze transakce v produkci jsou  10-20krat pomalejsi nez u me na localhostu. Snazim se zjistit cim to je (driv nez budu muset migrovat na jinou db).

Nesetkal jste se nekdo s necim podobnym? Nejake napady?

Zkousel jsem zreplikovat chovani pomoci jednoducheho (serioveho) skriptu s 500 commity: https://pastebin.com/huhhVGw2

vysledky: Journal (write ahead log) x synchronous mode (off nejrychlejsi, normal bezpecnejsi & pomalejsi), cisla jsou mean +- std vteriny.

localhost (ssd v notebooku) journal= sync=OFF    1.051 +- 0.042 journal= sync=NORMAL    2.502 +- 0.237 journal=WAL sync=OFF    1.042 +- 0.022 journal=WAL sync=NORMAL    1.135 +- 0.065

produkcni stroj @ node21.prg journal= sync=OFF    2.778 +- 1.415 journal= sync=NORMAL    2.876 +- 0.627 journal=WAL sync=OFF    2.382 +- 0.404 journal=WAL sync=NORMAL    2.475 +- 0.494

Prijde mi zvlastni maly rozdil mezi jednotlivymi rezimy ve vps & to ze vse je o hodne pomalejsi nez nevirtualizovany stroj, myslite, ze to vznika nejakou vps abstrakci nad ssd?

Nejake napady co s tim?

Diky, JM _______________________________________________ Community-list mailing list -- community-list@lists.vpsfree.cz To unsubscribe send an email to community-list-leave@lists.vpsfree.cz

---

Community-list mailing list -- community-list@lists.vpsfree.cz To unsubscribe send an email to community-list-leave@lists.vpsfree.cz

Diky moc vsem za pomoc.

- zkusit porovnat vuci :memory: jako baseline se ukazalo jako dobry napad, protoze to vysvetluje nejvetsi cast rozdilu, asi protoze - mam na ntb o dost vykonejsi hw? (takt jen o trochu, ale podezrivam, ze 12mb cache vuci 512kb na vps je znat hodne), takze absolutni cisla ve srovnani nedavaji moc smysl - na vps jsem modifikoval dataset - vypnuta komprese, a 32kb block, jak psal @snajpa (doufam, ze staci jen zmenit & restart vps :-D ); zitra zkusim jeste dalsi hodnoty - s timhle nastavenim & sqlite viz nize jsem v podstate jen kousek pod vykonem :memory: (pro memory db jsou rozdily mezi wal/newal/journal/pg skoro zanedbatelne), - v tabulce dole jsou videt rychlosti s ruznou kombinaci nastaveni sqlite, v prvnim sloupecku je srovnani s baseline - :memory: - nejrychlejsi je - neprekvapive - page size alignovana k velikosti toho zfs bloku (&wal & bez sync) - jeste vyzkousim vetsi zfs blok, ale myslim, ze to nebude zasadne jine

Diky vsem za info & pomoc! JM

mereni, od nejrychlejsiho (jiny benchmark nez v prvnim mailu) basediff mean +- std sqlite parametry # muj ntb 0.0000 0.612 +- 0.015 :memory: pg=4096 journal=None sync=OFF 0.0004 0.613 +- 0.018 test.db pg=16384 journal=None sync=OFF 0.0064 0.619 +- 0.030 test.db pg=16384 journal=WAL sync=OFF # vps @node prg21 0.0000 1.418 +- 0.392 :memory: pg=4096 journal=None sync=OFF 0.0761 1.494 +- 0.813 test.db pg=32768 journal=WAL sync=OFF 0.0904 1.509 +- 0.723 test.db pg=65536 journal=WAL sync=OFF 0.1198 1.538 +- 0.696 test.db pg=32768 journal=WAL sync=NORMAL 0.1258 1.544 +- 0.657 test.db pg=65536 journal=WAL sync=NORMAL 0.1410 1.559 +- 0.965 test.db pg=8192 journal=WAL sync=OFF 0.1516 1.570 +- 0.689 test.db pg=16384 journal=WAL sync=OFF 0.1600 1.578 +- 0.710 test.db pg=16384 journal=WAL sync=NORMAL 0.1836 1.602 +- 0.877 test.db pg=8192 journal=WAL sync=NORMAL 0.2002 1.618 +- 0.776 test.db pg=4096 journal=WAL sync=OFF 0.2501 1.668 +- 1.023 test.db pg=4096 journal=WAL sync=NORMAL 0.2721 1.690 +- 1.248 test.db pg=4096 journal=None sync=OFF 0.3096 1.728 +- 0.874 test.db pg=16384 journal=None sync=OFF 0.3118 1.730 +- 0.972 test.db pg=32768 journal=None sync=OFF 0.3124 1.731 +- 1.502 test.db pg=8192 journal=None sync=OFF 0.3361 1.754 +- 1.403 test.db pg=65536 journal=None sync=OFF 0.7100 2.128 +- 0.992 test.db pg=4096 journal=None sync=NORMAL 0.7371 2.155 +- 0.870 test.db pg=16384 journal=None sync=NORMAL 0.7811 2.199 +- 1.209 test.db pg=8192 journal=None sync=NORMAL 0.8101 2.228 +- 0.805 test.db pg=32768 journal=None sync=NORMAL 0.8395 2.258 +- 1.187 test.db pg=65536 journal=None sync=NORMAL

On Fri, 3 Mar 2023 at 18:44, Pavel Snajdr snajpa@snajpa.net wrote:

Aha, vlastne, kdyz nad tim premyslim, jeste nam zbyl node15 jako relikt s rotacnimi disky, to prijde poresit v nejblizsi dobe... jestli je nejaka z tech zminenych VPS tam, tak to bude zrejme o to vetsi bolest... snazili jsme se tam davat jenom ty veci, co z naseho pohledu potrebujou trochu karantenu kvuli moznemu crashi hosta, pripadne veci, co disk IO moc nepotrebuji...

Kdyztak se muzeme na podpore domluvit na presunu, to urcite neni problem :)

/snajpa

On 2023-03-03 18:38, Pavel Snajdr wrote:

...

Ahoj,

tak to by mne docela zajimalo, myslim, ze problem bude nekde jinde :)

Anekdoticky podobne relevantni tvrzeni: ja pozoruju jenom zrychleni, ale nikde na nic zrovna konkretne sqlite nepotrebuju :D zrovna pri tech aktualizacich si toho zrychleni vsimnu nejvic :) Pro drtivou vetsinu bezicich virtualu jeste presun na vpsAdminOS znamenal presun z rotacaku na SSDcka.

Ze bude spatne napsana aplikace mit se ZFS horsi vykon, mne vcelku neprekvapuje taktez - obzvlast, kdyz nepocita s potrebou predchazeni read-modify-write, jak pise Glux - cehoz je sqlite zrovna asi jeden z nejlepsich prikladu, co vubec jde najit :D

Jeste, kdyz se to pri kazdem tom RMW cyklu znova dekomprimuje a komprimuje... konstruktivne muzu poradit akorat udelat tomu sqlite separatni dataset, kteremu se vypne komprese a nastavi se velikost recordsize tak, sedela s page_size u sqlite (v nasem setupu bych videl jako optimalni sweet spot neco mezi 16 a 64 kB). Tohle plati pro jakoukoliv databazoidni aplikaci, od ktere je potreba vykon - hodit na zvlastni dataset, vypnout kompresi a naladit velikost bloku proti sobe spravne.

Jinak ma totiz ZFS dynamickou velikost bloku a pokud se zapise tech dat najednou vic, tak skonci az 128 kB v jednom bloku spolu a tohle se pak bude vzdycky prepisovat cele, i kdyz se v tom zmeni jeden jediny bajt.

Pro obecny use-case dava v nasem pripade smysl mit defaulty takto, benefity checksumu, komprese a dynamicke veikosti bloku hodne prevysuji vyhody storage natuneneho na perfektni latenci pri jednom threadu, ktery dela neoptimalni IO pattern. Zmenit/ovlivnit si to pro svoje data muze kazdy, tyhle properties jsou vystavene pres vpsAdmin. Doporucuju pro takova specificka data udelat separatni dataset, at muze mit ta nastaveni jenom on. Jedine, co nejde u ZFS vypnout, jsou checksumy a copy on write (ale presne kvuli tomu ZFS pouzivame :D)

/snajpa

On 2023-03-03 18:00, Petr Vanek wrote:

...

Caues. Já mám dost mizerný write od migrace na nový AdminOS nebo jak se to jmenuje. Ale ještě jsem nenašel čas na analýzu.

Objevil jsem to při manuálních aktualizacích.

Petr

Mar 3, 2023 17:53:25 Josef Moudrik j.moudrik@gmail.com:

...

Ahoj,

ladim spatny vykon zapisu do sqlite databaze v produkci (jak je to dobre rozhodnuti nechme na jinou debatu :-D ); zapisy se deji v jednom threadu. Problem je v tom, ze transakce v produkci jsou 10-20krat pomalejsi nez u me na localhostu. Snazim se zjistit cim to je (driv nez budu muset migrovat na jinou db).

Nesetkal jste se nekdo s necim podobnym? Nejake napady?

Zkousel jsem zreplikovat chovani pomoci jednoducheho (serioveho) skriptu s 500 commity: https://pastebin.com/huhhVGw2

vysledky: Journal (write ahead log) x synchronous mode (off nejrychlejsi, normal bezpecnejsi & pomalejsi), cisla jsou mean +- std vteriny.

localhost (ssd v notebooku) journal= sync=OFF 1.051 +- 0.042 journal= sync=NORMAL 2.502 +- 0.237 journal=WAL sync=OFF 1.042 +- 0.022 journal=WAL sync=NORMAL 1.135 +- 0.065

produkcni stroj @ node21.prg journal= sync=OFF 2.778 +- 1.415 journal= sync=NORMAL 2.876 +- 0.627 journal=WAL sync=OFF 2.382 +- 0.404 journal=WAL sync=NORMAL 2.475 +- 0.494

Prijde mi zvlastni maly rozdil mezi jednotlivymi rezimy ve vps & to ze vse je o hodne pomalejsi nez nevirtualizovany stroj, myslite, ze to vznika nejakou vps abstrakci nad ssd?

Nejake napady co s tim?

Diky, JM _______________________________________________ Community-list mailing list -- community-list@lists.vpsfree.cz To unsubscribe send an email to community-list-leave@lists.vpsfree.cz

---

Community-list mailing list -- community-list@lists.vpsfree.cz To unsubscribe send an email to community-list-leave@lists.vpsfree.cz

---

Community-list mailing list -- community-list@lists.vpsfree.cz To unsubscribe send an email to community-list-leave@lists.vpsfree.cz